Review this integration layer. An enterprise platform of SAP's shape defines a canonical Customer with 140 fields. Sixty source systems map into it and forty consumers read from it. Onboarding a new partner takes six weeks, most of it mapping. What would you remove, what would you change, and what would you keep?

What the canonical model was trying to solve

N×M translation. Sixty producers and forty consumers mapping point to point is 2,400 translations; routing everything through one shared model makes it 100. That arithmetic is correct, it is why the pattern exists, and any critique that ignores it will lose the room.

Why it still costs six weeks per partner

The canonical model is the union of every source's fields, not the intersection of what consumers need. Every new source adds fields, because refusing to add a field means telling a source that its data has no home, and nobody wins that argument. The model grows monotonically and has no mechanism for shrinking. A new partner therefore faces 140 decisions, answering "not applicable" to most of them.

Worse: the semantics do not survive the mapping. "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, which is the failure that makes the 100-translation arithmetic a fiction — the real count is 100 mappings plus 40 sets of per-source special cases.

What I would remove

The requirement that every source map every field. Most canonical models decompose into a genuine core of 10 to 15 fields with one organisation-wide meaning — identity, legal name, country, tax identifier — and a long tail that belongs to one domain each.

What I would change

Move from one model to a governed core plus domain-owned extensions. The core is small, shared and changes rarely. Each domain owns its extension, its schema and its evolution, and a source that has nothing to say about a domain says nothing.

Then move from a model to a contract per consumer: consumers declare the fields they depend on, so a source adding a field affects nobody, and a field can be retired once no contract references it. That is the mechanism the current design lacks entirely — there is no way to remove anything.

What I would keep, even though it looks like the problem

The canonical identity. One customer identifier with a documented resolution process is the highest-value component in the whole layer, and it is the part most likely to be thrown out along with the fat model. Remove it and you have 60 systems that cannot be joined, which is a far more expensive condition than slow onboarding.

How I would argue this in the review

With field-usage data, not with a diagram. Instrument reads at the consumer boundary for a quarter and publish the distribution. In every estate that has done this, a small subset of fields serves the large majority of consumers, and a substantial tail has not been read at all in a year. A field no consumer has read in twelve months is a mapping cost with no reader, and that sentence, with the number attached, ends the discussion.

When the fat canonical model is right, and when not to trim it

When the schema is not yours. A regulated reporting obligation where a supervisor defines the fields and requires all of them leaves nothing to trim, and the six weeks is the cost of the obligation rather than of the design. The mistake is inheriting that shape for data nobody outside the company has ever asked for.