Architecture Decision Records,  Software Design,  Team Collaboration

Adopting decision records

Architecture Decision Records (ADRs) serve as a crucial tool in documenting software design choices that address significant functional or non-functional requirements in architecture.

Adopting decision records

Photo by Maksym Kaharlytskyi on Unsplash

Architecture Decision Records (ADRs)

An Architecture Decision Record (ADR) is a software design choice documentation that addresses a functional or non-functional requirement that is architecturally significant.

Having this record-keeping allows the team to easily go back in time to understand the current status and be better able to pivot with complete knowledge. These prove very useful for new joiners as well. Another key thing is that when the team decides on something and someone is tasked with putting it down as a record, often that could identify gaps or misalignment and allow addressing this early on particularly when examples are involved.


Adopt SQL Temporal Tables for time travel

Created: 2023-01-01

Updated: 2023-01-05

Participants: Entire Tech Team




We are building an Analytics database that needs to keep track of historical data, and we need to decide on the best way to implement this feature.


  • SQL Temporal Tables: This approach involves using the built-in SQL temporal table feature to automatically track the history of a table. This approach allows for easy querying of historical data and does not require additional storage as the history is stored in the same table as the current data.


We will use the SQL Temporal Tables approach for tracking history.


SQL Temporal Tables allow for easy querying of historical data. It also allows storing the history of a table transparently and is easy to use.


  • Temporal tables allow for easy tracking and querying of historical data.


  • Temporal tables can add complexity to a database schema.

Authoring recommendations

DO ensure that the records are immutable. The decisions made in a previously published ADR should not be altered in a way that changes the decision, a new record should be made in the interest of maintaining the history.

DO ensure that each record is specific to one decision only.

DO ensure that all decisions are consistent with other team and organization agreed-upon principles and standards.

DO reference other detailed documentation and supporting artefacts to avoid duplications.

DO ensure that you document a clear argument as this is as important as the decision. Outline the position, including things like implementation cost, ownership cost, resource requirements, etc.

DO follow a minimalist approach and document only the issues that need addressing or attention.


NUMBER - Title

Created: [YYYY-MM-DD] when the decision was created

Updated: [YYYY-MM-DD] when the decision was last updated

Participants: [list involved participants/team]


Proposed | Rejected | Accepted | Deprecated | … | Superseded by [Another Run Book Link]


Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question


This is the decision that was made if any alternatives were considered, list them here


This is the consequence of the decision


In summary, ADRs are instrumental in maintaining a clear and accessible record of architectural decisions, aiding in team alignment, retrospective analysis, and onboarding new members.