How to Build an ArchiMate Capability Map in Sparx EA: A Complete Walkthrough

Published: 2026-04-18 Category: How To Offering relevance: Amplify

Direct Answer

Building an ArchiMate capability map in Sparx EA involves nine steps: defining what a capability means for your organisation, identifying Level 1 business domains, decomposing to Level 2 and Level 3 capabilities, creating ArchiMate Capability elements in Sparx EA, building the capability hierarchy diagram, assigning owners and maturity scores via tagged values, generating a heat map view, and linking capabilities to applications. This guide walks through each step in enough detail to execute the process. The most common failure point is Step 1 — if your organisation has not agreed on what a capability is versus a process or function, the rest of the model will be inconsistent. Spend time on Step 1 before opening Sparx EA.

Key Takeaways

Step 1 is the most important: agree on the capability definition before modeling.
Level 1 capabilities = business domains (6–12). Level 2 = core capabilities (15–40). Level 3 = detail where needed for heat mapping.
ArchiMate Capability element lives in the Strategy layer package — not the Business layer.
Named as noun + qualifier: “Customer Onboarding”, not “Onboard Customers”.
Tagged values carry governance data: owner, maturity score, strategic importance, application coverage.
Heat map is generated from tagged values with custom diagram colour styling.
Application linkage uses ArchiMate Realisation relationships.
The map is only as useful as the governance data it carries.

Step 1: Define What a “Capability” Means for Your Organisation

Before creating a single Sparx EA element, facilitate an agreement on the capability definition. Without this, different contributors will model different things at different levels of abstraction, and the resulting map will be inconsistent.

The definition to adopt: A capability is what the organisation needs to be able to do — independent of how it does it (process), who does it (role or team), or what it currently uses to do it (application or system). Capabilities are:

Outcome-oriented: “Real-Time Inventory Visibility” — what is needed. Not “Run MES Reports” — which describes how.
Stable across technology change: The capability “Customer Credit Assessment” exists whether it is performed manually, via an automated rule engine, or by an AI model. The capability persists; the implementation changes.
Abstract: A capability is not a process step, an organisational function, or a system feature. It is the business ability.

The practical test to use in workshops: “If we changed the technology completely but kept doing the same thing, would this capability still exist?” If yes, it is a genuine capability. If the definition implies a specific system (“SAP-based Financial Reporting”), it is a process or system description, not a capability.

Workshop approach: Run a 2-hour workshop with 4–6 business stakeholders and 2 architects. Present 3–5 draft Level 1 domains as a starting point. Have stakeholders validate, add, or rename. Do not attempt to build Level 2 in the same workshop — Level 1 consensus is the necessary prerequisite.

Step 2: Identify Level 1 Business Domains (6–12)

Level 1 capabilities are the highest-level business domains — major areas of business ability that are distinct and collectively exhaustive. For most organisations, 6–12 domains is appropriate.

Common Level 1 patterns:

For a general enterprise:

Customer Management
Product and Service Management
Supply Chain Management
Financial Management
Risk and Compliance
Technology Services
Human Capital Management
Partner and Ecosystem Management

For a financial services firm, modify accordingly:

Customer Acquisition and Onboarding
Product Portfolio Management
Credit and Risk Management
Transaction Processing
Regulatory Compliance
Technology and Operations
Finance and Treasury
People and Culture

Validation criteria:

Each Level 1 domain is distinct (no overlap)
Together they cover everything the organisation does (collectively exhaustive)
Each is meaningful at the executive level — a C-suite conversation would reference these domains
None are defined in terms of a specific technology or organisational unit

Step 3: Decompose to Level 2 (15–40 Capabilities)

For each Level 1 domain, decompose to the core capabilities within that domain. Level 2 is the working level — where heat mapping, investment decisions, and portfolio analysis are most commonly applied.

Guidelines for Level 2:

Each Level 2 capability should be distinct enough that it could have a different owner, different maturity, and different investment level from its siblings within the same Level 1 domain. If two capabilities always have the same owner and always receive the same investment, consider merging them.

Example: Customer Management → Level 2 decomposition:

Customer Acquisition
Customer Onboarding
Customer Identity Management
Customer Relationship Management
Customer Communications Management
Customer Credit and Risk Assessment
Customer Retention and Loyalty
Customer Feedback and Insights

Common mistakes at Level 2:

Including process steps (“Validate Customer Identity”) instead of capability abstractions
Including technology names (“SAP Customer Management”)
Creating too many capabilities (more than 60 Level 2 capabilities is usually Level 3 detail at Level 2)
Missing cross-cutting capabilities (Data Management, Analytics, Security are sometimes omitted because they cross all domains — include them in a Technology Services or Shared Services domain)

Step 4: Add Level 3 Where Needed

