At the end of a useful architecture review, I want to be able to write a sentence like this: “Account state remains in the current service during migration; Maya owns the parity test; we reconsider after two weeks of shadow traffic.”
That sentence contains a choice, an owner, evidence, and a review trigger. A diagram without those elements may help the discussion, but it has not resolved the work.
Name the decision
“Review the new platform” is too broad. “Decide whether account state remains in the current service during the migration” gives the group something it can resolve. It also exposes the evidence required: consistency during coexistence, ownership of writes, and the condition for moving the state later.
Before review, I want six things:
- the outcome the decision must support;
- the person accountable for the decision;
- the deadline and the cost of waiting;
- the constraints that cannot be traded away;
- the options considered, including keeping the current design;
- the evidence that separates those options.
If the decision owner is missing, the review cannot repair the ownership gap. If the outcome is unclear, more architecture detail usually creates more ways to disagree.
Make the packet earn its length
A useful review packet lets a reviewer test the decision without reconstructing the project. I keep the main argument short: current state, desired result, constraints, options, evidence, operating consequences, and recommendation.
The diagram should answer a question. A component view can show ownership. A sequence can expose partial failure. A state model can reveal recovery gaps. One picture rarely does all three.
Detailed benchmarks, threat models, and migration steps can sit behind the argument. Putting every artifact in the main path makes it hard to see which evidence actually governs the choice.
Review the assumption that controls the choice
Most decisions turn on a small number of assumptions. The proposed store must handle a particular access pattern. The old and new systems can run together without ambiguous ownership. A vendor can support the required failure isolation. The team can operate the design with its current staffing.
I ask which assumption, if false, would change the recommendation. That is where review time belongs.
When evidence is missing, the right result may be a test. The test must discriminate between options. “Run a prototype” is incomplete. “Measure whether the proposed index keeps the p99 read below the operating limit at twice projected load” can close the question.
Let expertise inform the owner
Reviewers contribute constraints, experience, and evidence. The system still needs one decision owner after the room has emptied.
I want objections stated as consequences: which requirement fails, under what condition, and what evidence supports the concern. The decision owner then accepts the objection, requests a test, or records why the risk is acceptable.
Dissent matters when it improves the decision record. A reviewer who believes the design will fail should be able to state the trigger that would prove the concern and the cost of learning later. Counting opinions hides that information.
End in a defined state
A review should end in one of a few explicit states:
- approve the recommendation;
- approve it with a named condition and owner;
- run a specified test before deciding;
- reject it because a stated constraint is unmet;
- return a product or ownership question to the person who can resolve it.
“Needs more thought” is not a state. It leaves the team to guess whether it may proceed and gives no one responsibility for producing the missing evidence.
Keep a decision record
The record does not need to be long. It should name the choice, owner, rejected options, accepted risks, next action, and review trigger. The trigger matters because architecture decisions are made with current evidence. A change in load, failure consequence, team boundary, or vendor behavior may invalidate the choice.
The record also lets future engineers distinguish an intentional tradeoff from an accident. They can challenge the original assumption instead of repeating the entire debate.
I judge the review the next morning. The team should know what it may build, which evidence it still owes, who owns the risk, and the condition that will reopen the decision.