An enterprise capability map is complete and current, and no investment decision has been changed by it. What is missing?

What is missing

Overlays. A capability map describing structure tells you what the business does. It tells you nothing about where to act.

Decisions come from the intersections of assessments layered onto the map:

• Strategic importance — differentiating, competitive necessity, or commodity.
• Current maturity — how well is this done today.
• System support — which applications implement it, how many, how well.
• Cost to operate.
• Change frequency — how often does this capability need to evolve.

High importance and low maturity is an investment case. Low importance and high cost is a consolidation or buy case. One capability implemented by nine applications is a rationalisation case with an estimable saving. High change frequency and shared implementation is an argument for decoupling.

The highest-value single overlay

Duplication: which capabilities are implemented more than once. In a large enterprise the same capability — customer master data, pricing, document generation, notification, identity — is typically implemented several times by different business units for historical reasons.

That overlay produces a concrete, arguable list of consolidation candidates with money attached, which is the kind of output that funds the mapping exercise and justifies keeping it current.

The second missing element

Anchoring to a live question. A map built to "document the enterprise" is an inventory. A map built to answer "should we consolidate order management across regions" or "what does separating this business line cost" produces a decision, and the parts of the map irrelevant to that question can stay shallow.

Asymmetric depth is what makes mapping affordable: two levels everywhere, five where a decision is pending.

The maintenance consequence

A map with no owner and no review trigger becomes wrong silently, and a wrong map is worse than none because it is used confidently. Tying maintenance to decisions solves this too — the parts that matter are refreshed when they are used, and the rest is allowed to be approximate.

The boundary to respect

A capability map says what the business does. It says nothing about whether a capability should be one service or twenty, synchronous or event-driven, shared or duplicated. Those are architectural decisions the map informs and does not make — and teams that treat the map as a service decomposition produce boundaries that ignore every technical constraint.