Architecture · 8 min read

Why Most Architecture Functions Fail to Create Business Value

Architecture teams drift into review boards, document factories and gatekeepers. Their actual job is the opposite: reduce uncertainty, accelerate delivery and enable decisions. The evidence on why the drift destroys value is now hard to ignore.

Part of Architecture & Decisions · Decision Architecture

There is a particular kind of architecture function that everyone recognises and no one defends. It meets fortnightly. It maintains a wiki no engineer reads. It runs a review board where designs are presented, questioned and stamped, and where the highest skill an engineer can develop is the art of getting past the board rather than building something users trust. It produces documents on schedule and value almost never. The people in it are usually thoughtful and senior. The function is failing anyway, and not because of who is in it.

The thesis of this site is that architecture is not about diagrams or technology. It is the discipline of making decisions that let an organisation change safely and deliver consistently. By that definition most architecture functions are not doing architecture at all. They have become review boards, document factories and gatekeepers. Their job, properly stated, is the opposite: to reduce uncertainty, accelerate delivery and enable decisions. The gap between those two descriptions is where the business value leaks out.

The failure mode is structural, not personal

The research is unusually blunt about why this happens. A 2025 study in Information Systems Frontiers found that enterprise-architecture initiatives fail mainly because they focus on deliverables rather than on the use of those deliverables to create value, because goals are unclear, and because there is a disconnect between what the business needs and what architects produce. The primary cause it names is the lack of collaboration between architects and business stakeholders. Read that as a sentence about incentives. A function measured on documents will produce documents. A function measured on whether the organisation can change safely will produce something else entirely.

The most visible symptom is the Architecture Review Board. Thoughtworks, drawing on the State of DevOps research, puts it plainly: the traditional Architecture Review Board approach is counterproductive, often hindering workflow and correlating with low organisational performance. The mechanism is worth dwelling on. A board that meets monthly turns just-in-time review into just-in-case delay. It attracts more stakeholders than any one decision needs. It rewards ceremony over real risk, and it teaches teams to design for the board rather than for users and reliability. The board feels like governance. It behaves like a queue.

Architecture is the work of needing less permission

The deepest evidence comes from DORA, and it reframes the whole question. DORA's research on loosely coupled architecture finds that when architecture lets teams test, deploy and change systems without depending on other teams, those teams require little communication to get work done. Conversely, organisations fail to achieve critical delivery outcomes because of limitations imposed by their architecture. In the 2021 cohort, elite performers who hit their reliability targets were roughly three times more likely to run a loosely coupled architecture than low performers.

Sit with what that implies. Architecture is fundamentally about reducing the need for communication and approval. The review board is, by construction, a generator of communication and approval. It is not a flawed implementation of architecture; on this evidence it is anti-architecture. DORA even names the metrics that expose it: the share of design changes requiring formal approval outside the team, and the share of deployments needing cross-service coordination. If those numbers are high, your architecture function is creating dependency, whatever its diagrams say.

A document factory optimises for legibility to the board. A Delivery Architecture: The Translation Layer function optimises for the organisation's ability to change safely and ship consistently. They are not the same goal, and most days they are opposite goals.

Decision velocity is half the job

Most reform efforts fix decision quality and ignore decision velocity, which is why they disappoint. Jeff Bezos's distinction between one-way and two-way doors is the useful frame here: irreversible decisions deserve deliberation; reversible ones should be made fast and delegated deep into the organisation. Treating two-way doors as if they were one-way produces slowness, risk aversion and diminished invention. A review board treats every door as one-way, because that is the safe posture for a body that meets occasionally and owns nothing. The result is governance that is simultaneously too slow for small decisions and too shallow for large ones.

The credible alternative is not to abolish governance but to decentralise it. Andrew Harmel-Law's architecture advice process, now on the Thoughtworks Radar at Trial as of April 2025, keeps the decision with the people closest to the work while requiring them to take advice from those affected and from those with expertise. Lightweight Architecture Decision Records, in the lineage Michael Nygard established, capture the reasoning rather than the ceremony. Thoughtworks reports this succeeding at scale, including in regulated industries, which removes the usual objection that gates are the price of compliance. Compliance needs an auditable decision trail. It does not need a monthly meeting.

The constraint is moving, and the board is on the wrong side of it

This is where the architecture failure meets the AI thesis. As generation becomes abundant and AI accelerates code production, the binding constraint shifts away from writing software and toward decision throughput and the human ability to accept change safely. We call that the acceptance gap. A function organised as a review queue is precisely the wrong shape for a world where the volume of changes needing judgement is rising fast. The 2024 DORA report sharpens the warning: an internal developer platform improves performance only when built around developer independence, and unstable organisational priorities cause large, persistent drops in productivity that no amount of documentation or strong leadership repairs. Throughput, not paperwork, is the scarce resource.

The analysts have noticed the function is at risk. Gartner expects enterprise architecture to shift from a business-outcome-driven posture toward an internal management consultancy model, and reckons that by 2028 about half of EA teams will rebrand to emphasise a strategic business-partner role simply to stay relevant. We would put it less gently. Rebranding the board does not help if it still behaves like a board. The job is to dissolve the gate, not redecorate it.

What a delivery-architecture function measures

The reframe is the contribution. Architecture sits on the spine that runs from business strategy through product, architecture, engineering and operations to outcomes; its job at every joint is to reduce uncertainty, accelerate delivery and enable decisions. That makes it measurable in ways a document factory never is. Track independence: the proportion of changes and deployments that need approval or coordination outside the owning team, and drive it down. Track the cost of delay on decisions: how long a reversible choice waits for a forum. Track reversibility-aware governance: gate the one-way doors deliberately, delegate the two-way doors by default. These are numbers a CTO can act on, unlike a count of diagrams produced.

None of this asks architects to do less thinking. It asks them to spend it on decision quality and decision velocity rather than on legibility to a committee. If you want the outcome metrics that make this concrete, start with our work on measuring AI engineering, and read Architecture Governance Without Bureaucracy for how to keep the audit trail while removing the queue. The board was never the architecture. The decisions were.