Integration debt: the bill nobody budgets for
Every system you add creates connections you did not price. The cost is not the connector — it is the coupling.
Enterprise architecture diagrams are drawn as boxes. The budget is written for boxes. The work, and the fragility, live in the lines between them — and almost nobody prices the lines.
This is integration debt: the accumulated cost of every point-to-point connection made under deadline, every field mapped by convention rather than contract, every synchronisation job that runs at two in the morning and is understood by one person.
Why it compounds faster than technical debt
Ordinary technical debt is local. A poorly structured module is unpleasant to work in, but the blast radius stops at its boundary. Integration debt is relational, and relationships multiply. Ten systems can support forty-five distinct pairwise connections. You will not build all of them, but you will build more than you intended, and each one is a coupling that must be honoured by both sides forever.
The compounding shows up as a specific symptom that every enterprise engineering leader recognises: a change that should take a day takes six weeks, because it touches a field that four systems read and two of them belong to teams who have their own release calendar.
What it actually costs
- Change latency. Every integration is a veto held by another team over your delivery schedule.
- Incident surface. Most production incidents in mature enterprises originate at a boundary, not inside a service.
- Testing burden that grows super-linearly, because meaningful tests require the other systems to exist in a known state.
- Vendor lock that was never negotiated. The switching cost of a platform is mostly the cost of its integrations, and that cost is invisible at signature.
- Knowledge concentration. Integrations are documented least and understood by fewest, which makes them the most dangerous thing on your estate to lose a person over.
The disciplines that hold
Nothing here is exotic. Publish contracts rather than schemas, and version them. Prefer events over synchronous calls where the consumer does not need an answer immediately, because that converts a hard dependency into a soft one. Route through a deliberate integration layer rather than allowing systems to reach into each other, so that replacing a system is a conversation with one component instead of nine.
Above all, put integration work in the estimate. A project plan that budgets for building a system and treats connecting it as a footnote is not a plan; it is an opening bid. The connecting is the project.
Let's build the system your business will run on next.
Tell us where it hurts. We'll bring the architects, engineers, and delivery model to fix it — and scale it.