ADR management:
ADR templates:
- ADR template by Michael Nygard (simple and popular)
- ADR template by Jeff Tyree and Art Akerman (more sophisticated)
- ADR template for Alexandrian pattern (simple with context specifics)
- ADR template for business case (more MBA-oriented, with costs, SWOT, and more opinions)
- ADR template using Planguage (more quality assurance oriented)
An architectural decision (AD) is a software design choice that addresses a significant requirement.
An architectural decision record (ADR) is a way to track an AD, such as by writing notes, or logging information.
An architecturally significant requirement (ASR) is a requirement that has a measurable effect on a software system’s architecture.
All these are within the topic of architectural knowledge management (AKM).
The goal of this document is to provide a fast overview of ADRs, how to create them, and where to look for more information.
Your comments and suggestions are welcome.
You can open a GitHub issue, or create a pull request, or email joel@joelparkerhenderson.com.
Introduction:
Templates:
- Documenting architecture decisions - Michael Nygard
- Template for documenting architecture alternatives and decisions - Stack Overflow
In-depth:
- ADMentor XML project - GitHub
- Architectural Decision Guidance across Projects: Problem Space Modeling, Decision Backlog Management and Cloud Computing Knowledge
- The Decision View's Role in Software Architecture Practice
- Documenting Software Architectures: Views and Beyond
- Architecture Decisions: Demystifying Architecture
See also:
- REMAP (Representation and Maintenance of Process Knowledge)
- DRL (Decision Representation Language)
- IBIS (Issue-Based Information System)
- QOC (Questions, Options, and Criteria)
- DRL (Decision Representation Language),
- IBM’s e-Business Reference Architecture Framework