Architectural Decision Records (ADR)

Open & Transparent Decision History
Contributed by

Deven Phillips

Published April 06, 2021

What Is Architectural Decision Records (ADR)?


An Architectural Decision (AD) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant. This might, for instance, be a technology choice (e.g., Java vs. JavaScript), a choice of the IDE (e.g., IntelliJ vs. Eclipse IDE), a choice between a library (e.g., SLF4J vs java.util.logging), or a decision on features (e.g., infinite undo vs. limited undo). Do not take the term “architecture” too seriously or interpret it too strongly. As the examples illustrate, any decisions that might have an impact on the architecture somehow are architectural decisions.

It should be as easy as possible to a) write down the decisions and b) to version the decisions.

What Does an ADR Look Like?

Here's an example of an Architectural Decision Record (In Markdown format) for deciding to adopt Architectural Decision Records.

# Use Markdown Architectural Decision Records

## Context and Problem Statement

We want to record architectural decisions made in this project.
Which format and structure should these records follow?

## Considered Options

* [MADR]( 2.1.2 – The Markdown Architectural Decision Records
* [Michael Nygard's template]( – The first incarnation of the term "ADR"
* [Sustainable Architectural Decisions]( – The Y-Statements
* Other templates listed at <>
* Formless – No conventions for file format and structure

## Decision Outcome

Chosen option: "MADR 2.1.2", because

* Implicit assumptions should be made explicit.
  Design documentation is important to enable people understanding the decisions later on.
  See also [A rational design process: How and why to fake it](
* The MADR format is lean and fits our development style.
* The MADR structure is comprehensible and facilitates usage & maintenance.
* The MADR project is vivid.
* Version 2.1.2 is the latest one available when starting to document ADRs.

Why Do Architectural Decision Records (ADR)?

We use this practice to:

  • Have a quick reference to understand what has been done in the past
  • Allow us to share our thinking and methods with our stakeholders
  • Maintain open and transparent communication inside and outside of our teams

How to do Architectural Decision Records (ADR)?

Have a look at some of the available templates and start reading about them. You can choose to use one of the ones linked below or create your own adaptation of the template in a format which works for your team and your organization.

Links we love

Check out these great links which can help you dive a little deeper into running the Architectural Decision Records (ADR) practice with your team, customers or stakeholders.

Except where noted, content on this site is licensed under a Creative Commons Attribution 4.0 International license. This site is graciously hosted by Netlify