The scene replays every year, with minor variations. A team explains that the platform needs reworking, that this version has to go, that the data access layer should be rebuilt. The arguments are solid and sincere. Across the table, the investment board listens politely, then allocates in favour of the projects carrying a legible business promise: a new customer journey, a compliance deadline, an offer to launch. The team’s request rolls over to the next planning cycle. And the following year, the same request comes back — more expensive.

It would be easy to read this as a failure of managerial nerve. It rarely is. The board does exactly what it exists to do: allocate a scarce resource across competing demands by comparing what they return. The problem is that technical debt, as it reaches that table, is not comparable. It arrives phrased in technical vocabulary, with no amount, no deadline, no dated consequence. It is not an investment case: it is a worry.

That is this article’s argument. Technical debt fails to get funded not because it is misunderstood, but because it is poorly prepared. As long as it remains an engineering topic, it will stay off-budget. The architectural work consists precisely in changing its nature: from diffuse technical discomfort to an identified liability, tied to what it puts at risk, and arbitrable on the same terms as an investment.

The metaphor is sound — we just don’t follow it through

The debt image is not a communication device. It was proposed in the early 1990s by Ward Cunningham to explain a precise mechanism to non-technical audiences: shipping fast on an imperfect design amounts to borrowing. You get an immediate benefit — the capability arrives sooner — against a future charge: every later change costs a little more until the design is put right.

What makes the metaphor powerful is that it is financially accurate on three counts.

It distinguishes a principal — the cost of remediation — from interest: the surcharge paid on every change while the principal remains outstanding. It concedes that borrowing can be rational: you take on debt to seize an opportunity that will not come round again, exactly as a company borrows to fund growth. And it carries a risk any finance function recognises: when interest exceeds the capacity to repay, the organisation only ever services the charge and never touches the capital. Translated into information systems, that is the point where most of the budget goes to keeping the existing estate alive and nothing structural ships any more.

The paradox is that the metaphor is used everywhere and its consequences nowhere. An organisation that spoke about its financial debt the way it speaks about its technical debt would have no outstanding balance, no maturity schedule, no owner, and no idea of the rate it pays. It would simply say, in a meeting, that it is “fairly indebted”. No finance director would accept that. Yet it is the normal state of technical debt in most estates.

Not all debt is the same

Before funding anything, you need to know what you have taken on. And “technical debt”, in common usage, covers realities that share neither the same origin nor the same treatment.

Martin Fowler proposed a grid that has become standard, crossing two axes: is the debt deliberate or inadvertent, and was the choice prudent or reckless? Four situations follow, and they do not call for the same responses.

  • Deliberate and prudent: “we know this design is simplified, we accept the surcharge to hold the date.” This is an acknowledged loan. It gets documented and provisioned.
  • Deliberate and reckless: “we don’t have time to design.” The loan is taken without knowing the rate. This is the most dangerous debt, because it is invisible at the moment it is incurred.
  • Inadvertent and prudent: “now that the system runs, we can see how it should have been structured.” This is the normal cost of learning; every design ages as understanding of the domain improves.
  • Inadvertent and reckless: debt born of insufficient command of the subject, discovered after the fact.

To this grid, the architect must add two categories that a code-level view misses, and that often weigh more.

Obsolescence first: it is not debt you took on, but debt that accumulates without anyone deciding anything. A version leaving vendor support, a component whose community thins out, a skill that disappears from the market. Time works on its own, and the principal grows without a single line of code being written.

Architectural debt next, which is different in kind from code debt. A badly written module costs whoever modifies it. An inadequate decomposition, a structural coupling between domains, a data model shared by things that should have stayed separate: that costs everyone, all the time, on projects that never asked for it. This is the debt whose interest compounds — because every new system built on a shaky foundation inherits the flaw and propagates it.

This distinction has a direct practical consequence: code-level instruments (static analysis, quality indicators, coverage ratios) are useful, but they see almost nothing of the most expensive debt. An impeccable codebase can perfectly well sit on top of an architecture that has immobilised the organisation.

Tie the debt to what it puts at risk

An organisation does not fund a remediation; it funds the protection or the release of a capability. That is the pivot of the argument, and precisely where most cases fail.

