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

Building a capability map is nine steps of structured work, but the whole thing stands or falls on Step 1. If your organization hasn’t agreed what a capability is, the rest of the model will be inconsistent. Spend the time there before you open Sparx EA.

For an architect, this is the job of turning what the business can do into a structure leaders can plan against. The steps below take the structure from workshop to model. The decisions in Steps 1 to 4, what a capability is, which domains exist and where the hierarchy stops, stay with the architect and the business owners. After Step 9, a short section shows how AI-augmented work changes the modeling steps.

A capability map in Sparx EA takes you from a shared definition of “capability,” through Level 1-3 decomposition, into modeled ArchiMate elements, and out to a heat map and application linkage. Each step is described in enough detail to execute.

The nine steps at a glance

Step 1: Define what a “capability” means for your organization

Before creating a single element, facilitate agreement on the capability definition. Without it, contributors model different things at different levels of abstraction and the map turns out inconsistent.

The definition to adopt: a capability is what the organization needs to be able to do: independent of how it does it (process), who does it (role), or what it uses (application). Capabilities are:

• Outcome-oriented: “Real-Time Inventory Visibility” (what is needed), not “Run MES Reports” (how).
• Stable across technology change: “Customer Credit Assessment” exists whether done manually, by a rule engine, or by a model. The capability persists; the implementation changes.
• Abstract: not a process step, an organizational function, or a system feature. It is the business ability.

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

Workshop approach: run a 2-hour session with 4-6 business stakeholders and 2 architects. Present 3-5 draft Level 1 domains; have stakeholders validate, add, or rename. Don’t attempt Level 2 in the same session. Level 1 consensus is the prerequisite.

Step 2: Identify Level 1 business domains (6-12)

Level 1 capabilities are the highest-level business domains, distinct, and collectively exhaustive. For most organizations, 6-12 is right.

A general-enterprise pattern: Customer Management, Product and Service Management, Supply Chain Management, Financial Management, Risk and Compliance, Technology Services, Human Capital Management, Partner and Ecosystem Management. A financial-services firm would adapt: 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 domain is distinct (no overlap); together they cover everything the organization does; each is meaningful at the executive level; none is defined in terms of a specific technology or organizational unit.

Step 3: Decompose to Level 2 (15-40 capabilities)

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

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

Example. Customer Management decomposed: 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: including process steps (“Validate Customer Identity”) instead of capabilities; including technology names (“SAP Customer Management”); creating too many (more than ~60 at Level 2 is usually Level 3 detail); missing cross-cutting capabilities like Data Management, Analytics, and Security.

Step 4: Add Level 3 where needed

Not all Level 2 capabilities need Level 3. Add it only where heat mapping needs finer granularity, application-to-capability linkage needs to be more specific, or a strategic initiative focuses on a sub-domain.

Example. Customer Onboarding decomposed: Identity Verification, Know Your Customer (KYC) Screening, Account Setup, Welcome and Activation, Initial Product Configuration.

Avoid Level 3 across the whole map initially. Build Levels 1 and 2 first, heat-map at Level 2, then add Level 3 only where the heat map shows a capability needs more granularity for action planning.

Step 5: Create ArchiMate Capability elements in Sparx EA

In the repository, create a package hierarchy under Business Architecture › Business Capabilities, with a Level 1 package per domain and Level 2 Capability elements inside each.

With the ArchiMate MDG active:

1. Navigate to the Strategy layer toolbox. Capability is a Strategy element in ArchiMate 3.x, not a Business-layer element.
2. Drag the Capability element into the appropriate Level 1 package.
3. Name it with the noun + qualifier convention.
4. Add a one-to-two-sentence definition in the Notes field.

Do not use generic Class elements with a “Capability” tagged value (this loses ArchiMate semantic precision), use Business Function or Business Process elements for capabilities, or place capabilities in the Business layer.

Step 6: Build the capability map diagram

With elements created, build the hierarchy diagram that serves as the visual map:

1. Create a new ArchiMate Strategy diagram in the Business Capabilities package.
2. Drag all Capability elements onto it.
3. Arrange in hierarchy. Level 1 domains across the top, Level 2 clustered beneath their parent.
4. Use ArchiMate Composition relationships from Level 1 to Level 2.
5. Size Level 1 elements wider than Level 2; keep Level 2 uniform.
6. Apply a consistent neutral color before heat-map coloring is added.

Sparx EA’s Diagram Layout feature can assist with initial arrangement; manual adjustment is usually needed for a well-presented map. Lock the diagram positions after layout to prevent accidental rearrangement.

Step 7: Assign owners and maturity scores (tagged values)

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

Business Owner, the business executive accountable for this capability’s performance. A business role (“Chief Customer Officer”), 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, consistently followed and measured
• 4 = Optimized, continuously improved based on measurement
• 5 = Leading, industry-best-practice capability

Strategic Importance (High/Medium/Low): how critical to current strategic goals, assigned from the strategic plan, not current capability state.

Populate these via right-click each Capability › Properties › Tags. Application coverage needs no tagged value of its own, because it follows from the Realization relationships in Step 9. Query it from the model instead of storing it.

Step 8: Generate the heat map view

The heat map is a second diagram, a styled copy of the base map color-coded by maturity or other tagged values. Three approaches in Sparx EA:

• Manual color styling, duplicate the map and set each element’s background by Maturity Score (1 red → 5 dark green). Always works.
• Scripted color styling, a JavaScript script reads each Maturity Score and sets colors programmatically; re-run it whenever scores change.
• Custom diagram style, a custom MDG style maps tagged-value ranges to colors for automated coloring. The most sophisticated approach.

Dual heat maps: many programs keep two, one colored by Maturity Score (where are we today?) and one by Strategic Importance (where do we need to be?). High importance + low maturity = priority investment area.

Step 9: Link capabilities to applications

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

1. Create an ArchiMate Application Architecture diagram titled “Application to Capability Coverage.”
2. Place the Capability elements on it.
3. Drag the relevant Application Component elements from the Application Portfolio package onto the same diagram.
4. Add ArchiMate Realization relationships from each Application Component to the Capabilities it supports.

Guidance: one application can realize multiple capabilities, and one capability can be realized by multiple applications (normal). Capabilities with zero realizations should be flagged, manual-process-only or a gap. Capabilities with more than 3-4 realizations may be rationalization candidates. After linking, application coverage (full, partial or none) can be read straight from the relationships.

The AI-augmented way to build the map

Steps 5 to 9 are mechanical: creating Capability elements, placing them in packages, drawing the hierarchy, coloring the heat map and linking applications. Today the architect does all of it by hand, and repeats it whenever the structure changes. The AI-augmented way keeps Steps 1 to 4 and the scoring in Step 7 with people. The architect decides the capability structure and the level of decomposition, the business owners supply the maturity and importance judgments, and AI builds and maintains the elements, the diagrams, the heat-map views and the Realization links to applications. The skill it asks of the architect is stating the structure and the decomposition rules clearly, and checking what AI built against them. Tools that help: Claude or GitHub Copilot with AI Power Tools.

Frequently asked questions

What this means for the architect

A capability map earns its place when the definition is agreed, the hierarchy stops at the right level and the links to applications stay current. Those are judgments an architect makes, and AI does the rest faster when they are stated clearly. A governed capability map is a natural first step in standing up a decision-useful repository under Configure the Solution, and it serves the enterprise architecture work your team does every day.