Can capabilities be reused across business units in the same organization?

Yes, and that is often the point. A capability like Financial Reporting or Contract Management may be required by several business units. In the model the capability exists once; different units may have different applications realizing it or different maturity scores. The map shows the enterprise view, and assessment data can be segmented by business unit if needed.

Insight · Business architecture

What Is Capability-Based Planning? Definition and EA Implementation Guide

By Sparx Services · May 4, 2025 · 9 min read

The short version: capability-based planning (CBP) focuses on what an organization needs to be able to do — its capabilities — rather than which systems, teams, or processes it currently runs. A capability is an abstract expression of business ability: “Customer Onboarding,” “Real-Time Inventory Visibility,” “Regulatory Reporting.” It sits above processes (how we do it today) and systems (what we use today), and that abstraction is what makes it strategically useful.

Capabilities persist across technology changes and reorganizations. The enterprise may swap its CRM, restructure operations, or outsource a function — but the need to “Manage Customer Relationships” remains. CBP connects strategy (what we must be able to do) with investment (where to focus improvement) and architecture (how systems and processes support those capabilities today and in future). It is one of the most load-bearing techniques in business architecture.

Capability vs process vs function

Before building capability maps, a team has to be clear on what a capability is — and isn’t. Three concepts get confused with near-universal frequency.

Capability: what the organization needs to be able to do. Abstract, stable, outcome-oriented. “Customer Credit Assessment.” It persists whether you use an automated credit system or a manual process.

Process: how the organization does something. Specific, sequential, step-oriented. “Receive application → validate identity → run credit check → generate decision → notify customer.” Processes implement capabilities, and one capability may be implemented by several processes.

Function: what an organizational unit does — its responsibilities. Often confused with capabilities because both read as nouns (“Credit Management” as a function vs “Customer Credit Assessment” as a capability). Functions are organizational; capabilities are business-ability abstractions.

The practical test: ask “could this be delivered differently — different process, system, or team — while still being the same thing?” If yes, it is a genuine capability. If the definition implies a specific process or system, it is a process or function description, not a capability.

The capability hierarchy: Level 1 to Level 3

Capability maps are structured hierarchically, and how many levels you need depends on the use case.

Level 1 — Business Domains (6–12). The highest abstraction: major domains representing distinct areas of business ability — Customer Management, Supply Chain, Financial Management, Technology Services, Human Capital Management, Risk and Compliance. Level 1 rarely changes; it reflects the fundamental nature of what the organization does and stays stable across years.

Level 2 — Core Capabilities (15–40). The working level: specific, named capabilities within each domain. Within Customer Management: Customer Onboarding, Customer Relationship Management, Customer Credit Assessment, Customer Communications, Customer Retention. Most planning and heat mapping happens here.

Level 3 — Sub-Capabilities (variable). Decomposition of Level 2 for cases that need more granularity — fine-grained heat mapping, or analysis identifying which applications support which sub-capability. Not every Level 2 capability needs Level 3; only those where granularity adds analytical value.

Heat mapping capabilities

Heat mapping is the primary analytical output of CBP. A heat map overlays a maturity, investment, or risk score on the hierarchy, making strategic priorities visible at a glance.

Maturity heat mapping: each capability scored (typically 1–5) for current maturity, from ad-hoc (1) to optimized and industry-leading (5). Overlaid with strategic importance, it shows where investment is urgently needed. Investment heat mapping: spend plotted against maturity — high investment with low maturity is an efficiency concern; high importance with low investment is a risk. Application coverage heat mapping: each capability assessed for application support — no coverage is a manual or shadow-IT risk; too many applications is a rationalization candidate.

In Sparx EA, tagged values on Capability elements store the maturity score, investment level, or coverage rating. Custom diagram styles apply color coding based on tagged-value ranges, producing a color-coded capability map that auto-updates as values change.

Connecting capabilities to applications, processes, and goals

The capability map earns its value through its connections to other architectural domains.

Capability → Application (Realization): an ArchiMate Realization relationship from an Application Component to a Capability says the application supports that capability. Multiple applications can realize one capability — normal and expected — and this relationship is the foundation of application portfolio rationalization: which capabilities are over-supported, under-supported, or adequately supported.

