ARCHITECTURE DECISION TEMPLATE
Keep the alternatives that lost next to the diagram.
Architecture Decisions become tomorrow’s constraints. This template keeps the lost alternatives, the operational load, and the Human Decision that later teams will inherit.
The Decision this template frames
Question: stay, move a workload, buy a managed service, split a boundary, or postpone. Owner: usually an architect or engineering lead. Stakeholders: security, operations, and the budget owner.
A diagram that shipped without the rejected paths is a poster, not a record.
Evidence that belongs on an architecture card
Reproduced workload characteristics beat vendor benchmarks. Teams disagree about lock-in, cost, and who gets paged. Those disagreements belong on the record.
Known unknowns: unreproduced numbers, hiring that has not landed, and an exit path nobody has tried. Material risks: blast radius and a constraint nobody can reopen.
Hinges, approvals, reversal, and Outcome
Decision Hinges: time to value with this team, exit, and operational load. Required approvals: Decision Owner plus security when blast radius is material.
What could reverse the Verdict: a hiring slip, a failed proof, or a cost that only appears in production. Outcome review: after the first production incident that the new boundary was supposed to contain.
How the method uses this frame
Champion defends the preferred architecture. Challenger attacks operations and exit. Strategist may propose a thinner path. Inspector marks unreproduced benchmarks. Judge scores time to value with this team.
Modern is not a criterion
Modern is not a criterion. A proof of concept is not production.
Champion and Challenger test the case, Inspector checks the evidence, and Judge records the Verdict for the Decision Owner.
What to write on the card
Keep the current boundary, split a service, or buy a managed substitute. Write the exit. If the Verdict favors split and the Human Decision stays because hiring will not land this half, both remain on the record.
Bring Argumont a Decision worth challenging.
Structure the question, test the evidence and the assumptions, and preserve what your organization ultimately decides.
Start an architecture Decision