Capability Mapping

Describe what the business does, independent of how, by whom, or with which system.

Mapping systems to stable business capabilities exposes where the same capability is built several times over.

To an executive

A map of what the business can do stays stable while teams, processes and systems change. It shows where money is spent, where work is duplicated and where gaps lie.

To an engineer

Map systems, data and vendors to business capabilities, which describe what the organisation does rather than how. Use the map to spot duplication and to anchor ownership.

The idea

A business capability is something the organisation is able to do to achieve an outcome, such as "onboard customers", "price products" or "manage claims". It describes what the business does, not how, by whom or with which system.

Capabilities are usually arranged in a hierarchy, from a dozen or so top-level areas down to more specific capabilities. They stay stable while processes, teams, organisation charts and systems change around them. That stability makes a capability map a shared language for business and technology, and a fixed frame on which to lay investment, risk, ownership and redundancy.

Why it works

It is stable when everything else moves. Reorganisations and replatforming change who does the work and with what, but rarely what the business needs to be able to do.

It joins business and IT conversations. Executives recognise capabilities; architects can map systems, data and vendors to them. Both sides look at the same picture.

It exposes duplication and gaps. Laying systems under capabilities shows where the same thing is built several times, and where an important capability has no real support.

Where it applies

Application portfolio rationalisation, finding several systems that serve the same capability.
Investment planning and roadmaps, anchored to capabilities rather than to projects that come and go.
Mergers and reorganisations, comparing what each part of the business can do before deciding what to keep.
Sourcing and domain design, deciding what to build, buy or partner for, and aligning domains and bounded contexts to capabilities.

How to apply

Start from a question, such as where to consolidate, what to fund or what to outsource.
Draft the top levels with business stakeholders, using nouns and verbs for outcomes, not system or team names. An industry reference model can help as a starting point.
Map what matters to the question onto the capabilities: systems, costs, owners, maturity or strategic importance.
Heat-map the result, for example by strategic importance against current support.
Turn the hot spots into decisions on the roadmap, and keep the map current as they land.

Example scenario

After several acquisitions, a group had no clear view of its application estate. Every business unit claimed its systems were unique.

The enterprise architects built a capability map with the business and laid the applications beneath it. Customer identity turned out to be implemented by many separate systems across the units, each with its own login and customer record. With the duplication visible on one page, consolidating identity became the top enterprise priority, and the map was reused to sequence the rest of the rationalisation.

Questions to ask

Which business capability does this system, project or vendor support?
Where do we have duplicate, missing or poorly supported capabilities?
Which capabilities are strategic, and which are commodity?

When not to use it

Small organisations with a handful of systems, where the duplication is obvious without a map.
Detailed process redesign, where you need to know how work flows, which a capability map deliberately leaves out.

How it misleads you

Producing beautiful capability maps that never inform a decision. A map without a question is wallpaper. Heat maps can also mislead: a red or green colour means little unless everyone agrees what it measures.