Technical Architecture Review

Structured ADR-style review covering context, decision, alternatives, and consequences.

# Architecture Decision Record â [Short title] **ADR number:** [NNNN] **Status:** [Proposed | Accepted | Superseded by ADR-XXXX] **Date:** [YYYY-MM-DD] **Authors:** [Names] **Reviewers:** [Names] ## Context What is the problem we are trying to solve? Why now? What changed (scale, requirement, cost, regulation) that surfaced this question? Be specific â vague context produces vague decisions. Include: - Current state diagram (one paragraph or a small mermaid diagram) - The forcing function (what breaks if we don't decide) - Constraints we must respect (budget, timeline, compliance, existing contracts) ## Decision A single declarative paragraph stating what we will do. No equivocation. Cross-reference any companion decisions made elsewhere. ## Alternatives considered For each alternative, write 2-4 sentences: ### Alternative A: [Name] What it is, why it was attractive, why we rejected it. ### Alternative B: [Name] What it is, why it was attractive, why we rejected it. ### Alternative C: Status quo Always include the "do nothing" alternative explicitly. If it's truly intolerable, say so and quantify the cost. ## Consequences What becomes easier as a result of this decision? What becomes harder? What new categories of problem are we accepting? - **Positive:** [list] - **Negative:** [list] - **Neutral but worth noting:** [list] ## Implementation plan - Phase 1 (week 1-2): [milestone] - Phase 2 (week 3-4): [milestone] - Phase 3 (week 5-6): [milestone] - Rollback plan: [how we undo this if Phase N reveals a blocker] ## Open questions List the things we don't know yet but plan to learn through implementation. Do NOT use this section to delay decisions that should be made up-front. ## References - Related ADRs - Vendor documentation - Cost models - Spike outputs

Price: Free
State: approved