Capability Decomposition Depth
also called Capability Map Depth, Capability Level Choice
The level at which a capability map stops describing what a business does and starts describing how it is currently organised - the point past which it must be redrawn at every reorganisation and its refresh cost exceeds its use.
A capability map arrives decomposed to four levels: 380 boxes, each with an owner, a maturity score of 1 to 5, a red/amber/green status and links to supporting systems. It took seven months and two contractors. In the year since publication it has been used once, to answer whether two business units duplicate a capability.
The artefact is not useless. It is about ten times larger than the question needed, and the surplus is what makes it impossible to keep true. Depth determines this, and the choice is usually made by whoever ran the workshops rather than by anyone weighing the cost.
The levels differ in kind, not just size. Levels 1 and 2 — typically 8 to 12 top-level capabilities decomposing into 40 to 70 — describe what the business does and change only when the business model changes. Level 3 begins to describe how work is organised. Level 4 is process, and process is re-cut at every reorganisation, which in most companies is annual.
Why it matters
The refresh cost of the whole artefact is set by its deepest layer. Re-validating 380 boxes at 15 to 20 minutes of interview each is 95 to 125 hours before anyone disputes a score; a 60-box map is about a week a year. That decides whether the map is maintained or quietly abandoned.
The stability of levels 1 and 2 is the entire reason the artefact exists. It is the one frame an organisation can hang systems, cost and duplication analysis on for several years, so comparisons across time mean something. A map redrawn with the org chart becomes a second, worse org chart, and a half-maintained map is worse than a small one because a reader cannot tell which half is current.
Implementation patterns
- Decompose to level 2 across the whole business and deeper only under a live decision. Two or three branches at level 3 or 4 is normal; blanket depth is not.
- Delete unused depth rather than marking it stale. Removal is the cheapest maintenance action and the only one that restores trust in what remains.
- Replace opinion columns with measured ones — annual run cost from finance, incident count from the tracker, change lead time from the pipeline. These refresh without interviews and are arguable only on the facts: a capability with £2.4m of run cost and 9 incidents starts a conversation, where one rated maturity 2 starts an argument.
- Keep the capability-to-system mapping including many-to-many links: it cannot come from an org chart and it answers duplication questions.
Industry example
Capability modelling is standardised rather than improvised. TOGAF's Phase B covers business architecture, and ArchiMate defines a capability element with typed relationships to applications and technology nodes, which is what allows a cross-layer query: which applications in production support a capability running on a platform that leaves support next year. The standards define the notation and say nothing about depth, so the decision that decides whether the artefact survives is the one no framework makes for you.
Failure scenarios
- The reorg invalidation. A map decomposed along current team boundaries is wrong the week the teams change, and the rework arrives as a new project.
- The maturity argument. A 1-to-5 score with no evidence definition turns every review into a negotiation, and the map's credibility goes with the first score overruled.
- The unanswerable question. A CFO asks why two units run two systems for one capability and the map has no system links — the only overlay that mattered.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Level 2 only | A week a year to maintain and stable for years | Cannot support decisions needing process detail |
| Level 2 plus deep branches | Depth where a decision needs it | A rule about when to add and remove depth |
| Full level 4 | Completeness an external reviewer can trace | 95 to 125 hours a year of re-validation and invalidation at each reorganisation |
When not to use it
Where a supervisor or auditor requires a traceable mapping from business services to supporting systems, completeness is the deliverable and trimming to 60 boxes fails the examination. Fund the full decomposition as a compliance artefact and build the small decision lens separately. At the other extreme, a company with a dozen systems needs no map at all.
Interview question
Q: You inherit a 380-box level-4 capability map with maturity scores, built over seven months and used once. Leadership asks whether to refresh it. What do you recommend, and how do you say it without discrediting the people who built it?
What a strong answer covers: the cost-per-refresh arithmetic driven by the deepest layer; keeping the system links while cutting depth and opinion columns; substituting measured columns the company already produces; and offering the explicit trade of roughly 60 boxes plus three deep branches maintained in a week a year.
Quick check
Quiz: Why does level-4 depth set the maintenance cost of a whole capability map? Level 4 describes process, process is re-cut at every reorganisation, and re-validating hundreds of boxes annually costs more than the map returns.
Flashcard: Which part of an over-built capability map should you keep? — The capability-to-system links, including many-to-many ones: they answer duplication questions and cannot come from an org chart.