The integration story

This page describes how CDC sits between source systems and data consumers: how data gets in, how consumers get it out, and why the things built on top do not break when the systems underneath change. It is written for an architect judging how CDC would fit an existing landscape of ERP, CRM, line-of-business, and SaaS systems on one side and analytics, integration flows, AI applications, and new digital products on the other. It develops the integration dimension of the architecture overview and the data-control value proposition.

The shape of the problem

A typical landscape has many sources (an ERP, a CRM, a PIM, a handful of line-of-business databases, some SaaS) and many consumers (a BI stack, an integration hub, AI applications, freshly built digital products). Wired directly, that is a mesh: every consumer reaches into every source it needs, each dependency coupled to a specific system’s schema, API, and availability. CDC’s proposition is to replace the mesh with a hub: a governed layer every source feeds and every consumer reads from, so the coupling is to CDC’s stable contracts rather than to each source’s shape.

The rest of this page is the three seams that make that work: how sources connect (plugins), how data crosses in and out under governance (ingest and egress), and how processes tie external systems into flows.

Sources connect through plugins

CDC integrates with heterogeneous systems through plugins: compiled .NET libraries containing typed tasks (units of work such as “read rows from system X”, “validate against a rule set”, “call an external API”). A plugin is where a connector lives: the HTTP client, the database driver, or the SaaS SDK that actually talks to a source system is private to the plugin, and the process that uses it sees only the task’s typed input and output contract.

Three properties make this the integration seam rather than just a code-loading mechanism:

• Plugins are isolated and versioned. Each runs in its own load context and can be updated or removed cleanly. A new version of a plugin is matched to the processes that use it by operation, so upgrading a connector rebinds the referencing processes without re-authoring the flows.
• Configuration and secrets are externalised. A plugin is instantiated as a named configuration profile that carries its endpoints and, through the secret store, its credentials. Because a process refers to that profile by name, the same process definition promotes across environments (dev, test, prod) and picks up the right endpoint and credential in each, with no secret ever living in the process or in configuration files.
• The contract is the boundary. A task exchanges only typed model objects. The engine never sees the source system; it sees a typed operation. Swapping the system behind a connector, or adding a new source, is a plugin concern that does not ripple into the processes, or the consumers, that depend on the governed data.

CDC ships connectors as examples of the pattern: an OData plugin that exposes governed models as a read API, and AI provider plugins (Azure OpenAI, an OpenAI-compatible base, and Anthropic) that connect language models as agent back-ends. Both are ordinary uploadable plugins, the same mechanism a customer uses to add their own connectors.

Data crosses in and out under governance

Connecting a source is only half the story; the value is that data crossing into or out of the platform does so through a governed boundary, not a raw read or write. Both boundaries are modelled the same way, as an inline element on a process, so integration and governance are the same act, not two layers.

Inbound: ingest

Inbound data flows through an ingest boundary. A task reads from a source and its output is committed to the governed store under policy: the record is schema-validated against its model, its access is decided by the governance hook, and, critically for a fragmented landscape, its identity is resolved. CDC maintains a mapping from each source system’s key to a single governed entity, so a customer the ERP knows as 100000-01 and the PIM knows as P-42 merge onto one governed Customer. A first write creates the entity; subsequent writes merge into it. Governed data is kept as an append-only event log, with creations and merges preserved, never overwritten in place, so the history behind current state survives for audit and replay.

The effect for an evaluator: many sources, keyed many ways, resolve to one governed view, the single-entity story that direct point-to-point integration cannot deliver.

Outbound: egress

Outbound data flows through an egress boundary, and egress is a decision, not a read. What a consumer receives is the result of ownership, sovereignty, masking, projection, and policy materialising into exactly the permitted view. A denial is a typed business outcome the surrounding process can branch on, not an error, and the free-text reason is recorded on the audit trail. Reads are bounded and paged, and every governed read is accounted for by an audit decision at its boundary.

Because the projected shape a consumer sees is stable (the governed model’s fields plus system attributes like identity and version) a consumer reads one governed entity regardless of how many source systems fed it, and never sees the per-source schemas at all. That stable projection is the contract consumers depend on.

Processes tie external systems into flows

Beyond the ingest/egress boundaries, CDC’s process model gives external systems several ways to participate in a flow:

• Message events. A process can start on, wait for, or emit a message over the broker, with the message’s shape defined by a published model. This is how an external event drives a process, or a process notifies an external system, without a point-to-point call.
• Webhooks. A process can be started by an inbound HTTP call at a customer-chosen path, authenticated by default (bearer token with required scopes) and “open” only as an explicit, warned choice. A paired HTTP end shapes the response. This is the front door for synchronous external triggers. When the process is set to single instance and one is already running, a webhook or API-operation call is rejected with an RFC 9457 409 carrying the code single_instance_busy, so a synchronous caller fails fast instead of waiting on a queue it cannot drain. Background triggers (timer, message, agent tool) queue instead.
• Timers. A process can start on a schedule, for polling or periodic reconciliation, recorded against a system principal.
• Call activities. A process can invoke another reusable process, composing larger flows from smaller ones.

In each case the triggering identity is captured on the instance, so a process reached through any of these paths still records exactly who (or which machine client, or system) set it going.

AI applications are first-class consumers and producers

AI applications integrate through the same governed boundaries as everything else, which is what keeps them accountable. An agent given a domain-query capability reads through the governed egress boundary: the governance hook decides every access, on behalf of the originating user, never on a standing identity of the agent’s own. An agent given a process capability triggers a BPMN process through the governed trigger path, with no bypass and the originating principal carried through. An agent can also be invoked as a step inside a process. So an AI app is not a special back door into the data; it is a consumer and a producer that crosses the same audited boundaries as a BI tool or an integration flow.

Why this decouples the landscape

Pulling the seams together, the integration story is one of inverted dependencies:

• A process depends on a task’s typed contract, not on a source system’s internals, so the system behind a connector can be replaced or re-platformed by re-pointing a configuration profile, without re-authoring the flow.
• A consumer depends on CDC’s governed contract (a stable projected model and a bounded, audited read) not on a source system’s schema or availability.
• Identity resolution collapses many source keys onto one governed entity, so consolidating or replacing a source does not fracture the entity consumers rely on.
• Every governed movement crosses a boundary that is standardised and audited, so integration does not quietly accumulate ungoverned side channels.

What to take into an evaluation

• CDC replaces a source-to-consumer mesh with a governed hub: sources feed it through isolated, versioned, externally configured plugins; consumers read stable governed contracts.
• Ingest resolves many source keys onto one governed entity and preserves full history; egress is a governed, audited decision, not a raw read.
• Processes bring external systems into flows through messages, webhooks, timers, and sub-flows, always with a captured, attributable principal.
• AI applications are ordinary governed consumers and producers, not a privileged path around the controls.