Last few days, i was learning on how to make a accountable decision on deciding technical stuffs. Then i came across ADR. So far i haven’t used or seen used by our team. I think this is a necessary step to be incorporated to make accountable decisions. In this blog i share details on ADR for my future reference.

What is an ADR?

An Architectural Decision Record (ADR) is a concise document that captures a single architectural decision, its context, the reasoning behind it, and its consequences. ADRs help teams document, share, and revisit architectural choices, ensuring transparency and better collaboration.

Why Use ADRs?

1. Documentation: ADRs serve as a historical record of why certain decisions were made.
2. Collaboration: They promote better understanding across teams.
3. Traceability: ADRs link architectural decisions to specific project requirements and constraints.
4. Accountability: They clarify who made a decision and when.
5. Change Management: ADRs help evaluate the impact of changes and facilitate discussions around reversals or updates.

ADR Structure

A typical ADR document follows a standard format. Here’s an example:

1. Title: A clear and concise title describing the decision.
2. Context: Background information explaining the problem or opportunity.
3. Decision: A summary of the chosen solution.
4. Consequences: The positive and negative outcomes of the decision.
5. Status: Indicates whether the decision is proposed, accepted, superseded, or deprecated.

Example:

Optimistic locking on MongoDB https://docs.google.com/document/d/1olCbicQeQzYpCxB0ejPDtnri9rWb2Qhs9_JZuvANAxM/edit?usp=sharing

References

1. https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
2. https://www.infoq.com/podcasts/architecture-advice-process/
3. Recommended: https://github.com/joelparkerhenderson/architecture-decision-record/tree/main