Enterprise architects can struggle to secure stakeholder support, not because their technical decisions are flawed, but because their communication fails to bridge the cognitive gap between technical rationale and business meaning.

Two well researched and documented cognitive biases (the curse of knowledge and framing effects) systematically undermine how architects present decisions to boards, CFOs and programme directors. The defining challenge is not what architects decide, but how they communicate those decisions to the people who fund, staff and sustain architecture programmes.

The Science Behind the Gap: Curse of Knowledge and Framing Effects

Before we can look at and address how architects communicate, we need to understand why the problem exists. The answer lies not in laziness or arrogance, but in well reserached and documented cognitive biases that affect every expert who tries to explain their domain to an outsider.

These biases are not character flaws. They are features of how human cognition works and they usually intensify with expertise. The more deeply an architect understands distributed systems, the harder it becomes to remember what it felt like not to understand them.

The Curse of Knowledge

In 1990, a Stanford graduate student called Elizabeth Newton conducted a deceptively simple experiment. She asked participants to tap out well known songs on a table while listeners tried to identify the melodies. Tappers (people in the study) consistently and dramatically overestimated how many songs listeners would recognise, because they could not suppress the melody playing in their own heads. Source: Wikipedia – Curse of Knowledge.

This is the curse of knowledge: once you know something, you cannot imagine not knowing it.

The implications for enterprise architects can be uncomfortable. When an architect presents a microservices migration strategy to a CFO, the architect hears a rich symphony of:

• Technical rationale
• Scalability
• Fault isolation
• Deployment independence.

The CFO hears tapping on a table. The architect assumes the logic is self-evident whilst the CFO wonders why the organisation should spend millions on something that sounds like rearranging internal plumbing.

“Top executives have had years of immersion in the logic and conventions of business, so when they speak abstractly, they are simply summarizing the wealth of concrete data in their heads. But frontline employees, who aren’t privy to the underlying meaning, hear only opaque phrases.” Source: Chip Heath and Dan Heath, Harvard Business Review

This dynamic operates in both directions. Business leaders summarise strategy in abstractions that feel obvious to them, whilst architects summarise technology in abstractions that feel obvious to them. The result is two groups of experts, each tapping confidently, neither hearing the other’s tune.

The curse of knowledge is not a problem that awareness alone can solve, it requires deliberate, structured techniques to overcome, which is why frameworks matter so much.

Framing Effects and Loss Aversion

The second cognitive mechanism that architects must understand is the framing effect, established by Tversky and Kahneman’s foundational research. Their work demonstrated that people’s decisions change depending on how options are framed, even when the underlying options are logically identical. When choices are framed as gains, people prefer certainty, whilst when framed as losses, people prefer risk. Source: Wikipedia – Framing Effect.

Prospect theory further posits that a loss is perceived as more significant than an equivalent gain.

For architects, this has a direct practical application. For example presenting a platform modernisation as “we will gain 30% faster deployment cycles” is less persuasive than presenting it as “without this investment, we risk losing £2.4 million annually in delayed time-to-market.”

The information is equivalent, the framing is not. Loss framing activates a different decision making circuit. One that demands action rather than deliberation.

Consider how this applies to a common architecture governance scenario. An architect needs board approval for a cloud native replatforming initiative.

• The gain framed version reads: “This migration will improve our infrastructure elasticity and reduce provisioning time from weeks to minutes.”
• The loss framed version reads: “Our competitors are already deploying new customer features in days. Every quarter we delay this migration, we fall further behind and our customer acquisition cost rises as our digital experience ages.”

Both statements are true. The second one gets better attention for funding. Architects who understand framing do not manipulate their stakeholders, but rather they respect how human decision making actually works and present information in the form most likely to enable good decisions.

Frameworks for Stakeholder Centred Communication

Understanding cognitive biases is necessary but insufficient. Architects need structured, repeatable frameworks for tailoring communication to different audiences. Fortunately, several well-established models exist.

TOGAF’s Stakeholder Engagement Architecture

I will use TOGAF for this first framework example, although other architecture frameworks exist, this is the one I am most familar with.

The TOGAF Architecture Development Method (ADM) provides formal mechanisms for stakeholder communication. Phase A, Step 6.3.2, requires architects to identify stakeholders, catalogue their concerns and tailor communication accordingly. This is not optional guidance, but a defined step in the architecture development cycle. Source: TOGAF Phase A – Architecture Vision.

