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.
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.
There are three different design techniques that improve team autonomy:
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.
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)
.
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.
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.
Chris teaches comprehensive workshops for architects and developers that will enable 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.
Learn moreChris offers numerous other resources for learning the microservice architecture.
Want to see an example? Check out Chris Richardson's example applications. See code
Got a specific microservice architecture-related question? For example:
Consider signing up for a two hour, highly focussed, consulting session.
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 MECNPWNR to sign up for $120 (valid until May 16th, 2023). There are deeper discounts for buying multiple seats.
Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.
Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,
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.
Engage Chris to conduct an architectural assessment.
Note: tagging is work-in-process
anti-patterns · application api · application architecture · architecting · architecture documentation · assemblage · beer · containers · dark energy and dark matter · deployment · design-time coupling · development · devops · docker · eventuate platform · glossary · hexagonal architecture · implementing commands · implementing queries · inter-service communication · kubernetes · 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 · tacos · team topologies · transaction management · transactional messaging