Finding that special plus one for your architecture

I spend a lot time talking with clients about their software architecture. Either I’m reviewing their microservice architecture or helping them migrate from a monolithic architecture to a microservice architecture. Most engagements start with the client presenting their AS-IS architecture. This article describes some common problems with how architecture is documented and/or presented and how it can be improved.

Clearly define the meaning of the boxes and lines

Quite often the architecture is presented as a series of diagrams that look something like this.

(Names changed to protect confidentiality 😀)

On the one hand, a diagram consisting of boxes and lines is a good start. After all, a classic definition of software architecture by Len Bass and colleagues at the Software Engineering Institute is:

The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

In other words, the architecture can be described visually as a set of boxes and lines.

However, a common problem with such diagrams quite often the meaning of those boxes and lines is often unclear or ambiguous. For examples, let’s assume - since that’s not clear - that the elements in this diagram are services. Does the arrow from Order Management to Consumer Management represent an API dependency? Perhaps, it does? Or, does it represent Order Management directly accessing Consumer Management’s database. Since direct database access is a major architectural smell, it’s essential that a diagram clearly describe the nature of dependencies.

Here are two ways to improve such a diagram First, include a legend that describes the diagram’s visual notation. Second, briefly describe of each of the elements and relations that are shown in the diagram

Architecture is multi-dimensional

Another common problem is that the architecture documentation might only describe one aspect of an architecture, such as the services. In reality, however, architecture is multi-dimensional. A classic format for describing software architecture is the 4+1 view model, which I described in my Code Freeze 2018 presentation and in my Microservices Patterns book.

An architecture is described by a set of, what was originally, four views - the precise number does not matter. Each view consists of certain types of elements and relations and shows an aspect of the architecture from a particular stakeholder’s perspective. The architecture documentation for a modern enterprise application should probably consist of views that describe key classes and their relationships; services and their dependencies; infrastructure elements; etc.

Bring your architecture to life with collaboration/sequence diagrams

Another common problem with architecture documentation is that it often only shows the static structure of the architecture. The views, which describe the architecture’s elements and relations, are only one part of the architecture description. The other key part is the +1, which are the scenarios that show how the elements within the view collaborate. These scenarios bring your architecture to life. They connect it back to the application’s functional requirements - the user stories or scenarios. It’s vital that you include them in any description of your architecture.

You should document each architecturally significant scenario and show how the elements of your architecture collaborate. A UML sequence diagram is are a very convenient way to to visualize how elements collaborate.

Also, it’s often useful to briefly describe each step in the flow. For example:

1. The Client makes Create Order request to the API Gateway
2. API Gateway proxies the request to Order Service
3. The Order Service invokes the Restaurant Service to validate and price the Order
4. The Order Service invokes the Customer Service to reserve credit for the Order
5. The Order Service creates the Order
6. The Order Service sends a response to the API Gateway
7. The API Gateway sends a response to the Client

Summary

• Good architecture documentation is essential if you are evolving your application’s architecture.
• It’s vital that the documentation includes the +1: the scenarios that animate your architecture and show how it relates to your application’s functional requirements.