Enterprise architecture has a communications problem. The discipline that describes how an organisation's people, processes, technology, and information relate to each other — and how those relationships should evolve to meet strategic objectives — is consistently either over-engineered into abstraction by practitioners or dismissed as IT infrastructure planning by executives who have never seen it done well. Both responses are costly mistakes.

What Enterprise Architecture Is — and Is Not

Enterprise architecture is not a technology function. It is a governance function that happens to involve technology. The distinction matters because it determines where in the organisation EA capability should sit, what it should produce, and how its outputs should inform decision-making at board and executive level.

A mature EA function produces three categories of output: current-state documentation (what the organisation's capabilities, information flows, and technology dependencies actually look like today); target-state specification (what they need to look like to deliver the strategic objectives the board has approved); and transition architecture (the sequenced, costed programme of change that moves the organisation from current to target state while managing operational risk).

The question enterprise architecture answers is not 'what systems should we buy?' It is 'how should our organisation be structured to do what we have decided we want to do?' The former is procurement. The latter is governance.

Why Boards Misunderstand EA

The most common executive-level misconception about enterprise architecture is that it is equivalent to IT infrastructure planning — selecting cloud providers, rationalising server environments, or managing software licences. This is not wrong so much as dramatically incomplete. IT infrastructure is one layer of enterprise architecture; it cannot be well-governed without the broader architectural context that EA provides.

The second misconception is that EA produces diagrams, not decisions. This is a symptoms-of-bad-EA-practice problem that has become incorrectly generalised into a diagnosis-of-the-discipline problem. EA done well produces decision packages: structured analysis of architectural options with explicit trade-offs, risk profiles, cost estimates, and strategic alignment assessments that enable executives to make informed choices. The diagrams are supporting evidence, not the product.

EA in Regulated Environments

For institutions operating in regulated industries — financial services, healthcare, government, regulated manufacturing — enterprise architecture carries a compliance dimension that amplifies both its value and the cost of doing it poorly. Regulators increasingly examine architecture decisions directly: FCA's operational resilience requirements, OSFI's technology risk guidelines, and FDA's 21 CFR Part 11 framework all create implicit or explicit standards for how systems are designed, documented, and governed.

An institution that cannot produce a coherent current-state architecture map on request from its regulator is communicating something about its operational maturity that goes beyond the immediate regulatory question. ELDR has seen clients in regulatory examination situations where the absence of maintained enterprise architecture documentation was treated by examiners as evidence of inadequate governance — an inference that, while arguably unfair, is not illogical.

Building EA Capability That Serves Decision-Makers

The practical recommendations for organisations that want EA capability that actually informs executive and board decision-making are straightforward, though not easy. First, locate EA accountability at the Chief Architecture Officer or equivalent level with direct access to the CEO — not embedded in the CTO organisation where it will be captured by technology implementation priorities. Second, define EA output formats around executive decision needs, not architectural completeness. Third, invest in the EA function's facilitation and communication capability as heavily as its technical knowledge — the best enterprise architects are governance translators, not technical specialists.