How are heat maps built on top of a capability map used to prioritize technology investment, and what do the two axes typically represent?

A capability heat map is the visualization layer that sits on top of the underlying capability model and the capability-to-application mapping, and its entire purpose is to force a side-by-side, apples-to-apples comparison of every capability in the business on the same two dimensions, so that investment decisions aren't driven by whichever business unit shouted loudest in the last budget cycle. ## The two axes Mechanically, you take the capability list, usually at L2 and sometimes L3 where the granularity is needed, and score each one on two largely independent axes. | Axis | What it asks | Where the score comes from | |---|---|---| | The first axis — **business value or strategic importance** | how much does this capability matter to competitive advantage, revenue, or strategic differentiation | scored by business stakeholders rather than IT, because architects are systematically bad at judging strategic importance from the technology side alone | | The second axis — **technology or application health** | how well is the current technology landscape actually serving this capability | typically rolled up from the capability-to-application mapping's health scores such as age, vendor support status, incident rate, technical debt, and scalability headroom | Both axes are usually collapsed to a simple three or five point scale rather than a spuriously precise percentage, because the underlying judgments, especially business value, are inherently qualitative consensus calls, not measured facts. ## The four quadrants Plotting every capability on this two-axis grid produces four broad quadrants, and each one implies a different investment posture. - **High business value paired with poor technology health** is the priority investment zone - these are capabilities the business depends on, running on technology that is failing or falling behind, and they are where a modernization or replacement budget should go first. - **High value paired with good health** is the protect-and-maintain zone - do not touch what is working, but keep monitoring since today's green cell can decay into tomorrow's amber one. - **Low value paired with poor health** is usually a retire-or-minimally-maintain zone - not worth investing further, and often a good candidate to sunset outright if the capability itself is becoming strategically irrelevant. - **Low value paired with good health** is the most interesting quadrant analytically: it often reveals over-investment - capabilities that got a shiny modern platform years ago because they were fashionable or well-connected internally, but that no longer justify that level of ongoing spend relative to their current strategic importance. ## Why it has to be a portfolio-wide exercise The reason this exists as a formal exercise rather than letting each business unit prioritize its own roadmap is that capability-scoped, portfolio-wide comparison surfaces a class of decision that unit-level prioritization structurally cannot: **cross-unit trade-offs**. A CFO or CIO deciding between funding fraud detection in the payments division versus warehouse management in logistics needs both scored on the same rubric to make a defensible call; without a shared heat map, each division brings: - its own internal ranking, - its own definition of critical, - its own inflated sense of urgency, and the loudest or most politically connected unit tends to win regardless of actual portfolio-wide value. ## Where it goes wrong: the scoring, not the picture The trade-offs and failure modes are mostly about the scoring process, not the visualization itself. 1. The biggest failure mode is treating the resulting colors as **objective, measured data** once they are in a slide deck - a red cell for one capability looks exactly as authoritative as a red cell for another even though one might be a careful multi-stakeholder consensus and the other a single architect's guess filled in the night before the steering committee meeting. Because both axes rest on judgment calls, a heat map is best treated as a **structured conversation-starter** that surfaces disagreement worth resolving, not as a computed ranking that settles the argument on its own. 2. A second common failure is **scoring health and value inconsistently across business units** - one division's top score and another's top score do not mean the same thing unless there is a shared, written rubric and, ideally, a calibration session across scorers before the results get compared. 3. A third failure is **letting the heat map go stale** the same way the underlying capability-to-application map does - a heat map built once for an annual planning cycle and never refreshed quietly becomes wrong as technology decays or improves underneath it. ## A worked example A concrete worked example: a retail bank runs an annual heat-mapping exercise and finds fraud detection scored high business value and low technology health, given a rules-based system with a high false-positive rate and a vendor sunset announcement - it becomes the top-funded initiative that year, ahead of several louder but lower-value requests from individual branches. Meanwhile branch teller cash management, scored low value and high health, gets flagged for a hold-spend decision rather than the refresh its business owner had been quietly lobbying for - a call the bank could defend to its board precisely because it came from a portfolio-wide, two-axis comparison rather than from whichever business owner made the most noise.