Skip to content

Playbook — Map your capability coverage gaps

Outcome: a coverage map of your business capabilities that highlights which ones are unsupported, thinly supported, or supported only by something at risk.

The situation

Leadership thinks in capabilities ("we need to be better at omnichannel fulfilment"), not in applications. You're being asked which business capabilities are actually covered by working systems — and where the gaps are that put strategy at risk. A list of apps doesn't answer that; a capability map does.

You'll walk away with

  • A capability map (L1 → L2 → L3) with a coverage overlay.
  • A coverage gap report flagging each capability as covered, at-risk, or a gap.
  • The ability to say, concretely, "this strategic capability is supported by one ageing application" — the sentence that gets investment approved.

Before you start

Your capability model (even a first-draft L1/L2 list) and your applications imported. You don't need a perfect taxonomy to begin — coverage gets more accurate as you map.

Steps

  1. Build (or import) your capability map. Business → Capability Map (/capabilities). You can import a capability hierarchy or build it directly. → Detail: Building a capability map
  2. Connect applications to the capabilities they deliver. Add & Connect → Discover (/discover) proposes app → capability links with AI; confirm the right ones. This is what populates coverage. → Detail: Discovery & connecting
  3. Read coverage on the map. Back on the Capability Map, the coverage overlay shows which capabilities have delivering applications and which don't.
  4. Open the gap report. The Capability gap report (/capabilities/gap-report) lists L2 capabilities by coverage status — gap / at-risk / covered — grouped by domain, with the delivering apps shown (including any flagged end-of-life or decommissioning). Export to CSV for the strategy deck.

Where people get stuck

Coverage is a function of the app → capability links, so an unmapped estate shows as all gaps — which is misleading, not insightful. The fix is step 2; the mapping is assisted (suggest-and-confirm) but it's the pass that makes everything downstream true. Until it's done, treat the coverage view as "not yet known," not "not covered."

Make it stick

A capability with coverage that's at risk (its only delivering app is end-of-life) is the single most fundable finding an architect can produce — it links a business capability directly to a technical risk and a remediation ask. Revisit the gap report whenever the sunset-risk list changes, because an app going end-of-life is what turns a "covered" capability into an "at-risk" one.