Architecture Decision Record

Active theme: Light

← Guide

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 responsibilities 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 responsible 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 principles 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.