How do we make architecture decisions?
How do we make good decisions about our software design?
The “easiest” solution to this is for someone with a gigantic brain to make all the decisions. The “Megamind” approach certainly has some advantages — an individual can make decisions quickly, and there’s a single person with responsibility (or “single wringable neck” or “throat to choke” or some other term that’s not very Redgate-y). The drawbacks dwarf these advantages. Putting the onus on a single person is risky — people aren’t perfect (sorry!).
Let’s try and improve that a bit. We could appoint a change advisory board (CAB). A CAB is a small group with relevant domain experience that review decisions and suggest improvements. A CAB sounds like an improvement; diverse groups make better decisions, and relevant domain expertise is bound to make things better. Unfortunately, research shows having a change approval process is not a good idea.
“… found that external approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate. In short, approval by an external body (such as a manager or CAB) simply doesn’t work to increase the stability of production systems, measured by the time to restore service and change fail rate. However, it certainly slows things down. It is, in fact, worse than having no change approval process at all.” (Accelerate: Nicole Forsgren)
Our core belief at Redgate is that “We believe that the best way to make software is by engaging teams empowered with clear purpose, freedom to act and a drive to learn.”. Submitting designs for approval goes against the grain of freedom to act. However, we also recognize that sometimes an individual team may not have the whole context, and local decisions might be local optimums.
How might we fix this? Well, the answer has been given to us by the captain of the Santa Fe submarine, David Marquet. After being placed in an unfamiliar environment, he developed a style of leadership that emphasized local decision making without giving up control. Intent-based leadership empowers teams to make decisions but uses an “intent-check” to allow others to give insight.
We’ve embodied this approach in how we make architecture decisions. Before starting a new bit of work, we ask engineers to write a record of their decision. The act of writing things down improves design (after all, if you can’t write it down, how on earth are you going to implement it), but it also provides an intent check for those with a different perspective.
Our approach borrows from two established processes to build something for Redgate.
- RFC (Request for Comments) documents originated in the very early days of the internet in 1969. It’s a formal process that works in the open to give everyone input. The RFC process is still used today to define key parts of the internet. For example, you can see the complete record of discussion on IPv6 (introduced since there are now billions of devices connected together).
- ADRs (Architecture Decision Records) are a lightweight record of engineering decisions on the other end of the spectrum. The ADR log is kept alongside the source code and gives engineers an excellent overview of the historical context behind decisions.
We’ve combined the two — and come up with something we call “Architecture Intent Checks” (AIC). AICs act as a non-blocking check before starting work on architectural changes. We ask teams to seek feedback from relevant stakeholders, and if new information comes to light that would change the decision, we’ll change the decision! We assume that most of our engineering decisions are good because we’re constantly making an effort to make sure engineering teams have the broader context of the business.
