When Should I Write an Architecture Decision Record

Josef Blake
5 min readadvanced
--
View Original

Overview

The article discusses the importance of Architecture Decision Records (ADRs) in documenting significant architectural decisions within engineering teams, particularly at Spotify. It outlines the benefits of using ADRs, such as improved onboarding, ownership handover, and alignment across teams, while providing guidance on when to write an ADR.

What You'll Learn

1

How to document significant architectural decisions using ADRs

2

Why ADRs improve onboarding for new team members

3

When to backfill undocumented decisions in your team

Key Questions Answered

What is an Architecture Decision Record (ADR)?
An Architecture Decision Record (ADR) is a document that captures a significant architectural decision, including the context of how the decision was made and the consequences of adopting it. It serves as a historical record to help future team members understand the rationale behind decisions.
When should I write an Architecture Decision Record?
An ADR should be written whenever a decision of significant impact is made, which varies by team. Scenarios include backfilling undocumented decisions, proposing large changes, or even documenting small decisions that could prevent future confusion.
What are the benefits of using ADRs in a team?
The benefits of using ADRs include improved onboarding for new team members, smoother ownership handovers during team changes, and better alignment on best practices across teams, which reduces duplicative efforts and enhances code reusability.
How do ADRs facilitate ownership handover?
ADRs help new owners of a system quickly understand how and why the system’s architecture evolved, reducing the loss of context and knowledge during team transitions. This leads to increased productivity and smoother transitions.

Technologies & Tools

Some links below are affiliate links. We may earn a commission if you make a purchase.

Key Actionable Insights

1
Document significant architectural decisions using ADRs to maintain a clear history of choices made by the team.
This practice not only aids in onboarding new team members but also ensures that existing members have a reference point for understanding the evolution of the system.
2
Regularly review and update ADRs to reflect ongoing changes and decisions in your projects.
Keeping ADRs current helps prevent confusion and misalignment within the team, especially as team members change or as the project evolves.
3
Use ADRs to align on best practices across different teams within your organization.
By referencing and adopting ADRs from other teams, you can reduce duplicated efforts and create a more cohesive development environment.

Common Pitfalls

1
Failing to document decisions can lead to confusion and duplicated efforts among team members.
When decisions are not recorded, new hires may not understand existing standards, leading to inconsistent implementations and wasted resources.
2
Not updating ADRs can result in outdated information that misguides team members.
As projects evolve, it is crucial to keep ADRs current to reflect the latest architectural decisions and practices.