Architecting for Change - Part V: Why Architecture Review Boards Make Complexity Worse

In the previous post in this series, I looked at accidental complexity and how it enters a system. When organisations begin to feel the effects of accidental complexity, they usually respond by adding more control. If the architecture is drifting, if duplication is increasing, if teams are making inconsistent decisions, and if change is starting to feel risky, then it is tempting to conclude that the organisation needs more oversight. More review boards. More approval steps. More meetings. More gates. If the architecture is becoming harder to control, surely more control should help. But...

Control is not the same as governance

Architecture Review Boards can make an organisation feel in control, but that sense of control is often misleading. They can slow work down while doing very little to improve the system, or the decisions shaping it, because the people on those boards are often too far removed from the context, constraints, and trade-offs the teams are dealing with.

Teams then spend time preparing approval documents, waiting for scheduled meetings before they can move forward, and reshaping decisions so they satisfy the process. That is process complexity. And process complexity is another form of accidental complexity. It adds more work around the work without necessarily improving the work itself.

The organisation feels more controlled, but the system has not become simpler, safer, or easier to change. It has just gained another layer of coordination cost.

The problem is not that governance is unnecessary. The problem is confusing governance with approvals. Good governance helps the organisation make better decisions. Approval-based governance doesn't.

But even setting aside the process overhead, ARBs are built on a flawed assumption about how software delivery works.

By ARB, I mean the common approval-based model: a central board that reviews architecture documents at fixed points, challenges decisions from a distance, and grants or withholds permission to proceed.

ARBs don't fit modern software delivery

Both waterfall and ARBs share the same foundational assumption: that the most important thinking happens upfront, before the work begins. Get the analysis right, get the design approved, and execution follows. The hard intellectual work is done. What remains is delivery. In a world of discrete phases, ARBs made sense. Finish the design, get it approved, then build.

However, that assumption is wrong, and it's wrong in the same way for both.

Software development is a knowledge-discovery process. You don't fully understand the problem at the start. Every implementation decision surfaces new information. Every deployment reveals something the design didn't anticipate. Every real user interaction exposes assumptions that seemed safe on paper.

Waterfall treats that discovery process as something to minimise through more upfront analysis. If you just analyse hard enough upfront, you won't be surprised later. ARBs do the same thing: get the architecture approved before the work starts, and you've controlled the risk. Both assume that knowledge is front-loaded, when in reality, it accumulates as you go, not before you begin.

The false sense of control is a symptom of this, not the root cause. Waterfall gives you a Gantt chart and a phase gate. The ARB gives you a signed-off design. Both feel like certainty. Neither is.

What they actually do is freeze a decision at the point of maximum ignorance: before implementation, before testing, before production, before real users. The plan or the approved design represents what the team believed to be true before they had done any work to tell them whether they were right. Both mistake the absence of known-unknowns for the absence of unknowns or unknown-unknowns.

“People overvalue their knowledge and underestimate the probability of their being wrong.”
- Nassim Taleb in Fooled by Randomness.

In reality, over-analysis increases risk. Teams form assumptions and hypotheses, but the process encourages them to treat those assumptions as facts. The longer the implementation is delayed, the longer the organisation carries untested beliefs as if they were true. This doesn't mean you forego upfront design, in the words of Dave Thomas, "Big design up front is dumb. Doing no design up front is even dumber."

Real learning happens when the rubber hits the road. Assumptions break. Integrations that looked simple turn painful. Dependencies behave differently than expected. Operational concerns that barely registered in the design review become critical in production. If a governance process cannot absorb that learning, it is no longer governing architecture. It is governing paperwork.

Modern software delivery is different. It is continuous, iterative, and incremental. It values tighter feedback loops, learning and validation. Teams make small bets, test assumptions, validate them against real usage, learn from production, and adjust. In those settings, you do more design and architecture, not less, but in a way that complements modern delivery, not blocks it.

Where do ARBs fit in that cycle? They don't.

By the time a team reaches the board, many of the important decisions have already been made, implicitly or explicitly. The review then becomes less about shaping the architecture and more about approving, challenging, or reworking a design from a distance. That slows feedback down at exactly the point where the organisation needs faster learning.

If you try to crowbar review boards in, you will grind delivery to a halt. Changes pile up for approval, feedback loops stretch, and batch sizes grow. That increases risk significantly.

The incentive to avoid the board altogether is just as damaging. Teams make stealth changes: decisions that quietly bypass the process because the cost of going through it is too high. Others simply delay progress until the board is available to review the decision. Over time, teams also learn to batch more decisions together so they do not have to keep paying for that delay again and again. Both behaviours have the same effect: slower feedback, larger changesets, more interdependencies, and more risk landing at once. The ARB was intended to reduce risk, but it ends up delaying learning and concentrating risk.

ARBs reward the wrong behaviour

ARBs change the nature of the decisions people bring to them. When teams know their work will be judged rather than improved collaboratively, the goal shifts. They stop asking for help with hard problems and start packaging decisions to gain approval. The board sees the version of the architecture most likely to pass, not the one that most needs scrutiny. That is not governance. That is performance.

This results in the organisation making decisions based on architecture that has been sanitised for approval. Risk that was real gets documented away. Complexity that needs addressing is reframed as a future consideration or downplayed. The board signs off confident that the hard questions were answered. Often, they were just hidden.

ARBs review intent, not reality

Architecture review boards usually focus on intent. Approvers review the High-Level Design, debate the diagrams, log the risks, and sign it off. But they rarely govern reality. What actually gets shipped to production can quietly drift away from what was approved.

That gap matters. The real system is not on paper; it is in production. That is what customers actually touch, what teams have to run, and what breaks in ways no slide deck ever saw coming.

The approved design also becomes the official record of the architecture. But that record starts drifting from reality the moment implementation begins. Decisions change during delivery. Pragmatic workarounds become permanent. Nobody updates the HLD. The organisation ends up with documentation that reflects what was intended before the work started, not what was actually built. The ARB process rewards polish at the point of submission. Hence, teams invest heavily in documentation to get through the gate, then nothing at all in keeping it accurate afterwards.

That gap has consequences beyond documentation. Decisions get made against the approved design as if it reflects the real system. New services are designed around dependencies that no longer exist, or that have changed shape significantly. Incident response starts from a diagram that doesn't match what's actually running. Capacity planning is based on an architecture that was superseded two quarters ago. The further the real system drifts from the record, the more those decisions compound the problem.

Architecture management tools can help keep the record closer to reality, but they cannot fix a culture that treats documentation as a gate to pass through. If teams only update the architecture record to gain approval, the tool becomes another place where intended architecture drifts away from the real system.

Final Thoughts

The problem is not architectural review itself. Review is valuable. Challenge is valuable. Governance is valuable. But it has to fit the way work actually happens.

This does not mean architecture should be left to chance, or that teams should make every decision in isolation. The opposite is true. Complex systems need stronger architectural thinking, but that thinking has to be embedded in the flow of work rather than deferred to a periodic approval ceremony.

In a modern delivery system, architecture governance should be closer to the work, earlier in the thinking, and more continuous and conversational. The answer is not a lighter version of the same ARB process. It is a different model entirely: one built around enabling teams rather than approving their decisions.

That will be the topic of the next post in this series.