Capability → Business Process (Association/Realization): connecting the how (process) to the what (capability) enables process-improvement analysis — if a capability rates low, what process changes would lift it? Capability → Strategic Goal (Influence/Association): linking capabilities to the Goals or Outcomes they support gives strategic traceability — “this application supports this capability which contributes to this goal” — the chain that lets EA demonstrate investment alignment with strategy.

Implementing CBP in Sparx EA, step by step

The setup is methodical, and the order matters. Build the structure first, then the semantics, then the analysis layer.

Build the package structure

Create a “Business Capabilities” package at the top of the Business Architecture domain, with sub-packages for each Level 1 domain. Level 2 and Level 3 capabilities are elements within these packages.

Use the right element type

Use the ArchiMate Capability element (Strategy layer, introduced in ArchiMate 3.2). Don’t use generic Class elements with a “Capability” stereotype — that loses semantic precision.

Name and tag for heat mapping

Use Noun + Qualifier naming (“Real-Time Inventory Visibility”), avoiding verb forms that slide toward process naming. Define tagged values on the Capability stereotype: Maturity Score (1–5), Strategic Importance, Application Coverage, Business Owner, Investment Band.

Link applications and build the views

Add Realization relationships from each Application Component to the capabilities it supports, modeled in an application-capability traceability diagram. For heat maps, apply a custom diagram style that colors Capability elements by Maturity Score.

When CBP delivers the most value

Capability-based planning pays off hardest in four situations.

Investment prioritization: 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: spotting applications that support the same capabilities, so you can decide which to decommission and which is the system of record. Strategic alignment: when new goals are set, the map answers “do we have the capabilities to execute this, and at what maturity?” Mergers and acquisitions: in due diligence, comparing two organizations’ capability maps reveals overlaps (rationalization opportunities) and gaps (integration requirements).

Done well, CBP is the bridge between executive strategy and architectural design — and building that bridge into your practice is exactly the kind of capability we help architecture teams develop.

Frequently asked questions

How many capabilities should a Level 2 capability map have?

For most organizations, 25 to 50 Level 2 capabilities is the right range. Fewer than 20 is often too coarse for useful heat mapping — gaps and overlaps don’t show. More than 60 becomes hard to maintain and usually means Level 3 detail is sitting at Level 2. Aim for a map where each capability is distinct, stable, and meaningful at the planning level.

Can capabilities be reused across business units?

Yes, and that is often the point. A capability like “Financial Reporting” or “Contract Management” may be required by several units. In the model it exists once; different units may have different applications realizing it or different maturity scores. The map shows the enterprise view, and assessment data can be segmented by business unit where needed.

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), ask leaders to validate the domains, identify the two or three capabilities they most want to improve, and discuss what “good” looks like. That grounded conversation beats presenting a finished technical model. Once leaders see the map used in investment planning, engagement follows.

What is the difference between a capability map and an operating model?

A capability map shows what the organization needs to be able to do — abstract and stable. An operating model shows how it delivers value: structure, processes, governance, technology. The map informs the operating model; it establishes what must be delivered before you design how. Both are valid artifacts answering different questions, and maps are usually built first.

How often should capability maps be updated?

The hierarchy (Level 1 and 2) should be relatively stable — major updates once or twice a year with strategic planning. Heat-map scores (maturity, investment, coverage) update more often, quarterly or semi-annually. Application-to-capability links update whenever the portfolio changes. Keeping the map current is an ongoing governance responsibility, not a one-time project.

Can AI tools query the capability map in Sparx EA?

Yes, where the repository is exposed to AI assistants through a suitable connectivity layer. A connected assistant can query Capability elements and their relationships, tagged-value scores, and application coverage from the repository — answering “which capabilities have no application coverage?” or “what is the average maturity for our Customer Management capabilities?” from current data. The prerequisite is a well-governed model: the quality of the answers is bounded by the quality of the repository.

Build a capability map your executives actually use.

Talk to a practitioner about capability hierarchy design, heat-map configuration, and application-to-capability linkage in your Sparx EA repository.

Book a call →

Keep reading