# These are optional metadata elements. Feel free to remove any of them.
status: "{proposed | rejected | accepted | deprecated | … | superseded by ADR-0123}"
date: {YYYY-MM-DD when the decision was last updated}
decision-makers: {list everyone involved in the decision}
consulted: {list everyone whose opinions are sought (typically subject-matter experts); and with whom there is a two-way communication}
informed: {list everyone who is kept up-to-date on progress; and with whom there is a one-way communication}

{short title, representative of solved problem and found solution}

Context and Problem Statement

{Describe the context and problem statement, e.g., in free form using two to three sentences or in the form of an illustrative story. You may want to articulate the problem in form of a question. Consider adding links to collaboration boards or issue management systems. Make the scope of the decision explicit, for instance, by calling out or pointing at structural architecture elements (components, connectors, ...).}

{Describe the current state: the existing topology, constraints or legacy workflows in place today, and why that state no longer meets the requirement.}

Decision Drivers

Optional — remove this section if you don't need it.

• {decision driver 1, for instance, a desired software quality, faced concern, constraint or force}
• {decision driver 2}
• {a constraint the decision must respect, e.g., security policy, infrastructure limit, or a vendor or SaaS limitation}
• {an architecture principle the decision should align with, e.g., "API First", "Cloud First", "Least Privilege"}
• …

Considered Options

• {title of option 1}

• {title of option 2}

• {title of option 3}

• …

• {title of option dismissed early} — not taken forward, because {reason it was ruled out before evaluation, e.g., violates a security principle}

Decision Outcome

Chosen option: "{title of option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.

Consequences

Optional — remove this section if you don't need it.

• Good, because {positive consequence, e.g., improvement of one or more desired qualities, …}
• Bad, because {negative consequence, e.g., compromising one or more desired qualities, …}
• Bad, because {it creates architecture debt: what it is, and the trigger for paying it down}
• Neutral, because {it is a tactical solution: its expected lifetime, and what replaces it}
• …

Confirmation

Optional — remove this section if you don't need it.

{Describe how the implementation / compliance of the ADR can/will be confirmed. Is there any automated or manual fitness function? If so, list it and explain how it is applied. Is the chosen design and its implementation in line with the decision? E.g., a design/code review or a test with a library such as ArchUnit can help validate this. Note that although we classify this element as optional, it is included in many ADRs.}

Pros and Cons of the Options

Optional — remove this section if you don't need it.

{title of option 1}

{example | description | pointer to more information | …}

• Good, because {argument a}
• Good, because {argument b}
• Neutral, because {argument c}
• Bad, because {argument d}
• …

{title of other option}

{example | description | pointer to more information | …}

• Good, because {argument a}
• Neutral, because {argument b}
• Bad, because {argument c}
• …

Evaluation Summary

Optional — remove this section if you don't need it.

{Where several options are close, rate them side by side. Keep the criteria that matter for this decision and delete the rest.}

Alignment to Principles

Optional — remove this section if you don't need it.

More Information

Optional — remove this section if you don't need it.

{You might want to provide additional evidence/confidence for the decision outcome here and/or document the team agreement on the decision and/or define when/how this decision the decision should be realized and if/when it should be re-visited. Links to other decisions and resources might appear here as well.}

Governance

Related Decisions and Documents

Review Feedback