We will keep a collection of records for "architecturally significant" decisions: those that affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques.
An architecture decision record is a short text file in a format similar to an Alexandrian pattern. (Though the decisions themselves are not necessarily patterns, they share the characteristic balancing of forces.) Each record describes a set of forces and a single decision in response to those forces. Note that the decision is the central piece here, so specific forces may appear in multiple ADRs.
We will keep ADRs in the project repository under doc/arch/adr-NNN.md
We should use a lightweight text formatting language like Markdown or Textile.
ADRs will be numbered sequentially and monotonically. Numbers will not be reused.
If a decision is reversed, we will keep the old one around, but mark it as superseded. (It's still relevant to know that it was the decision, but is no longer the decision.)
We will use a format with just a few parts, so each document is easy to digest. The format has just a few parts.
Title These documents have names that are short noun phrases. For example, "ADR 1: Deployment on Ruby on Rails 3.0.10" or "ADR 9: LDAP for Multitenant Integration"
Context This section describes the forces at play, including technological, political, social, and project local. These forces are probably in tension, and should be called out as such. The language in this section is value-neutral. It is simply describing facts.
Decision This section describes our response to these forces. It is stated in full sentences, with active voice. "We will …"
Status A decision may be "proposed" if the project stakeholders haven't agreed with it yet, or "accepted" once it is agreed. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement.
Consequences This section describes the resulting context, after applying the decision. All consequences should be listed here, not just the "positive" ones. A particular decision may have positive, negative, and neutral consequences, but all of them affect the team and project in the future.
The whole document should be one or two pages long. We will write each ADR as if it is a conversation with a future developer. This requires good writing style, with full sentences organized into paragraphs. Bullets are acceptable only for visual style, not as an excuse for writing sentence fragments. (Bullets kill people, even PowerPoint bullets.)
Implement as shell scripts
Date: 2016-02-12
Accepted
ADRs are plain text files stored in a subdirectory of the project.
The tool needs to create new files and apply small edits to the Status section of existing files.
The tool is implemented as shell scripts that use standard Unix tools -- grep, sed, awk, etc.
The tool won't support Windows. Being plain text files, ADRs can be created by hand and edited in any text editor. This tool just makes the process more convenient.
Development will have to cope with differences between Unix variants, particularly Linux and MacOS X.
Not everything needs ADR's. Only decision that could be costly if done wrongly, or decisions that are hard to implements deserves an ADR. Small changes do not deserve an ADR.
ADR's are good for making awareness about decisions, don't be tempted to use them for convincing or arguementative purposes.
- Use https://app.diagrams.net/ to create diagrams to add to ADR's