The data-control value proposition

This page makes the case for CDC as a data-control layer: the why behind the architecture. It is written for a technical decision-maker weighing whether a control layer between source systems and data consumers earns its place in the landscape. For how the platform delivers this, see the architecture overview, the governance and audit model, and the governed domain models.

The problem: dependencies that outlive the systems they point at

In most enterprise landscapes, data-sharing is point-to-point. An analytics job reads straight from the ERP’s tables; an integration pushes directly into the CRM’s API; an AI application scrapes a warehouse that was itself fed by a dozen bespoke pipelines. Each of these is a direct dependency on the shape and availability of a specific source system.

The result is a landscape that is expensive to change and hard to account for:

Every consumer breaks when a source changes. Upgrading, replacing, or consolidating a source system means finding and fixing every consumer that reached into it, so the systems that should evolve fastest are the ones nobody dares touch.
Governance is scattered and unenforceable. Access rules, masking, ownership, and region restrictions live (if they live at all) inside each pipeline, each report, each integration. There is no single place that can answer “who is allowed to see this data, and who actually did.”
Accountability is retrofitted. When a regulator or an internal audit asks what happened to a piece of data, the answer has to be reconstructed from logs that were never designed to answer it, if they exist.

These are not integration bugs. They are the structural cost of letting consumers depend directly on sources.

The idea: a control layer in between

CDC inserts a governed layer between source systems and consumers. Consumers stop depending on the ERP, the CRM, or the warehouse directly, and instead depend on governed contracts that CDC owns: versioned domain models, exposed through governed boundaries under policy.

This inverts the dependency in a way that is worth stating plainly:

Consumers depend on the control layer, not on the source systems. The source systems can then change without breaking the consumers, because the contract the consumers hold lives in CDC, not in any source.

That single move is what unlocks the rest.

What the layer standardises

The value is not one feature; it is that a set of concerns that were previously scattered become standardised in one place:

Exposure is uniform. Data leaves CDC through a governed egress boundary, not as a raw read of a store, but as a decision. Ownership, sovereignty, masking, and projection all materialise at that boundary, so what a consumer is allowed to see is decided once, consistently, regardless of which consumer or which underlying source is involved. Ingest is its symmetric counterpart: inbound data is shaped, validated, and committed under policy at a matching boundary.
A single view spans a fragmented source landscape. Because governed models carry declared identity, records that the ERP and the PIM key differently merge onto one governed entity. Consumers get one Customer, not one per system.
Governance is embedded in execution, not bolted on. Ownership rules, quality checks, approvals, and access policies are reusable components inside auditable processes, so a control is enforced at runtime, uniformly, rather than re-implemented in each pipeline and hoped for.
Accountability is a property, not a project. Every governed operation yields lineage by construction: what happened, when, at whose request, under which decision, against which model version. The audit trail is designed to answer the regulator’s question, not reconstructed after the fact.

The value, by stakeholder

An evaluator usually has to make the case to more than one audience. The layer pays off differently for each:

For the enterprise architect: the landscape becomes evolvable. Source systems can be modernised, replaced, or consolidated behind stable contracts, so technical debt in one system stops holding the whole estate hostage.
For the data / governance owner: control becomes operational and provable. Classification, ownership, and region rules are declared once and enforced everywhere data moves, and the audit trail demonstrates that they were.
For the security and compliance function: obligations map onto real mechanisms: fail-closed enforcement, tamper-evident audit, attributable principals, and region containment (developed in the governance and security pages).
For the delivery teams building new products: new digital products, AI applications, and integrations build against governed, stable data contracts instead of brittle direct taps into production systems, so they ship faster and break less.

Why a platform, not a project

An organisation could, in principle, hand-build a control layer: a canonical data model here, an access-policy service there, an audit pipeline somewhere else. CDC’s proposition is that these are not independent features but one coherent capability: a process-driven execution engine where the governed contracts, the enforcement boundaries, the identity model, and the audit trail are the same system, designed to reinforce each other. The architecture overview shows how that coherence is achieved; this page is the argument for why it is worth having.

What to take into an evaluation

The core move is dependency inversion: consumers depend on CDC’s governed contracts, not on source systems, so the landscape can evolve without breaking the things built on it.
The layer standardises exposure, identity resolution, governance enforcement, and accountability, concerns that are otherwise scattered and unenforceable.
The value lands across architecture, governance, security, and delivery: it is a platform capability, not a point solution.