Business Capability Mapping: Levels, Applications and Value Streams
A capability map describes what the organisation is able to do. It supports decisions when each capability has its owner, its applications and its place in the value streams.
Updated on
What a capability map describes
A business capability describes what the organisation is able to do, independently of teams and tools: pricing, order fulfilment, risk management. The map arranges these capabilities on one page that executives, business teams and IT read together.
The map leaves out processes, the organisation chart and software. Those change often; capabilities change less. Processes, teams and applications are then linked to the map, which becomes a common language for business and IT.
Levels and hierarchy
The map is built in levels. Level 1 groups the main capability domains, level 2 breaks them into capabilities that carry decisions, and a level 3 appears only where the detail changes an investment choice.
A first map can be read at a glance and is meant to stay stable for several years. It is refined when a decision needs more detail. In ArchiLU, capabilities are arranged from L1 to L4 under groupings, ArchiMate’s Grouping element, for example a BIAN column. A grouping organises the map and is not linked to any application.
- Level 1: about ten domains that business readers recognise.
- Level 2: the capabilities that carry decisions.
- Level 3: only where the detail changes an investment choice.
Owners and coverage
A map that nobody owns ages quickly. Level 1 capabilities, and the level 2 capabilities that matter, need an owner who can speak to their performance and the systems supporting them. In ArchiLU, if your rules require it, the designated person accepts or declines the designation; only an accepted responsibility counts.
Coverage shows which applications, processes and value streams rely on each capability. One application can realise several capabilities, and several applications can realise the same one. Redundancies and capabilities without applications become inputs to rationalisation.
Declared state and layered views
A map coloured by one dimension shows where to focus attention and budget: maturity, cost, risk, strategic importance. The dimension and the scoring rule must be explicit, otherwise two readers interpret the same colour differently. Crossing strategic importance with maturity highlights important but underdeveloped capabilities.
In ArchiLU, the default colour is the state declared by the owner: exercised with a tool, exercised manually, not exercised or not declared. This state is entered, never inferred from links. Other layers show maturity, maturity gap, health, cost, redundancy or technical debt. A capability with nothing modelled shows “not assessed”.
Value streams and capabilities
A value stream describes, stage by stage, how the organisation creates value for a stakeholder: acquire a customer, settle a claim. Capabilities serve the stages of these value streams.
When a stage underperforms, the team traces back to the capabilities serving it, then to their processes and applications. In ArchiLU, each stage shows these objects, and the map highlights the capabilities of a chosen value stream. A capability shared by several value streams has its own assessment, and each value stream inherits its target.
Capability-based planning
Capability-based planning sets which capabilities must improve for the strategy, by how much and by when. Initiatives, budgets and roadmaps are then aligned with these targets.
The framework stays stable from one year to the next, even when projects and suppliers change. Investing in one capability makes the choice not to invest elsewhere visible. In ArchiLU, the map offers Current, Target and Gap views; until an architecture dossier has set a target, the last two views say so.
Common mistakes
A map built once in a workshop and never linked to the application portfolio informs no decision. Without a business owner, it also loses its authority.
- Describing processes or departments instead of capabilities.
- Detailing the map before it serves a decision.
- Never linking capabilities to applications and value streams.
- Treating the map as an IT artefact without a business owner.
Getting started
A first map takes a few focused workshops: draft level 1 with business owners, detail the domains under transformation, designate owners and link each capability to its applications.
In ArchiLU, the foundation can start from your own repository, a reference catalogue or the BIAN model for banking. Links between applications and capabilities are set on the map or imported from Excel.
In ArchiLU
Frequently asked questions
- What is a business capability?
- What an organisation does to create value, described in a stable way: customer onboarding, claims management. The capability stays independent of how the work is done, which team carries it and which application supports it.
- How does capability mapping differ from process mapping?
- A process map describes how work flows, step by step. A capability map describes what the business is able to do. Processes realise capabilities: they show how the work runs, the map shows where to focus effort.
- How many levels should a capability map have?
- Two or three are usually enough. Level 1 usually has about ten domains; level 3 appears only where a decision requires it.
- How to link applications to business capabilities
- From a capability record, select the applications that realise it, or import the links through the Excel workbook. The link reads both ways: the capability lists its applications, the application lists its capabilities.
- What is the relationship between value streams and business capabilities?
- Capabilities serve the stages of value streams. In ArchiLU, a capability shared by several value streams has its own assessment, and each value stream inherits its target.