A solution architecture review is only as good as what it's given to review. Documenting the solution properly — context, options, decisions and impact — is half the battle.
A solution architecture review exists to answer one question before money is committed: is this design good enough to build, and if not, what specifically has to change?
It is not a quality gate for its own sake, and it is not an opportunity for architects to redesign someone else's solution. A review that consistently produces better outcomes has a narrow remit — surface the risks the delivery team cannot see or cannot raise, check the design against agreed constraints, and produce a decision that sticks.
Timing determines whether a review can change anything. Three gates cover most situations:
Reviewing only at the end is the most common structural mistake. By then the review can either wave the solution through or trigger an expensive fight, and it usually waves it through.
Small enough to decide, broad enough to see the risks. A chair with authority to make the call. Two or three architects covering the relevant domains — usually security and data, plus infrastructure or integration depending on the solution. The solution architect presenting. Someone who understands the business outcome, so the review does not optimise a technically elegant solution to the wrong problem.
Beyond about eight people, the session becomes a briefing rather than a review. If more people need visibility, circulate the outcome rather than expanding the room.
The quality of a review is capped by the quality of the submission. Insist on:
If the pack does not arrive 48 hours ahead, move the review. Holding it anyway teaches everyone that the deadline is decorative.
| Outcome | Means | Next step |
|---|---|---|
| Approve | Proceed as designed | Record decision; no further gate |
| Approve with conditions | Proceed, but specific items must be resolved | Conditions logged with owner and date |
| Rework | A material aspect must change; return for re-review | Re-submission with a defined scope |
| Reject | The approach is not viable | Escalate with a written rationale |
Making this defensible rather than subjective is what a weighted scorecard is for — assessing each domain, weighting by materiality, and producing a recommendation the chair can explain to a sponsor who disagrees with it.
Conditions are the mechanism by which reviews change outcomes, and they fail for predictable reasons: no named owner, no date, or wording so vague that closure is a matter of opinion.
Track them somewhere visible, review open conditions at the start of each design authority meeting, and escalate ones that pass their date without movement. If an accepted deviation becomes permanent, it should convert into a formal exception or waiver with an expiry, rather than quietly becoming the new standard.
Reviews lose credibility in one of three ways. They become unfailable, so teams stop preparing seriously. They arrive too late to change anything, so they become a formality. Or they produce conditions nobody tracks, so the organisation learns that agreeing to a condition costs nothing.
All three are governance problems rather than architecture problems, which is why the review process needs a design authority behind it with the standing to say no and to be supported when it does.
The Architecture Review Kit includes a solution review template plus review-type variants, so the depth always matches the stage and risk.
