The method helps clarify architecture context, options, and consequences concretely. It organizes technical context, alternatives, and consequences. The result is captured as an ADR file, decision log, and rationale.
Architecture Decision Record
Turns architecture context, options, and consequences into a tangible result by naming the decision, describing context, and capturing consequences.
Which architecture decision needs to be recorded, and what context, options, decision, and consequences must a future reader understand?
The team follows the steps: name the decision, describe context, capture options, document the decision, and capture consequences. Each step is captured visibly. At the end, an ADR file, decision log, and rationale are available so decisions, tests, or actions can follow directly.
Visual orientation
Method sketch for a quick mental model.
Flow
- 1Name the decision
- 2Describe context
- 3Capture options
- 4Document the decision
- 5Capture consequences
The runsheet guides execution with 5 phases, timeboxes, 5 pitfalls, and clear stop criteria.
Open runsheetIdeal for
- Architecture governance
- Team memory
- High-change codebases
Not good for
- Trivial decisions
- Long specifications
Deep dive
Architecture Decision Record follows a clear working logic: name the decision, describe context, capture options, document the decision, and capture consequences. This turns the method into a visible thinking process rather than only a conversation. Participants move step by step from raw material, observations, or options toward a shared structure. The result is an ADR file, decision log, and rationale that make decisions, learning, or further planning actionable.
Prepare a clear guiding question, the right information, and a visible workspace. Plan about 15-45 min with 1-3 people and use the format asynchronously. The facilitation stays lightweight; short timeboxes, visible intermediate results, and a parking lot for open questions help.
ADR Markdown TemplateCompact template for architecture decision records in a repository or wiki.markdown
adr-markdown.md
Compact template for architecture decision records in a repository or wiki.
ADR-0001: Decision Title
Status: proposed Date: YYYY-MM-DD Decider: First Last Trigger: Ticket, incident, or RFC
Context
What situation makes the decision necessary? Which constraints, quality attributes, or earlier decisions matter?
Options
Option 1: ...
- Pros:
- Cons:
Option 2: ...
- Pros:
- Cons:
Decision
We decide to ...
Consequences
Positive consequences:
- ...
Negative consequences and risks:
- ...
Follow-up ADRs or tickets:
- ...
When to choose differently
Short decision aid for existing alternatives.
Statt Architecture Decision Record, wenn du die ersten Architekturfragen in einer knappen Startfolie bündeln willst.
Similar methods
All methodsTurns architecture context, options, and outcomes into a tangible result by identifying stakeholders, selecting views, and validating completeness.
Turns architecture context, options, and consequences into a tangible result by capturing goals and stakeholders, scoping context, and linking risks and decisions.
Uses a structured proposal and review process to make non-trivial technical or product changes discussable and decidable.
Turns architecture context, options, and consequences into a tangible result by defining the problem, collecting goals and constraints, and determining next investigations.
Statt Architecture Decision Record, wenn du die ersten Architekturfragen in einer knappen Startfolie bündeln willst.
Turns architecture context, options, and consequences into a tangible result by drawing system context, identifying containers, and adding code-level detail only when needed.
Moves architecture context, options, and consequences toward a concrete result through "place the architecture diagram or plan in the center", "set risk categories such as technical, organizational, and external", and "assign an owner and next steps for each top risk".