The decision
Build a capability map without drawing the org chart
The enterprise needs a stable view of what it must be able to do, but the first draft mirrors departments, applications, products, process steps, or a borrowed reference model instead of enduring business abilities.
- Decision supported
- What stable capability vocabulary and level of detail are sufficient for the current enterprise decision?
- Start with
- A named decision, representative scenarios, business-model context, and existing capability, organization, process, and technology evidence.
- Boundary
- Creates a capability baseline; it does not assess performance, reproduce a reference model, or encode the current organization and application landscape.
When to use this method
- The enterprise has no governed capability baseline for a real decision
- Existing maps differ by business unit, initiative, consultant, or tool
- Capability names are dominated by organizational or technology labels
- Strategy, portfolio, operating-model, or impact analysis needs a common business vocabulary
Evidence to bring
- Decision, scope, scenarios, audience, and required level of precision
- Business model, products and services, stakeholders, and value propositions
- Representative value streams, business objects, policies, outcomes, and measures
- Existing organization, process, application, initiative, and reference-model material as evidence rather than structure
- Business content owners, subject-matter experts, modeling rules, and repository constraints
The method
Work through the decision.
- State the decision the map must support and limit initial depth to the branches needed for that decision
- Describe what the enterprise must be able to do independently of who performs it, how work flows, or which technology enables it
- Draft capability names in stable business language and write definitions before arranging hierarchy or assigning color
- Separate capabilities from organizations, roles, processes, activities, products, business objects, outcomes, applications, and projects while preserving those terms as related evidence
- Group and decompose capabilities using coherent business scope, outcomes, rules, and business-object lifecycles rather than visual symmetry
- Normalize synonyms, near-duplicates, mixed abstraction levels, and borrowed terms whose meaning does not fit the enterprise context
- Test every material capability across more than one value stream, product, organization, or scenario, including a plausible reorganization or technology change
- Assign stable identifiers, sources, status, steward, effective date, confidence, and unresolved issues before assessment or initiative mapping
- Validate the decision-relevant baseline with business content owners and publish the level contract, naming rules, and deferred-decomposition backlog
What the work should produce
- Decision-scoped capability map and level contract
- Capability definitions, identifiers, sources, and stewardship
- Classification and modeling rules
- Scenario validation and duplicate-term findings
- Governed issues and deferred-decomposition backlog
When to stop
Stop when the map provides a stable, governed vocabulary at sufficient depth for the stated decision and the next level would not change assessment, investment, accountability, dependency, sequence, scope, or risk. Do not complete every branch merely for visual symmetry.
Worked example · Northstar v1.1
Separate the promise from the resources that enable it.
In the fictional Northstar v1.1 case, a scheduling-platform proposal prompts a closer look at service promises. These selected capability definitions keep customer commitments distinct from scheduling people and reserving parts.
| ID | Capability | Decision-relevant definition and boundary | Accountable executive |
|---|---|---|---|
| C-110 | Service Promise Management | Propose, validate, communicate, monitor, and change a customer commitment. Uses resource signals but does not plan work, reserve parts, assign technicians, or confirm final customer value. | EVP Service Operations |
| C-130 | Resource Scheduling | Match authorized demand to qualified people, time, geography, and capacity. Does not establish part status or own the customer promise. | VP Field Service |
| C-140 | Parts Availability Management | Determine, reserve, position, consume, release, and expire required part availability. Does not assign technicians or make customer commitments. | VP Supply Operations |
The boundaries make the dependency visible: improving scheduling alone does not establish who owns the customer promise or whether part availability can be trusted. Keep those relationships in the architecture without merging them into one capability.
Editable template · Version 1.1
Capability definition, decomposition, and validation workbook
Create stable capability definitions, test decomposition depth, expose orphaned or weak records, and structure a validation workshop without reproducing the organization chart.
Inside the workbook
- Read me and modeling rules
- Capability register
- Formula-driven decomposition QA
- Validation workshop record
- Completed Northstar example
Use it with your own evidence
- Define the decision and scenarios first.
- Enter capabilities and parent relationships.
- Review automated QA flags.
- Validate definitions, levels, ownership, and scenario coverage with business experts.
Does not provide an authoritative industry reference model or prove that a capability belongs at a particular level without enterprise context and governance.
Continue the work
Which branches require decomposition, validation, assessment, or connection to value and information?
Related Field Notes
- Start Small, Build for the Enterprise: A Practical Guide to Standing Up a Business Architecture Practice
- The Minimum Viable Business Architecture Package
Reference material
- Business Capability Mapping Guide ↗Ardoq
- TOGAF Series Guide: Business Capabilities, Version 2 ↗The Open Group · Account required
- Capability Mapping — Public Video ↗Business Architecture Guild