An estate has 34 systems, 210 running interfaces, and a proposal to introduce a canonical hub. Before deciding, estimate the annual engineering cost of the current integration surface and how it changes when one system's schema is revised. Which number should decide the proposal?

The assumptions, stated

• Interfaces are not free at rest. Each one needs credential rotation, certificate renewal, monitoring, occasional failure investigation and a compatibility check when either end changes. Assume 3-8 engineer-days per interface per year for a stable one; more for anything with a batch window or a file transfer.
• Not every pair connects. 34 systems could support 561 pairs; the estate has 210 interfaces, so the graph is sparse. Average degree is about 12 interfaces per system, and the distribution is skewed — a few hub-like systems carry most of them.
• Schema revisions are the dominant change event, not new integrations.

The arithmetic

Run cost: 210 interfaces × 5 engineer-days is roughly 1,050 engineer-days a year, on the order of 4-5 full-time engineers, spread invisibly across teams so no budget line shows it. That number alone usually surprises the sponsor, which is why it is the first thing to produce.

Change amplification: when a system with 12 interfaces revises its schema, 12 counterparties must each read, map, test and release. At 2-5 days per counterparty that is 24-60 engineer-days for one system's change, coordinated across up to 12 teams, and the elapsed time is set by the slowest of them rather than by the sum. A change in the busiest system — say 40 interfaces — becomes a programme.

What a hub changes: each system maps once to the canonical form, so a schema revision costs one mapping update plus regression against consumers of that canonical entity. The theoretical shape moves from a number that grows with degree to a number that grows with one.

Which assumption dominates the error

Whether the canonical model can actually represent the domain. The arithmetic above assumes a mapping exists. In practice the canonical entity becomes the union of every system's view of "customer", accumulating optional fields until it means nothing, and mappings acquire conditional logic that reintroduces the pairwise coupling through the back door. When that happens the hub adds a hop and a team without removing the amplification, which is the documented failure mode of a generation of enterprise service bus programmes.

The second-largest error is the run-cost-per-interface figure. It varies by an order of magnitude between a well-instrumented HTTP API and a nightly SFTP drop with a bespoke fixed-width format. Sample ten real interfaces and measure rather than assuming.

What the number rules in and out

At 210 interfaces and this amplification, doing nothing is not free and should not be presented as the null option — that is the useful output of the estimate.

It does not, on its own, rule in a canonical hub. Two cheaper interventions usually beat it: publishing events rather than exposing schemas, so consumers depend on a stable contract rather than on an internal model, and retiring interfaces, since in most estates a meaningful fraction of interfaces feed systems nobody has used for years. Count those before building anything: an interface that can be switched off costs nothing to map.

When this is the wrong answer

Below roughly 20-30 interfaces the coordination cost is small, the graph is legible, and a hub is pure overhead — one more thing to operate, with a team in the path of every change. The threshold is not the system count, it is the degree of the busiest system. One system with 15 counterparties in an estate of 12 systems has the problem; 30 systems with 2 interfaces each do not.

Common weak answers

• Counting pairs as n(n-1)/2. The formula describes a complete graph. Real estates are sparse, and quoting 561 when the answer is 210 destroys the argument's credibility with the people who know the estate.
• "An integration platform will fix it." Buying a platform does not write the mappings, and the mappings are the work. A platform changes where the code lives, not how much there is.
• Ignoring the retirement option, which is usually the cheapest engineering available and the only one that reduces the surface rather than moving it.