Architecture Reviews
Reviewing early enough to influence rather than to veto.
5 to work through
-
intermediate
The business has selected a SaaS product. You are asked to review the integration architecture after the contract is signed. What do you do?
2 min answer -
advanced
An architecture review board has become a bottleneck that teams route around. What should replace it?
2 min answer -
advanced
An enterprise's architecture review board is seen by engineering teams as a gate to be survived rather than a source of value. What should change?
2 min answer -
advanced
An interviewer tells you: you now own architecture review for 400 engineers in 40 teams. Median time from submitting a design to getting a decision is 19 days, and three teams shipped significant designs without review last quarter. Talk me through what you change.
3 min answer -
advanced
Architecture review boards are widely disliked and frequently ineffective. What makes a review actually improve a design, and what should the reviewer's posture be?
3 min answer
2 terms in this topic
Architecture Review Practice
Running a design review that improves the design rather than performing gatekeeping, through timing, framing and the questions asked.
practiceReview Readiness Criteria
A stated bar a design must meet before review, so the session is spent on judgement rather than on discovering that the work is not ready.
Neighbouring topics
Architecture Communication
General material on communicating architecture.
Architecture Diagrams
Choosing an audience and refusing to mix levels of abstraction.
C4 Model
Context, container, component and code as four separate diagrams.
Context Diagrams
The system as one box, with its users and external systems.
Sequence Diagrams
Ordered message exchange, and walking the failure of each arrow.
Data-Flow Diagrams
Following the data across trust boundaries rather than the calls.
Deployment Diagrams
What runs where, in which zone, behind which boundary.
Communicating Threat Models
Making risk legible to people who will fund or accept it.
Writing Decision Records
Context, alternatives and consequences, written once and never edited.
Technical Proposals
A written argument circulated before the decision feels made.
Presenting to Executives
Decision first, cost, risk, and what happens if we do nothing.
Presenting to Engineers
Mechanism, alternatives rejected, and what you are unsure about.
Explaining Trade-offs
Naming what was given up, and the condition that would change it.
Handling Disagreement
Arguing from consequences, and escalating in the room.
Negotiation
Trading on interests rather than positions, with priced options.
Documentation Practice
Keeping documents close to the code and honest about staleness.
Presentation Skills
Structure, pacing and the slide that carries the decision.
Written Communication
Writing that survives being read without you in the room.
Facilitation
Running a design session that reaches a decision.