The ultimate output of knowledge work,in this case software architecture and engineering, is decision making. Regardless of what form it takes, recording the thought process of key decisions is an important part of maintaining clarity before, during and after decision are agreed upon, to help prevent hind-sight bias and to allow your future self and others, understand the environment in which the decisions were made.
In this post I will be sharing what I have been learning about Architecture Decision Records their applications in software and data projects.
What are ARDs anyway?
Architecture Decision Records are essentially a paper trail for significant architectural decisions that you make in the lifecyle of a project. I will mostly refer to them as ADRs from now on.
In my years as an software engineer and data engineer, I have scarcely, if at all come across this ADRs. Documentation has taken many forms in the projects I have been apart of; abandoned Notion pages, diagrams and sparsely detailed text files about what was going to be implemented or has already been implemented, or no documentation at all. When decison change, ADRs help track this by introducing states to these documents i.e Propose, Accepted, Rejected, Superseded
Why should you care?
Architectural decisions are some of the most costly in any organization. They have impacts on how easy it will be to add features or how resilient and flexible the system will be to changing requirements of the business. Interrogating and justifying these decisions with a decent amount of rigour, within the required time-frame becomes that much more important. Not to mention the framework can be adopting to many other fields and types of decision processes.
How do you know what to document?
Not every decision warrants a paper trail; the administrative overhead would be a nightmare. Michael Nygard describes "architecturally significant" decisions as those affecting:
- Structure and construction techniques.
- Non-functional characteristics, for example how it affects scalability or security.
- Dependencies and interfaces
Ask yourself: Is this decision reversible, and what is the cost of reversing it?
Olaf Zimmermann goes into great detail on this in his blog post about what criteria to use. regarding decision criteria
Lightweight ADRs: Setting Them Up
I'll be the first to hold up a cross to administrative overhead and because gaining initial velocity on the habit of documentation is hard enough, lightweight ADRs make for the best format to help reap the benefits of documenting your decision without dramatically affecting your workflow.There are even tools that help you manage ADRs, which you can find in this gihub repo to help grease the wheels.
In my projects, I simply add an /adr folder consisting of one Markdown document per decision:
ADR 001 - Postgres for Operational Database.mdADR 002 - Microservice Architecture for Orders Module.md
I include diagrams directly in the folder and commit everything to source control. This allows the documentation to version-match the code. When a decision changes, I don’t edit the old ADR; I create a new one, mark the old one as Superseded, and link to the replacement.
The lifecycle of ADRs
The lifecycle of these documents vary and are affected by team dynamics and roles and responsibilities of different stakeholder in the decision making process. There is always a main contact person or team responsible for communicating, publishing and maintaining these documents where maintenance is moving an adr from one state to the next.
I have come to interprete the states as below:
- Proposed: The draft phase; getting stakeholders to poke holes in the logic.
- Accepted: The green light; ensuring everyone is aligned on the path.
- Rejected: Recording why we said "no" so we don't repeat the debate next year.
- Superseded: Signaling that a new ADR has taken its place, ensuring there is only one "source of truth."
Conclusions
Documentation is a habit and one that is important especially with the changing landscape of tools and technologies that teams adopt. Though many of the organizational consideration that go into documentation frameworks haven't been touched on here, the rigour required to fill-in and socializing ADRs alone should help stave off some of the pitfalls that come with insufficient documentation and decision silos that are created as a result. Where ADRs live is just as important as writing them and it affects how they are versioned and maintained which is, in my opinion, the biggest battle with technical documentiation.
Top comments (0)