Every organisation that has been running IT for more than a few years has architecture debt. Most of them don’t know how much.
Architecture debt is the accumulated cost of past shortcuts. Every time a project used a deprecated technology because it was faster. Every time a system was built outside approved integration patterns because the approved approach would have taken too long. Every time a solution was approved with known deviations from IT Standards because the business need was urgent. Every one of those decisions was a debt. It will cost more to fix later than it would have cost to do right in the first place.
Like financial debt, architecture debt is not inherently wrong. Sometimes borrowing is the rational choice — implementing a tactical solution now to meet an urgent business need, while planning to invest in the strategic solution later. The problem is not the debt; it is undisclosed debt.
Undisclosed architecture debt accumulates silently. Future initiatives consume more effort because the landscape they have to work with is messier than it should be. Integration projects take longer because the data models don’t align cleanly. Security improvements are harder because the authentication patterns are inconsistent. The total cost of the portfolio quietly rises, and nobody quite understands why.
The Architecture Debt Register
When a governance forum approves a deviation — grants an exemption because the business case is strong enough — the deviation is documented in an Architecture Debt Register. Five fields:
- A description of the deviation.
- Which IT Standards or architectural direction it departs from.
- The estimated future cost to remediate.
- The planned remediation date.
- A severity classification: minor, medium, or major, based on landscape impact.
That’s it. A spreadsheet or a simple database. Not a sophisticated tool. The sophistication is in the discipline of actually maintaining it.
Three purposes the register serves
- Makes the true cost of IT decisions visible. A solution that costs £500k to build but carries £400k of architecture debt has a total cost of £900k. Many urgency-driven decisions look different when the deferred cost is made explicit.
- Drives Technology Alignment. Debts with remediation dates become planned Technical initiatives. The register is not a historical record of regrettable decisions; it is a planning tool.
- Enables governance escalation. Deviations creating minor debt can be approved by the Design Forum. Deviations creating major debt require escalation to the Technology Forum or Strategy Forum. This translates the abstract governance principle into an auditable decision rule.
What the register reveals: An organisation with a comprehensive register, realistic cost estimates, and active remediation plans has a mature, honest practice. An organisation with an empty register and a chaotic landscape has an architecture function that either isn’t looking or isn’t recording what it sees. The register is not a report of failure. It is evidence of honesty.
The question is not whether you have architecture debt. The question is whether you know what it is.