Inverted Capability Map

A capability map is quoted in every strategy deck. Each level-3 capability lists four to eleven supporting systems, no system supports only one capability, and the two capabilities the strategy calls differentiating are both rated mature. Two quarters of funding decisions contradict the map's own priorities and nobody notices.

The map was built the easy way, from the application inventory outward. That inverts the direction of the artefact, and an inverted map is worse than no map, because it gives the current architecture the authority of a strategy document. This is an anti-pattern, not a technique to apply.

Why it matters

A capability map exists to answer one question: what must this business be able to do, independently of how it currently does it? The answer is useful precisely when it disagrees with the estate, because that disagreement is where investment belongs.

When the names come from systems, that disagreement is impossible by construction. Capabilities inherit system scope, maturity ratings track system health, and the gap analysis returns the estate's own opinion of itself. The failure is invisible, because the artefact looks exactly like a good one, which is why it survives for years and justifies the next round of spend on whatever already exists.

Implementation patterns

The patterns here are for detecting and correcting the inversion.

• The replacement test. Ask: if every system were replaced next year, would any capability name change? In a sound map, none would. In an inverted map, most would.
• Check the fan-out in both directions. Many systems per capability is normal; every system supporting many capabilities is the tell, because boundaries were drawn where the data sits.
• Read the vocabulary. "Supplier content ingestion" is a system. "Agree what we sell and at what price" is a capability.
• Rebuild the top two levels from outcomes, in workshops with business owners and with the inventory not in the room. Two workshops and a week of drafting — about 10 days of effort, not a quarter.
• Re-rate maturity against outcome evidence — first-time resolution rate, unit cost per transaction, lead time to change a pricing rule — rather than against system health or age.
• Reattach systems afterwards as an overlay, keeping the mapping many-to-many. Resist tidying it: the messiness is information about coupling.

Industry example

Travel-supplier aggregation in the mould of Expedia shows the inversion cleanly. An inventory-derived map produces one capability per supplier integration, because that is how the code is organised. The capability the business actually competes on is "present a comparable priced offer across suppliers", which no single integration performs and which an inverted map therefore never names, never rates and never funds. The same pattern has been seen in production in core-banking programmes that mapped capabilities onto vendor modules and concluded that the target state was the current estate with a new user interface.

Failure scenarios

• Differentiating capabilities rated mature, so investment goes to the weakest systems rather than the most important outcomes.
• Team boundaries redrawn onto system boundaries because the map appeared to endorse them.
• A vendor's product map adopted as the capability model, which guarantees the answer is more of that vendor, usually reinforced by an expensive heat-map overlay.
• A three-year target state that is the estate with renamed boxes, discovered when a competitor does something the map has no room for.

Trade-offs

Building outward from systems is fast and defensible: the data exists, it is accurate, and the result arrives in weeks. Building from outcomes needs executive time and produces disagreement. The cost of the honest version is political, paid in the room rather than in the budget. The workable compromise is to draft from outcomes and use the inventory strictly as a coverage check, at about one extra week.

When not to use it

The correcting work is not always worth doing. Below a few hundred people, skip capability mapping entirely: a one-page memo naming the three things the business must get good at this year beats any model and is written in an afternoon. Mapping earns its cost when ownership is spread widely enough that no one person can see the whole.

And a map cannot resolve an undecided strategy. If two executives would rate the same capability's importance differently, fix that disagreement first; otherwise the map is rebuilt around whoever reviews it last, and the inversion returns in a new form.

Interview question

Q: You inherit a capability map that leadership likes and that you believe was reverse-engineered from the application inventory. Rebuilding it will cost executive time and imply that last year's work was wrong. How do you handle it?

What a strong answer covers: the evidence first — replacement test, fan-out, ratings against outcome data — presented as a diagnosis rather than a critique · rebuilding only the top two levels · reframing it as an extension so the previous work is not attacked · one short list of high-importance low-maturity capabilities with a number attached, because that list is what changes funding · and keeping the existing map as an overlay of the estate, which is useful under a different name.

Quick check

Quiz: Every capability in a map supports four or more systems and every system supports several capabilities. What does the second half tell you? That boundaries came from where data sits rather than from business outcomes, so the map describes the implementation and cannot challenge it.

Flashcard: One-question test for an inverted capability map? — If every system were replaced next year, would the capability names change? They should not.