An organization evaluates two solutions for the same need. The first has a licence price half that of the second. The choice looks obvious; the decision is made in a few weeks. Three years later, the “cheaper” one has cost more — endless integration, heavy operations, data trapped in a proprietary format, and an entire team tied up keeping it alive rather than evolving it. The sticker price was right about one thing: it was the lowest. It was wrong about the only thing that matters: the real cost.

This confusion between price and cost is one of the most common decision errors in information systems. Price is what you pay at signing; cost is what you pay over the entire life of the decision. Between the two hides everything the quote doesn’t show. Total cost of ownership — TCO — is the tool that makes that real cost visible. This article explains what it covers, why it has become vital, how to calculate it, and why — this is the central claim — it is settled far more in the architecture than in the commercial negotiation.

What TCO really covers

The concept isn’t new. Gartner Group popularized it back in 1987, first applying it to the desktop: beyond the purchase price of a computer, you had to count support, administration, failures, training. The intuition was already there: the cost of acquisition is only a fraction of the cost of ownership. What held for a PC in 1987 holds, magnified, for an enterprise application in 2026.

TCO is a financial estimate that sums up all the costs, direct and indirect, generated by a solution over its full life cycle — from the decision to acquire it until it is decommissioned. It therefore captures three moments the price ignores: what entry costs (acquiring, integrating, deploying), what the run costs (operating, maintaining, securing, driving adoption), and what exit costs (migrating, decommissioning, recovering your data).

The classic image is the iceberg. The licence, or the initial build cost, forms the visible tip — visible, quantified, debated. Below the waterline sits everything else, bulkier and heavier: integration into the rest of the information system, operations year after year, compliance, team training, accumulated debt, and the cost — often forgotten until the worst moment — of getting out. To reason in TCO is to refuse to decide on the tip alone.

Why the subject has become vital

TCO has always mattered. What has changed is the relative weight of its submerged part. Three shifts have turned it from an accounting exercise into a strategic concern.

The cost of the run has overtaken the cost of the build. In many organizations, most of the IT budget no longer goes to building, but to maintaining what already exists. According to Deloitte, maintenance can absorb as much as 56% of IT spend. In other words, for every euro invested in new capabilities, more than one euro goes to keeping the existing estate standing. Each solution added without regard for its operating cost swells that share, and shrinks future investment capacity by just as much.

Technical debt has become a measurable cost line. It is no longer an engineer’s concept but a line that boardrooms watch. According to McKinsey’s research, technical debt amounts to 20 to 40% of the value of an organization’s technology estate, before depreciation; and 10 to 20% of the budget meant for new products is diverted to fixing problems inherited from the past. More telling still: 60% of the CIOs surveyed feel their technical debt has risen perceptibly over the past three years. That debt is deferred TCO — a cost you failed to pay at the right time, which comes back with a premium.

The cloud has made cost continuous and moving. The pay-as-you-go model replaced the one-off purchase with an invoice that runs, month after month, and swells silently if no one watches it. Flexera’s State of the Cloud 2025 report, based on 759 organizations, estimates that 27% of cloud spend is wasted — oversized resources, forgotten environments, reserved capacity never used. And 84% of organizations say they struggle to keep that spend under control. The cloud didn’t remove TCO: it turned it into a permanent flow, harder to see and easier to let slip.

These three dynamics converge on the same conclusion: the cost of a solution can no longer be read at purchase; it is suffered in use. Hence the urgency of making it visible before deciding.

The layers of real cost

Estimating a TCO means descending methodically below the waterline. Seven layers recur, whatever the type of solution — packaged software, custom build, platform, cloud service.

1. Acquisition. Licence, subscription, or initial build cost. The visible part — and often the smallest over time. The pricing model matters as much as the amount: per user, per module, per volume, every grid hides tiers.

2. Integration. Connecting the solution to the rest of the information system: data migration, interfaces, adaptation to existing repositories. This is frequently the heaviest layer at entry, and it depends directly on architectural choices — the more coupled and heterogeneous the landscape, the higher the bill.

3. Operations (the run). Hosting, monitoring, backups, version upgrades, support, administration time. This is the layer that runs over the whole life span, and therefore the one that weighs most in aggregate. A modest annual cost, multiplied by five years, often exceeds the acquisition price.

4. Security and compliance. Encryption, identity management, logging, audits, sovereignty requirements. In regulated sectors — banking, insurance, healthcare, public sector — this layer isn’t optional, and it costs all the more when it was thought about late. Security bolted on afterwards structurally costs more than security by design.

5. Adoption. Training, change management, skill-building. The most underestimated layer: a solution the teams don’t use is a dead loss, whatever its price. Licences paid for but dormant — shelfware — are pure TCO with no value against it.

6. Debt and obsolescence. What the solution will cost as it ages: unfollowed versions, customizations to replay, workarounds that pile up. This layer is invisible at purchase and yet is largely determined by the quality of the initial design.

7. Exit. The most forgotten cost, and sometimes the highest: migrating to something else, recovering your data in a usable format, decommissioning cleanly. When data and models are locked in a proprietary format, switching becomes prohibitive. That is lock-in — a cost you only pay at the worst moment, the one when you’ve already decided to leave.

To these seven layers, add an eighth cost, of a different nature but very real: opportunity cost. Every month spent deploying rather than producing value, every budget frozen in a mediocre solution, is that much value not created elsewhere. The highest TCO is not always the one that costs the most, but the one that prevents you from doing something else.

(For a detailed breakdown of these layers applied to a specific case — choosing an enterprise architecture platform — see our article The hidden cost of legacy EA platforms.)

How to calculate it: the methods that hold

