Ask a leadership team: “Where should we invest in our information system next year?” The answer often comes as a list of projects, or an inventory of four hundred applications no one agrees on. That’s the symptom of a blind spot: the organisation reasons in applications and projects, not in capabilities.

The business capability map fixes that blind spot. It’s arguably the most powerful architecture artifact — and the most underused. Here’s why, and how to build yours.

The symptom: IT decisions made without a map

With no shared reference, IT trade-offs are made blind. Every department defends its projects, every vendor pushes its solution, and prioritisation follows the loudest voice rather than value. You end up investing in what’s visible (a shiny new portal) at the expense of what’s critical but invisible (identity management, data quality).

The outcome is familiar: duplicated systems, scattered budgets, and a chronic inability to answer simply, “what actually creates value, and where are we fragile?”

What is a business capability map?

A business capability describes what the organisation can do — “handle claims”, “grant credit”, “retain a customer” — regardless of how it does it (the process) or with what (the application). It’s a deliberately stable abstraction: your processes change, your software is replaced, but the capability “invoice a customer” remains.

A capability map organises them by levels (L1 → L2 → L3), from general to detailed, and provides a single view shared by business and IT. It doesn’t prescribe how to work; it gives a common language to decide.

Three confusions to avoid:

  • Capability ≠ process. A process is a sequence of activities; a capability is the underlying ability. One process can draw on several capabilities.
  • Capability ≠ application. An application enables one or more capabilities; it isn’t the capability.
  • Capability ≠ org chart. A capability often spans several departments — and that’s precisely its strength.

Why an application inventory isn’t enough

Many organisations have an application inventory (often in a CMDB) and believe they have a view of their IS. That’s a map of the how, not the what. It answers “which software do we have?” but not “which capabilities are under-invested, redundant or critical?”

The capability map is the missing link between strategy and IT: strategy is expressed in objectives and capabilities to strengthen; IT is expressed in applications. Without the capability layer in between, the two speak different languages — and alignment stays a wish.

What the absence of this map really costs

Major IT failures often share a single root cause: technology decisions disconnected from a clear view of capabilities and their value.

  • Mergers and acquisitions are the most common illustration. Two merging banks end up with two core banking systems, two CRMs, two credit engines. Without a capability map to decide which building block best serves each target capability, rationalisation drags on for years and costs a fortune in duplicate maintenance.
  • The UK NHS National Programme for IT, often cited among the largest public IT failures, consumed billions of pounds before being largely abandoned — a textbook case of IT driven by technology and a political timeline rather than by real, ground-level capabilities and their value.
  • The botched TSB core banking migration in 2018 locked British customers out of their accounts for days, triggering regulatory investigations and penalties. Beyond the technology, it illustrates the cost of underestimating the dependencies between capabilities, data and systems.

No capability map alone would have prevented these episodes. But they all reflect the same absence: no shared view linking what the organisation must be able to do, what supports it, and where the risks lie.

Building your capability map: a five-step method

  1. Start from the business, not from IT. Bring business leaders together and identify the top-level (L1) capabilities (often 8–15): what the company does, not its departments.
  2. Break down by levels. Unfold each L1 capability into L2, then L3 where useful. Stop when another level no longer helps you decide.
  3. Stay stable and exhaustive without overlap. Each capability appears once, in one place (the MECE principle). If you’re tempted to file something in two places, that’s usually a sign of poor decomposition.
  4. Attach applications, data and processes. Once the map is stable, link each capability to the applications that enable it, the data it handles, the processes it serves. That’s where the map becomes a genuine steering instrument.
  5. Validate and keep it alive. Have the map validated by business and IT — co-creation drives adoption. Then maintain it: it’s a living asset, not an end-of-engagement deliverable.

The heatmap: turning the map into a decision tool

A capability map reaches full power when you colour it in. By overlaying two dimensions — a capability’s current maturity and its strategic importance (or criticality) — you get a heatmap that instantly shows where to invest: capabilities that are both critical and weakly mature are your obvious priorities.

It’s this visual reading that turns a debate of opinions into an evidence-based decision. (To see the principle in action, an interactive capability map is part of our architecture diagrams library.)

Pitfalls to avoid

  • Too much detail. A five-level map no one reads is useless. The right level is the one that helps you decide.
  • Building it in a silo. A map produced by IT alone, without the business, will be accurate… and ignored. Adoption is won through co-creation.
  • Freezing it. A map that doesn’t evolve becomes wrong within eighteen months.
  • Mistaking it for an inventory. If your “capability map” lists applications, it isn’t a capability map.

In short

The business capability map replaces neither your application inventory nor your processes — it gives them shared meaning. It’s the lens that finally answers, without ambiguity, the question that matters: where to invest, and where are we fragile? For an organisation seeking to align technology with strategy for the long run, it’s the most cost-effective starting point — and the most often overlooked.