What makes an architecture design authority useful rather than an obstacle?

The failure mode

A body that reviews every design becomes a queue, is staffed by people distant from the systems, makes decisions with less context than the team, and is resented. Teams pre-negotiate outcomes, present decisions already made, and route around it — so it consumes time and changes little.

What makes one useful

• Decision rights that are explicit and narrow. It decides a small set of genuinely cross-cutting things — shared platform choices, interface standards, decisions with consequences beyond one team — and everything else is the team's.
• Advice available on demand and cheaply, which is where most of its value actually is. Teams use a resource that helps them; they avoid one that judges them.
• Members who build. An authority staffed by people not currently working in the systems loses credibility and context simultaneously.
• Decisions recorded with reasoning and a revisit condition, so they can be revised when the context changes rather than persisting because nobody remembers why.
• A defined significance trigger, so teams know what requires the authority and what does not, rather than guessing.
• A fast path, since a body that takes three weeks will be worked around regardless of its authority.

The alternative worth considering

An architecture community with a small decision-making core — the wider group builds shared understanding and the core decides the genuinely cross-cutting questions. It scales better and produces decisions teams actually implement, because they participated in forming them.

The honest measure

Not decisions made, but whether teams consult it voluntarily. A body teams seek out is adding value; one they are compelled to attend is a tax. That measure is uncomfortable and it is the one that predicts whether the decisions get implemented.