Building teams to deliver business value faster
The microservice architecture encourages the idea of building small, focused, and cross-functional teams to deliver business capabilities. This requires a shift in mindset, led by team restructuring. In 1967, Melvin E. Conway introduced the idea:
Therefore, if an organization needs to build software systems that are loosely coupled, then they need to make sure that they build teams that have a minimum dependency to allow them to function with autonomy.
A team is defined as a cohesive and long-lived group of individuals working together on the same set of business problems, owning a problem space/business area, and having sufficient capacity to build and operate. In essence, the team needs to fully understand the piece of software they are building and operating. This helps them build confidence in the software, optimize lead time, and deploy more frequently to bring agility. In practice, the team's size varies, depending on the size and complexity of the service. Adding a new member to a team adds new connections, resulting in communication overhead, which affects productivity. Organizing teams based on features and components is considered a standard approach to building teams to facilitate collaboration and bring cross-functional skills together. Recently, Matthew Skelton and Manuel Pais introduced a structure that lowers the cognitive load of agile teams by presenting fundamental team topologies in their book Team Topologies. There are four fundamental team topologies, as discussed here:
- Stream-aligned team: The stream-aligned team is a cross-functional team that's aligned to the value stream of the business and is responsible for delivering customer value with minimal dependencies. They know their customers and apply design thinking to understand business requirements to address customer needs. They support their service in production and are focused on continuous improvement and quality of service. The stream-aligned team is long-lived and has complete ownership of the service. They are responsible for building, operating, diagnosing, and supporting these services during their life cycles.
- Enabling team: The role of the enabling team is to provide support and guidance to stream-aligned teams in adopting tools, technologies, and practices that can help them perform better. Enabling teams are formed to identify areas of improvement and promote the learning mindset by keeping the wider organization aware of new technologies and best practices. Depending on their purpose, enabling teams can be short-lived or long-lived in an organization. However, their engagement with stream-aligned teams is only for a short period. Once the required capability is achieved, the enabling teams move to support other teams.
- Complicated subsystem team: The complicated subsystem teams are formed to address the requirements of complex subsystems, which can add significant cognitive load to stream-aligned teams and affect their ability to stay focused on the business domain. They are responsible for developing and operationalizing these systems to ensure their service availability when it comes to consuming other value streams.
- Platform team: The platform team is responsible for providing infrastructure support to enable stream-aligned teams to deliver a continuous stream of value. They ensure that the capabilities offered by the platform are compelling and provide a good developer and operator experience for consuming and diagnosing these platform services. These services should be accessible via APIs, thus enabling self-service and automation. The platform team is aligned to the product life cycle and guarantees that the stream-aligned teams are getting the right support on time to perform their duties. These services are usually bigger and supported by larger teams.
When you adopt a microservice with DevOps, individuals are responsible for handling both the development and operations of a microservice. These microservices are built with the guidance provided by product managers and product owners. In the real world, teams start small until they grow big and add complexity, before being subdivided into multiple teams to ensure autonomy and independence. For example, your application may need to build multiple channels to interact with its customers and want to work with teams with capabilities around iOS and Android, or they may have to add a notification functionality that needs a separate team altogether. In these teams, individuals have a shared responsibility, where design decisions are usually led by senior engineers and discussed with the team before implementation.
Now, let's learn about the advantages that microservices bring.