The Architecture Committee

In many companies, I often see something called an architecture committee — or at least a strong desire to create one. But what exactly is it, and what problems does it actually solve?
At its core, an architecture committee is a meeting of architects (and sometimes stakeholders) where architectural artifacts are discussed.
The real question is: why are they discussed?

1. To check the quality of an architectural proposal?
Not really. In fact, the effect on quality is usually the opposite. Instead of finding the best solution, the group often ends up choosing the option that the fewest people disagree with.
Details also tend to get lost in spoken discussion. Many participants don’t fully grasp what’s being presented, and it takes a lot of time to explain things clearly — while everyone else just waits around, bored.
A far more effective way to check quality is to do it asynchronously.

2. To reduce architectural risks?
Yes, in some cases. There are times when a large-scale architectural decision impacts huge parts of the organization. In those situations, speed isn’t as important as risk awareness.
Take, for example, an architectural strategy or a company’s long-term technical roadmap. Long discussions can help prevent catastrophic mistakes from going unnoticed.
But even here, an architecture committee isn’t the most effective approach — asynchronous reviews work better for this too.

3. To get fast stakeholder feedback under time pressure?
In theory, yes. But in practice, I’ve never seen it actually work. Stakeholder comments usually create multiple rounds of committee meetings, and the original goal of “quick feedback” ends up lost.

So what does asynchronous review mean?
It’s when a proposal is written up in a clear and objective way, and stakeholders review it on their own time. They provide targeted feedback, and the author addresses it directly.
If disagreements take too long to resolve asynchronously, that’s when synchronous meetings help. But those meetings should be focused only on specific stakeholders and their issues. They’re not for debating alternatives — they’re for clarifying gaps in the solution or in stakeholders’ understanding of it.

You might ask: “But isn’t that still a kind of architecture committee?”
Technically, yes. But I’m talking about the way the term is most often used inside companies: as a recurring meeting where everyone gathers in one room (or Zoom).

The unfortunate part
Because of how popular the term “architecture committee” has become, and how inefficiently it’s often used, consulting firms now treat it as a benchmark for organizational maturity. If you don’t have one, they label you as having a “low maturity level” 🤡.

Instead of chasing labels, let’s stay pragmatic. Use the tools that are actually the most effective for solving the problems at hand.

How does your company handle the architecture committee?