There is no single, universal TCO standard, but a set of converging practices. Four principles are enough to produce a solid estimate, without a sophisticated financial model.

Set the horizon to the life of the decision. A TCO is not calculated “per year” but over the period during which the solution commits the organization — typically three to five years. This is what reveals the weight of the run against acquisition. A simple back-of-envelope formula is enough to start:

TCO ≈ Acquisition + Integration + Adoption + (Operations × number of years) + estimated Exit cost

Discount, when the amounts are significant. A euro spent in three years doesn’t weigh as much as a euro spent today. For structural decisions, bringing future flows back to their present value (a discounted-cost logic, or net present value) avoids comparing cost trajectories that unfold at different rhythms — a heavy upfront investment against a spread-out expense.

Reason by capability, not by tool. Relate the cost to the business capability it serves — “what does identity management, or billing, really cost us?” — rather than to the tool alone. This is what lets you compare heterogeneous options and spot redundancies: two solutions covering the same capability are two TCOs for a single value.

For the cloud, anchor TCO in a FinOps discipline. Pay-as-you-go spend demands continuous governance: tracking, allocation, waste detection. Cloud TCO is not an estimate frozen at purchase but a cost steered over time — otherwise you fall back into the 27% waste mentioned above.

And once the total is set, it must be tested against two indicators that change the reading: time to first value (how long before the solution produces a real benefit?) and the value-to-cost ratio (what it returns against what it costs). A solution twice as expensive but that produces value three times faster is, in real TCO relative to value, the cheapest.

Why this is an architecture question

Here is the point that purely financial approaches miss. TCO is not only measured by finance; it is determined by architecture. Most of the costs that will make up the iceberg are committed — though not yet paid — at the moment of the structural choices, long before the first operating invoice.

Three examples make it plain.

Coupling sets the cost of integration and change. A solution that integrates through clear, contracted interfaces will cost little to connect and little to replace. The same solution wired in hard and deep into the rest of the system will cost a lot to integrate and become almost impossible to remove. That is not a pricing parameter, it is an architectural decision.

Reversibility sets the cost of exit. Choosing an open data format, guaranteeing export, avoiding deep dependencies on a single vendor: these decisions, made at design time, determine whether the “exit” layer will be painless or prohibitive. Lock-in is not a fate of the market, it is the consequence of an architectural choice that wasn’t made.

Design sets future debt. A clean, decoupled, documented architecture ages slowly. A make-do architecture accumulates the debt that, as we saw, represents 20 to 40% of the estate’s value. Tomorrow’s technical debt is, very largely, today’s architectural decision.

From this follows a simple rule worth remembering: by the time TCO becomes visible in the budget, it is already largely committed by the architecture. Room to manoeuvre is greatest when you’re drawing, and closes as you build. This is why TCO cannot be a financial exercise run after the technical decision: it must be a criterion of the technical decision itself. An architectural choice is, whether you like it or not, a multi-year cost commitment. Better to make it with eyes open.

Who is responsible

If TCO is settled in the architecture, then the question of who owns it gets a different answer. The usual temptation is to make it the business of finance or procurement — those who sign. But finance records the cost; it doesn’t shape it. TCO is a shared responsibility, with architecture as the pivot.

  • The architect is best placed to illuminate TCO at the moment it is decided: they see the coupling, the dependencies, the reversibility, the effect of a choice on the whole landscape. Their role is not to compute a budget, but to make explicit the cost of ownership attached to each structural option — and to treat it as a design criterion on a par with performance or security.
  • The IT leadership arbitrates between the cost of the run and investment capacity: it carries the balance between maintaining the existing and building the future.
  • Finance and procurement bring rigour to the costing, the discounting, the comparison over time. They frame the method, but cannot alone settle a trade-off that is first and foremost technical.
  • The business owner or product owner carries the expected value, the other half of the equation: a TCO only makes sense relative to what the solution produces.

The right mechanism is not a TCO audit after the fact, but a TCO recorded at the moment of decision. That is exactly the spirit of an architecture decision record: documenting, at the point of choice, not only the option retained and its alternatives, but the estimated cost of ownership it commits. TCO then becomes a governance criterion — visible, comparable, revisable — rather than a budget surprise discovered three years later.

The classic pitfalls

Four errors recur, and each is corrected by an architectural reflex.

Confusing price with cost. Deciding on the tip of the iceberg. The fix: accept no costing that stops at the licence or the initial build cost.

Underestimating the run and the exit. These are the two heaviest layers and the easiest to ignore, because they are paid later. The fix: cost them explicitly, even roughly, from the evaluation stage.

Ignoring opportunity cost. Focusing on visible spend while forgetting what the solution prevents you from doing elsewhere. The fix: always set cost against value and time to value.

Treating TCO once, at purchase. Real cost evolves — debt accumulates, the cloud bill drifts. The fix: re-assess periodically, especially for solutions with continuous cost.

From price to cost, from cost to value

To reason in TCO is, first, to refuse to decide on the sticker price. It is then to understand that the real cost of a solution is not a figure you discover, but a property you design: it is set, for the most part, by the quality of the architectural choices — coupling, reversibility, cleanliness of design. A cheap, poorly architected solution is expensive; a well-architected solution is economical over time, even if it costs more at entry.

But TCO is not an end in itself. Minimizing cost at zero value is pointless. The objective is not the lowest cost, it is the best ratio between value produced and total cost of ownership. Price is an input; TCO is a decision input; value relative to TCO is the only judge that counts.

That is why total cost of ownership does not belong in the end-of-process spreadsheet. It belongs to the moment you draw — where, silently, it is already being decided.