More powerfully, TOGAF’s Views, Viewpoints and Concerns framework, aligned with ISO/IEC/IEEE 42010:2022, provide the conceptual machinery for audience-centred communication. It defines stakeholders as individuals or classes having an interest in a system, concerns as interests relevant to those stakeholders and architecture viewpoints as specifications for constructing views that address specific concerns. This principle sets out clearly that there is no single “architecture” to communicate. There are multiple views, each constructed for a specific audience and a specific concern. Source: TOGAF – Architectural Artefacts

“Stakeholders are individuals, teams, organizations or classes thereof, having an interest in a system. Concerns are interests in a system relevant to one or more of its stakeholders. An architecture viewpoint establishes the conventions for constructing, interpreting, and using an architecture view to address a specific concern.” Source: TOGAF Standard ,The Open Group

McKinsey’s Three Horizons for Investment Framing

When communicating with CFOs and boards about architecture investments, McKinsey’s Three Horizons framework provides a powerful organising structure.

• Horizon 1 investments optimise the core business (infrastructure consolidation, technical debt reduction)
• Horizon 2 investments build emerging capabilities (API platforms, data mesh architectures)
• Horizon 3 investments place transformational bets (AI-native architectures, quantum-readiness)

Each horizon carries a different cost profile, risk tolerance and time-to-value expectation. By mapping architecture decisions to these horizons, architects can speak the language of portfolio management that financial leaders already understand.

The Cost-Risk-Value Trade-off Matrix 

Practitioner frameworks such as Rozanski and Woods’ Software Systems Architecture prescribe mapping each executive audience to their primary concern dimension.

TOGAF’s own Business Value Assessment Technique (Chapter 24.5) supports this by providing a structured method for evaluating architecture alternatives against business value criteria. Source: TOGAF – Migration Planning Techniques

The practical application is straightforward:

• When presenting to a CFO, lead with total cost of ownership and return on investment
• When presenting to the board, lead with strategic risk and compliance exposure
• When presenting to programme directors, lead with delivery timelines and time-to-value

Evidence Table: Communication Frameworks and Techniques for Enterprise Architects

Framework / Technique	Source	Primary Audience	Core Mechanism	Application for Architects
Views, Viewpoints & Concerns	TOGAF / ISO 42010 (Source)	All stakeholders	Maps concerns to tailored architecture views	Create distinct views for each executive audience rather than one monolithic model
Three Horizons	McKinsey	CFOs, Boards	Segments investments by time horizon and risk	Frame architecture decisions as H1 (optimise), H2 (grow), or H3 (transform)
Business Value Assessment	TOGAF Ch. 24.5 (Source)	Financial stakeholders	Evaluates alternatives against business value criteria	Quantify architecture options in cost, risk and value terms
Loss-Framing	Kahneman & Tversky (Source)	Risk-averse executives	Leverages loss aversion for persuasion	Present inaction costs rather than action benefits
Curse of Knowledge Mitigation	Heath & Heath (Source)	All non-technical audiences	Replaces abstraction with concrete language	Use specific scenarios and stories instead of technical jargon
Berinato’s 2×2 Visualisation	HBR (Source)	All stakeholders	Matches visual format to information type and intent	Select conceptual or data-driven visuals based on whether declaring or exploring
Stakeholder Identification (ADM Phase A)	TOGAF (Source)	Architecture teams	Formal stakeholder cataloguing and concern mapping	Systematically identify and plan engagement for every stakeholder group

The Power of Narrative in Architecture Governance

Frameworks provide structure, but stories provide meaning.

Paul Zak’s neuroeconomics research, found that character driven stories trigger oxytocin production in the brain, increasing empathy, cooperation and willingness to act. Source: HBR – Why Your Brain Loves Good Storytelling

“Character driven stories consistently cause oxytocin synthesis and this is what is amazing about narrative: it changes the activity of people’s brains.”, Source: Paul J. Zak, Harvard Business Review

This is not a soft finding, but a measurable neurochemical response that directly affects decision making. When an architect presents a migration decision as a set of bullet points on a slide, the audience processes information. When the same architect frames the decision as a narrative, “Our customer service team currently waits 47 seconds for each policy lookup because our legacy system cannot index across three decades of records, here is how we change that”, the audience experiences the problem and feels compelled to solve it.

