Architecture Debt

Part 3 · The Core Concepts

Most people in IT have heard of technical debt. Fewer have a name for the thing that sits above it and constrains far more: architecture debt. The distinction matters, because the two are paid down differently, justified differently, and — crucially — explained to a board differently.

Technical debt is the accumulated cost of implementation shortcuts — the code that was written quickly, the tests that were skipped, the workaround that became permanent. It lives inside systems. Architecture debt is the accumulated cost of structural decisions that constrain future options — the point-to-point integration that should have been a platform, the duplicated capability that should have been consolidated, the absent data master that everything now works around. It lives between systems, in the shape of the estate itself.

This chapter explains what architecture debt is, how it accumulates, why it is more dangerous than technical debt, and — the part that determines whether anything gets done about it — how to make it visible to the person holding the budget.

How Architecture Debt Accumulates

Architecture debt is not created by bad decisions. That is the thing that makes it so hard to address. It is created by good decisions made in isolation.

Every system in an estate was, at the moment it was procured, a rational answer to a real problem. The clinical portal solved a genuine need in 2011. The departmental database solved a genuine need in 2014. The point-to-point integration between them was the quickest way to get data flowing in 2015, and it worked. Each decision was locally rational — correct given what was known and needed at the time.

Architecture debt is what locally rational decisions add up to when nobody is coordinating them. No single decision was wrong. The accumulation is the problem. Thirty separate teams each choosing the quickest integration produce an estate with thirty fragile connections that nobody designed and nobody fully understands. The debt is emergent — it arises from the absence of coordination, not the presence of error.

This is why architecture debt cannot be blamed on anyone, and why “who let this happen?” is the wrong question. Nobody let it happen. Everybody, acting reasonably, made it happen together. The fix is not to find the culprit; it is to introduce the coordination that was missing.

Why It Is More Dangerous Than Technical Debt

Technical debt and architecture debt are both real costs, but they differ in three ways that make architecture debt the more serious.

Scope. Technical debt is contained within a system. You can pay it down by refactoring that system, and the cost is bounded by the system’s size. Architecture debt spans systems. Paying it down means changing the relationships between systems, which touches everything connected to them. The blast radius is the estate, not the component.

Visibility. Technical debt is visible to the people who maintain the system — the developers feel it every time they change the code. Architecture debt is invisible from inside any single system. Each team sees only their own corner. The debt lives in the connections and the gaps between teams, which is precisely where nobody is looking. It becomes visible only when someone assembles the whole picture — which is what enterprise architecture is for.

Reversibility. Technical debt can usually be paid down incrementally. Architecture debt often cannot, because the structural decisions have been built upon. The absent data master is not a line of code to fix; it is an assumption baked into a dozen systems that each built their own version of patient identity. Unwinding it means coordinating change across all of them at once.

The combination — wide scope, low visibility, poor reversibility — is what makes architecture debt the kind of problem that grows quietly for years and then presents as a crisis that seems to have come from nowhere. The VMware licensing shock, the failed integration, the data-quality scandal: these are often architecture debt becoming visible all at once.

Architecture Debt at Meridian

Meridian’s architecture debt is thirty years of locally rational decisions that nobody coordinated, and by the time the EA arrives it has compounded into the conditions described throughout this book.

The 34 point-to-point integrations are architecture debt. Each was the right answer to a specific data-flow need at a specific moment. Collectively they are a web of dependencies that makes any change a high-risk event — the structural cost of fifteen years of nobody owning the integration question.

The dual EPR is architecture debt. It arose from a merger: two organisations, each with its own clinical record system, neither willing to abandon its own, no governance with the authority to force consolidation. The decision to run both was rational for each predecessor organisation. The accumulated cost — duplicated licensing, fragmented patient records, clinicians toggling between systems — is borne by the merged organisation that nobody designed.

The absent patient-identity master is the deepest debt. Twenty-three of thirty-one data entities have no owner; patient identity, the most important of them, is reconstructed differently by each system that needs it. No single decision created this. Each system, when built, reasonably solved its own identity problem. The structural cost — the inability to trust that two records refer to the same patient — is the debt those reasonable decisions left behind.

The EA’s insight is that the VMware crisis, which the board experiences as a sudden cost shock, is not sudden at all. It is architecture debt presenting as a bill. The infrastructure was never consolidated, never modernised, never governed as an estate — a series of locally rational deferrals, each of which made sense, which together produced a platform that is now simultaneously expensive, fragile, and end-of-life. The shock is the debt becoming visible, on a timetable set by a vendor rather than by Meridian.

Making It Visible to a CFO

Here is the practical problem. Architecture debt is invisible, structural, and blameless. A CFO sees none of that. A CFO sees a request for investment in something that does not produce new capability — that merely restructures what already exists. To the financial eye, paying down architecture debt looks like spending money to stand still.

The translation that unlocks the conversation is cost of inaction. Architecture debt is not a request to spend money on improvement; it is the quantified consequence of not spending it. The frame is not “we would like to modernise the integration estate.” The frame is “the integration estate carries a quantifiable risk and a quantifiable run cost, both of which grow each year we defer, and here is what each year of deferral costs.”

This makes the debt visible in the only language a CFO is obliged to act on: financial consequence over time. Architecture debt translates into three financial quantities. There is the carrying cost — what the debt costs to live with each year, in run cost, maintenance effort, and licensing. There is the risk cost — the expected cost of the failure the debt makes more likely, weighted by its probability. And there is the option cost — the future investments the debt blocks or makes more expensive, because they cannot proceed until the debt is paid.

The VMware crisis is the clearest example. Framed as “we want to migrate to cloud”, it is a discretionary modernisation competing for capital. Framed as “the current platform’s run cost has tripled, it is unsupported and carries a clinical-continuity risk, and every month of deferral adds £X to the eventual migration cost while the risk compounds”, it is a cost-of-inaction case that a CFO can take to a board. Same underlying reality. Entirely different conversation.

The skill is not financial modelling. It is refusing to ask for money to improve things, and insisting instead on showing what not improving them already costs.

Translator Panel

Architects say: “We’ve accumulated significant architecture debt across the integration estate.” > What that means: The way the systems connect to each other has become a structural liability — not because any one connection is wrong, but because the accumulation constrains every future change and carries a growing run cost and risk. It is a statement about the shape of the estate, not the quality of any component.

What a CFO needs to hear instead: “Living with the current integration estate costs us roughly £X a year to run, carries a quantified risk of clinical-system failure, and adds an estimated £Y to the cost of every major system change. Each year we defer, those numbers grow. Here is what addressing it costs, and here is what not addressing it costs.” > What that means: The same debt, translated from a structural statement into a financial one with a time dimension. The CFO cannot act on “architecture debt”. The CFO can act on “cost of inaction, growing annually”.

The Key Idea

Architecture debt is the accumulated cost of structural decisions that constrain future options — and unlike technical debt, it lives between systems rather than inside them, which makes it wider in scope, lower in visibility, and harder to reverse. It accumulates not from bad decisions but from good ones made in isolation, with nobody coordinating the whole. That is why it cannot be blamed on anyone and why the missing ingredient is always coordination rather than competence. And because it is structural and invisible, it must be translated into financial consequence before anyone with a budget will act on it. The decisive move is to stop asking for money to improve things and start showing what not improving them already costs — the cost of inaction, growing every year it is deferred.

Next: Chapter 27 returns to the application portfolio from Chapter 20 and introduces the decision framework for acting on it — the 6R model that turns an assessment into a set of dispositions.