Architectural Decision Records ADR
Architecture Decision Record ADR is compact and traceable documents of all important decisions taken during the realization of a product. Use Asciidoc or Markdown and Git to have agile and lean documentation of your major decisions.
The huge advantage of Architecture Design Record ADR is the timeline of the decisions. It tremendously helps to understand the technical changes during the product lifecycle.
Please try architecture design records to document your key decisions when developing your software product. Feel free to identify better approaches
Definition
An Architecture Design Records ADR is a software design choice that addresses a functional or non-functional requirement that is architecturally significant. A decision can be documented in an architecture design record (ADR).
In each ADR file, write these sections:
- Title
-
Short present tense imperative phrase, less than 50 characters, like a git commit message.
- Status
-
Proposed, accepted, rejected, deprecated, superseded
- Context
-
What is the issue that we are seeing that is motivating this decision or change?
- Decision
-
What is the change that we are actually proposing or doing?
- Consequences
-
What becomes easier or more challenging to do because of this change?
I use Asciidoc format to write all our architecture design records. You can add to the same git repository as the product, visualize differences, and if desired, generate a nice-looking document. And my IDE IntelliJ IDEA has a nice plugin for this format.
Before using ADR, I documented the decision changes as footnotes in a Microsoft Word document. The ADR approach is way more legible and easier to trace with the help of git repositories.
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 Multiple tenant Integration"
Context
This section describes the forces at play, including technological, political, social, and product 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 product stakeholders have not 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(s).
The status and the graph of related decisions can be tracked and visualized using tools. You can also track your decisions without any tools, a regular product has often less than a hundred decisions. And you can always write a small parse utility to extract your dependency graph.
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 will affect the team and product in the future.
Tips and Tricks
The whole document describing an ADR 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).
The cost of undocumented decisions is hard to measure, but the effects usually include duplicated efforts. Other engineers try to solve the same problems or competing solutions with (two third-party libraries that do the same thing).
The approach is very similar to how you would document a software pattern.
Believe and respect is the prime directive.
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
— Norman Kerth
Write down important decisions influencing your digital product and software design. Detailed choices are of a tactical nature and do not need an explicit ADR. Finding a good abstraction level requires some experimentation.