Compare two framings of the same situation. “The billing platform runs on a version going out of support, and the code is no longer tested.” Nobody knows what to do with that: it is a technical observation addressed to a board that does not speak the language. Reframe it: “Any pricing change now takes several months and ties up the few people who know that platform; once support ends, we lose the ability to fix a billing error within an acceptable delay.” Nothing changed in the facts. Everything changed in the decision: the second framing names a weakened business capability, a consequence, and a horizon.

This shift requires explicitly linking each debt item to the business capabilities it supports — which is where a capability map becomes a financial instrument as much as an architectural one. Once that link is drawn, prioritisation stops being a contest of opinions: heavy debt on a differentiating capability is not handled like the same debt on a capability nearing end of life, whose fate is to disappear.

Three questions are enough to prepare a debt item. What does this debt prevent us from doing? — not what is ugly, but which change becomes slow, expensive or impossible. What happens if we do nothing? — and by when, bearing in mind that an external deadline (end of support, a regulatory requirement, a dependency going away) is infinitely more mobilising than an internal worry. What does waiting cost? — because debt whose principal grows over time does not compare to stable debt.

Three ways to fund it, one way not to

Once prepared, debt becomes fundable. Three modes exist, and choosing between them is itself an architectural decision.

Dedicated repayment is an identified, budgeted piece of work with a start and an end: rebuilding a component, migrating a version, extracting a domain. It is the only mode that genuinely addresses significant structural debt, and the only one that demands an explicit trade-off. Its drawback: it competes head-on with business projects, which presupposes a solid case.

Amortisation inside projects means having remediation carried by the functional changes that pass through the area concerned: you don’t fund a debt programme, you fund a project that requires, to be done properly, cleaning up what it touches. It is the smoothest mode politically, and the most effective for local debt. Its limit is strict: it never addresses structural debt, because no single project traverses a foundation on its own.

Refinancing amounts to not repaying at all: replace, decommission, or have the capability carried by a market solution. It is often the most rational option for old debt on a non-differentiating capability — provided it is prepared as an option rather than dismissed out of habit.

Alongside these three, one common practice deserves an unsentimental look: the 20 % rule — devoting a fixed fraction of team capacity to debt. It has a real merit, that of making maintenance continuous instead of waiting for a crisis, and it handles local debt well. But it produces two perverse effects when it stands in for a policy. It creates the impression that the subject is handled, when it only touches what a team can repair alone — never architectural debt, which is precisely the debt that cuts across teams. And absent prioritisation criteria, that fraction gets spent where it is most visible to the team, not where the risk is highest for the organisation. A percentage is not a trade-off; it is a provision nobody allocates.

The debt you choose never to repay

It has to be said plainly, because it cuts against the grain of an article arguing for funding debt: part of the debt should not be repaid. Wanting to fix everything is as irrational as fixing nothing, and it discredits the architecture function, which then looks like it is demanding an unlimited budget for an aesthetic ideal.

Debt carried by an application at end of life, on a capability the organisation no longer intends to evolve, is debt to be accepted and frozen. The decision is then to stop investing in it, document the residual risk, contain the area — and never reopen the debate at the board. That is a full architectural decision, recorded like any other.

This triage has an underrated virtue: it makes everything else credible. An architecture function that states explicitly which debt it is giving up on earns the right to be heard on the debt it asks to fund.

Why debt registers fail

The approach described here has one dominant failure mode, worth naming because it is so widespread: the register that changes nothing. Debt gets inventoried, a list of several hundred lines appears, it is sorted by technical severity, it is presented — and it triggers no decision. Three causes almost always combine.

The list is too granular: it inventories code symptoms where the board expects capability stakes. It is unowned: debt without an identified owner is arbitrable by no one. And it is undated: nothing separates what becomes critical in six months from what can wait three years, which amounts to no prioritisation at all.

A useful register is short, phrased in consequences, dated, and tied to capabilities. It fits on one page for a board, with the technical detail available underneath for those who want to go down. It looks more like a schedule of commitments than an audit report.

Making debt decidable

None of the above is technical. Technical debt is a management object that has been handed, by default, to the people who suffer its effects rather than to those who can arbitrate it. The architect’s job is not to repair it — it is to make it decidable: named, quantified as far as possible, tied to a capability, given a deadline and an owner, and accompanied by a clear recommendation, including the recommendation to do nothing.

A mature organisation is not recognisable by the absence of debt. It is recognisable by this: it knows, at any moment, what debt it carries, what that debt costs it, what it has decided to do about it — and which portion it has deliberately chosen to keep on the balance sheet.