Architecture Decision Records
Architecture Decision Records (ADRs) are short documents that capture a significant architectural choice, its context, the options considered, and the rationale for the decision. They give future team members the reasoning behind the system's current shape.
itEnterprise architecture and integration | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Architecture Decision Records
An architecture decision record is a small document that remembers why a consequential technical choice was made. This is valuable because code is very good at proving that a choice happened and remarkably bad at explaining the constraints, rejected options, and trade-offs that made it sensible at the time.
The useful shape is context, credible options, one decision, and consequences. Context names the forces before the choice: requirements, constraints, risks, assumptions, and tensions. Consequences name the conditions after it: benefits, costs, risks, follow-up work, and new limits. The decision sits between them, doing the difficult work of being specific without pretending the future has signed a contract.
One record should hold one decision. That sounds fussy until a document called Choose the Entire Architecture arrives and quietly contains choices about data, deployment, interfaces, ownership, and operations. Those choices can change independently, so they need records that can be reviewed, linked, and replaced independently. The decision log is the collection of those records, a map of how the system acquired its current personality.
An ADR is not a tiny constitution. It does not decide who has authority, enforce implementation, or prove that the team was right. Teams still need review, tests, policies, and operational evidence. The record gives those controls a durable statement of intent, which is less glamorous than magic and rather more useful when a requirement changes.
Status is the part that prevents historical improvisation. A proposed record is under review. An accepted record describes the direction that was chosen. When new evidence changes that direction, write a new record and mark the old one superseded. The earlier decision stays visible because its original context may explain code, data, or operational constraints that have not yet vanished.
Start with the intro for the full mental model and lifecycle. Use the slides to see the relationships at a glance. Keep the cheatsheet nearby while drafting or reviewing a record, especially its selection test and option comparison card. The practice section turns that structure into a repeatable technique, and the exercise asks you to make the trade-offs visible in a proposed decision.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
Supports
- Motivation for small, modular architecture records
- Architecturally significant decision scope
- One significant decision per ADR
- Title, status, context, decision, and consequences format
- Active decision language and value-neutral context
- Positive, negative, and neutral consequences
- Repository storage, sequential records, and supersession
- https://adr.github.io/
Supports
- Architectural decision and ADR definitions
- One architectural decision and its rationale per record
- Decision log as a collection of ADRs
- ADR vocabulary, tooling, research, and practice references
- https://adr.github.io/adr-templates/
Supports
- Nygard template fields
- MADR emphasis on considered options and pros and cons
- MADR decision metadata and confirmation
- Existence of multiple ADR formats, including Y-Statements
- https://adr.github.io/madr/
Supports
- Structured Markdown ADR format
- Decision drivers, considered options, outcome, and consequences
- Confirmation and detailed option trade-offs
- Manual creation and filename conventions
- Organization approaches for large decision logs
- MADR version 4.0.0 documentation
- https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/welcome.html
Supports
- Team alignment and strategic direction outcomes
- Repeated-decision and missing-justification anti-patterns
- Context preservation for current and future stakeholders
- ADRs for technical and process-related architectural decisions
- https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html
Supports
- ADR, lifecycle, and decision log definitions
- Architecturally significant decision categories
- Minimum context, decision, and consequences content
- Ownership, proposal, review, acceptance, and rejection process
- Accepted record immutability and supersession
- Use of ADRs during code and architecture reviews
- https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/best-practices.html
Supports
- Distributed authorship with explicit ownership
- Preservation of ADR history and superseding links
- Central, accessible storage in a repository or wiki
- Separate remediation for non-compliant legacy code
- https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/faq.html
Supports
- ADR scope and review timing
- Ownership and contribution guidance
- Minimum content and imperative decision language
- Trade-offs, status, and change history
- https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/appendix.html
Supports
- Worked ADR with title, status, date, context, decision, and consequences
- Positive and negative consequence examples
- Compliance, ownership, version, and changelog fields
- https://www.thoughtworks.com/en-ca/radar/techniques/lightweight-architecture-decision-records
Supports
- Lightweight ADRs in evolutionary architecture
- Context and consequences as core information
- Source control as a recommended storage location
- Benefit to future team members and external oversight
- https://adr.github.io/adr-tooling/
Supports
- Current ADR tooling categories and project listings
- adr-tools, Log4brains, adr-viewer, MADR tooling, and commercial ADR applications
- https://github.com/npryce/adr-tools
Supports
- ADR directory initialization and numbered Markdown records
- Creating records that supersede an earlier ADR
- https://github.com/thomvaill/log4brains
Supports
- Docs-as-code ADR publication, search, timeline navigation, and pull-request workflow
- https://github.com/mrwilson/adr-viewer
Supports
- Generating navigable web pages from an ADR directory
- https://engineering.atspotify.com/2020/04/when-should-i-write-an-architecture-decision-record
Supports
- ADRs as a record after RFCs or engineering discussions
- Backfilling undocumented decisions and the cost of conflicting solutions
- https://keeling.dev/essays/distribute-design-authority-with-architecture-decision-records/
Supports
- Review churn when teams record undeveloped ideas as ADRs
- Bundled decisions, sparse consequences, and non-architectural records as adoption failure modes
- Pull-request review and practice needed to make ADRs effective
