The Interfaces Nobody Owns: Auditing Integration Debt Before It Becomes an Incident
Most UK organisations can tell you what they spent on software licences last quarter. Very few can tell you how many interfaces connect their systems, who owns each one, or when any of them was last reviewed. That gap is not a housekeeping issue. It is an unrecorded liability sitting inside the delivery estate, and it compounds quietly until a certificate expires on a Saturday morning and a fulfilment process stops.
The phrase integration debt borrows from technical debt, but the financial metaphor is worth taking literally. A point-to-point link between a finance system and a payroll platform is an asset in the sense that it produces value. It also has a build cost, a run cost, a support life and a replacement date. When those attributes go unrecorded, the organisation cannot depreciate the interface, cannot impair it when a vendor withdraws support, and cannot compare the cost of keeping it alive against the cost of replacing it with something better.
Why the liability stays invisible
Finance systems record what has been bought. They rarely record what has been glued together. Integration work is usually absorbed into a project budget, then into operational overhead, and finally into a general assumption that systems will keep talking to each other. Middleware is purchased as a platform and thereafter treated as plumbing. One-off scripts written by a contractor in 2019 sit on a virtual machine whose purpose nobody has revisited.
The outcome is a class of asset that is real, expensive and unaudited. In regulated sectors the gap has consequences beyond cost. The operational resilience expectations set by the Financial Conduct Authority, and the critical third-party regime overseen by the Bank of England, both assume that firms know their important business services and the dependencies behind them. An interface that nobody has inventoried is a dependency that cannot be mapped, tested or recovered in the timescale a regulator would expect.
What counts as integration debt
It helps to be strict about scope, because the register will otherwise collapse under its own ambition. Four categories cover most estates:
- Point-to-point links. Direct API calls, database views, file shares and screen-scraping connectors between applications that have no mediation layer.
- Middleware and brokers. Enterprise service buses, message queues, API gateways and iPaaS tenants, including the ones bought by a business unit outside central IT.
- Scheduled jobs and scripts. Cron jobs, stored procedures, PowerShell and Python scripts, RPA bots and spreadsheet macros that move data on a timetable.
- Data movement. Overnight CSV drops, SFTP transfers, manual uploads and the weekly reconciliation that exists only because a person performs it.
That last category matters. A manual reconciliation is an interface with a human being as the transport layer, and it carries exactly the same risks of key-person dependency and silent failure.
A four-week audit that technical leads can run
The framework below is deliberately lightweight. It is designed to produce a first-pass register in a month, not a perfect one in a year.
Week one: inventory
Start with discovery data rather than memory. API gateway logs, network flow records, integration platform inventories, CI/CD pipelines, cloud resource tags and database connection strings will together reveal far more than a workshop. Then interview the operations teams, who know about the interfaces that never appear in any design document. Expect the two lists to disagree. Treat the disagreement as the finding.
Week two: ownership
Every entry needs two names: a business owner accountable for the outcome the interface delivers, and a technical custodian accountable for changing it safely. Where ownership is contested or absent, assign interim custody to the team that would be paged if the interface failed. That default is uncomfortable, which is precisely why it works.
Week three: criticality scoring
Score each interface from one to five across five dimensions, then weight the results.
| Dimension | Question it asks | Weight |
|---|---|---|
| Business impact | What stops if this fails for a day? | High |
| Data sensitivity | Does it carry personal, financial or regulated data? | High |
| Concentration risk | Is there a single point of failure or a single expert? | Medium |
| Change frequency | How often is it modified, and how well is that tested? | Medium |
| Recoverability | How quickly could it be rebuilt from documentation? | High |
Anything scoring in the top band enters a remediation queue. Anything that scores low on recoverability but high on business impact deserves attention first, because it is the combination that produces long outages.
Week four: lifecycle dates
Record the introduction date, last review date, runtime and library versions, vendor end-of-support date and a target replacement date. This is the depreciation schedule. An interface running on an unsupported runtime past its end-of-support date is an impaired asset, and saying so in those terms changes the tenor of the conversation with finance.
Making the register behave like a ledger
Once the register exists, the investment discussion shifts. Rather than asking for a new integration platform in the abstract, a technical lead can say that fourteen interfaces reach end of support in 2027 and that remediation costs less than the modelled exposure of a week-long outage in the order pipeline. That is a business case a finance director can evaluate.
Three practices keep the register honest. Add interface fields to the architecture review checklist so new links cannot be created without an owner and a lifecycle date. Move the register out of a spreadsheet and into the configuration management database or service catalogue, where it will be reviewed alongside other assets. And put a quarterly review in the governance calendar with a named chair, because a register that is reviewed annually is a register that is already out of date.
Warning signs that debt is about to become an incident
Several indicators tend to precede failure, and most are visible before anything breaks:
- Change lead time rising while ticket volumes stay flat, suggesting that each change now requires more coordination than it should.
- Repeated incidents caused by certificate, credential or token expiry.
- Version drift between environments, so that a fix tested in staging behaves differently in production.
- A single engineer who is the only route to diagnosing a particular failure.
- Growing manual reconciliation effort, usually absorbed silently by an operations team.
- Integration tests being skipped or quarantined in release pipelines to protect delivery dates.
- A vendor announcement that requires code changes across several systems at once, with no inventory to scope the work.
None of these is conclusive on its own. Together they describe an estate where the interfaces have become more complex than the organisation's ability to describe them.
The point of the audit is not documentation for its own sake. It is to convert an invisible operational risk into a visible line item, with an owner, a date and a cost. Integration debt does not disappear when it is measured. It simply stops being able to surprise you.
