Capability mapping step by step

Why map capabilities

A strategy is hard to translate into action without a shared view of what the organisation must be able to do. A capability map describes the enterprise through its business capabilities, instead of its projects, systems or organisation chart.

Projects, systems and structures change; capabilities remain more stable. Linked to applications and decisions, the map provides a common language for steering change.

What a business capability is

A business capability is what the organisation does or must be able to do, in a stable, outcome-oriented way. It describes the what; processes, applications, projects and roles describe the how or the who.

• Examples: customer onboarding, order management, pricing, financial reporting, workforce planning.
• Counter-examples: Sales Department, which is an organisational unit; Approve an invoice in SAP, which is a process step in a system.

Step 1: start from the decision to inform

Before mapping, the team names the decision the map must help make. Without that purpose, the map stays abstract and supports no choice.

• Support a transformation programme.
• Establish an enterprise architecture baseline.
• Align business and IT portfolios.
• Identify activities to hand over to AI or automation.
• Simplify the application landscape.
• Prepare an integration after a merger.
• Set operating model priorities.

Step 2: set the scope

The first pass covers a clear scope, at levels 1 and 2. The rest of the enterprise waits for the next pass.

• The whole enterprise, at a high level.
• One business domain: sales, supply chain, finance, human resources, digital commerce.
• One region or one value stream.
• The scope of a transformation.

Step 3: identify level 1 capabilities

Level 1 capabilities are the large, stable building blocks of the enterprise. The following list is a starting point to adapt.

• Strategy and planning
• Product management
• Marketing
• Sales
• Customer service
• Supply chain management
• Finance
• Human resources
• Risk and compliance
• Technology management

Step 4: break down into levels 2 and 3

Decomposition isolates the distinct capabilities inside each higher-level capability. It is what makes the map usable for a decision.

In ArchiLU, a child capability requires its parent to exist: higher levels are created first, and the hierarchy goes down to level 4.

• Use stable, business-oriented names.
• Avoid process sequences and system names.
• Keep a consistent granularity between sibling capabilities.
• Keep capabilities separate from organisational roles and functions.

Steps 5 and 6: validate and define

Business owners validate the map with the architects; a map built in isolation carries no authority. Each capability receives a definition that removes ambiguity.

• Validation points: value creation, missing capabilities, clarity of names, consistency of the breakdown.
• Definition fields: name, description, business outcome, scope, inclusions, exclusions.

Steps 7 and 8: owners and the state of each capability

The map becomes a governance tool when each capability has its owner and its state is visible. Colouring by importance, maturity or risk then helps prioritise.

In ArchiLU, the owner declares whether the capability is exercised with a tool, exercised manually or not exercised. Until they do, the map shows it as not declared; the colour is never inferred from linked applications.

• Types of ownership: business, architecture, platform, data.
• Colouring dimensions: strategic importance, maturity, performance, investment, automation, risk, technical debt, data quality.

Steps 9 and 10: connect and use

The map becomes the backbone of the architecture when it is linked to applications, processes, data, teams, risks and initiatives. Its value shows in the boards that use it to make choices.

In ArchiLU, links are set from the capability record or imported through the workbook, whose capabilities sheet accepts an optional column for the declared state. The map then shows, under each capability, the applications, processes and value streams linked to it.

• Portfolio prioritisation and investment planning.
• Application rationalisation and operating model redesign.
• Target architecture design and post-merger integration.
• Identifying activities for AI and planning roadmaps.

Common mistakes

A capability map that supports no decision remains a decorative document.

• Confusing capabilities with processes.
• Confusing capabilities with organisational units.
• Going into detail too early.
• Making the map too technical.
• Building the map without business validation.
• Never using it in governance.