Ask any CTO what their organisation's business capabilities are, and you will get a confident answer. They will reel off customer management, financial operations, supply chain, product development. Ask them to show you the map — the actual structured model that connects those capabilities to the services, systems, and decisions that support them — and the confidence evaporates.
I have had this exact conversation more times than I can count, at large retailers, at public sector organisations, at government departments, at mid-market tech companies. The story is always the same. There is an instinctive understanding of what the organisation does, but it lives in people's heads. It has never been formalised into something the rest of the organisation can use, challenge, or build on.
That gap matters more than most people think. Without a structured business capability model, every strategic conversation starts from scratch. Every investment decision is argued on its own merits without reference to what the organisation already has and what it is missing. Every architecture review is disconnected from the business outcomes it exists to support.
What business capabilities actually are
This is where most explanations go wrong, so let me be direct. A business capability is what an organisation does, not how it does it.
"Customer Onboarding" is a capability. "The three-step online form followed by a manual identity check" is a process. "The React application that hosts the form" is a service. These are different things, and conflating them is the single most common mistake in capability mapping.
Capabilities are stable. They change slowly, if at all. An insurance company needed the capability "Claims Processing" in 1990 and it needs it in 2026. The processes, systems, and teams that deliver that capability have changed dramatically, but the capability itself has not. That stability is precisely what makes capability mapping useful. It gives you an anchor point that survives organisational restructures, technology migrations, and strategy pivots.
Here is a test I use with teams who are new to this: if you reorganised your entire company tomorrow — new departments, new reporting lines, new org chart — your capabilities would not change. The people delivering them would move around, the processes might be redesigned, but the fundamental things your organisation needs to do would remain the same. If something changes when you reorganise, it is probably a process or a function, not a capability.
The L0-L3 hierarchy, explained without the consulting slides
Business capability frameworks use a hierarchical model, typically labelled L0 through L3. The labels are arbitrary — some frameworks call them Level 1 through Level 4 — but the structure is consistent. Each level adds specificity.
L0: Strategic domains
These are the broadest groupings. A typical organisation has between six and twelve. Think of them as the major columns on a capability map: "Customer Management", "Financial Operations", "Product Development", "Risk & Compliance", "People Management". An L0 capability should be immediately recognisable to a board member. If it requires explanation, it is probably too granular.
L1: Major capabilities
Each L0 decomposes into four to eight L1 capabilities. Under "Customer Management" you might have "Customer Onboarding", "Customer Communication", "Customer Retention", "Customer Analytics". Under "Financial Operations" you might have "Accounts Receivable", "Accounts Payable", "Payment Processing", "Financial Reporting". L1 is where most strategic planning happens. Investment decisions, capability gap analysis, and technology roadmaps are typically framed at L1.
L2: Specific capabilities
This is where it gets operationally useful. Under "Customer Onboarding" you might have "Identity Verification", "KYC Assessment", "Account Provisioning", "Welcome Communication". L2 capabilities are specific enough to map directly to services, applications, and teams. When someone asks "which system handles KYC?", the answer lives at L2. Most organisations that get real value from capability mapping operate at L2 depth.
L3: Atomic capabilities
L3 breaks L2 down further. Under "Identity Verification" you might have "Document Upload", "Biometric Check", "Sanctions Screening", "PEP Check". In my experience, most organisations do not need L3 for general governance purposes. It becomes useful in highly regulated environments — banking, healthcare, defence — where you need to demonstrate precisely which atomic capability is supported by which system, and who is accountable for it. If you are starting from nothing, stop at L2. You can always add L3 later for the domains that need it.
If your capability map requires a legend to explain the colour coding, it is already too complicated for anyone to actually use.
Business capabilities versus technology capabilities
This distinction trips up even experienced architects, and getting it wrong undermines the entire model.
Business capabilities describe what the organisation does in business terms. "Payment Processing", "Regulatory Reporting", "Customer Retention". These exist regardless of technology choices. They would exist if you ran the entire operation on paper.
Technology capabilities describe what your technology estate can do. "API Management", "Data Integration", "Identity & Access Management", "Observability". These are the building blocks that enable business capabilities but are not business capabilities themselves.
Both matter. Both belong in your capability model. But they serve different audiences and answer different questions. The CFO cares about business capabilities. The CTO cares about both. The engineering team cares primarily about technology capabilities. A good capability framework separates them clearly and then maps the relationships between them. "Payment Processing" (business) depends on "API Management" (technology) and "Data Integration" (technology). That mapping is where the strategic value lives.
The mapping trap: beautiful slides that go stale in a month
I need to be honest about this, because I have fallen into this trap myself.
The first time I built a capability map for an organisation, I spent three weeks producing a beautiful multi-layered diagram. It had colour-coded maturity assessments, neat L0-through-L2 decomposition, and a supporting document that explained every capability in detail. The CTO loved it. The architecture board loved it. It was presented to the executive team, who nodded approvingly.
Within six weeks it was out of date. Two new services had been deployed that were not on the map. A reorganisation had shifted ownership of three L1 capabilities. The maturity assessments were based on a point-in-time view that no longer reflected reality. Nobody updated it because updating a PowerPoint capability map is tedious, error-prone work that nobody wants to own.
This is the fundamental problem with static capability maps. They capture a snapshot that starts degrading immediately. And because the effort to create them was significant, there is a psychological reluctance to admit they are already wrong.
The solution is not to map more carefully. The solution is to stop treating the capability map as a document and start treating it as live data. Capabilities need to be entities in a system, not boxes on a slide. They need to be connected to the services, contracts, suppliers, ADRs, and business cases that relate to them. When a new service is added or a supplier changes, the capability map updates because the underlying data changed, not because someone remembered to open PowerPoint.
Connecting capabilities to real things
A capability map on its own is a taxonomy. Useful, but limited. The real value comes when capabilities are connected to the operational artefacts that support them.
Capabilities to services. Which services in your catalogue support which capabilities? This is the most fundamental mapping and the one that immediately reveals gaps. If you have a defined capability with no supporting service, that is either a gap or a capability that does not actually exist in practice. Both are worth knowing.
Capabilities to ADRs. Architecture decisions affect capabilities. A decision to adopt a new API gateway pattern affects every capability that depends on API integration. Linking architecture decision records to the capabilities they affect gives you traceability from strategic intent down to technical choice.
Capabilities to business cases. Investment decisions fund the development or improvement of capabilities. Connecting business cases to the capabilities they target lets you answer questions like: "How much have we invested in Customer Onboarding over the past three years?" and "Which capabilities have had no investment at all?"
Capabilities to suppliers. If "Payment Processing" depends on Stripe, and "Identity Verification" depends on Onfido, that supplier-to-capability mapping is critical for risk assessment. If Onfido has an outage, you need to know instantly which capabilities are affected. If you are renegotiating the Stripe contract, you need to know the blast radius.
None of these connections are exotic. They are obvious once you think about them. The problem is that most organisations store these artefacts in different systems with no structured relationships between them. The capability map is in PowerPoint. The service catalogue is in a spreadsheet. The ADRs are in Confluence. The business cases are in email chains. Connecting them requires a shared system where these relationships are first-class entities, not manual cross-references.
Coverage analytics: measuring what matters
Once capabilities are connected to services, you can start asking genuinely useful questions. The one I find most valuable is this: what percentage of your defined capabilities are actually supported by governed services?
At an enterprise technology company I worked with, the answer was 62%. Nearly four in ten of their defined business capabilities had no formally governed service supporting them. That did not mean the capabilities were not being delivered — they were, but through shadow IT, manual workarounds, and undocumented processes. The organisation was governing its known services diligently while entire capability domains operated outside the governance perimeter.
Other coverage questions worth asking:
- Investment coverage: Which capabilities have received investment in the past two years, and which have been neglected? This reveals strategic drift — where the organisation says it is investing versus where it actually is.
- Single-supplier risk: Which capabilities depend on a single supplier? If that supplier fails, which business outcomes are affected?
- ADR coverage: Which capabilities have architecture decisions governing them, and which are ungoverned? Ungoverned capabilities tend to accumulate technical debt faster because there is no formal record of why things are built the way they are.
- Maturity distribution: Across your capability landscape, where are the pockets of maturity and where are the gaps? This is only useful if maturity is assessed periodically and connected to evidence, not self-reported once a year.
These are not vanity metrics. They directly inform investment prioritisation, risk management, and strategic planning. But they are impossible to calculate if your capability map lives in a static document disconnected from your operational data.
Getting started: practical advice from someone who has done this badly
If you are reading this and thinking "we need a capability map", here is what I would tell you based on having done this well twice and badly three times.
- Start with L0 and L1 only. Get your strategic domains and major capabilities defined first. This should take days, not weeks. If it is taking longer, you are over-thinking it. Aim for eight to twelve L0 capabilities and four to eight L1 capabilities under each. That gives you a map of roughly sixty to ninety capabilities, which is more than enough to start.
- Involve the business, not just architecture. The most common failure mode I have seen is an architecture team building a capability map in isolation. The resulting model is technically precise and business-irrelevant. Get a senior business stakeholder to validate every L0 and L1. If they do not recognise the language, change the language.
- Do not assess maturity on day one. The temptation to immediately colour-code every capability red, amber, or green is strong. Resist it. Get the structure right first. Connect capabilities to at least one other domain — services or suppliers, whichever is easier. Maturity assessments without operational connections are just opinions.
- Put it in a system, not a document. I know I am repeating myself, but this is the single biggest determinant of whether your capability map will still be useful in six months. If it lives in PowerPoint, Visio, or a static wiki page, it will decay. If it lives in a structured system that connects capabilities to services, decisions, and investments, it stays alive because the connections keep it honest.
- Expand to L2 only where you need to. Not every L1 needs L2 decomposition. Start with the domains that are most strategically important or most problematic. For a bank, that might be "Customer Onboarding" and "Regulatory Reporting". For a healthcare provider, it might be "Patient Records" and "Clinical Decision Support". Go deep where depth adds value, and leave the rest at L1 until there is a reason to decompose further.
A capability map that is 70% complete and connected to live data is infinitely more useful than one that is 100% complete and locked in a slide deck.
When capability mapping pays for itself
I will close with the moment I knew capability mapping had shifted from theoretical exercise to practical tool.
A CTO I worked with was presenting an investment case for a major platform migration. The board asked a reasonable question: "What business capabilities does this migration affect, and what is the risk if we delay it by a year?" In previous years, answering that question would have taken two weeks of analysis. This time, because the capability model was connected to the service catalogue and the supplier records, the answer took about four minutes. Twelve L2 capabilities, three of which were supported by a supplier whose contract was expiring in eight months.
The board approved the investment in that meeting. Not because the capability map was pretty, but because it gave them the information they needed to make a decision with confidence. That is what a business capability framework is for. Not taxonomy for its own sake, but connected intelligence that makes the organisation faster and more deliberate about where it invests, what it governs, and which risks it is actually carrying.
Start with L0 and L1. Connect them to something real. Expand from there. And whatever you do, do not let it become another PowerPoint that nobody updates.