A mid-sized company needs architectural consistency without the overhead of a formal governance function. What is the minimum viable arrangement?

The minimum that works

• A written, short list of decisions that require consultation — identity, data classification, the audit record, primary datastores, public API conventions, anything crossing a regulatory boundary. Everything else is explicitly a team decision, and stating that is as important as stating the list.
• Decision records for anything expensive to reverse, stored beside the code, with the rejected options and the conditions that would change the answer.
• A paved road: a template producing a compliant, observable, deployable service. This does more for consistency than any review process, because it is adopted for being fastest.
• Automated checks for anything mechanical — dependency direction, observability presence, authorisation on endpoints, tenant columns. A control in the pipeline is faster and more consistent than a human, and it produces evidence as a by-product.
• A regular, short, voluntary forum where anyone can bring a design for advice, with a commitment to respond quickly. The test of whether it works is whether people bring things voluntarily.

What to avoid at this size

• A review board, which becomes a bottleneck with fixed capacity against unbounded demand and gets routed around.
• A framework, which imposes a vocabulary and a process disproportionate to the organisation and consumes the effort that should go into the paved road.
• A dedicated architecture team detached from delivery, which separates decision authority from the feedback that would correct it. Designs become optimistic, teams route around them quietly, and the documented architecture diverges from the real one.
• Comprehensive documentation, which will be stale and unread.

The single highest-return investment

The paved road. Everything else is a control on behaviour; the paved road changes what the easiest behaviour is. A team that gets a compliant, observable, audited service from one command does not need to be reviewed into compliance.

The scaling trigger

More formality becomes necessary when the number of teams exceeds the number any individual can keep track of, or when a regulatory obligation requires demonstrable governance. Adding it earlier is overhead; adding it later is a period of divergence that must then be reconciled — and the reconciliation is expensive.