Canonical Data Model

With 60 producers and 40 consumers, point-to-point mapping is 2,400 translations. Route everything through one shared representation and it becomes 100. That arithmetic is correct, and it is the entire case for the pattern.

What the arithmetic omits is what happens to the shared model over time. Every new producer has fields that do not fit, and refusing to add them means telling a source system its data has no home — an argument nobody wins. The model is therefore the union of everything anyone has ever sent, not the intersection of what consumers need, and it has no mechanism for shrinking, because nobody knows who reads a given field.

The second omission is semantic. "Customer status" means one thing in billing and another in support. A single field forces one meaning, so consumers apply per-source correction rules anyway: the translation has been centralised and the interpretation has not, and the true count is 100 mappings plus 40 sets of special cases.

Why it matters

It is the default answer to integration at enterprise scale, and its failure mode is slow and quiet. Nobody notices the model growing. What gets noticed, years later, is that onboarding a partner takes six weeks, most of it spent deciding that 120 of 140 fields are not applicable.

By then the model is load-bearing for dozens of systems and cannot be replaced, only extended — which is the specific reason the pattern deserves a decision rather than a default.

Implementation patterns

• Core plus extensions. A small governed core of 10 to 15 fields with one organisation-wide meaning — identity, legal name, country, tax identifier — and domain-owned extensions with their own schemas and their own evolution.
• Contracts per consumer. Consumers declare the fields they depend on, which gives you the one capability the fat model lacks: the ability to retire a field once no contract references it.
• Instrument reads at the consumer boundary. Publish field-usage counts. A field no consumer has read in 12 months is a mapping cost with no reader, and the number ends arguments that words cannot.
• Keep the canonical identity even if you dismantle the model. One identifier with a documented resolution process is the highest-value part of the layer and the part most likely to be discarded along with the rest.
• Version the core and let extensions move independently, so a domain change does not require enterprise-wide coordination.
• Write down what is deliberately not in the model. Without a stated boundary, growth is the default.

Industry example

The pattern is documented in Hohpe and Woolf's Enterprise Integration Patterns (2003), which introduces the canonical data model alongside the message translator and is explicit that its purpose is to decouple the message format from any one application. Large enterprise platforms of SAP's shape institutionalise it, and the reported experience is consistent: the translation arithmetic holds and the governance of the model becomes the constraint, because the model is jointly owned and monotonically growing.

Failure scenarios

• Monotonic growth to hundreds of fields, of which most are populated by one source and read by none.
• Semantic collapse: one field forced to mean several things, with per-source rules reappearing in every consumer.
• Onboarding cost dominated by mapping decisions that are almost all "not applicable".
• No retirement path, because nobody can establish who reads a field.
• Mapping errors as data errors: a defect in one translation is invisible until a consumer reconciles, and the source of truth is now ambiguous.

Trade-offs

When not to use it

When the producer and consumer counts are small. At five systems, point-to-point is 20 mappings and a canonical model is a governance body with a backlog — the arithmetic that justifies the pattern simply is not there.

And when the semantics genuinely differ between domains, forcing one representation produces a field that is wrong for everyone and corrected downstream by everyone. Share identity and the handful of facts that really do mean one thing; let the rest be translated at the boundary where somebody understands both sides.

The one case where the fat model is right regardless: when the schema is not yours, because a regulator or an industry standard defines it. There, every field is required by someone outside the company, and the onboarding cost is the obligation rather than the design.

Interview question

Q: An integration layer defines a canonical Customer with 140 fields; 60 sources map in, 40 consumers read out, and onboarding a partner takes six weeks. What do you change, what do you keep, and what evidence do you bring?

What a strong answer covers: conceding the N×M arithmetic that justified the model; explaining monotonic growth and the absence of any retirement mechanism; the semantic point that centralised translation does not centralise interpretation; the move to a governed core plus domain extensions and per-consumer contracts; keeping the canonical identity at all costs; and bringing field-usage telemetry rather than a diagram to the review.

Quick check

Quiz: Why does a canonical data model grow and never shrink? Because refusing a new source's fields means telling it its data has no home, while retiring a field requires knowing who reads it — and the pattern provides no mechanism for the second.

Flashcard: What replaces a fat canonical model? A small governed core of universally-meaningful fields, domain-owned extensions that evolve independently, and per-consumer contracts declaring dependencies — which is what makes field retirement possible at all.