An estate has 140 point-to-point integrations between 20 systems. What is the problem and what would you do?

What is being tested

Whether you recognise the combinatorial topology problem and can propose something better than a canonical model.

The problem

Integration count grows with the product of systems rather than their sum. Each of those 140 has its own authentication, error handling, retry logic, data mapping and — theoretically — an owner.

The consequences compound:

• The estate cannot change. Nobody can modify a system because nobody can enumerate what depends on it. Every change becomes an archaeology exercise.
• Nobody owns most of them. Built for a project, the project ended, the integration remains.
• Failure diagnosis is impossible. Data is wrong somewhere and the path it took is unclear.
• Adding the 21^st system means potentially several more integrations, and the growth is superlinear.

What not to do

A single canonical data model for the enterprise. It is the intuitive response and it is the classic enterprise architecture failure:

• The same word means different things in different contexts — "customer" in sales, fulfilment and finance are genuinely different concepts sharing a name.
• The model must serve everyone, so it serves nobody: sixty fields of which each consumer uses eight.
• Nobody can change it without coordinating with every consumer, so it freezes within a year.

What to do

1. Inventory and attribute. Which integrations exist, what data flows, who owns each, and — from traffic data — which are actually used. Expect a meaningful proportion to be dead.

2. Retire the dead ones. The cheapest win, and it builds credibility for the rest.

3. Introduce an event backbone for the high-fan-out data. Where several systems need the same data, publishing facts once inverts the dependency: producers do not know their consumers, and a new consumer requires no change to any producer. This is the property that actually matters at enterprise scale.

4. Keep translation at the boundaries. Each context maintains its own model; mapping happens where they meet. More mapping code, and each context evolves independently — which is the whole point.

5. Standardise the mechanics, not the model. Transport, authentication, error semantics, retry behaviour, schema evolution rules and observability genuinely benefit from consistency and constrain nobody's domain model.

6. Require an owner for every new integration, with a review date.

The realistic expectation

This is a multi-year direction, not a project. Sequence it so each step delivers value and is safe to stop after — retire dead integrations, move the highest-fan-out data to events, then work down. A programme whose value arrives at the end will be cancelled before it gets there.

What a strong answer adds

Naming the failure mode of the hub approach: an integration platform that accumulates business logic becomes a third system nobody owns, and a single point of failure for the entire estate. Standardise the mechanics there; keep the meaning in the systems that own it.