Not all Level 2 capabilities require Level 3 decomposition. Add Level 3 only where:

Heat mapping requires finer granularity than Level 2 provides
Application-to-capability linkage needs to be more specific than Level 2 allows
A specific strategic initiative focuses on a sub-domain of a Level 2 capability

Example: Customer Onboarding → Level 3 decomposition:

Identity Verification
Know Your Customer (KYC) Screening
Account Setup
Welcome and Activation
Initial Product Configuration

Avoid Level 3 for the entire map initially. Build Level 1 and Level 2 first, heat-map at Level 2, then add Level 3 where the heat map reveals that a Level 2 capability needs more granularity for action planning.

Step 5: Create ArchiMate Capability Elements in Sparx EA

Package structure:

In the repository, create the following package hierarchy:

“ Business Architecture [Top-level package] └── Business Capabilities [Package] ├── Customer Management [Package — Level 1] │ ├── Customer Acquisition [Capability element — Level 2] │ ├── Customer Onboarding [Capability element — Level 2] │ └── Customer Relationship Management [Capability element — Level 2] ├── Financial Management [Package — Level 1] │ └── ... Level 2 capabilities └── ... other Level 1 domains “

Creating Capability elements:

In Sparx EA with the ArchiMate MDG active:

Navigate to the Strategy layer toolbox (not the Business layer — Capability is a Strategy element in ArchiMate 3.x)
Drag the Capability element type from the toolbox into the appropriate Level 1 package
Name the element using the noun + qualifier convention
Add a brief description in the Notes field — one to two sentences defining what this capability covers

Do not use:

Generic Class elements with a “Capability” tagged value — this loses ArchiMate semantic precision
Business Function or Business Process elements to represent capabilities — these have different ArchiMate semantics
The ArchiMate Business layer for capabilities — Capability is a Strategy layer element

Step 6: Build the Capability Map Diagram

With elements created, build the hierarchy diagram that will serve as the visual capability map:

Create a new ArchiMate Strategy Diagram in the Business Capabilities package
Drag all Capability elements onto the diagram
Arrange in hierarchy: Level 1 domains across the top row; Level 2 capabilities clustered beneath their parent Level 1 domain
Use ArchiMate Composition relationships from Level 1 to Level 2 capabilities (Level 1 is composed of Level 2)
Set element sizing — Level 1 elements are typically wider than Level 2; Level 2 elements are uniform in size
Apply consistent colour to all Capability elements (a neutral grey or blue is standard before heat mapping colours are applied)

Auto-layout: Sparx EA’s Diagram Layout feature (Layout > Auto Layout) can assist with initial arrangement; manual adjustment is usually needed for a well-presented capability map.

Tip: Lock the diagram positions after layout is complete (right-click diagram → Properties → Lock Layout) to prevent accidental rearrangement during later editing.

Step 7: Assign Owners and Maturity Scores (Tagged Values)

With the MDG-governed tagged value definitions in place, populate governance data for each Capability element:

Business Owner: The executive or senior manager accountable for this capability’s performance. Not an IT role — a business role. “Chief Customer Officer” or “VP Supply Chain”, not “CRM System Owner”.

Maturity Score (1–5):

1 = Ad hoc — performed inconsistently, no standard approach
2 = Defined — standard approach exists but not consistently followed
3 = Managed — standard approach consistently followed, measured
4 = Optimised — continuously improved based on measurement
5 = Leading — industry-best-practice capability

Strategic Importance (High/Medium/Low): How critical is this capability to the organisation’s current strategic goals? This is assigned based on the strategic plan, not the current capability state.

Application Coverage (Full/Partial/None): Does this capability have adequate application support? Assessed after completing Step 9 (capability-to-application linkage).

Populating tagged values: Right-click each Capability element → Properties → Tags. Enter values for each tagged value definition.

Step 8: Generate the Heat Map View

The heat map is a second diagram — a styled copy of the base capability map that applies colour coding based on maturity scores or other tagged values.

Approach in Sparx EA:

Option A — Manual colour styling: Create a duplicate of the capability map diagram. Select each Capability element and change its background colour based on the Maturity Score tagged value (1 = red; 2 = orange; 3 = yellow; 4 = light green; 5 = dark green). This is manual but always works.

Option B — Scripted colour styling: Write a Sparx EA script (JavaScript in the scripting engine) that reads each Capability element’s Maturity Score tagged value and sets the element’s background colour programmatically. Run the script on the heat map diagram to auto-colour all elements. Re-run the script whenever maturity scores are updated.

Option C — Custom diagram style: Create a custom MDG diagram style that maps tagged value ranges to colours. This is the most sophisticated approach and produces automated heat map colouring without manual intervention. Sparx Services builds this as part of the Amplify engagement.

