Integration Change Amplification

Estates are usually described by counting: 34 systems, 210 interfaces. Those numbers are easy to produce and they do not predict anything. The number that predicts is how many other teams have to do work when one system changes, because that is what sets both the cost and the elapsed time of every modification to the estate.

For a system with degree d — d counterparties reading or writing its interface — a schema revision costs roughly d × (read, map, test, release) in engineering, and its elapsed time is set by the slowest counterparty, not the sum. At 12 counterparties and 2-5 days each, that is 24-60 engineer-days coordinated across up to 12 teams and a calendar measured in months, because each of those teams has its own backlog.

Why it matters

This is the quantity that makes an estate feel unchangeable, and it is invisible in every conventional report. Interface count grows slowly and amplification grows with the degree of the busiest system, so an estate can look stable for years while becoming steadily harder to modify.

It also explains the shape of the decision people actually face. The question is never "should we integrate" — it is whether the coupling is pairwise or mediated, and amplification is how you tell the difference in numbers rather than in architecture-diagram aesthetics.

Implementation patterns

• Measure degree per system, from observed traffic rather than from documentation, which is always shorter than reality. Network flow data, API gateway logs, and scheduled-job inventories between them cover most estates.
• Rank by degree, not by count. The intervention list is the top five systems by degree, which is usually a very short list and a very concentrated problem.
• Publish events rather than expose schemas. A consumer that subscribes to "order placed" depends on a contract; a consumer that reads the orders table depends on your internal model, and the difference shows up entirely in this metric.
• Version contracts additively with a deprecation window, so a revision costs counterparties nothing until they choose to move. This reduces amplification without any central machinery.
• Retire before you mediate. Interfaces feeding systems nobody uses — commonly 10-20% of an estate — are the cheapest reduction available, and an interface that is switched off has no amplification at all.
• Track it over time. A rising figure for the busiest system is the leading indicator that the estate is calcifying, years before anyone describes it that way.

Industry example

The best-documented reduction of this metric is The New York Times's 2017 account of replacing a web of point-to-point API and feed integrations with a single ordered log (its "Monolog") holding every published asset, which back-end systems consume from. The structural claim is exactly this metric: publishers write once to the log, consumers read from it, and adding or changing a consumer no longer requires the publisher to do anything. What it cost is equally instructive — an ordered log as the source of truth constrains how consumers are built and requires them to handle replay, so the reduction in amplification was bought with a new set of obligations rather than for free.

Failure scenarios

• The canonical model becomes a union. Every system's view of "customer" is merged until the canonical entity has 200 optional fields and means nothing, so mappings acquire conditional logic and the pairwise coupling returns through the mapping layer. This is the documented failure of a generation of enterprise service bus programmes.
• The hub becomes a team in every critical path. Mediation without ownership of the mappings by the connecting teams turns a technical bottleneck into an organisational one.
• Undocumented consumers. Amplification measured from documentation is understated, so a change lands on counterparties nobody knew existed, during the release.
• Degree concentrated in a system nobody will touch, typically a mainframe or a vendor package, so the metric identifies a problem the organisation cannot act on directly — the correct response there is an anti-corruption layer, which moves the degree onto something changeable.

Trade-offs

Reducing amplification always means putting something in the middle, and the middle has to be owned, operated and versioned. A log or a hub adds a hop, an operational surface and a team; in exchange, a schema revision stops being a twelve-team project.

The honest position is that the trade only pays above a threshold, and the threshold is degree, not size. One system with 15 counterparties in a 12-system estate has the problem. Thirty systems with two interfaces each do not, and mediating them adds cost with nothing to recover.

When not to use it

Do not build mediation for an estate whose busiest system has three counterparties; point-to-point is legible and cheap there, and the hub is one more thing to run. Do not use the metric to justify a platform purchase either: a platform does not write the mappings, and the mappings are the work.

And do not chase the metric to zero. Some coupling is the business: an order system and a fulfilment system are supposed to be tightly related, and paying mediation cost to pretend otherwise buys nothing.

Interview question

Q: You inherit an estate of 34 systems and 210 interfaces and are asked whether to fund an integration platform. What do you measure first, what number would make you say yes, and what would you do instead if the number came back low?

What a strong answer covers: measuring degree per system from observed traffic rather than counting interfaces or quoting n(n-1)/2 on a sparse graph; the amplification arithmetic and the fact that elapsed time is set by the slowest counterparty; a threshold expressed as the degree of the busiest systems rather than estate size; the cheaper interventions first — retiring dead interfaces, publishing events, additive versioning with deprecation windows; the canonical-model union as the named failure mode; and the willingness to recommend not buying anything, with the run-cost estimate that keeps "do nothing" from looking free.

Quick check

Quiz: Why is interface count a poor predictor of how hard an estate is to change? — Because cost and elapsed time scale with the degree of the system being changed, not with the total; 210 interfaces spread evenly across 34 systems is a very different estate from 210 concentrated on four.

Flashcard: What does a schema revision cost in a point-to-point estate? — Roughly d counterparties each reading, mapping, testing and releasing, at 2-5 days each, with elapsed time set by the slowest team rather than by the total effort.