## Suggestions for writing good ADRs Characteristics of a good ADR: * Rationale: Explain the reasons for doing the particular AD. This can include the context (see below), pros and cons of various potential choices, feature comparisons, cost/benefit discussions, and more. * Specific: Each ADR should be about one AD, not multiple ADs. * Timestamps: Identify when each item in the ADR is written. This is especially important for aspects that may change over time, such as costs, schedules, scaling, and the like. * Immutable: Don't alter existing information in an ADR. Instead, amend the ADR by adding new information, or supersede the ADR by creating a new ADR. Characteristics of a good "Context" section in an ADR: * Explain your organization's situation and business priorities. * Include rationale and considerations based on social and skills makeups of your teams. * Include pros and cons that are relevant, and describe them in terms that align with your needs and goals. Characteristics of good "Consequences" section in an ADR: * Explain what follows from making the decision. This can include the effects, outcomes, outputs, follow ups, and more. * Include information about any subsequent ADRs. It's relatively common for one ADR to trigger the need for more ADRs, such as when one ADR makes a big overarching choice, which in turn creates needs for more smaller decisions. * Include any after-action review processes. It's typical for teams to review each ADR one month later, to compare the ADR information with what's happened in actual practice, in order to learn and grow. A new ADR may take the place of a previous ADR: * When an AD is made that replaces or invalidates a previous ADR, then a new ADR should be created

## Teamwork advice for ADRs If you're considering using decision records with your team, then here's some advice that we've learned by working with many teams. You have an opportunity to lead your teammates, by talking together about the "why", rather than mandating the "what". For example, decision records are a way for teams to think smarter and communicate better; decision records are not valuable if they're just an after-the-fact forced paperwork requirement. Some teams much prefer the name "decisions" over the abbreviation "ADRs". When some teams use the directory name "decisions", then it's as if a light bulb turns on, and the team starts putting more information into the directory, such as vendor decisions, planning decisions, scheduling decisions, etc. All of these kinds of information can use the same template. We hypothesize that people learn faster with words ("decisions") over abbreviations ("ADRs"), and people are more motivated to write work-in-progress docs when the word "record" is removed, and also some developers and some managers dislike the word "architecture". In theory, immutability is ideal. In practice, mutability has worked better for our teams. We insert the new info the existing ADR, with a date stamp, and a note that the info arrived after the decision. This kind of approach leads to a "living document" that we all can update. Typical updates are when we get information thanks to new teammates, or new offerings, or real-world results of our usages, or after-the-fact third-party changes such as vendor capabilities, pricing plans, license agreements, etc.

## Teamwork questions for ADRs ### Who can create an ADR? Consider areas such as specific people, or specific roles, or specific teams, or specific departments; also consider if there are people, or roles, or teams, or department that can commission an ADR, meaning they request one that someone else will author. Example answer: Any person in our organization who has read the architecture decision record README page can propose an ADR, meaning the person can start writing it, and share it with the team. ### What justifies raising an ADR? Consider areas such as your organization's team ways of working, your software system structure, cross-team coordination, long-term maintainability, external interfaces, who you want to benefit, and the like. Example answer: We want to create an ADR when we want future developers to understand the “why” of what we're doing. ### What justifies not raising an ADR? Consider areas such as decisions that are not about architecture, or are tiny such as minimal-risk or self-contained or single-developer, or are already fully covered elsewhere such as by standards or policies or documentation, or are temporary such as workarounds or proofs of concepts or orexperiments. Example answer: We want to skip an ADR when a decision is limited in scope and time and risk and cost, or is already covered elsewhere. ### What is the lifecycle of an ADR? Consider areas such as the creation process, research process, decisioning process, implementation process, and sunsetting process. Consider how to track the ADR lifecycle over time, such as how to move the ADR from one state to the next state, and also how to communicate this to stakeholders. Example answer: We want an ADR to have five lifecycle stages: Initiating → Researching → Evaluating → Implementing → Maintaining → Sunsetting. ### What are criteria for lifecycle steps of an ADR? Consider areas such as acceptance criteria for an ADR, meaning how do you know it's good enough to progress from one lifecycle step to the next? Is the problem clearly articulated? Have the alternatives been considered? Are trade-offs well-enough understood and documented? Is all relevant context in place? Are all relevant stakeholders involved? Has all feedback been incorporated? Example answer: We want an ADR to be voted on by stakeholders when the active team has 1) completed their research, 2) completed their evaluation, 3) published the ADR proposal to the stakeholders with a request for comments and a timebox of one week, 4) all stakeholder comments have been incorporated and addressed. ### What roles and responsibilities interact with an ADR? Consider roles such as proposer, researcher, evaluator, reviewer, approver, maintainer, and the like. Consider responsbilities such as communication with stakeholders, ensuring expectations are met, sharing on the website or intranet, and reviewing the work periodically and especially when relevant changes happen. Example answer: We want each ADR to always have a primary contact person, secondary contact person, and accountable team; these are responsble for communications, publications, maintenance, periodic review at least once per year, and eventual sunsetting as needed. ### How does governance interact with an ADR? Consider areas such as your organization's ways of working, any special compliance needs such as for legal aspects or human resource aspects, how you want to handle consensus versus conflict versus escalation. Are there areas or people or teams that can have more influence than others regarding an ADR, such as being able to approve it, or vote on it, or veto it? Example answer: The governance of an ADR is in this priority order: the CEO, the CTO, the CLO, the team that implements an ADR, the experts on the team that are most-knowledgeable about the AD. No one else has governance unless described in the ADR. ### What principles interact with an ADR? Consider areas such as your organization's ways of working that include moving quickly versus moving slowly, for decision consensus versus decision conflict, and for risk preferences versus safety preferences, public discussion versus private discussion, and the like. Example answer: We use the leadership priciples of bias for action, disagree-and-commit, 70% estimates are good enough for easily-reversable easily-isolatable decisions, and public ways of working with the exception of confidential information as described in our organization's confidentiality agreement.

