Field Note
Integration debt is operating debt
Integration debt usually gets described with technical nouns: old middleware, point-to-point interfaces, inconsistent payloads, weak monitoring.
All true. The bigger bill lands in operations.
Integration debt determines how many teams have to coordinate to make a change, how quickly anyone can diagnose a failure, and how much manual work exists because the systems never quite agree.
The expensive part is disagreement
Two systems can exchange data reliably and still disagree about what it means.
Customer status, available inventory, order completion, product eligibility, and price can each have different definitions depending on which team and system is speaking. The integration layer maps fields, but the business process carries the disagreement.
That creates familiar behavior:
- manual reconciliation reports
- exception queues nobody fully owns
- batch jobs that correct the previous batch job
- releases coordinated across unrelated teams
- support tickets that move between system owners
The interface may be technically stable. The operating model is paying interest.
A new integration platform can preserve old debt
Modern integration tooling can improve deployment, transformation, security, observability, and reuse. Good.
It cannot decide which system owns a fact or which team owns an exception.
If a modernization program takes every point-to-point interface and redraws it through a central platform without revisiting those questions, the architecture becomes easier to diagram. The business process stays the same.
Sometimes it gets worse because the integration team becomes the owner of behavior it does not control.
Cool. So we centralized the ambiguity.
Follow a transaction across the system
Application inventories are useful, but integration debt becomes clearer when you trace a business transaction end to end.
Take an order, return, product update, customer change, or inventory adjustment. Identify:
- where the transaction begins
- which system owns each state transition
- every copy of the data
- synchronous and asynchronous dependencies
- retry and reconciliation behavior
- the team that handles each exception
- how a person knows the transaction is complete
This tends to reveal that the worst integration is not always the oldest one. It is the one whose failure requires three teams to compare screenshots.
Reduce coordination, not only interfaces
The goal of integration remediation should be fewer reasons for teams and systems to coordinate.
That may mean clarifying a source of truth, changing the business process, moving validation closer to the system that owns it, replacing a shared database with a contract, or accepting eventual consistency where the business does not require an immediate answer.
It may also mean keeping an ugly integration because it is stable, understood, and not constraining change. Age is not a sufficient reason to rebuild something.
Prioritize the interfaces that create business risk, recurring manual work, or change friction.
Ownership is part of the contract
An API contract explains fields and behavior. An operating contract should explain who responds when the interaction fails.
Who owns the alert? Which team decides whether to retry? Who can repair data? What is the expected resolution time? Which system communicates status to the customer?
If those answers only exist in somebody’s memory, the integration is not fully designed.
Integration debt does not disappear because every payload uses the same format. It falls when a change can move with fewer hidden dependencies and a failure has somewhere obvious to go.
If six teams still join the incident call to decide whose system is wrong, the middleware modernization is not finished.