Dark energy force: team autonomy

microservice architecture   architecting   dark energy and dark matter  

a dark energy, dark matter force

Team autonomy is the ability of a team to make decisions and take actions without the need for approval from other teams. Let’s first look at why team autonomy is important for rapid, frequent, and reliable software delivery. Then we’ll look at how to achieve it.

Why is team autonomy important?

The authors of the book Accelerate found that it is an essential aspect of high performance software delivery. A team should be able to develop, test and deploy their software (i.e. subdomains) independently of other teams.

That’s because coordinating with other teams is a source of delays and bottlenecks. You need to schedule a meeting, determine what needs to be done, and then wait for the other team to do the work. In many organizations, meeting rooms are in short supply. Moreover, research has found that decision making within teams (e.g. at the daily standup), is much faster than decision making across teams.

The challenge with developing a large application is if there are N teams, then according to The Mythical Man-Month each team potentially has to coordinate with N-1 teams. The coordination effort is proportional to O(N^2) - the edges in an undirected graph with N vertices. As a result, the coordination effort grows very quickly as the number of teams grows. It’s essential that we design an architecture that minimizes the coordination effort between teams.

Designing for team autonomy

There are three different design techniques that improve team autonomy:

  • Design loosely coupled subdomains
  • Use a modular monolith to separate subdomains
  • Use a microservice architecture to physically separate subdomains

Design loosely coupled subdomains

Team autonomy requires that subdomain that are owned by different teams are loosely coupled from a design-time perspective. Loose design-time coupling minimizes how often teams need to coordinate with each other. It’s usually achieved by designing stable APIs that encapsulate the subdomain’s implementation details. It’s also beneficial to minimize each subdomain’s inbound and outbound dependencies, since each one is a potential reason for change and, hence, collaboration. Once you have designed your subdomains to be loosely coupled, you can then use a modular monolith or a microservice architecture to physically separate them.

Use a modular monolith

In a monolith, this can be accomplished to some degree by having a modular monolith, which organized around the subdomains rather than technically oriented layers. Instead of every team working on every layer, each team owns and develops their subdomain module. They mostly need to coordinate from time to time with the teams that own their subdomain’s inbound and outbound dependencies.

One limitation, however, of a modular monolith is that all teams are contributing to the same code base. Multiple teams will need to coordinate some kinds of changes, such as upgrades of dependencies, such as frameworks and libraries. For example, let’s imagine that the Order Management team wants to use a library that depends on a newer major version some library that’s already being used by numerous other subdomains. They will need to spend time coordinating the upgrade with the teams that own each of those subdomains. As a result, the coordination effort is still proportional to O(N^2).

Use the microservice architecture

When developing a large application, an even better way to physically separate the subdomains is to use the microservice architecture. Each team owns a service, which they can develop, test and deploy independently of other teams. They only need to periodically coordinate with the teams that own their services’s inbound and outbound dependencies. Moreover, the team is free to make many technology choices independently of other teams. For example, unlike when developing a modular monolith, if the Order Management team owns their own service they can use any library they want without having to coordinate with other teams.

The primary source of application-wide changes is the application’s infrastructure, such as the message broker and deployment platform. Any changes to the infrastructure will likely require coordination with all teams. Fortunately, such changes are relatively rare and are presumably only made for good reasons.

microservice architecture   architecting   dark energy and dark matter  

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 ILFJODYS to sign up for $95 (valid until April 12, 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