As a Software Engineer, I have had the opportunity to write multiple Architecture Decision Records(ADRs).
Head over to Spotify's Blog Post for in-depth reading.
An ADR answers two questions -
What is the problem?
How should we solve it?
Writing ADRs brings clarity and binds teams to a common goal.
ADRs serve as suitable communication mediums for new team members - they can live the past without being there.
Let's dive deeper into the art of writing an ADR.
Depth of Solution
ADRs should solve the problem, but the way it's solved shouldn't matter if the constraints are apparent.
Ex: Rotate credentials every 24 hours.
The implementation doesn't matter - it could be a cron, manual or a scheduler service; the details lie with the folks who work on it.
What is necessary is that the credentials should have a shelf-life of 24 hours.
State Your Assumptions
State assumptions to gauge if the design becomes obsolete.
Ex: How much data traffic rate can the software support?
Provided the technique is reliable and resilient, we should -
Architect for the future, but settle for simplicity.
Security Aspects
Security is vital for software dealing with sensitive customer information, including accessing customer data.
A "Threat Modeling" exercise done in advance to cover all security breaches goes a long way.
Costing Aspects
Every offering of your software product has a fixed, affordable budget, and a technical decision is almost always strongly linked with this cost.
Does the design involve a managed service? It's good to include baseline costing for data transfer, hourly rates and so on.
Single Decision Record
Before writing the ADR, an array of discussions happen in the background.
Every ADR should have a "decision" section which states a single locked-in decision - assimilation of all the discussion meetings.
In conclusion, when it comes to writing ADRs -
The key is to promote transparency and participation while maintaining focus and ownership of the architecture.
That's all for today! Until later!
Top comments (0)