Business Capability Map

Business capability map for enterprise architects

A business capability map is the structural artefact that names what the business does, independent of how or who does it. This page covers how to build one, the heatmap dimensions that turn it into a decision tool, and how it anchors application portfolio management.

By Jack Finnegan · Updated 21 May 2026

Build your map Enterprise architecture software

What it is

What a business capability map actually is

A business capability map is a hierarchical model of what a business does - the activities the business performs to deliver value to customers and stakeholders. It is deliberately abstracted from how the work is done (the process), who does it (the org), and the systems that support it (the application landscape). The model typically decomposes from 5-12 top-level capabilities into more granular sub-capabilities at level 2 and level 3.

The discipline sits inside enterprise architecture but speaks the language of business strategy. A well-built capability map is what allows executives to discuss the business at the right level of abstraction, and what allows architecture to anchor application portfolio management, target operating model design, and modernization roadmaps to something that does not shift every time the org chart changes.

The problem today

Most capability maps document how, not what

The familiar failure mode: a workshop produces a capability map that is actually a process model or an org chart in disguise - 'Sales' as a capability decomposes into 'Hold weekly sales meeting' or 'Sales Manager EMEA'. The map is useful for nothing because it shifts with every reorganisation and every process change.

The fix is rigorous abstraction. A capability is what the business does, not how or who. 'Generate qualified leads' is a capability; 'Run the weekly marketing standup' is not. Map producers need to keep asking 'would this still be a capability if we restructured the team, changed the tooling, and rewrote the process?' - if the answer is no, it is not a capability.

Four pillars

Four pillars of a useful capability map

Hierarchical decomposition

Level 1 (5-12 top-level), level 2, level 3 with owners. Beyond level 3 most maps lose their usefulness as a strategic artefact.

Independence from how/who/where

Capabilities are about what, not how. They survive reorganisations, process redesigns, and system migrations.

Mapped to applications and processes

The map only becomes useful when capabilities link to the applications, processes, and data that operationalise them. Otherwise it is a hierarchy without a payload.

Heatmap for decisions

Strategic importance, current performance, planned investment - the dimensions that turn the map into a portfolio-decision tool rather than a wall poster.

Process Map

Building a capability map as a process

The construction sequence - executive workshop, level-1 identification, decomposition, mapping, heatmap, use, refresh.

Open in editor

Building a business capability map as a process

The construction process for a business capability map rendered as a BPMN 2.0 diagram. Workshop with executives, identify level-1 capabilities, decompose to lower levels, map to applications, heatmap, and refresh on cadence.

Workshop with executives to align on business strategy and operating model.
Identify level-1 business capabilities (5-12 typically) - the highest-level things the business does.
Decompose to level 2 and level 3 with capability owners.
Map applications, processes, and data domains to each capability.
Heatmap each capability against strategic importance, current performance, and planned investment.
Use the map to drive portfolio decisions - applications, investments, capability gaps.
Refresh on cadence (typically annually) or on material change.

What this diagram shows: Construction starts when capability mapping is mandated by an EA or strategy programme. The executive workshop aligns on business strategy and the level of abstraction. Level-1 identification produces the 5-12 top-level capabilities; decomposition takes them to level 2 and 3. Application and process mapping ties the model to operational reality; heatmapping adds the decision dimensions. The use task drives portfolio decisions; the refresh task schedules the annual cycle.

FAQ

Frequently asked questions

What is a business capability map?

A hierarchical model of what the business does - independent of how, who, or where. Typically 5-12 top-level capabilities decomposed to level 2 and level 3, with each capability linked to the applications, processes, and data that operationalise it.

What's the difference between a capability map and a process map?

A capability map answers what the business does; a process map answers how. The same capability ("Generate qualified leads") can be operationalised by many different processes; the same process can support multiple capabilities. Both artefacts are useful but they serve different purposes - capability maps drive strategic decisions, process maps drive operational execution.

What's the difference between a capability map and an org chart?

Capabilities are independent of who does them; org charts capture who. A good capability map survives reorganisations. An org chart by definition does not.

How deep should a capability map go?

Most strategic capability maps stop at level 3 (level 1 = 5-12 top-level; level 2 = 20-80; level 3 = up to a few hundred). Beyond level 3 the maps start to lose their abstraction discipline and become process or task lists.

How is the heatmap built?

Each capability is scored against several dimensions: strategic importance (does this capability differentiate us?), current performance (how well is this capability delivered today?), and planned investment (where is the firm spending to improve this?). The combined scores drive portfolio decisions.

Does BA Copilot help with capability mapping?

BA Copilot produces the BPMN process maps that anchor each capability to operational reality - making the capability layer concrete rather than abstract. The capability hierarchy itself is typically maintained in an EA platform; BA Copilot complements it by producing the process artefacts that prove the capability is real.

Jack Finnegan, Founder & CEO, BA Copilot

From the founder

14 Years in BPMN

I'm Jack Finnegan. I've spent fourteen years working hands-on with BPMN, as an analyst, an engineer, and a product director, where I felt every sharp edge of legacy business process platforms.

BA Copilot is the platform I wanted on every one of these projects: AI-first process management, which treats BPMN as a first-class output rather than an export afterthought.

Jack Finnegan on LinkedIn

Make capabilities concrete

Open BA Copilot, model the processes that operationalise each capability, and produce the BPMN evidence that the capability is real - not just a box on a slide.