Concrete Language Defeats Abstraction. The Heath brothers’ research reinforces this principle. Abstract strategy statements fail to unite people behind organisational goals, but concrete language and stories succeed (source: HBR, The Curse of Knowledge).

For architects, this means replacing “we need to decouple our monolithic architecture to improve agility” with “right now, a single change to our pricing engine requires redeploying the entire platform, which takes three weeks and costs the business £180,000 in delayed feature releases each quarter.” The first statement is technically accurate. The second statement gets a CFO’s attention.

“Impenetrable strategy statements can’t unite employees behind an organization’s goals, but concrete language and stories can.” Source: Chip Heath and Dan Heath, HBR

The discipline of concrete language can be harder than it sounds to master. It requires architects to do the translation work before the meeting :

• Convert latency figures into customer wait times
• Convert coupling metrics into delivery delays
• Convert technical debt into pounds and pence.

This translation is not dumbing down, but adding a layer of meaning that the technical metrics alone cannot convey.

A Narrative Pattern for Architecture Decisions. 

The most effective architecture narratives follow a clear four-part structure: 

• Problem (what business pain exists today and who feels it)
• Mechanism (why the current architecture causes or fails to prevent this pain)
• Design Decisions (what architectural changes address the root cause and what alternatives were considered)
• Evidence (what measurable outcomes we expect and how we will verify them)

This pattern transforms technical rationale into business storytelling by anchoring every decision in observable consequences.

For example, an architect recommending an event-driven architecture might structure the narrative as follows.

• Problem: “Our order fulfilment process currently takes 4.2 days on average because seven systems must synchronise sequentially, and any failure in the chain requires manual intervention.”
• Mechanism: “The current point-to-point integration architecture means each system waits for the previous one to complete, creating a serial dependency chain with no resilience.”
• Design Decision: “An event-driven architecture decouples these systems so they operate independently, reducing the critical path and enabling automatic retry on failure.”
• Evidence: “Based on our proof of concept, we project fulfilment time will reduce to 1.8 days, saving approximately £640,000 annually in operational overhead and reducing customer complaints by an estimated 35%.”

This pattern is explored further in Architecture Decision Records for AI Systems,  transforms what could be an impenetrable technical discussion into a business case that any programme director can evaluate.

As discussed in Graceful Speech & Timeless Tales: The Complete Series, the art of persuasive communication has deep roots in human culture.

Architects who invest in narrative craft are not departing from rigour they are adding a dimension of communication that data alone cannot provide.

The story does not replace the evidence, it makes the evidence land.

Visual Communication and Cognitive Load

The third pillar of effective architecture communication (alongside frameworks and narrative) is visual design.

Cognitive load theory, established by Sweller in 1988, identifies three types of cognitive load: intrinsic (the inherent complexity of the material), extraneous (load imposed by poor presentation design), and germane (productive load that builds understanding). Source: Cognitive Load Theory

The architect’s goal is to minimise extraneous load so that stakeholders can devote their working memory to the decision at hand rather than to deciphering the diagram in front of them.

This principle has immediate consequences for how architects design their artefacts. A detailed UML sequence diagram that maps every service interaction in a distributed system may be technically precise, but it imposes enormous extraneous cognitive load on a non-technical viewer. The viewer spends all their mental energy trying to understand the notation rather than evaluating the decision. The same information, presented as a simplified flow with three or four key decision points highlighted, reduces extraneous load and frees the executive to engage with the substance.

“Visual communication is a must-have skill for all managers, because more and more often, it’s the only way to make sense of the work they do.” Source: Scott Berinato, HBR

Berinato’s framework, provides a practical decision tool for selecting the right visual format. By asking two questions:

• “Is the information conceptual or data-driven?”
• “Am I declaring something or exploring something?”

Architects can select among four visualisation types: idea illustration, idea generation, visual discovery and everyday dataviz. Source: Visualizations That Really Work

This simple 2×2 matrix prevents the common mistake of using a data-heavy chart when a conceptual diagram would be more effective or vice versa.

Audience-Specific Visual Artefacts 

The practical implication is that architects should maintain a repertoire of visual formats matched to their stakeholders rather than defaulting to whatever diagram tool they are most comfortable with.

