Enterprise Architecture (EA) has been part of organisations for many decades. Most companies have some form of EA and plenty of diagrams meant to show how everything fits together. These are often built around frameworks such as TOGAF and Zachman, but there are several other well-established architecture frameworks that can be used depending on industry and requirements.
Yet when boards discuss technology, architecture may not feature on the agenda unless there’s a problem. It’s not that boards don’t care or know about architecture, the issue is that EA can be seen as not delivering what boards genuinely need.
Why Boards Rarely Discuss Architecture
Boards typically only hear about architecture when something goes wrong: a hack or security issue, a major outage, a failed transformation or a regulatory breach. Otherwise architecture may be left out of the conversation. The reason isn’t indifference, but more that EA often misses the mark on what matters most to the board.
What Boards Care About (Not Diagrams)
Boards have a handful of core responsibilities and these can follow a governance code / framework
Examples of governance codes/frameworks (others are available):
This article provides a good explaination of a board governance framework “What are the core components of a board governance framework?“
Some of these responsibilities cover areas such as:
- Strategic coherence: Are we investing in the right capabilities to succeed?
- Risk oversight: Where could the business fail on a large scale? (for example COSO ERM)
- Capital allocation: Are our technology investments building lasting value?
- Execution confidence: Can management deliver on its promises?
- Ethical oversight: Are we upholding appropriate standards of conduct and integrity?
- Resilience: Can we adapt to shocks, new regulations or disruptions? (For example: guidance from the UK FCA)
- Stakeholder engagement: Are we considering the interests of shareholders, employees, customers and society?
- Compliance and legal responsibility: Are we fulfilling our statutory and regulatory obligations?
- Performance monitoring: Are we regularly reviewing organisational performance against targets and objectives?
Technology serves as the foundation supporting each of these critical governance areas. However the board’s primary concern is not with technology itself, but with the confidence that technological choices are purposeful, well-aligned with overall organisational objectives and capable of being maintained over time.
Boards are seeking assurance and reassurance that all technology related decisions are made with intention, in harmony with strategic aims and are structured to support ongoing sustainability.
When Enterprise Architecture fails at Board Level
When EA fails at the board level, it often shows up with:
- Dense application landscape diagrams (EA is positioned too low)
- Framework heavy language (TOGAF, Zachman, capability maps)
- EA is measured on output and not impact
- Long lists of “standards” and “principles”
- Abstract future state visions disconnected from funding decisions
This can happen when an EA function focuses on:
- Structural correctness
- Technical consistency
- Compliance with standards (e.g., ISO/IEC 42010 for architecture descriptions)
- Logical completeness
While these areas are essential for building a sound EA /technical foundation, they do not by themselves address the broader, strategic questions that boards are concerned with, such as the organisation’s fragility, implicit assumptions, compounding risks or potential bottlenecks under pressure.
This can create a disconnect between what EA can typically deliver and the insight boards actually require to steer the business effectively.
Enterprise Architecture / Architecture can becomes valuable to a board when it explains why certain outcomes are likely or unlikely given the current shape of the enterprise. This is an idea aligned with Systems Thinking.
What Boards Actually Need from Enterprise Architecture
A Map of Enterprise Constraints (Not Systems)
Boards need to see where change is slow, expensive or risky. Consider these questions which a board needs to understand and align with the Theory of Constraints at the enterprise level.
- Where change is slow, expensive or risky?
- Which capabilities are tightly coupled?
- What cannot be altered quickly without cascading impact?
Mapping an architecture and using an EA tool to do this can help in identifying answers to these questions, but remember these diagrams are not what the board are looking for, but providing a constraint map of the architecture.
- “If we pursue Strategy X, these three bottlenecks will determine our cost, timeline and risk.”
Early Warning Signals, not Post-Event Explanations
Most architecture analysis happens after failure:
- “Here’s why the outage happened”
- “Here’s why the transformation stalled”
Boards need EA to surface leading indicators that don’t match strategy. These signals should work like Key Risk Indicators (KRIs) in risk management:
- Rising integration density
- Fragile data ownership
- Overloaded platforms
- Capability dependencies that no longer match strategy
Without this, architecture can remain reactive and something repeatedly criticised in post-incident reviews such as major outages.
Clear Trade-Offs Tied to Strategy
Every architectural decision involves a bet such as:
- Centralisation vs. autonomy
- Speed vs. control
- Standardisation vs. differentiation
Boards don’t need the “right” answer, but rather a need to know which trade-offs management is making and which ones they’re inheriting by default. A good EA makes these choices explicit, a poor EA hides them behind technical language.
A Line of Sight from Spend to Structural Outcomes
Boards approve large technology budgets with surprisingly little insight into what those investments change structurally. If architecture cannot connect spending to changes in the enterprise, boards will see technology investment as risky and uncleary. This is where IT value realisation can help.
EA should consider this IT Value Realisation checklist
- 1) Outcomes defined & quantified (targets, baselines, owners)
- 2) Capability → value stream → process model in place
- 3) Architecture decisions trace to value hypotheses
- 4) Governance embeds value gates (Architecture Review Boards)
- 5) Tooling configured for reuse & traceability (Archimate / UML)
- 6) Incremental delivery plan
- 7) Benefits tracking live (variance, forecast vs. actual, corrective actions)
- 8) Operating model aligned (ITIL/IT4IT value streams instrumented)
- 9) Risk controls (security, compliance, quantum‑resilience strategy)
- 10) Communication cadence (value dashboards to execs/boards)
Confidence That Someone Is Watching the Whole System
Boards want to know that someone genuinely understands how the organisation works as a system. This expectation matches the intent behind enterprise-wide architecture governance, not just IT governance. This is a function that Enterprise Architecture should be fulfilling.
Reframing Enterprise Architecture for the Board
If if EA is to truly influence decision making at the highest level, it must evolve its approach.
To become relevant at board level, EA must shift from traditional practices to a more impactful, business centric approach. This transformation involves:
Describing the enterprise → Explaining its behaviour
Instead of merely cataloguing systems and processes, Enterprise Architecture should interpret how the organisation functions, highlighting patterns, interdependencies and emergent risks.
This can be met by telling stories about why things happen the way they do and what that means for the board’s strategic oversight.
Defining standards → Surfacing consequences
Rather than presenting lists of standards and principles, Enterprise Architecture should highlight the real world implications of these choices.
- What risks are introduced or mitigated?
- How do these standards impact business agility, resilience, or regulatory compliance?
Boards need to understand not just what the rules are, but why they matter.
Producing models → Influencing decisions
Enterprise Architecture should move beyond the creation of abstract models and frameworks by using its insights to actively shape board-level discussions.
This can be met by providing recommendations, challenging assumptions and framing choices in terms of risk, opportunity and strategic alignment.
The critical question EA must answer for boards
“Given how this enterprise is built today, what should leaders worry about tomorrow?”
This question captures the essence of board-level engagement. Anticipating future challenges, highlighting areas of fragility and ensuring leaders are equipped to make informed, forward-looking decisions.
Enterprise Architecture’s true value lies in its ability to surface these concerns before they become crises enabling boards to act proactively rather than reactively.
When EA can answer board level questions with clarity and relevance, the board will listen.
Max Hemingway 