Business Capability Mapping

A business capability is a stable description of what an organization does — independent of org structure, process, or technology.

At a glance

• What it is: A verb-plus-noun description of something the business does (e.g. “Assess Credit Risk”), plus a capability map that arranges these into a hierarchy or heat-mapped grid.
• Why it matters: Capabilities stay stable across reorgs and platform migrations, giving architecture a foundation that doesn’t go stale every time the org chart changes.
• For developers: think of a capability map as the enterprise-level equivalent of a bounded-context map — use one to find out which team actually owns the business logic you’re about to touch.
• When to use it: As the first artifact of an EA practice, before app rationalization, gap analysis, or roadmapping.
• When not to use it: As a substitute for a process model — a capability says what, not the sequence of how.
• Prerequisites: A basic understanding of Enterprise Architecture and the organization’s business areas.

Mental model

graph TD
    L0["L0: Manage Customer Orders"]
    L0 --> L1a["L1: Capture Order"]
    L0 --> L1b["L1: Fulfill Order"]
    L0 --> L1c["L1: Handle Returns"]

Capabilities decompose top-down: a small number of high-level (L0) capabilities, each broken into more specific L1/L2 capabilities as needed. The names never change based on which team or system does the work today.

Step-by-step walkthrough

1. List the business functions the organization performs, ignoring current team names and systems.
2. Group them into 10–30 top-level (L0) capabilities, phrased as verb-plus-noun.
3. Decompose each L0 into L1 (and, if needed, L2) sub-capabilities.
4. Check every name for department/product jargon and rename until it’s technology- and org-agnostic.
5. Validate the map with business stakeholders, not just architects.

Worked example

A retail bank’s order-taking work is split across “Branch Ops”, “Digital Channels”, and “Contact Center” teams, each with its own system.

• Input: three teams, three systems, no shared vocabulary for the work they all do.
• Process: identify the common capability all three actually support.
• Output: one L0 capability, “Manage Customer Orders”, with L1 children “Capture Order”, “Fulfill Order”, and “Handle Returns” — true regardless of which team or system executes them.

Common use cases

Use case	When to use	Notes
Heat-mapping investment	Prioritizing where to invest first	Color capabilities by maturity, cost, or risk
Application rationalization	Multiple systems, unclear ownership	Link apps to capabilities to expose duplication and gaps
M&A integration	Merging two organizations with different org charts	Capability map gives a shared reference point independent of either org’s structure

Advanced details

• Granularity: start with L0 only (10–30 capabilities); resist decomposing to L2 everywhere before there’s a reason to.
• Ownership: the map should be centrally maintained and periodically reviewed, not a one-time deliverable.
• Capability vs. process: a capability is what (“Assess Credit Risk”); a process is how (the ordered steps to do it). Don’t conflate the two in the map.
• Starting from a taxonomy: rather than naming capabilities from a blank page, many enterprises start from a published cross-industry taxonomy like the APQC Process Classification Framework (PCF) and tailor its categories to their own vocabulary and structure, instead of adopting it verbatim.

Quick reference

Term	Meaning
Capability	Stable verb-plus-noun description of what the business does
Capability map	Full hierarchy or heat map of all capabilities
L0 / L1 / L2	Decomposition levels, from high-level to detailed
Heat map	Capabilities colored by an assessment dimension (e.g. maturity, risk)

Troubleshooting

Symptom	Likely cause	Fix
Map looks like the org chart	Capabilities named after departments	Rename using verb-plus-noun phrasing, independent of team
Map needs rework after every reorg	Capabilities defined too close to current structure	Re-derive names from business outcomes, not who does the work today
Stakeholders can’t agree on names	Jumped straight to naming without validating scope	Anchor on outcomes (“Assess Credit Risk”), not activities or systems

Check your understanding

• Why does “Manage Salesforce Accounts” make a poor capability name?
• Take a function you know well and phrase it as a capability name — then test whether it would survive a reorg or a platform migration.

Related pages

Part of Introduction to Enterprise Architecture. See also The Four Architecture Domains for how capability mapping fits into the Business Architecture domain, and the Glossary for term definitions.