Published: 2026-04-18 Category: What Is Offering relevance: Amplify
Direct Answer
Capability-based planning (CBP) is a strategic planning approach that focuses on what an organisation needs to be able to do — its capabilities — rather than on which specific systems, teams, or processes it currently operates. A capability is an abstract expression of business ability: “Customer Onboarding,” “Real-Time Inventory Visibility,” “Regulatory Reporting.” It exists at a level above processes (how we do it today) and systems (what we use today). This abstraction is what makes CBP strategically useful: capabilities persist across technology changes and organisational restructures. The enterprise may change its CRM, restructure its operations team, or outsource a function — but the need to “Manage Customer Relationships” remains. Capability-based planning connects strategy (what we need to be able to do to succeed) with investment (where we should focus technology and process improvement) and architecture (how our systems and processes support our capabilities today and in the future).
Key Takeaways
- A capability = what the organisation needs to do, not how it does it or what it uses.
- Capability vs process vs function: three distinct, frequently confused concepts.
- Capability maps have levels: Level 1 (6–12 domains) → Level 2 (15–40 capabilities) → Level 3 (detail for heat mapping).
- Heat mapping applies maturity, investment, or strategic importance scores to capabilities.
- In Sparx EA: Capability elements in the Strategy layer (ArchiMate), structured in a package hierarchy.
- Capabilities connect to applications (Realisation), processes (Association), and strategic goals (Influence/Association).
- Heat mapping in Sparx EA is implemented via tagged values and custom diagram styles.
- CBP is the bridge between executive strategy and architectural design.
Capability vs Process vs Function: The Three Most Confused Concepts
Before building capability maps, teams must be clear on what a capability is — and what it is not. These three concepts are confused with near-universal frequency:
Capability: What the organisation needs to be able to do. Abstract, stable, outcome-oriented. “Customer Credit Assessment.” Capabilities persist across technology changes — the capability exists whether you use an automated credit system or a manual process.
Process: How the organisation does something. Specific, sequential, step-oriented. “Receive application → validate identity → run credit check → generate decision → notify customer.” Processes implement capabilities. One capability may be implemented by multiple processes (automated and manual, different business units).
Function: What an organisational unit does — its responsibilities and activities. Often confused with capabilities because functions are also expressed as nouns (“Credit Management” as a function vs “Customer Credit Assessment” as a capability). Functions are organisational; capabilities are business-ability abstractions.
The practical test: Ask “could this capability be delivered differently (different process, different system, different team) while still being the same capability?” If yes, it is a genuine capability abstraction. If the definition implies a specific process or system, it is not a capability — it is a process or function description.
The Capability Hierarchy: Level 1 to Level 3
Capability maps are structured hierarchically. The number of levels depends on the use case:
Level 1: Business Domains (6–12) The highest level of abstraction — major business domains that represent distinct areas of business ability. Examples: Customer Management, Supply Chain, Financial Management, Technology Services, Human Capital Management, Risk and Compliance.
Level 1 capabilities rarely change. They reflect the fundamental nature of what the organisation does and are stable across years and even decades of organisational change.
Level 2: Core Capabilities (15–40) The working level of the capability model — specific, named capabilities within each Level 1 domain. Examples within Customer Management: Customer Onboarding, Customer Relationship Management, Customer Credit Assessment, Customer Communications, Customer Retention.
Level 2 is where most planning and heat mapping occurs. Investment decisions, gap analysis, and strategic initiatives are typically framed at Level 2.
Level 3: Sub-Capabilities (variable) Decomposition of Level 2 capabilities for use cases that require more granularity — particularly for heat mapping at a fine-grained level, or for specific architecture analysis (identifying which applications support which sub-capability). Not all Level 2 capabilities need Level 3 decomposition — only those where granularity adds analytical value.
Heat Mapping Capabilities
Heat mapping is the primary analytical output of capability-based planning. A heat map overlays a maturity, investment, or risk score on the capability hierarchy, making strategic priorities visible at a glance.
Maturity heat mapping: Each capability is scored (typically 1–5) for its current maturity level. A score of 1 = ad-hoc, unmanaged. A score of 5 = optimised, industry-leading. The heat map shows where the organisation is strong and where it has significant gaps. When overlaid with strategic importance (which capabilities are most critical to the strategy), the combination identifies where investment is urgently needed.
Investment heat mapping: Capability spend (or planned investment) is plotted against capability maturity. Capabilities receiving high investment but showing low maturity are efficiency concerns. Capabilities with high strategic importance but low investment are risk areas.
Application coverage heat mapping: Each capability is assessed for the quality of its application support. A capability with no application coverage is a manual or shadow-IT risk. A capability with too many applications is a rationalisation candidate.
How heat mapping works in Sparx EA: Tagged values on Capability elements store the maturity score, investment level, or coverage rating. Custom diagram styles apply colour coding based on tagged value ranges. The result is a colour-coded capability map diagram that auto-updates when tagged values change.
Connecting Capabilities to Applications, Processes, and Goals
The capability map is not useful in isolation — its value comes from its connections to other architectural domains:
Capability → Application (Realisation): An ArchiMate Realisation relationship from an Application Component to a Capability indicates that the application supports the delivery of that capability. Multiple applications can realise a single capability; this is normal and expected. The application-to-capability relationship is the foundation of portfolio rationalization — identifying which capabilities are over-supported (too many applications), under-supported (no application coverage), or adequately supported.
Capability → Business Process (Association/Realisation): A Business Process that implements a Capability connects the how (process) to the what (capability). This enables process improvement analysis: if a capability is rated low maturity, what process changes would improve it?
Capability → Strategic Goal (Influence/Association): Connecting Capabilities to the Strategy layer Goals or Outcomes that they support enables strategic traceability — “this application supports this capability which contributes to this strategic goal.” This is the chain that allows EA to demonstrate technology investment alignment with strategy.
Implementing Capability-Based Planning in Sparx EA
Package structure: Create a “Business Capabilities” package at the top level of the Business Architecture domain. Within it, create sub-packages for each Level 1 capability domain. Level 2 and Level 3 capabilities are elements within these packages.
Element type: Use the ArchiMate Capability element (introduced in ArchiMate 3.0, Strategy layer). The Capability element has a built-in stereotype in the ArchiMate MDG — do not use generic Class elements with a “Capability” stereotype, as this loses semantic precision.
Naming conventions: Noun + Qualifier is the standard naming pattern for capabilities: “Customer Onboarding,” “Real-Time Inventory Visibility,” “Regulatory Reporting.” Avoid verb-form naming (“Onboard Customers”) — this slides toward process naming.
Tagged values for heat mapping: Define MDG Technology tagged value groups on the Capability stereotype: Maturity Score (integer, 1–5), Strategic Importance (enumeration: High/Medium/Low), Application Coverage (enumeration: Full/Partial/None), Business Owner (text), Investment Band (enumeration: High/Medium/Low/None).
Diagram types: ArchiMate Strategy Diagrams display Capabilities in the hierarchy view. For heat maps, use a custom diagram style that applies background colour to Capability elements based on the Maturity Score tagged value. Sparx Services builds these custom styles as part of the Amplify engagement.
Linking to applications: Open each Application Component element in the Application Architecture package and add Realisation relationships to the Capabilities it supports. This is modeled in an Application-Capability traceability diagram, not on the capability map itself.
When CBP Delivers the Most Value
Capability-based planning delivers its highest value in:
Investment prioritisation: Showing the CIO and business leadership which capabilities need investment and which are over-served. A capability heat map is one of the most effective executive communication tools an EA practice can produce.
Application rationalization: Identifying applications supporting the same capabilities enables rationalization decisions — which applications can be decommissioned? Which should be the “system of record” for a given capability?
Strategic alignment assessment: When the organisation defines new strategic goals, the capability map answers “do we currently have the capabilities we need to execute this strategy, and at what maturity?”
Merger and acquisition architecture: In M&A due diligence, comparing capability maps of two organisations reveals overlaps (rationalization opportunities) and gaps (integration requirements).
Frequently Asked Questions
Q: How many capabilities should a Level 2 capability map have? For most organisations, 25–50 Level 2 capabilities is the right range. Fewer than 20 is often too coarse for useful heat mapping — gaps and overlaps are not visible. More than 60 becomes difficult to manage and maintain, and often indicates that Level 3 detail is being placed at Level 2. The goal is a Level 2 map where each capability is distinct, stable, and meaningful at the planning level.
Q: Can capabilities be reused across business units in the same organisation? Yes — and this is often the point. A capability like “Financial Reporting” or “Contract Management” may be required by multiple business units. In the capability model, the capability exists once. Different business units may have different applications realising it or different maturity scores assessed for their delivery of it. The capability map shows the enterprise view; assessment data (maturity scores, application coverage) can be segmented by business unit if needed.
Q: How do you get business leaders to engage with capability mapping? Start with a focused workshop, not a comprehensive model. Bring a draft Level 1 map (6–10 domains) and ask business leaders to validate the domains, identify the two or three capabilities they would most want to improve, and discuss what “good” looks like for those capabilities. This grounded conversation is more productive than presenting a complete technical model and asking for comment. Once leaders see the capability map used in investment planning and portfolio discussions, engagement follows naturally.
Q: What is the difference between a capability map and an operating model? A capability map shows what the organisation needs to be able to do — it is abstract and stable. An operating model shows how the organisation delivers value — it includes organisational structure, processes, governance, and technology. The capability map informs the operating model: the operating model describes how each capability is actually delivered. Both are valid architectural artefacts; they answer different questions. Capability maps are often built before operating model design, as the capability view establishes what must be delivered before addressing how to deliver it.
Q: How often should capability maps be updated? The capability hierarchy (Level 1 and Level 2) should be relatively stable — major updates once or twice a year as part of strategic planning cycles. Heat map scores (maturity, investment, coverage) should be updated more frequently — quarterly or semi-annually to reflect the current state. Application-to-capability linkages should be updated whenever application portfolio changes occur. The discipline of keeping the capability map current is an EA governance responsibility, not a one-time project.
Q: Can AI tools query the capability map in Sparx EA? Yes — with EA GraphLink deployed. Connected AI assistants (Copilot, Claude, Gemini, Agentforce) can query Capability elements and their relationships, tagged value scores, and application coverage directly from the Sparx EA repository via the MCP Server. An executive can ask “which capabilities have no application coverage?” or “what is the average maturity score for our Customer Management capabilities?” and receive answers from current repository data. This is one of the most valuable AI use cases in mature EA practices.
Ready to Build Your Capability Map?
Sparx Services’ Amplify engagement includes capability modeling as a core deliverable: capability hierarchy design, heat map configuration, ArchiMate Capability element setup, tagged value governance, and application-to-capability linkage framework.
We build the capability model alongside your architects so you own the methodology, not just the artefact.