Dual heat maps: Many programs maintain two heat map diagrams — one coloured by Maturity Score (where are we today?) and one coloured by Strategic Importance (where do we need to be?). The combination makes investment priorities immediately visible: high strategic importance + low maturity = priority investment area.

Step 9: Link Capabilities to Applications

The application-to-capability linkage is what connects the capability map to the application portfolio and enables portfolio analysis.

Creating the linkage:

Create a new diagram — an ArchiMate Motivation or Application Architecture diagram — titled “Application to Capability Coverage”
Place the Capability elements from the Business Capabilities package on this diagram
From the Application Portfolio package, drag the relevant Application Component elements onto the same diagram
Add ArchiMate Realisation relationships from each Application Component to the Capabilities it supports

In Sparx EA: Select an Application Component element → right-click → Add → Realisation → navigate to the target Capability element.

Guidance on relationship creation:

One Application Component can realise multiple Capabilities
One Capability can be realised by multiple Application Components (this is normal)
Capabilities with zero realisation relationships should be flagged — they represent capabilities with no application support (manual process only or gap)
Capabilities with more than 3–4 Application Component realisations may be candidates for rationalization investigation

Updating Application Coverage tagged value: After creating all Realisation relationships, update the Application Coverage tagged value on each Capability element based on the coverage assessment: Full (well-supported by one or more applications), Partial (some application support but gaps exist), None (no application realises this capability).

Frequently Asked Questions

Q: How long does it take to build a Level 1–2 capability map for a medium-sized organisation? For a medium-sized organisation (1,000–10,000 employees, 50–150 applications), a Level 1–2 capability map with heat map and application linkage typically takes 6–10 weeks of focused effort. This includes the stakeholder workshops (Step 1–2), capability decomposition (Step 3), Sparx EA modeling (Steps 5–9), and stakeholder validation sessions. The elapsed time may be longer if workshop scheduling is constrained. Sparx Services delivers the capability map as the core output of the Amplify engagement.

Q: Should the capability map be built by architects or by business stakeholders? The content of the capability map is validated by business stakeholders — they know what capabilities the organisation needs. The modeling in Sparx EA is performed by architects. The most effective approach is a collaborative process: architects prepare drafts (based on industry reference models and initial stakeholder conversations), present drafts to business stakeholders for validation and correction, and iterate until the map reflects business-validated capabilities. Attempting to build the full map in the room with stakeholders is inefficient; presenting a near-complete draft and asking for input is much more productive.

Q: What is an industry reference capability model and should we use one? Industry reference capability models (Bian for banking, APQC Process Classification Framework, TM Forum for telecoms) provide starting-point capability taxonomies for specific industries. They are useful as a prompt list and completeness check — they surface capabilities you might not have thought of. However, they should not be adopted wholesale — every organisation has a unique strategic context that the reference model does not reflect. Use a reference model as a starting point for your Level 1 and Level 2 decomposition workshop, not as a final answer.

Q: Can we version-control the capability map over time? Yes. Sparx EA’s baseline feature captures the state of the Business Capabilities package at a point in time. Take a baseline before each major update cycle (typically at quarterly reviews). When comparing the current map to a baseline, Sparx EA highlights which capabilities were added, removed, or modified — providing a changelog of the capability evolution. This is useful for tracking how strategic priorities and technology investments are changing the capability landscape over time.

Q: How do we handle capabilities that don’t belong to a single business domain? Cross-cutting capabilities — Data Management, Cybersecurity, Analytics, Regulatory Compliance — do not neatly belong to one Level 1 domain. Two approaches: (1) Create a “Shared Services” or “Technology Services” Level 1 domain for capabilities that serve all domains; (2) Place the capability in the domain where it is primarily owned, and note cross-domain applicability in the element documentation. Both are valid. The first approach (Shared Services domain) is more visible to stakeholders; the second keeps the map cleaner. Sparx Services recommends the Shared Services domain approach for organisations with significant cross-cutting capabilities.

Q: Can AI tools query the capability map in Sparx EA? Yes — with EA GraphLink deployed. Connected AI assistants can query Capability elements, their maturity scores, strategic importance, application coverage, and realisation relationships. Example queries: “Which capabilities have a maturity score of 1 or 2 and high strategic importance?” or “How many applications realise the Customer Onboarding capability?” These queries are answered from current repository data. For organisations where executives want to ask capability-related questions in Copilot or Teams, the well-governed capability map becomes a strategic intelligence asset.

Ready to Build Your Capability Map?

Sparx Services’ Amplify engagement includes capability map delivery as a core workstream: workshop facilitation, capability hierarchy design, Sparx EA modeling, heat map configuration, and application-to-capability linkage.

We build the map alongside your architects and business stakeholders — you own the result and the methodology.

Talk to Sparx Services about capability mapping →