An enterprise architecture team builds a 'business capability heat map' — a diagram of everything the business does, with each capability shaded by color. What is a business capability in this context, what do the heat-map colors typically represent, and how does the team use the result to prioritize IT investment?

## What a business capability is A business capability is a description of what an organization is able to do — a stable noun phrase like 'Order Management,' 'Customer Onboarding,' or 'Claims Processing' — as opposed to how it does it today. The **'what, not how'** distinction is the entire point: an org chart, a business process, and the applications that support a process all change constantly (reorgs, process re-engineering, system migrations), but the underlying capability the business needs — the ability to onboard a customer, say — persists across all of those changes. Capability models are usually drawn as a hierarchy: 1. **Level 1** capabilities are broad ('Customer Management'), 2. decomposed into **level 2** ('Customer Onboarding,' 'Customer Service,' 'Customer Retention'), 3. sometimes further into **level 3**. Because the model is stable and framework-neutral, it becomes a common map that both business stakeholders and IT can point at without arguing about which department or which system 'owns' a box — a capability can be shared across departments and supported by multiple systems. ## What the colors represent A capability heat map takes that stable structure and overlays it with color, typically red/amber/green, on one or more assessment dimensions. Common dimensions include: | Dimension | What the rating captures | |---|---| | **Business value or strategic importance** | how much this capability matters to competitive advantage or customer experience right now | | **Current maturity or IT support quality** | are the systems supporting this capability modern, reliable, and well-integrated, or are they legacy, manual, or duct-taped together | | **Cost** | how much is currently spent operating the capability, including licensing, support headcount, and infrastructure | | **Redundancy** | how many separate systems or teams implement the same capability, often the result of M&A or years of siloed builds | Each capability box gets shaded, and a team can toggle between dimensions or blend them (e.g., 'high value + low maturity') to make gaps visually obvious in a way a spreadsheet would not surface as quickly to an executive audience. ## How the map drives prioritization The mechanism for using this in prioritization is straightforward once the map exists: cross-reference the value dimension against the maturity dimension. - **High value, low maturity** capabilities are the most urgent investment targets — the business depends heavily on something IT is currently supporting badly, and every quarter that gap persists is a quarter of competitive exposure or operational risk. - **Low value, high cost** capabilities (often revealed by the redundancy dimension — three different systems doing the same low-value thing) are prime candidates for consolidation, decommissioning, or moving to a cheaper, standardized platform, freeing budget to fund the high-value gaps. - **High value, already high maturity** capabilities get a 'protect and evolve' treatment. This produces a defensible, visual input to portfolio and budget conversations that is far more persuasive to non-technical stakeholders than a list of application names, because it starts from what the business cares about rather than from IT's internal inventory. ## The trade-off — the ratings behind the colors The trade-off is that a heat map is only as good as the ratings behind it, and those ratings are frequently subjective, self-reported, or stale. - Getting **business value** ratings requires genuine business-side workshops with people who understand strategy, not just an architect's guess. - Getting **maturity** ratings requires someone to actually assess system health, not just ask the application owner, who has an incentive to rate their own system favorably. A heat map built once during a strategy offsite and never refreshed decays into decorative wallpaper — six months later the 'red' capabilities may have shipped fixes and the 'green' ones may have quietly rotted, and nobody notices because the map isn't a living artifact tied to a review cadence. ## Failure modes 1. **Granularity mismatch.** The most common production failure mode is granularity mismatch: mapping at too coarse a level (treating 'Order Management' as one box) hides that one sub-capability inside it is a critical bottleneck while the rest is fine, so investment gets spread evenly across the whole box instead of targeted; mapping at too fine a level produces hundreds of tiny capabilities that overwhelm the audience and make the exercise unusable for executive decision-making. 2. **Capability sprawl from mergers.** A second failure is capability sprawl from mergers — after an acquisition, the combined capability map often reveals three systems all claiming to do 'Claims Processing,' and the heat map correctly flags this as a redundancy problem, but organizations frequently stall at the flagging stage and never fund the consolidation because it has no natural business sponsor. Large insurers and banks doing post-merger IT rationalization are the textbook users of this technique — the heat map is what turns 'we have too many claims systems' from a vague complaint into a prioritized, fundable consolidation roadmap.