Architecture Decision Records (ADRs) document all the decisions made about software. Every change is recorded in a plain text file sitting inside a version control system (like GitHub). The record should be a complement to the information you can find in a version control system. The ADR provides context and information around every decision made about a piece of software.
Why are lightweight Architecture Decision Records needed?
We are always making decisions when we build software. Even the simplest piece of software will have required the engineer to take a number of different decisions. Often these decisions aren’t obvious. If you’ve ever had to work with code written by someone else you’re probably familiar with this sort of situation.
You might have even found that when you come across someone else’s code, you need to make a further decision. Either you can simply accept what has been written, and merely surmise and assume why it has been done in the way that it, or you can decide to change it, based on your own judgement. Neither option is ideal. This was what Michael Nygard identified in this blog post in 2011. This was when the concept of Architecture Decision Records first emerged.
An ADR should prevent situations like this arising. That makes life easier for you. More importantly, it should mean that every decision is transparent to everyone involved.
So, instead of blindly accepting something or immediately changing it, you can simply check the Architecture Decision Record. This will then inform how you proceed. Perhaps you need to make a change. But perhaps you also now understand the context of why something was built in the way it was.
Any questions you might have should be explicitly answered in the architecture decision record. So, when you start asking yourself why has she done it like that? instead of floundering helplessly, you can find the answer in the ADR.
Why lightweight Architecture Decision Records now?
Architecture Decision Records aren’t a new thing. Nygard wrote his post all the way back in 2011, after all. But the fact remains that the context from which Nygard was writing in 2011 was very specific. Today it is mainstream.
As we’ve moved away from monolithic architecture towards microservices or serverless, decision making has become more and more important in software engineering.
This is a point that is well explained in a blog post here:
“The rise of lean development and microservices… complicates the ability to communicate architecture decisions. While these concepts are not inherently opposed to documentation, their processes often fail to effectively capture decision-making processes and reasoning. Another possible inefficiency when recording decisions is bad or out-of-date documentation. It’s often a herculean effort to keep large, complex architecture documents current, making maintenance one of the most common barriers to entry.”
ADRs are, then, a way of managing the complexity in modern software engineering. They are a response to a fundamental need to better communicate decisions. Most importantly, they codify decision-making within the development process. It is when they are lightweight and sit within the project itself that they are most effective.
Architecture Decision Record template
Architecture Decision Records must follow a template. Not only does that mean everyone is working off the same page, it also means people are actually more likely to document their decisions. Think about it: if you’re asked to note how you decide to do something without any guidelines, you’re probably not going to do it at all.
Below, you’ll find an Architecture Decision Record example template. There are a number of different templates you can use, but it’s probably best to sit down with your team and agree on what needs to be captured.
An Architecture Decision Record example
- Date
- Decision makers [who was involved in the decision taken]
- Category [which part of the architecture does this decision pertain to]
- Contextual outline [Explain why this decision was made. Outline the key considerations and assumptions at play]
- Impact consequences [What does this decision mean for the project? What should someone reading this be aware of in terms of future decisions?]
As I’ve already noted, there are a huge number of ways you may want to approach this. Use this as a starting point.
Read next
