| name | business-capability-modeling |
| description | Models stable business capabilities, levels, ownership, maturity and heatmaps. Use when mapping organisational abilities, decomposing strategy, or assigning capability ownership. |
| aliases | ["business-capability-modelling","capability-mapping"] |
Business Capability Modelling
When to use
Use when defining what a business must be able to do, not how work is performed.
Objective
Produce a practical, concise, traceable architecture artefact that a coding agent can use to guide implementation or review.
Procedure
- Define scope.
- Identify capabilities in business language.
- Remove process, system and team names.
- Decompose to useful levels.
- Check MECE overlaps/gaps.
- Assign owners.
- Assess maturity/importance/pain where needed.
- Link to value streams, data and initiatives.
Required outputs
- Capability map
- Definitions
- Ownership
- Heatmap criteria where used
- Traceability links
Best-practice alignment
Align with BIZBOK business architecture practice: keep capabilities, value streams, processes, organisation, information concepts, initiatives and metrics separate, then link them from strategy to execution.
Quality checks
- Capabilities are stable abilities.
- Names are not process steps.
- Levels are balanced for decisions.
Avoid
Do not mirror the organisation chart.
Mini example
For a retail returns programme, model Manage Returns as the capability and decompose it into Authorise Return, Receive Returned Item, Assess Refund Eligibility and Recover Inventory Value. Do not name capabilities after systems such as Returns Portal; link the capability to the returns value stream, return request information concept, owner and heatmap criteria.
References
Verification
