Harmel-Law's architecture advice process and fast flow

architecting   deliberative design   modular monolith   microservice architecture   books   team topologies   fast flow  

---

---

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. Most notably, it promotes team autonomy and faster decision-making, both of which are essential for fast flow.

Let’s look at the architecture advice process and explore how it relates to fast flow, team topologies, and architecture.

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 that each team needs to regularly consult must be minimized. 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 is important because localizes changes. As a result, code is easier to understand and change.

Loose design-time coupling and team autonomy

Loose design time coupling is critical for large-scale software development involving multiple teams. 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 service has a technology stack that’s mostly private. The exception are infrastructure services, such as message brokers, that are shared by multiple services. As a result, if the Orders team owns the Order Service they do not have to seek advice from any other team when changing the private elements of the 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.

Learn more about how I can help