Quick Navigation
- Start here — What capabilities are
- Building a capability map
- Connecting capabilities to systems
- Connecting capabilities to outcomes
- Capability heat maps
- Using capability maps in decisions
- Common mistakes
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Most organisations describe themselves by their org chart — marketing, finance, operations. But org charts change. What the business does doesn't. I've seen capability maps that were just org charts in disguise — "Salesforce management" listed as a capability, "the KYC team" listed as a capability. Those aren't capabilities. They're temporary structures.
A business capability map shows what an organisation does — not how it does it, not who does it, not what system does it — and connects those capabilities to the systems, processes, and investments that deliver them.
Capabilities are stable. Org charts, processes, and technology change around them. When you map capabilities, you see the real structure of the business — and where technology supports, duplicates, or ignores it.
Keep it in mind.
1. What business capabilities are — And why they're not processes or org units
People confuse capabilities with processes, departments, or systems. When they do, the map reflects today's temporary structure instead of the enduring logic of the business.
A capability is a stable ability — something the business can do, regardless of how it's currently organised or what system currently supports it.
| Capability | Not a process | Not an org unit | Not a system |
|---|---|---|---|
| Customer Onboarding | "The 7-step onboarding workflow" | "The KYC team" | "Salesforce" |
| Risk Assessment | "The quarterly risk review" | "The risk department" | "The risk engine" |
| Order Fulfilment | "Pick, pack, ship" | "Warehouse operations" | "SAP WM module" |
The capability is the what. Processes, org units, and systems are the how. The how changes. The what is stable.
flowchart TD
CAP["🏢 Business Capability\nWhat the business can do\nStable, enduring"]
CAP --> P["📋 Process\nHow it is done today\nChanges over time"]
CAP --> O["👥 Org Unit\nWho does it today\nReorganises frequently"]
CAP --> S["💻 System\nWhat supports it today\nGets replaced"]
If you map processes, your map breaks every time a workflow changes. If you map org units, your map breaks every reorganisation. If you map capabilities, your map stays stable — and that stability is what makes it useful for architecture decisions.
Key properties of a capability: Stable — doesn't change when processes, teams, or systems change. Unique — each capability is distinct, no duplication. Technology-free — describes the ability, not the tool that delivers it. Hierarchical — can be decomposed into sub-capabilities at increasing levels of detail. Measurable — can be assessed for maturity, investment, and performance.
Capabilities are stable — processes, org units, and systems change around them.
Try it yourself — The capability test
Take three things your organisation does. Are they capabilities or something else?
| Thing | Capability, process, org unit, or system? | If not capability, what's the capability? |
|---|---|---|
| e.g. "The 7-step onboarding workflow" | Process | Customer Onboarding |
If you can't name the capability behind the process, you're mapping the wrong thing.
2. Building a capability map — Levels, categories, and how to run the exercise
You can't make architecture decisions based on capabilities if you don't have a map.
Building a capability map is a collaborative exercise — not a solo modelling task. It brings business and technology stakeholders together to agree on what the organisation does.
The process: Start with level 1 — the highest-level categories (Customer, Product, Operations, Finance, People, Technology). Decompose to level 2 — the major capabilities within each category. Optionally go to level 3 — sub-capabilities, only where detail is needed. Validate with business stakeholders — the map must reflect how the business sees itself. Keep it technology-free — resist the urge to name systems.
flowchart TD
L1["Level 1: Categories\nCustomer · Product · Operations\nFinance · People · Technology"]
L1 --> L2["Level 2: Capabilities\nCustomer Onboarding · Customer Support\nProduct Development · Product Launch"]
L2 --> L3["Level 3: Sub-capabilities\nIdentity Verification · Credit Check\nEligibility Assessment"]
Practical guidance: Level 1 — 6-10 categories. This is the lens, not the detail. Level 2 — 30-80 capabilities. This is the working level for most decisions. Level 3 — only where you need granularity. Don't decompose everything.
Common level 1 categories: Customer — Customer Onboarding, Customer Support, Customer Analytics, Customer Retention. Product — Product Development, Product Launch, Product Lifecycle, Product Pricing. Operations — Order Fulfilment, Inventory Management, Supply Chain, Quality Management. Finance — Financial Reporting, Accounts Payable, Accounts Receivable, Budgeting, Tax. People — Recruitment, Onboarding, Performance Management, Learning & Development. Technology — Infrastructure Management, Application Development, Security Operations, Data Management. Risk & Compliance — Risk Assessment, Regulatory Reporting, Audit Management, Incident Management.
Common mistakes in map-building: Naming capabilities after systems — "Salesforce management" isn't a capability. Describe the ability, not the tool. Mirroring the org chart — the map should outlast reorganisations. Use capability language, not department names. Too many levels — level 4+ is rarely useful. Stop at level 2 or 3. Solo modelling — architect's view ≠ business view. Run collaborative workshops. Over-engineering — 200+ capabilities at level 2 is too many. Target 30-80 at level 2.
Build the map collaboratively, keep it technology-free, decompose only where needed.
Try it yourself — The map draft
Draft your level 1 categories:
| Category | Example level 2 capabilities |
|---|---|
If you have more than 10 categories, you're too granular. If you have fewer than 6, you're too broad.
3. Connecting capabilities to systems — Which technology serves which capability
A capability map without technology is a business model. A capability map with technology is an architecture tool.
Once you have the map, the next step is to overlay which systems support each capability. This immediately reveals: Duplication — two systems doing the same thing. Gaps — capabilities with no system support. Over-reliance — one system supporting too many capabilities. Misalignment — a system supporting capabilities it wasn't designed for.
flowchart TD
C1["Customer Onboarding"] --> S1["CRM System"]
C2["Customer Support"] --> S1
C2 --> S2["Ticketing System"]
C3["Customer Analytics"] --> S3["BI Platform"]
C3 --> S4["Data Warehouse"]
C4["Order Fulfilment"] --> S5["ERP System"]
C4 --> S6["Warehouse Management"]
C5["Risk Assessment"] --> S7["Risk Engine"]
C5 --> S1["❌ CRM — duplicate?"]
In the example above, the CRM is being used for risk assessment — something it wasn't designed for. The capability map makes this visible.
The mapping matrix:
| Capability | Primary System | Secondary Systems | Coverage |
|---|---|---|---|
| Customer Onboarding | CRM | Identity verification service | Full |
| Customer Support | Ticketing system | CRM, Knowledge base | Full |
| Customer Analytics | BI Platform | Data warehouse | Partial — no real-time |
| Order Fulfilment | ERP | Warehouse management, Shipping API | Full |
| Risk Assessment | Risk Engine | CRM (shouldn't be here) | Overlapping |
Coverage assessment: Full — the capability is well-supported by appropriate systems. Partial — gaps exist, some aspects are unsupported or manual. Overlapping — multiple systems serve the same capability, potential duplication. Missing — no system supports this capability, manual process or gap. Misaligned — a system supports a capability it wasn't designed for.
The capability-to-system overlay reveals duplication, gaps, and misalignment that org charts hide.
Try it yourself — The overlay exercise
Pick three capabilities. Which systems support them?
| Capability | Systems | Coverage | Duplication? |
|---|---|---|---|
If you find overlap, you've found a rationalisation opportunity.
4. Connecting capabilities to outcomes — The link to strategic priorities
A capability map shows what the business does. But it doesn't show what matters most — or whether the right capabilities are being invested in.
Connecting capabilities to business outcomes bridges the gap between "what we do" and "what we're trying to achieve." This is where capability mapping becomes a strategic tool, not just an inventory.
Example: Business outcome: "Increase customer retention by 15% in 18 months." Depends on: Customer Analytics, Customer Support, Customer Retention. Requires investment in: Customer Analytics (currently partial coverage). De-prioritise: New product capabilities (not linked to this outcome).
flowchart TD
O1["🎯 Outcome: Increase retention by 15%"]
O2["🎯 Outcome: Reduce fulfilment cost by 20%"]
O3["🎯 Outcome: Launch 3 new products this year"]
O1 --> CA1["Customer Analytics"]
O1 --> CA2["Customer Support"]
O1 --> CA3["Customer Retention"]
O2 --> OP1["Order Fulfilment"]
O2 --> OP2["Inventory Management"]
O3 --> PD1["Product Development"]
O3 --> PD2["Product Launch"]
CA1 --> INV["💰 Investment priority: HIGH\n(partial coverage, blocking outcome)"]
CA2 --> INV2["💰 Investment priority: MEDIUM\n(full coverage, optimise)"]
OP1 --> INV3["💰 Investment priority: HIGH\n(cost reduction target)"]
Each capability can be scored on two dimensions: Strategic importance — how critical is this capability to achieving stated outcomes? 1-5 (low to critical). Current health — how well is this capability supported today? 1-5 (broken to excellent).
The investment signal: High impact, high health — maintain. Keep investing, optimise. High impact, low health — invest now. Critical gap, fund immediately. Low impact, high health — monitor. No new investment. Low impact, low health — tolerate or retire. Consider rationalising.
Outcomes tell you which capabilities matter most — and where to invest.
Try it yourself — The outcome linkage
Take your top business outcome. Which capabilities does it depend on?
| Outcome | Dependent capabilities | Current health | Investment needed? |
|---|---|---|---|
If a capability is blocking a high-priority outcome, it's an investment priority.
5. Capability heat maps — Identifying investment priorities
A capability map with 50+ capabilities is hard to read. Executives and architects need a visual summary — which capabilities are healthy, which are struggling, and which need investment.
A heat map overlays colour onto the capability map — green for healthy, amber for adequate, red for broken or missing. This creates an instant visual picture of where the organisation's strengths and weaknesses are.
flowchart TD
subgraph HEAT["Capability Heat Map — Visual Summary"]
direction LR
subgraph CUST["Customer"]
direction TB
CO["Onboarding 🟡"]
CS["Support 🟢"]
CA["Analytics 🔴"]
CR["Retention 🔴"]
end
subgraph PROD["Product"]
direction TB
PD["Development 🟢"]
PL["Launch 🟡"]
PP["Pricing 🟢"]
end
subgraph OPS["Operations"]
direction TB
OF["Fulfilment 🟢"]
IM["Inventory 🟡"]
SC["Supply Chain 🟡"]
end
subgraph FIN["Finance"]
direction TB
FR["Reporting 🟢"]
AP["Payable 🟢"]
AR["Receivable 🟡"]
end
end
Reading the heat map: 🟢 Green — well-supported, no immediate investment needed. 🟡 Amber — partially supported, improvement needed. 🔴 Red — poorly supported, missing, or blocking a strategic outcome.
What to do with it: Red capabilities linked to high-priority outcomes → invest now. Amber capabilities linked to medium-priority outcomes → plan for next cycle. Green capabilities not linked to any outcome → question whether investment is needed.
Scoring criteria for health: 5 - Excellent — fully automated, well-integrated, no known issues. 4 - Good — supported with minor gaps or manual workarounds. 3 - Adequate — functional but with significant limitations or technical debt. 2 - Poor — major gaps, heavy manual effort, frequent failures. 1 - Missing — no system support, entirely manual or not performed.
Heat maps turn a 50-capability map into an executive-ready investment signal.
Try it yourself — The heat map
Score your top 10 capabilities:
| Capability | Health (1-5) | Strategic importance (1-5) | Action |
|---|---|---|---|
Red + high importance = invest now. That's your priority list.
6. Using capability maps in architecture decisions — Practical application
A capability map that sits in a document and is never used has no value.
The map becomes valuable when it's used as a decision tool — in solution design, in investment discussions, in rationalisation, and in communication.
Practical uses: Solution design — "Which capabilities does this system support?" Boundaries align to capabilities. Investment prioritisation — "Which capabilities are under-invested?" Heat map drives funding. Rationalisation — "Are two systems serving the same capability?" Consolidation opportunity. Communication — "What does this technology change affect?" Capabilities translate to business language. Onboarding — "What does this organisation do?" The map is the fastest orientation tool.
flowchart TD
MAP["📐 Capability Map"] --> SD["Solution Design\nAlign system boundaries\nto capabilities"]
MAP --> IP["Investment\nPrioritise capabilities\nlinked to outcomes"]
MAP --> RAT["Rationalisation\nFind duplication\nand gaps"]
MAP --> COM["Communication\nTranslate technical changes\nto business language"]
MAP --> ONB["Onboarding\nFastest way to understand\nwhat the org does"]
Example — capability-driven solution decomposition: "We are building a new customer platform." → Which capabilities does it serve? → Customer Onboarding (L2), Customer Support (L2), Customer Analytics (L2), Customer Retention (L2). → Are these capabilities currently served by the same systems? → No — CRM, ticketing, BI, custom app. → Should they be? → Customer Onboarding + Support: yes, related. Customer Analytics: different data needs, keep separate. Customer Retention: new capability, build into the platform. → Decision: new platform covers Onboarding + Support + Retention. Analytics stays on existing BI platform.
A capability map is only valuable when it influences decisions — use it or lose it.
Try it yourself — The decision test
When was the last time your capability map influenced a decision?
| Decision type | Did the map influence it? | If not, why? |
|---|---|---|
| Solution design | ||
| Investment | ||
| Rationalisation |
If the answer is "never," your map is architecture theatre.
7. Common mistakes — Over-engineering the map vs keeping it useful
Capability maps are easy to over-engineer. A 300-capability map at five levels of depth is an academic exercise, not a decision tool.
Common mistakes:
| Mistake | Why it fails | Fix |
|---|---|---|
| Too many levels | Nobody reads past level 2 | Stop at level 2 unless specific detail is needed |
| Too many capabilities | 200+ at level 2 is unmanageable | Target 30-80 at level 2 |
| Naming after systems | "Salesforce management" isn't a capability | Describe the ability, not the tool |
| Mirroring the org chart | Map breaks every reorganisation | Use capability language |
| Built by one person | Architect's view ≠ business view | Run collaborative workshops |
| Never updated | Stale map loses credibility | Review annually or after major changes |
| Treated as a deliverable | Map made, filed, forgotten | Embed in decision processes |
| No outcome linkage | Map without strategic context is an inventory | Connect to business outcomes |
The capability map health check: How many level 2 capabilities? Healthy: 30-80. Unhealthy: 150+ (too granular) or <15 (too coarse). How many levels deep? Healthy: 2-3. Unhealthy: 5+ (over-engineered). Who contributed? Healthy: Business + technology. Unhealthy: Architect alone. When was it last reviewed? Healthy: Within the last 12 months. Unhealthy: More than 2 years ago. Is it used in decisions? Healthy: Referenced in investment cases, solution design. Unhealthy: Never mentioned outside EA team. Are outcomes linked? Healthy: Yes — each red/amber capability has an outcome connection. Unhealthy: No — map is an inventory only. Are capabilities technology-free? Healthy: Yes — no system names in capability names. Unhealthy: No — "SAP Order Management."
The minimum viable capability map: Level 1: 6-10 categories. Level 2: 30-50 capabilities. Coverage: all capabilities scored for health. Outcome linkage: top 5 business outcomes mapped to capabilities. Heat map: simple RAG visualisation. Review: annual refresh. This is enough to drive decisions. You don't need 200 capabilities and 5 levels to be useful.
A useful capability map is shallow, collaborative, current, and outcome-linked — nothing more.
Try it yourself — The health check
Run your capability map through the health check:
| Question | Your answer | Healthy or unhealthy? |
|---|---|---|
| How many level 2 capabilities? | ||
| How many levels deep? | ||
| Who contributed? | ||
| When was it last reviewed? | ||
| Is it used in decisions? |
Any unhealthy answer means your map needs attention.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
ORG["🏢 The Organisation\nWhat it does, not how it's structured"]
ORG --> MAP["📐 Capability Map\nStable abilities, technology-free\n30-80 at level 2"]
MAP --> SYS["💻 System Overlay\nWhich technology serves which capability"]
MAP --> OUT["🎯 Outcome Linkage\nWhich capabilities drive which business goals"]
MAP --> HEAT["🌡️ Heat Map\nWhere to invest, where to hold"]
SYS --> DEC["🧭 Architecture Decisions\nSolution design · Rationalisation · Investment"]
OUT --> DEC
HEAT --> DEC
DEC --> VAL["✅ Value\nShared understanding\nBetter investment decisions\nDurable system boundaries"]
The foundation:
Capabilities describe what the business does — not how, not who, not what system. They're stable; everything else changes around them. Connecting capabilities to outcomes turns an inventory into an investment tool. Without outcome linkage, a capability map is just a list. The map must be used to have value. Embed it in solution design, investment cases, and rationalisation — or it becomes architecture theatre. A capability map is the stable backbone of enterprise architecture. Build it once. Keep it current. Use it everywhere.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Business capability | What the business does, not how | Describe the ability, not the tool or team |
| Capability map | Stable structure of the organisation | Build collaboratively, 30-80 at level 2 |
| Capability vs process | Capabilities are stable, processes change | Keep the map technology-free |
| Capability-to-system overlay | Which technology serves which capability | Identify duplication, gaps, misalignment |
| Capability-to-outcome linkage | Which capabilities drive which business goals | Score health and strategic importance |
| Heat map | Visual investment signal | Red + high importance = invest now |
| Common mistakes | Over-engineering, solo-built, never updated | Keep shallow, collaborative, current |
How to know if this landed
You'll know this has landed when someone stops describing their organisation by org chart and starts describing it by capabilities. Can explain what a business capability is — and what it isn't. Has built or contributed to a capability map with business stakeholders. Can connect capabilities to systems and identify duplication or gaps. Has linked capabilities to business outcomes and scored investment priority. Uses the capability map in solution design and investment discussions. And reviews the capability map at least annually — updating for organisational change.
What changes when the mental model clicks
I've run this session with a large retail organisation where every technology investment was justified on its own — no portfolio view. Two teams built separate "customer analytics" platforms without knowing about each other. New architects spent weeks understanding how the business was structured. The gap at the start is usually not about understanding capabilities — it's about not having a stable reference point that survives reorganisations.
What changes after this session:
Teams stop justifying investments in isolation and start connecting them to capabilities and outcomes. The capability-to-system overlay exercise — "which systems serve which capabilities?" — is always the moment things click. People stop treating capability maps as deliverables and start treating them as decision tools. Their results get better. They stop building duplicate platforms when the real problem was that nobody had mapped the capabilities.
The heat map exercise tends to immediately change how teams think about their investment priorities. They start scoring capabilities on health and strategic importance. Their clarity goes up. They stop investing in green capabilities when the real problem was that red capabilities were blocking strategic outcomes.
Book a Workshop
Ready to build a capability map that actually drives decisions?
or
1.5-day workshop includes collaborative capability map-building exercise with your business stakeholders, capability-to-system overlay — finding duplication and gaps in your real portfolio, outcome linkage modelling — connecting capabilities to your strategic priorities, heat map creation — investment-ready visualisation for leadership, integration planning — embedding the map in architecture review and investment governance, and business capability map template + capability-to-outcome linkage model.