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.


Copyright © 2023 Chris Richardson • All rights reserved • Supported by Kong.

About Microservices.io

Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns.

Chris helps clients around the world adopt the microservice architecture through consulting engagements, and training workshops.

Learn how to create a service template and microservice chassis

Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.

New virtual bootcamp: Distributed data patterns in a microservice architecture

My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment!

It covers the key distributed data management patterns including Saga, API Composition, and CQRS.

It consists of video lectures, code labs, and a weekly ask-me-anything video conference repeated in multiple timezones.

The regular price is $395/person but use coupon JUNVCEJE to sign up for $195 (valid until February 1st, 2023). There are deeper discounts for buying multiple seats.

Learn more

Signup for the newsletter


LEARN about microservices

Chris offers numerous resources for learning the microservice architecture.

Training classes

Chris teaches comprehensive workshops, training classes and bootcamps for executives, architects and developers to help your organization use microservices effectively.

Avoid the pitfalls of adopting microservices and learn essential topics, such as service decomposition and design and how to refactor a monolith to microservices.

Delivered in-person and remotely.


Get the book: Microservices Patterns

Read Chris Richardson's book:

Example microservices applications

Want to see an example? Check out Chris Richardson's example applications. See code

BUILD microservices

Ready to start using the microservice architecture?

Consulting services

Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,


The Eventuate platform

Use the Eventuate.io platform to tackle distributed data management challenges in your microservices architecture.

Eventuate is Chris's latest startup. It makes it easy to use the Saga pattern to manage transactions and the CQRS pattern to implement queries.

ASSESS your architecture

Assess your application's microservice architecture and identify what needs to be improved.

Consulting services

Engage Chris to conduct an architectural assessment.



Join the microservices google group

Topics

Note: tagging is work-in-process

anti-patterns   ·  application api   ·  application architecture   ·  architecting   ·  architecture documentation   ·  dark energy and dark matter   ·  deployment   ·  development   ·  devops   ·  docker   ·  implementing commands   ·  implementing queries   ·  inter-service communication   ·  loose coupling   ·  microservice architecture   ·  microservice chassis   ·  microservices adoption   ·  microservicesio updates   ·  multi-architecture docker images   ·  observability   ·  pattern   ·  refactoring to microservices   ·  resilience   ·  sagas   ·  security   ·  service api   ·  service collaboration   ·  service design   ·  service discovery   ·  service granularity   ·  service template   ·  software delivery metrics   ·  success triangle   ·  team topologies   ·  transaction management   ·  transactional messaging

All content


Posts

24 Jul 2017 » Revised data patterns