How organizational structure matters in the move to microservices

Amir Kazemi
December 17, 2020

Moving to microservices isn’t always just a shift in technology. It should also be accompanied by a shift in how teams are formed and the way individuals work together. Oftentimes, some of that decentralization and autonomy of teams may already exist in a monolith which makes the transition to microservices even easier. 

Conway’s law says, “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” 

This organizational shift is sometimes referred to as a part of an organization’s ‘digital transformation,’ a term that is somewhat of a misnomer itself — it could just as well be called an ‘organizational transformation’ because the fundamental transformation is one in cultural and team structure -- not in the technology being used.

For some teams, part of the move to microservices could also mean throwing out legacy development practices to a more agile, DevOps approach. From a technical perspective, the way that these services communicate with each other is different as well. So, if an organization doesn’t end up adapting, then ultimately none of the benefits like speed, autonomy, and flexibility get realized in the process. 

Map teams to one or multiple services 

If we accept that a microservice architecture means a software system that is made out of individually deployable, independent, lightweight and modular components -- according to Conway’s law the organization should be organized in a similar manner: Out of small, modular, independent teams who clearly own and are ultimately responsible for the microservice’s entire lifecycle. 

While all these microservices interact with each other, each one of them may have its own unique or limited function. In general in a more distributed environment teams tend to rely more heavily on automation tools in order to manage the complexity of the relationship between the microservices and the tasks involved with building, testing and deploying them. 

Think about autonomy, organizational structure, & the development process

If Conway’s law holds — and while an organization continues to grow — attempting to adopt microservices without empowering your teams to have complete ownership and autonomy could ultimately end in failure. In some cases, monoliths could traditionally require a different communication structure than microservices, so organizations would need to adapt the way their team members are given a clear set of owners and accountability in order to be successful. 

Development processes matter too. If organizations continue to use the same waterfall approach that focuses on ‘projects’ and involves adding features to existing microservices, they could end up with well -- many monoliths. Not true independent, lightweight microservices. In addition, development teams that throw their code over the wall to an operations team ultimately won’t reap the benefits of having the faster development cycles they’d wished for. 

To succeed with microservices, organizations need to build teams that are independent, have well-defined responsibilities, with complete ownership over the service through its entire life cycle. Instead of having a development team, a security team, a networking team and an ops team, companies need every team to be cross-functional, organized around the service or services it may be responsible for. Though the services will clearly have interconnected and often complex dependencies, each service and each team has to be able to do its work independently of the other. 

Always remember engineers are human :)

Embracing new technologies, whether it is containers or Kubernetes or cloud environments, may not be the most difficult piece. Engineers are human, and they work in human organizations, often with a relatively long history and strong inertia. Adopting microservices requires empowering teams so that each team is focused on delivering and maintaining a complete product rather than ‘adding features’ to an established codebase. Changing and improving a culture to succeed with microservices generally involves the following: 

Changing how developers, operators and security professionals work together. It’s hard for individuals to collaborate when they are all evaluated based on criteria that are not only different but also competing, or at least have traditionally been seen as competing. 

Changing perspectives about what is and is not mutually exclusive goals. There’s a common misperception that increasing development velocity inherently reduces operational stability and increases security risk, for example. That misconception makes it hard for developers, who want to deliver fast and are incentivized to do so, to work with operators, who want the application to be as reliable as possible. 

Becoming comfortable with independence. Microservices and micromanagement don’t work well together. 

Taking those steps make it easier to build the cross-functional teams that organizations need in order to be successful with microservices. 

You still need visibility into all of your microservices, especially because they’re interconnected. A modern microservice catalog like effx can help team members clearly own and understand how services relate to each other even if they’ve never interacted with the service owners themselves. If you’re curious to see how it works, take effx for a spin for free.