Next step concepts for ADRs

Arc42 answers two questions in a pragmatic way and can be tailored to your specific needs. What should you document/communicate about your architecture? How should you document/communicate? Arc42 includes architecture decision records plus guidance on goals, contraints, contexts, quality, risks, and more.

The C4 model is an easy to learn, developer friendly approach to software architecture diagramming. C4 is a set of hierarchical digrams for context, containers, components, code, plus supporting diagrams for system landscape, dynamic, and deployment.

For more information

Introduction:

• Architectural decision (wikipedia.org)

• Architecturally significant requirements (wikipedia.org)

Templates:

• Documenting architecture decisions - Michael Nygard (thinkrelevance.com)

• Markdown Architectural Decision Records (adr.github.io)

• Template for documenting architecture alternatives and decisions (stackoverflow.com)

In-depth:

• ADMentor XML project (github.com)

• Architectural Decision Guidance across Projects: Problem Space Modeling, Decision Backlog Management and Cloud Computing Knowledge (ifs.hsr.ch)

• The Decision View's Role in Software Architecture Practice (computer.org)

• Documenting Software Architectures: Views and Beyond (resources.sei.cmu.edu)

• Architecture Decisions: Demystifying Architecture (utdallas.edu)

• ThoughtWorks Technology Radar: Lightweight Architecture Decision Records (thoughtworks.com)

• A Skeptic’s Guide to Software Architecture Decisions (infoq.com)

• Architectural Decisions — The Making Of

• Architectural Retrospectives: the Key to Getting Better at Architecting

• Software Architecture Monday with Mark Richards - free monthly software architecture lesson

• Solution Architecture Decisions - By Gareth Morgan

Tools:

• Command-line tools for working with Architecture Decision Records

• Command line tools with python - by Victor Sluiter

• Architectural Design Decision Support Framework (ADvISE)

Company-Specific Guidance:

• Amazon: AWS Prescriptive Guidance: ADR Process

• GitHub: ADR GitHub organization

• RedHat: Why you should use ADRs

Examples:

• Repository of Architecture Decision Records made for the Arachne Framework

Videos:

• An introduction to arc42 with Savvas Kleanthous

• The C4 model for visualising software architecture - by Simon Brown

Podcasts:

• Software Architecture Bookclub Podcast

Books:

• Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture - by Christian Ciceri, Dave Farley, Neal Ford, Andrew Harmel-Law, Michael Keeling and Carola Lilienthal

• Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives - by Nick Rozanski and Eoin Woods

• Software Architecture in Practice (SEI Series in Software Engineering)

• Documenting Software Architectures: Views and Beyond (SEI Series in Software Engineering)

• The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise

• Fundamentals of Software Architecture: An Engineering Approach - by Mark Richards and Neal Ford

• Building Evolutionary Architectures - by Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage

• Foundations of Decision Analysis by Ronald Howard and Ali Abbas

• Head First Software Architecture - by Raju Gandhi, Neal Ford and Mark Richards

• Communication Patterns: A Guide for Developers and Architects - by Jacqui Read

See also:

• REMAP (Representation and Maintenance of Process Knowledge)

• DRL (Decision Representation Language)

• IBIS (Issue-Based Information System)

• QOC (Questions, Options, and Criteria)

• IBM’s e-Business Reference Architecture Framework