Capability maps and strategy-on-a-page views resonate with board members focused on strategic alignment because they show the organisation’s capabilities in relation to strategic objectives without requiring technical knowledge to interpret.

Cost heatmaps overlaying risk, technical debt, or investment exposure suit CFOs who need quantified information at a glance. They can see immediately where the highest concentrations of cost or risk sit without reading a single line of technical documentation.

RAG dashboards with milestone tracking serve programme directors managing delivery velocity because they answer the question every delivery leader asks first: “Are we on track?”

Decision matrices work best when executives must compare trade-offs across options (build versus buy, cloud-native versus lift and shift) because they make the evaluation criteria and scoring transparent.

The One-Diagram Trap

A common failure mode is the architect who creates a single comprehensive diagram and presents it to every audience.

TOGAF’s stakeholder-driven viewpoints principle directly addresses this anti-pattern: enterprise architects should create distinct viewpoints for business executives (value and capability), financial stakeholders (cost and investment) and delivery managers (implementation and migration), rather than presenting a single monolithic mode. Source: TOGAF – Architectural Artefacts

The architecture has not changed, the view of it has been tailored to the viewer. This is not redundant work, but the core communication discipline that separates effective architecture governance from technical documentation that nobody reads.

The investment in visual communication pays through well-designed artefacts that become reusable assets that stakeholders reference between meetings, share with their own teams and use to advocate for architecture decisions in forums where the architect is not present.

A clear capability map on a board slide deck does more for architecture programme support than any number of detailed technical specifications.

Building Credibility Through Communication Discipline

Communication discipline (the practice of showing up with the same rigour, transparency and follow-through in every interaction) builds credibility over time. An architect who delivers a brilliant presentation once but fails to follow up on commitments or who communicates only when seeking approval, will never earn the sustained trust that effective governance requires.

The TOGAF Leader’s Guide defines the EA capability leader role around organisational alignment, governance communication and stakeholder engagement rather than purely technical deliverables. Source: TOGAF Leader’s Guide – General Concepts

It structures the architect’s responsibilities around accountability models, decision models and reporting frameworks that connect technical architecture to business leadership. The guide dedicates substantial attention to understanding the enterprise’s strategic position, business model and operating model. Positioning the architect’s role as one of translating business context into architectural decisions and communicating architectural value back to business stakeholders.

“The TOGAF Leader’s Guide structures EA capability around Accountability Model and Decision Model, Reporting Framework, and alignment of EA Capability Team in the Organization Model, indicating that governance communication and stakeholder engagement are core architectural leadership functions.” Source: The Open Group, TOGAF Leader’s Guide

This framing positions communication, not as a supplementary skill that architects should develop if they have time, but as a core architectural leadership function. This is as fundamental to the role as technical analysis or solution design.

Architecture Decision Records as Communication Artefacts

One of the most powerful tools for building credibility is the Architecture Decision Record (ADR). As I explored in Architecture Decision Records for AI Systems,  ADRs create a transparent, traceable record of what was decided, why it was decided, what alternatives were considered and what trade-offs were accepted.

When an executive asks “why did we choose this approach?” six months after the decision was made, the architect who can point to a well-structured ADR demonstrates not just technical competence but governance maturity.

The ADR becomes a communication artefact that outlives the meeting in which the decision was made, providing institutional memory that protects against revisionism and scope creep.

ADRs also serve a subtler credibility function through documenting alternatives that were considered and rejected (along with the reasoning) architects demonstrate intellectual honesty. They show that the chosen path was not the only path, but the best path given the constraints. This transparency builds trust with executives who are accustomed to being presented with fait accompli decisions dressed up as consultations.

The Evidence for Communication-Driven Success

Research from MIT Sloan’s Center for Information Systems Research suggests that organisations with mature enterprise architecture practices and strong governance communication can achieve significantly higher IT efficiency and business agility, with top-quartile firms reportedly generating up to 26% higher profit margins from their IT investments compared to peers with weaker architecture governance. Source: Enterprise Architecture: Driving Business Benefits from it

Large IT transformation projects frequently overrun budgets and timelines, with stakeholder misalignment and inadequate communication cited as key contributing factors to failure rates that can be substantial.

