How do you build a business capability hierarchy with multiple levels (e.g. L1/L2/L3), and what determines how many levels you need?

## Level 1 — the top of the tree Building a capability hierarchy is a top-down decomposition exercise, and the discipline is in knowing when to stop, not in how to start. You begin at Level 1 with the smallest number of capabilities that, together, exhaustively cover everything the organization does to survive and compete - typically somewhere between six and twelve items such as "Customer Management," "Product & Service Management," "Operations," "Finance," "Human Capital Management," "Technology Management," and "Risk & Compliance." The test for a good L1 set is: - **completeness** (every activity in the company should trace to exactly one L1 capability); - **mutual exclusivity** (no activity should plausibly belong to two L1s at once). Together these are the classic **MECE** property borrowed from strategy consulting. ## Level 2 — narrower, still stable Each L1 is then decomposed into Level 2 capabilities - typically five to ten per parent - that are still stable, noun-phrased abilities, just narrower in scope. "Customer Management" might decompose into "Customer Acquisition," "Customer Onboarding," "Customer Service," and "Customer Retention." The decomposition test at every level is the same: does this child capability represent a distinct ability the business needs, that could in principle be staffed, funded, and matured independently of its siblings? If two candidate capabilities always move together — that is: - always funded together, - always delivered by the same team, - never independently prioritized — they are probably one capability, not two, and should be merged. ## Level 3 — where the map becomes actionable Level 3, when built, pushes decomposition to the point of practical usefulness: granular enough to map cleanly to individual applications, vendor products, or investment line items. "Customer Onboarding" might decompose into "Identity Verification," "Account Setup," and "Welcome Communication." This is usually the level where capability-to-application mapping and heat-mapping actually happen, because L1/L2 capabilities are typically too broad for a single application to map to cleanly - a dozen systems might touch "Customer Management" at L1, which tells you nothing actionable, whereas "Identity Verification" at L3 might map to exactly one KYC vendor product, which is directly actionable. ## How deep to go is a purpose question The number of levels an organization needs is a **purpose-driven decision**, not a fixed methodology rule. 1. A capability model built purely to support **board-level strategic conversations** about where to invest across the business might stop at L2 - "we are underinvesting in Customer Retention relative to Customer Acquisition" is actionable at that grain. 2. A model built to support **application rationalization, technical debt remediation, or IT cost allocation** almost always needs L3, because those decisions require mapping specific systems to specific capabilities, and L1/L2 capabilities are usually served by too many overlapping systems to draw a clean line. 3. Some **large, complex enterprises** go to L4 for specific domains under heavy regulatory scrutiny, but pushing every branch of the tree to L4 uniformly is rarely worth the maintenance cost. ## The failure mode at the boundary The failure mode at the boundary is decomposing past the point where you are still describing a stable ability and starting to describe a process step or a system feature instead. "Identity Verification" is a capability - a business needs the ability to verify who a customer is, independent of whether that is done via a manual document check or an automated biometric API. "Send SMS OTP to Customer's Registered Mobile Number" is not a capability; it is an implementation detail of one specific process, and it will change far more often than "Identity Verification" itself. A hierarchy that bottoms out at that granularity stops being a stable EA artifact and turns into a process/feature inventory that needs re-validation every sprint - which defeats the entire premise of capability mapping as a durable reference model. ## The trade-off in going deeper The trade-off in going deeper is straightforward: more levels give you more actionable granularity for specific decisions at the cost of more modeling effort up front and more maintenance burden to keep the lower levels validated against a business that keeps reorganizing and re-platforming underneath them. Many EA teams deliberately keep L1/L2 as the stable spine that rarely changes and gets broad executive sign-off, while treating L3 as a working layer that gets refreshed more frequently and validated closer to the teams doing the actual mapping work, so the churn is contained to the layer that needs it rather than propagating up into the strategic-level model. | L1/L2 — the stable spine | L3 — a working layer | |---|---| | gets broad executive sign-off | gets refreshed more frequently | | the strategic-level model | validated closer to the teams doing the actual mapping work | ## A worked example A concrete worked example: a telecom operator's L1 "Product Management" decomposes at L2 into "Product Development," "Product Portfolio Management," and "Product Pricing." For a heat-map exercise on pricing-engine technical debt, L2 is too coarse - "Product Pricing" might cover consumer plans, enterprise contracts, and wholesale rates all mapped to wildly different systems with wildly different health scores, which would average out into a meaningless heat-map cell. Decomposing to L3 - "Consumer Pricing," "Enterprise Contract Pricing," "Wholesale Rate Management" - lets each map to its actual owning system, producing a heat map that tells the CIO exactly where the pricing technical debt is concentrated rather than a muddy average across three unrelated platforms.