Most architecture reviews begin with diagrams.
Boxes. Arrows. Databases. Queues. Cloud services.
Within minutes the room is debating implementation details: Kafka or RabbitMQ, monolith or microservice, Kubernetes or something simpler.
Those discussions matter. They are also usually too early.
The best architecture reviews start with one question:
> What problem are we actually optimizing for?
Two engineers may argue about architecture while optimizing different objectives.
One wants event-driven architecture to maximize deployment independence. Another wants a monolith to minimize operational overhead.
They are not really arguing about technology. They are arguing about priorities.
Architecture is downstream of intent, constraints, assumptions, and tradeoffs.
Technology comes afterward.
When reviews start with implementation, the reasoning has to be reconstructed in real time. It rarely emerges cleanly.
Start with:
If the architecture is correct, what should improve? By how much? Over what time horizon? How will we know?
Most architecture reviews produce decisions.
The best ones produce understanding.
A future engineer reading the review should understand the objective, constraints, assumptions, rejected alternatives, and expected outcomes.
The diagram becomes almost secondary.
Architecture is organized judgment. The best reviews make that judgment impossible to misunderstand.