I’m a fan of Andrew Harmel-Law’s book Facilitating Software Architecture. It’s a must-read for anyone who wants to improve their architecture skills. One of the many gems in the book is the ‘Architecture Advice Process’. It describes how an organization should make architectural decisions. The architecture advice process is a refreshing and superior alternative to traditional architecture practices.
The architecture advice process
The architecture advice process is quite simple. To quote from the book.
Anyone (a development team member or someone playing a cross-team architecture role) can take (select a decision option) and communicate an architectural decision as long as during the option-making stage, they seek advice from:
- Everyone who will be meaningfully affected by the decision
- People who have expertise in the area in which the decision is being taken
Let’s clarify a few of the terms in the quote:
- ‘option making’ - the process of coming up with a candidate solutions to the problem at hand. It corresponds to step 4 Find candidate solutions of deliberative design and most likely step 3 Define evaluation criteria.
- ‘select a decision option’ - the process of picking a solution: steps 5 Evaluate Tradeoffs and 6 Select a solution of deliberative design.
- ‘communicate’ - letting the affected people and experts know about the decision - i.e., step 7 Document the decision of deliberative design. This typically consists of creating an architecture decision record.
Benefits of the architecture advice process
The architecture advice process has many benefits, including:
- Faster decision-making - anyone can make a decision, not only architects. Also, the decision is made by a single person or team - others only provide advice, not agreement - which avoids long, drawn out consensus building.
- Better decisions - by considering the needs of the teams and the big picture
- Creates trust - by involving people affected by the decision in the decision-making
I strongly recommend reading the book to get a full understanding of the architecture advice process.
The decentralized architecture advice process supports fast flow
The reason I like the architecture advice process is not only because it is a better way to make architectural decisions, but also because it resonates with the concepts of fast flow, team topologies, and the microservice architecture.
Team topologies and the microservice architecture are - along with DevOps - elements of the fast flow success triangle. A key enabler of fast flow - the continuous delivery of changes to customers - is team autonomy. Teams work mostly independently and only collaborate when necessary. For example, Team Topologies describes how stream aligned teams primarily use the X-aaS interaction model. They consume the APIs, tools, platforms of other teams “as a service”. They rarely need to collaborate with other teams.
The architecture advice process is a good fit for this model. It allows teams to make decisions without having to ask an architect to do it for them.
Architecting to reduce the scope of a change
Yet while the architecture advice process promotes team autonomy, decision-making requires collaborating with people affected by the decision and with experts. To properly support team autonomy, the number of people who need to be regularly consulted must be minimized, ideally to just the team itself. The solution is to use a loosely design-time coupled architecture
About loose design-time coupling
Loose design-time coupling is an essential property of a good software design. Two software elements - classes, packages, subdomains, services, etc. - are loosely design-time coupled if changes to one element do not regularly require changes to the other.
Loose design-time coupling localizes changes, which ensures that they are easier to make.
Loose design-time coupling and team autonomy
Loose design time coupling is also critical for large-scale software development.
Teams can only be autonomous if their respective software elements are loosely design-time coupled.
Consider, for example, the Orders team and the Deliveries Team.
In order for those two teams to work independently, their subdomains - Order Management and Customer Management must be loosely design-time coupled.
In other words, one team can make architectural decisions without regularly having to seek advice from the other team.
Some changes will, however, require collaboration.
For example, when the Customers team needs to change the Customer Management subdomain’s API, they will need to collaborate with the teams that develop subdomain’s clients, such as the Orders team.
Such collaboration cannot be avoided, but it should be minimized.
In a monolith, the technology stack is global
For many applications, the Modular monolith architectural style is a good choice. It consists of loosely design-time coupled domain modules. The teams can mostly work independently without regularly having to seek advice from other teams. There is, however, one part of the architecture that is tightly coupled to all other parts: the technology stack.
An application’s technology stack consists of libraries, the language runtime (e.g., JVM), infrastructure services, deployment pipeline technology, and deployment infrastructure. Sometimes a team will need to make a change to the technology stack that affects other teams.
Let’s imagine, for example, that in order for the Orders team to implement a feature, they need to upgrade a library - a change that requires all other teams to modify their code. Before making the change, the Orders team would need to seek advice from the other teams. They might even have to involve product management, especially if the upgrade is time-consuming. While in principle, no other team can veto the change, the Orders team might encounter very strong push back from the other teams.
Microservices localize technology stack changes
An important benefit of the microservice architecture is that it localizes technology stack changes.
Each microservice (mostly) has its own technology stack.
If the Orders team owns the Order Service they do not have to seek advice from any other team when changing that services’s technology stack.
The only time collaboration is needed is when changing API technologies and shared infrastructure services. The Orders team cannot unilaterally change the API technology, for example, from REST to GraphQL. Nor, could they change the message broker without consulting the other teams.
Need help with accelerating software delivery?
I’m available to help your organization improve agility and competitiveness through better software architecture: training workshops, architecture reviews, etc.