myBusinessArchitectmyBusinessArchitectmyBusinessArchitectmyBusinessArchitectMarcus brought the full capability heat map to the board: twenty-seven capabilities, five faculties, 135 colour-coded cells, no annotation. The board saw a wall of colour that communicated nothing. Two weeks later, he presented the same data to Academic Council: six capabilities, five columns, one annotation line across the top. The audience saw the gap immediately, before Marcus said a word. Same data. One was an architecture artifact designed for architects. The other was a communication tool designed for a decision. This chapter teaches you to make that translation -- from comprehensive to clear, from artifact to instrument -- without distorting the insight. You will see both versions of the heat map the way James Firth would: quickly, with twelve other items on the agenda.
By the end of this chapter, you'll be able to:
A development NGO needed to present program effectiveness data to a donor board that controlled $50M in annual grants. The program team's standard reporting used a complex logic model: inputs, activities, outputs, outcomes, and impact indicators arranged in a five-layer diagram with forty data points. It was analytically rigorous. It was also unreadable to the people who controlled the funding.
The program director scrapped the logic model for the board presentation. In its place, she built a three-column visual: what we set out to do, what happened, and what we learned. Three rows, one per program. Traffic-light indicators. The full logic model went into the appendix. The board approved continued funding in twelve minutes and asked for the same format from every program going forward.
Forty data points. One page. Twelve minutes. That is the difference between an architecture artifact and a communication tool. The logic model was not wrong. It was wrong for the room.
This chapter is about making that translation: taking the artifacts that architecture produces and reshaping them for the people who need to act on what those artifacts reveal. The principles work whether you are presenting capability heat maps, value stream bottlenecks, or program logic models. They start with a question that sounds simple and proves difficult: what does this audience actually need to see?
The story that follows shows what happens when the translation fails, and what changes when it succeeds.
When Marcus prepared the capability heat map for the board, he printed the full model. All five faculties across the top. All twenty-seven capabilities down the side. Colour coding from deep green (maturity level 4-5) through yellow (level 3) to red (level 1-2). It was comprehensive, accurate, and precisely what you would want if you were conducting a detailed capability assessment workshop with a team of business architects.
The board saw a wall of colour that communicated nothing.
Two weeks later, Marcus presented the same capability data to the Academic Council. This time, he showed a simplified version: five columns (one per faculty), but only the six capabilities that directly supported the institution's strategic priorities. The colour coding was the same. The visual was one-third the size. And he had added a single annotation line across the top: "Capabilities required for our industry-connected graduates strategy." Now the audience could see the pattern immediately. Health Sciences was green across all six rows. The other faculties had significant red. The visual told the story before Marcus said a word.
Same data. Two visuals. One was an architecture artifact designed for architects. The other was a communication tool designed for a decision. The difference is the subject of this chapter.
To make the difference concrete, here are both versions. Look at them the way James Firth would: quickly, with twelve other items on the agenda.
Title on the slide: "HERM-Adapted Capability Maturity Assessment, Lakeshore Polytechnic"
[27 capabilities. 5 faculties. 135 cells. No annotation. No indication of what the audience should look at first.]
Notice what you just experienced. Your eye went everywhere and nowhere. There is a pattern in this table, but you have to work to find it. If you are James Firth, sitting in a board meeting with a packed agenda, you are not going to do that work. You are going to nod politely and move to the next item. This is the "polite nod" problem in visual form.
The title names the artifact, not the insight. There are 135 coloured cells competing for attention. The capabilities that matter for the strategic decision are buried among the capabilities that do not. And nothing on this slide tells the board what to do with what they are seeing.
This is the visual equivalent of reading the audience your research notes.
Title on the slide: "Capabilities required for our industry-connected graduates strategy"
[6 capabilities. 5 faculties. 30 cells. One strategic question. Annotation where the conversation will go.]
Look at the difference. The second version tells you what you are looking at before you read a single cell. The six capabilities are the ones that matter for the decision. The colour pattern is visible at a glance: a column of green on the left, significant red everywhere else. James Firth can see the problem. Sandra Mwangi can see the problem. The board member reading this slide two weeks later, without Marcus in the room, can see the problem.
The full 27-capability assessment did not disappear. It went into the appendix, available for anyone who wanted it. No one asked for it. They did not need to. The filtered version told them what they needed to know.
Architecture produces visual artifacts: capability models, heat maps, value stream diagrams, business model canvases, gap assessments. These artifacts are powerful diagnostic tools. They are also, in their raw form, almost always wrong for the communication context. They contain too much information, organized for the architect rather than for the audience, presented at a level of detail that serves completeness rather than clarity.
This chapter teaches you how to take those artifacts and make them work as communication tools: simplifying without losing the insight, organizing for the audience's eye rather than the architect's logic, designing for the specific decision at hand, and annotating so the visual can stand without you in the room to explain it.
Create a free account to access Communicating Business Architecture and start learning.