The correlation is not coincidental. As I explored in The Business Value of Enterprise Architecture Explored, architecture programmes that invest in structured communication plans tend to achieve higher adoption rates and faster business value realisation. When stakeholders understand and support architecture decisions, they fund them, staff them and remove organisational barriers to implementation. When they do not understand, they hedge, delay and divert resources to initiatives they can comprehend.

Consistency Over Brilliance

The most credible architects are not necessarily the most charismatic presenters. They are the ones who deliver the same quality of communication in a Monday morning stand-up as in a quarterly board review. Maintaining regular cadences of stakeholder updates, not just when there is good news to share, but when there are problems to surface.

They use consistent terminology, consistent visual formats and consistent reporting structures so that stakeholders can track progress without having to re-learn the communication framework each time. This consistency reduces the cognitive burden on executives and signals that the architecture function operates with the same discipline it expects from the systems it designs.

From Architect to Trusted Adviser: A Practitioner’s Path

The journey from technically excellent architect to trusted business adviser is not about abandoning technical depth, but adding communication breadth.

• The architect who understands cognitive load theory designs better presentations.
• The architect who understands loss aversion frames better business cases.
• The architect who maintains Architecture Decision Records builds institutional trust.
• The architect who tells stories (grounded in evidence, structured around business outcomes) changes minds.

The modern enterprise architect operates at the intersection of technology strategy and business leadership. The technical decisions have never been more consequential, cloud migration, AI integration, platform modernisation, data sovereignty, but consequence without communication is just risk without governance.

An architecture decision that the board does not understand is a decision the board cannot support and a decision without support is a decision without resources.

A Communication Maturity Model

Architects can assess their own communication maturity across four levels.

• First Level: the architect communicates primarily in technical terms and relies on stakeholders to translate.
• Second Level: the architect begins to frame decisions in business language but does so inconsistently, typically only for major governance gates.
• Third Level: the architect maintains structured communication plans with audience-specific artefacts, consistent cadences, and documented decision records.
• Fourth Level: the architect operates as a trusted adviser, proactively surfacing risks, framing strategic options, and shaping business strategy through architecture insight.

Most architects operate at level one or two. The frameworks and techniques in this post are designed to accelerate the journey to level three and beyond.

Practical Steps for Application. 

The practical steps are:

1. Invest in understanding your stakeholders’ concerns
2. Frame every architecture decision in terms of cost, risk and time-to-value
3. Replace abstract language with concrete scenarios and narratives 
4. Design visual artefacts for specific audiences
5. Maintain communication discipline 

The Strategic Imperative

As organisations navigate increasingly complex technology landscapes (multi-cloud architectures, AI governance, data mesh, zero-trust security) the gap between technical complexity and executive comprehension widens.

The architects who bridge this gap will not merely survive the next wave of technology transformation. They will lead it, because they will be the ones whom boards, CFOs, and programme directors trust to translate complexity into clarity and clarity into action.

Communication is not a soft skill that architects should develop when they find the time. It is the leadership skill that determines whether architecture programmes deliver value or deliver PowerPoint.

References

1. “Curse of Knowledge.”, Wikipedia
2. “The Curse of Knowledge.”, Harvard Business Review
3. “Framing Effect (Psychology).”, Wikipedia
4. The Open Group. “TOGAF Standard, Version 9.2 – Phase A: Architecture Vision.” https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html
5. The Open Group. “TOGAF Standard, Version 9.2 – Architectural Artifacts.” https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap31.html
6. The Open Group. “TOGAF Standard, Version 9.2 – Migration Planning Techniques.” https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap24.html
7. Berinato, S. (2016). “Visualizations That Really Work.” Harvard Business Review. https://hbr.org/2016/06/visualizations-that-really-work
8. Zak, P.J. (2014). “Why Your Brain Loves Good Storytelling.” Harvard Business Review. https://hbr.org/2014/10/why-your-brain-loves-good-storytelling
9. The Open Group. “TOGAF Leader’s Guide – General Concepts.” https://pubs.opengroup.org/togaf-standard/togaf-leaders-guide/togaf-leaders-guide_3.html

Architecture Decision Records for AI Systems. Why ADRs Are the Missing Governance Layer for Agentic AI

Graceful Speech & Timeless Tales: The Complete Series Index

The Business Value of Enterprise Architecture Explored

Communicating Architecture Value to the CFO

Data Storytelling

Why Boards Overlook Enterprise Architecture