Skip to content

Building a capability map

The capability map (/capabilities, Business → Capability Map) is the organizing spine of your repository. This guide gets you from nothing to a useful map.

Aim low first

You do not need a complete or academically pure taxonomy. A rough two-level map of 10–20 capabilities is enough to start hanging applications against and to make coverage meaningful. Detail (L3) is added only where it earns its keep.

Steps

  1. Open Capability Map.
  2. Create your L1 domains — the big areas of what the business does (e.g. Customer & Commerce, Supply Chain & Fulfilment, Technology & Platforms). Use + New → Capability or the on-map controls.
  3. Under each L1, add L2 capabilities — the distinct things the business can do within that domain.
  4. Add L3 sub-capabilities only where the extra granularity will drive a real decision.
  5. Set a business owner on each capability (see Assigning owners) — applications will inherit a derived business owner from these.

Don't want to type it all?

Use Capability Discovery (in Add & Connect → Discover) for AI-assisted suggestions, and let imported applications auto-suggest their capability links. See Discovery & connecting.

Reading the coverage overlay

Each capability shows a coverage status derived from the applications that realise it and their health:

  • Covered — supported by healthy application(s).
  • At risk — supported, but by applications with lifecycle/EOL concerns.
  • Gap — no supporting application.

Gaps and over-coverage (many overlapping applications) are your rationalization conversations.

Linking applications to capabilities

Capabilities become powerful once applications are linked to them (the app_realises relationship). You can:

  • Confirm AI suggestions in Discover or on an application page, or
  • Add the link directly from an application's Architecture context section, or
  • Let import auto-queue suggestions.

Exporting & sharing the map

The Export dropdown on the Capability Map header gives you three formats:

  • PNG / SVG — the map as shown, rendered straight from the live grid (vector SVG stays sharp at any size). Good for slides and stakeholder packs.
  • JSON — the full L1→L2→L3 hierarchy as a structured data document (ids, names, levels, app counts, strategic importance / maturity, plus per-node health when the heatmap overlay is on). Exports at full depth regardless of what's collapsed on screen.

What good looks like

  • Whole-business coverage at L1/L2.
  • Most active applications linked to at least one capability.
  • A business owner on each capability.
  • Visible gaps and redundancy driving decisions.