Dissecting 'architecting for fast, sustainable flow'

architecting   success triangle   fast flow   architecture   devops   team topologies  

New public workshop: Architecting for fast, sustainable flow - enabling DevOps and Team Topologies thru architecture. Learn more and enroll.

In a previous article, I described how the success triangle is all about the fast flow of changes. I also announced a new workshop on architecting for fast, sustainable flow, which teaches how to develop application architectures that enable fast flow.

In this article, I dissect the phrase ‘architecting for fast, sustainable flow’ and briefly describe the architectural characteristics that DevOps and Team Topologies need.

Let’s begin by defining the term ‘fast flow’.

What is fast flow?

As I described in the previous article, the key idea of fast flow is that an organization’s structure, culture and work practices along with its application architecture should be such that it delivers a continuous stream of valuable changes to its customers. The underlying metaphor is of a river flowing fast and smoothly, with no blockages or bottlenecks.

Fast flow is a key goal of both DevOps and the Team Topologies. Team Topologies is set of principles and patterns for organizing business and technology teams for fast flow. DevOps is a set of principles and practices that those teams should follow in order to deliver software rapidly, frequently, and reliably.

What is sustainable flow?

The Law of Continuing Change describes how software must constantly change in response to changing requirements. However, even if the requirements miraculously never changed, you would still need to develop your application. That’s because technologies (and technology versions) constantly evolve. It’s essential that you continually upgrade your application’s technology stack - libraries, language, infrastructure, … - in order to keep it current.

Specifically, the importance of a technology (version) to your organization should match its importance in the market. Otherwise, you will encounter various issues caused by the lack of support, bug patches, learning resources, and developers who know the technology and want to use it

What is architecting?

Architecting is the act of designing an application’s architecture. The 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.

Architecture is multi-dimensional

Architecture is multi-dimensional. The dimension determines the nature of the elements and their relationships. One important dimension is the domain view, which is comprised of subdomains/bounded contexts. A subdomain/bounded context is a slice of business functionality. It can collaborate with one or more other subdomains/bounded contexts to fulfill its responsibilities. A subdomain/bounded context is owned by a stream-aligned team.

The goal of architecture is to satisfy the non-functional requirements

The purpose of architecture is to satisfy the application’s non-functional requirements. There’s two broad categories of non-functional requirements. There are the runtime requirements, such as performance, scalability, availability, and security. Quite often, it’s the runtime requirements that the architects focus on. However, there are also development time requirements. In particular, the architecture must have development time characteristics that support fast, sustainable flow.

Architectural requirements for fast flow

In order for fast flow to occur, an architecture must support DevOps and Team Topologies. There are five key architectural requirements for fast flow:

  • Team-sized elements - in order to avoid cognitive overload the architecture must consist of team-sized elements
  • Loose (design-time) coupling - loose coupling identified by the authors of the book Accelerate as a key predictor of high performance. It’s also a consequence of Conway’s law: loosely coupled teams (defined by Team Topologies) need a loosely coupled architecture.
  • Testability - the path from development to production must be a fast, automated deployment pipeline. An application must, therefore, be capable of being tested using automated tests. Those tests must be fast. Moreover, a developer must be able to run the tests on their local machine.
  • Deployability - the application must support fast, reliable, automated deployments.
  • Observability - the deployed application must emit a stream of telemetry - logs, metrics, and distributed traces - which is feedback to the developers about the behavior of application and its users. The telemetry is used to monitor the application’s health and diagnose problems. It’s also used to understand user behavior.

Architecting for sustainable flow

In order to sustain fast flow, an architecture must support the continual upgrading of the application’s technology stack. One clear advantage of the microservice architecture over the monolith architecture is that it enables you to incremental upgrade an application’s technology stack one service at a time. The upgrade can be done as a series of comparatively small tasks. In contrast, you must upgrade the entire monolith at once. While this is clearly doable, it’s a much bigger task that typically spans multiple teams and hence less likely to be done.

Intentional architecting is required

An architecture that supports fast, sustainable flow doesn’t happen by accident. For example, applying Conway’s law to define the architecture that mirrors the organization is a good start. But it doesn’t guarantee that the architecture will have the characteristics described above. Team Topologies even emphasizes the importance of first knowing the architecture:

Conway’s law tells us that we need to understand what software architecture is needed before we organize our teams, otherwise the communication paths and incentives in the organization will end up dictating the software architecture. As Michael Nygard says: “Team assignments are the first draft of the architecture.”

You need to intentionally design your architecture using a rational decision making process, such as Assemblage, to ensure that it has the characteristics described above. You can then use the Inverse/Reverse Conway Maneuver and apply the Team Topologies patterns to design an organization that mirrors the architecture.

Want to learn more?

If you want to learn more, enroll in my upcoming public online workshop on architecting for fast, sustainable flow.

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

architecting   success triangle   fast flow   architecture   devops   team topologies  

Copyright © 2024 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.

New workshop: Architecting for fast, sustainable flow

Enabling DevOps and Team Topologies thru architecture

DevOps and Team topologies are vital for delivering the fast flow of changes that modern businesses need.

But they are insufficient. You also need an application architecture that supports fast, sustainable flow.

Learn more and register for my June 2024 online workshops....


I help organizations improve agility and competitiveness through better software architecture.

Learn more about my consulting engagements, and training workshops.

LEARN about microservices

Chris offers numerous other resources for learning the microservice architecture.

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

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 MJXJDTBJ to sign up for $95 (valid until May 22nd, 2024). There are deeper discounts for buying multiple seats.

Learn more

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.

Signup for the newsletter

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.

Join the microservices google group