Effective Architecture Decisions
From Request for Comments (RFC) to Documenting Architecture Decisions (ADR)
Why do we need a Decision Making Process?
Distributed teams face many challenges when making technical decisions. Without a clear process, they may end up with unnecessary complexities, poor decisions, demotivated and disengaged team members, lack of understanding of decisions and delays in decision making. In this article, I will describe a process and tools that can help distributed teams make better technical decisions together.
The following are examples challenges, which we can tackle by having such a decision making process.
I didn’t know we had added a new tool to our stack.
Other team members who should’ve known about it, didn’t know either.
Someone made an important decision on behalf of our entire team, but the team wasn’t included in it.
Something was reinvented, although a solution for the problem existed
Some important aspects and problems where not considered
The wrong guiding principles were chosen
As a team of architects, we needed a way and teams to make decisions that would allow us to:
enable teams to make decisions for systems they’re responsible for
be asynchronous, written document allowing for asynchronous communication are especially important in our distributed remote or hybrid setup
allow topic experts to have input in decisions when they’re not directly involved in building a particular system
manage the risk of decisions made
reduce uncertainty
develop better outcomes by hearing multiple perspective
involve team members in decision making - involvement creates commitment
have a documentation of decision - to be able to understand made decisions in the future
One of the advantages of having a clear process for technical decision making is that we can keep track of our decisions and their rationale in a versioned repository. This allows us to access our decisions at any time and answer any questions that may arise about our architecture. It also enables us to review and improve our decisions based on feedback and results.
From Exploration and Discussion with Request for Comments (RFC) to Documenting Architecture Decisions (ADR)
For achieving the above aspects we can leverage RFCs and ADRs. What is the difference between Request for Comments (RFC) and Documenting Architecture Decisions (ADR)?
A request for comment (RFC) is a document that is used to propose, explore and discuss a problem space, solution space, new idea or a significant change to a system. It allows anyone to provide input on the proposed idea or change.
An architecture decision record (ADR) is a document that is used to capture important decisions made during the development of a software system. An ADR typically includes information about the decision, the context in which it was made, and the alternatives that were considered. Unlike an RFC, an ADR is not used to solicit input from others; it is used to document a decision that has already been made.
In general, an RFC is used to propose, explore and discuss, while an ADR is used to document decisions that have been made. Both documents are important for ensuring that the development of a system is transparent and well-documented.
Resources
Subscription: If you want to get updates, you can subscribe to the free newsletter:
Mark as not spam: : When you subscribe to the newsletter please do not forget to check your spam / junk folder. Make sure to "mark as not spam" in your email client and move it to your Inbox. Add the publication's Substack email address to your contact list. All posts will be sent from this address: ecosystem4engineering@substack.com.
✉️ Subscribe to the newsletter — if you aren’t already.
❤️ Share it — The engineering ecosystem newsletter lives thanks to word of mouth. Share the article with someone to whom it might be useful! By forwarding the email or sharing it on social media.