⏱ 5 min read
Recommended Reading
Executive summary
Capability heatmaps are popular because they translate complexity into executive-friendly decisions—but they often become misleading when color is not tied to evidence. A capability map viewpoint is explicitly described as a structured overview of enterprise capabilities and can be used as a heat map to identify investment areas. ArchiMate capability map example
Advanced heatmapping turns “heat” into a defined measurement model: criticality, maturity, risk exposure, cost efficiency, and transformation readiness. It then ties each score to traceable evidence (assessments, incidents, audit findings) and to planned work packages. This makes the heatmap defensible and reduces “political coloring.” When coupled with governance processes (architecture boards, compliance review), the heatmap becomes an investment artifact rather than a poster. ArchiMate for architecture governance
- Measurement model: define dimensions and scoring
- Modeling pattern: capability map + overlays
- Evidence linkage: audits, incidents, control gaps
- Roadmapping: work packages and plateaus
- Capability map viewpoint and heatmap use.
- ArchiMate standard framing.
- TOGAF architecture governance/compliance concept for decision use.
- TOGAF Architecture Board.
Multi-dimensional heatmapping
A basic capability heatmap uses one dimension (typically maturity or fitness). Advanced heatmapping uses multiple dimensions simultaneously to reveal strategic priorities that single-dimension analysis misses. capability mapping for strategic planning
Dimension 1: Technical fitness. How well does the current architecture support this capability? Assessed on: technology currency (modern vs legacy stack), scalability (handles growth), reliability (uptime and recovery), and security posture. Score: High / Medium / Low.
Dimension 2: Business value. How important is this capability to the organization's strategy? Assessed on: revenue contribution, customer impact, regulatory necessity, and competitive differentiation. Score: Critical / High / Medium / Low.
Dimension 3: Investment need. How much investment does this capability require? Derived from the gap between current fitness and required fitness given business value. A capability with low fitness and high business value has high investment need.
The heatmap visualization uses color intensity to show the combined assessment. Red cells (low fitness, high value) demand immediate action. Green cells (high fitness, appropriate value) need maintenance investment only. Amber cells require planned improvement.
Implementation in ArchiMate
Model each capability as a Business Function with tagged values: Technical_Fitness, Business_Value, Investment_Need, Heatmap_Color. Build a custom viewpoint that displays capabilities as colored boxes sized by budget allocation. In Sparx EA, use the Diagram Filters feature to colorize elements based on tagged values — no manual coloring needed.
// jArchi: Auto-calculate heatmap color from fitness + value
$("business-function").forEach(function(cap) {
var fitness = cap.prop("Technical_Fitness") || "Medium";
var value = cap.prop("Business_Value") || "Medium";
var color = "Amber"; // default
if (fitness === "Low" && (value === "Critical" || value === "High")) color = "Red";
if (fitness === "High" && (value === "Low" || value === "Medium")) color = "Green";
if (fitness === "High" && value === "Critical") color = "Green";
cap.prop("Heatmap_Color", color);
console.log(cap.name + " → " + color);
});
The Scoring Model, Written Down
Everything defensible about an advanced heatmap traces back to one artefact most practices never produce: the scoring model as a document, agreed before the first capability is coloured. It needs three decisions per dimension — the scale, the evidence that moves a score, and the scorer. The table below is the shape we deploy, and it doubles as the answer to every "why is this amber" challenge the map will ever receive:
| Dimension | Scale | Evidence that sets it | Scored by |
|---|---|---|---|
| Criticality | 1–4 | Business continuity classification, revenue dependence | Business owner, annually |
| Maturity | 1–5 | Assessment workshops, process audit findings | Capability owner + architect |
| Risk exposure | 1–4 | Open risk assessments, incident frequency, control gaps | Risk function, quarterly |
| Cost efficiency | 1–4 | Run-cost per transaction vs benchmark, debt interest | Finance + architect |
| Transformation readiness | 1–4 | Dependency count, platform lifecycle, team availability | Architect, per roadmap cycle |
Each score lives as a tagged value on the capability element, dated, with the evidence linked as associations to the assessments and findings that justify it. That linkage is what separates a measurement model from a colouring exercise: when the CFO taps an amber cell, the answer is two clicks deep and written by the risk function, not improvised by whoever presents. The scoring meeting itself becomes shorter every cycle, because arguing with evidence attached converges in a way that arguing with opinions attached never does.
Rendering the Heat Honestly
Advanced heatmaps fail at the rendering stage more often than at the scoring stage, and the failures are visual design failures with governance consequences. The first rule: one dimension per view. A colour that blends maturity and risk and cost into a single hue answers no question and permits every interpretation — which is precisely why politically convenient maps blend. Render each dimension as its own overlay on the same capability layout, and let the committee flip between them; the layout constancy is what makes the flipping legible.
The second rule: colour never carries the value alone. Every cell shows its score as a number or label, both for the colour-blind readers every board contains and because printed and photocopied decks are where these maps spend half their lives. The third, subtler rule: render confidence. A score set last month from a workshop and a score inherited from an assessment three years old should not look identical — a simple age-based border or a small stale marker turns the map's weakest cells into visible review candidates instead of confident-looking fiction. In our engagements this single addition has triggered more genuine re-assessment work than any governance mandate, because nobody senior enjoys presenting a map with staleness marks on their own capabilities.
From Heatmap to Investment Case
The map earns its place in the boardroom the day it stops describing and starts pricing. Cross the heat with money: criticality against the debt interest rolled up per capability, and the investment quadrant draws itself — critical-and-expensive is the remediation shortlist, critical-and-healthy is what to protect, peripheral-and-expensive is the rationalisation list nobody had assembled, and peripheral-and-healthy is where to deliberately do nothing, which is an investment decision too and the one boards find hardest without evidence.
Then project it. With remediation modelled as work packages against plateaus, the same map renders per future state: this is Q4's heat if the funded programmes land, this is eighteen months out. Boards respond to that projection differently than to any backlog listing, because it is expressed in the exact visual language of the current-state map they have already accepted — the red they dislike, shown shrinking, with the price tags attached. That closing of the loop, from evidence-scored heat through priced debt to projected relief, is what "advanced" heatmapping actually means; the techniques are ordinary, and the advancement is that every colour on the page can survive the question "says who?"
The Map Under the Heat
All the scoring sophistication above assumes something the article has not yet said out loud: a capability map worth colouring. Half the failed heatmaps we are shown fail below the paint — the map itself is wrong in ways no measurement model can rescue, and the failure modes are consistent enough to check for.
Granularity first. A board-facing map wants two levels: eight to twelve level-one capabilities, each decomposing into a handful at level two, and nothing finer on any executive artefact. Level three exists — it is where the scoring evidence attaches and where architects work — but rendering it upward produces the eighty-cell quilt that executives politely ignore. Roll level-three scores up to level two by worst-of or weighted rules, stated in the scoring model, so the aggregation is a policy rather than a presenter's judgement call. Stability second: capabilities describe what the business does, not how or who, which is why "Payments" is a capability and "the SEPA platform team" is not. Maps contaminated by org structure inherit org-chart churn, and a map that changes shape every reorganisation cannot show trends — losing the single most persuasive thing a heatmap does, which is looking different from last year for reasons everyone can discuss.
The Workshop That Produces Honest Scores
The scoring model defines the dimensions; a repeatable ninety-minute workshop per domain produces the numbers, and its choreography matters more than it should. Score one dimension across all capabilities before moving to the next — dimension-by-dimension, never capability-by-capability — because scoring "Payments" on five dimensions in a row invites a narrative about Payments, while scoring maturity across twelve capabilities invites the comparisons that calibrate the scale. Require evidence on the extremes: any 1 or top score must name its assessment, incident or audit finding in the meeting, which single-handedly eliminates both vanity greens and budget-bid reds. And record disagreement rather than averaging it away — a capability the business owner scores 4 and the architect scores 2 is not a 3; it is a finding about visibility, usually the most valuable one the workshop produces.
Close each workshop by writing the scores and their evidence links into the model before the room empties, with the date. The map that renders that afternoon is then already sourced, already dated, and already better than the previous quarter's deck — and the practice has acquired the only thing that makes heatmapping "advanced" in any durable sense: a repeatable measurement ritual whose outputs accumulate, quarter over quarter, into the trend lines that boards actually change budgets over.
Applying these patterns in practice
The value of ArchiMate modeling is realized not through comprehensive coverage of every element type, but through disciplined application of a few core patterns that answer recurring stakeholder questions. Three patterns account for the majority of architecture communication needs.
The Layered View pattern shows how business processes depend on applications, and how applications depend on infrastructure. Build this view by placing Business Processes at the top, Application Components in the middle, and Technology Nodes at the bottom. Connect them with Serving and Realization relationships. This single view demonstrates cross-layer traceability — when a server is decommissioned, trace upward to see which applications and business processes are affected.
The Cooperation View pattern shows how application components interact through interfaces and data flows. Place the core application in the center and its integration partners around it, connected by Flow relationships labeled with the data exchanged. This view reveals integration dependencies that are otherwise buried in technical documentation.
The Motivation View pattern connects strategic goals to architecture decisions. Stakeholder concerns drive Goals, Goals are realized by Outcomes, Outcomes are enabled by Capabilities, and Capabilities are realized by Application Components. This chain answers the question executives always ask: "Why are we building this?"
If you’d like hands-on training tailored to your team — Sparx Enterprise Architect, BPMN, SysML, Apache Kafka or the Archi tool — or modelling coaching in ArchiMate and TOGAF-aligned governance, you can reach us via our contact page.
Frequently Asked Questions
What is a capability map in enterprise architecture?
A capability map is a structured view of what a business must be able to do — independent of how it is currently organised or which applications support it. Capabilities are grouped by domain and linked to strategic goals, helping architects prioritise investment and identify gaps.
How do capabilities relate to applications in ArchiMate?
In ArchiMate, Application Components realise Business Capabilities through Realisation relationships. This traceability shows which systems support which capabilities, enabling portfolio analysis, rationalisation decisions, and investment planning linked directly to business outcomes.
What is capability-based planning?
Capability-based planning is a strategic approach where investment decisions are driven by the capabilities the organisation needs to develop or improve, rather than by project requests. It aligns IT investment to business strategy by making the capability gap explicit and measurable.
The Quarterly Rhythm That Keeps It Alive
Heatmaps die between quarters, so the closing prescription is a calendar, not a technique. Week one of each quarter: refresh the mechanical inputs — incident counts, lifecycle dates, debt interest — by import. Week two: the scoring workshops, ninety minutes per domain, extremes evidenced, disagreements recorded. Week three: regenerate the overlays, the trend deltas and the projected plateaus, and circulate the one-page "what moved and why" note alongside. Week four: the investment forum reads the map that is now three weeks fresh, with every cell traceable.
Four weeks, mostly automated, repeating — and after four cycles the practice owns something no one-off mapping exercise ever produces: motion. Capabilities visibly improving where money landed, visibly sliding where it did not, on a map whose layout the audience has internalised. Static heatmaps inform; moving ones govern. The advanced technique, in the end, is simply refusing to let the map be an event.
A final calibration point for ambitious practices: the whole apparatus described here — model, scores, evidence, rhythm — runs comfortably at two to four architect-days per quarter once established. If yours is consuming more, the map is too fine, the dimensions too many, or the evidence bar set at proof rather than support. Trim toward the ninety-minute workshop and the one-page note; heatmaps govern best when they are cheap enough to keep honest.
Because in the end that is the test every advanced technique here serves: not whether the map impresses on the day it is shown, but whether the practice can afford to keep telling the truth with it, quarter after quarter, when the colours are inconvenient.