A company grows and their now legacy monolithic software doesn’t perform well. Engineers are complaining, features take long to release and bugs are piling up in JIRA. The hard decision to rewrite is taken - better to build something using a modern architecture that solves the problems they have today.
But things are far from pretty. The teams were meant to have autonomy and ownership over their microservices but they still need to notify people and get a green light to release. Some of the services depend on one another, requiring close collaboration between the different teams which sometimes results in blocked work.
Such problems are more organizational than technical. When a company decides to change the way it builds systems but the organizational structure lags behind it will experience the full weight of Conway’s law.
Systems Mirror Organizations
Conway’s law says that companies will produce system designs that are similar to their organizational structure. Imagine a small company with a handful of engineers all sitting in the same room. They will probably end up with a more tightly coupled solution that relies on their constant communication.
A large company with teams in different timezones working on separate parts of the product will need to come up with a more distributed solution. That will allow them to work autonomously, build and deploy without interfering with each other.
Architecture to Match the Company
Teams will naturally come to the architecture that fits their communication structure. Being forced to use something that doesn’t match it will cause trouble.
Imagine that the whole engineering team is sitting together in the office. There’s nothing wrong with building a monolith and yelling whenever you’re going to release. A small team can split the back-end and front-end work and work productively in a MVC monolith.
One part of the team is working on the presentation, the other on the business logic. Alternatively, they could build a React application and a REST API but the idea is the same.
A large company with many products and large systems wouldn’t operate productively using the same approach. There’s a team in the US that works on one part and one in eastern Europe that works on the other. They need to be able to work and deploy independently because syncing communication is a blocker.
The application could be split based on the parts of the domain that they’re working on. One team owns the invoicing while the other owns the membership. I worked at a company in which the UI was built in one destination and the back-end in another.
An organization in which teams need to operate in a fully autonomous manner would naturally come to an architecture like microservices. That way even teams in the same location can have their own release schedules and deploy whenever they see fit.
One of the key factors is size because it affects the processes and structure. Many large organizations use microservices precisely because of that. The bigger you are, the harder it is to operate as one. Teams move independently and that architectural style mirrors it.
It’s important to note that Conway’s law doesn’t guarantee the quality of the software that a company will build. Even if the architecture is a good fit for the organization the end product could still be a nightmare.
You Can’t Fight Conway’s Law
Sadly, often a company’s structure may not support the system it wishes to create. Time and time again, when a company decides that it doesn’t apply to them they learn a hard lesson.
Imagine an organization that decides to rewrite its large monolithic application using a modern microservices approach. In order to successfully create a different design the organization’s structure and communication channels need to change as well.
Engineers, designers and managers need to disband and form new teams that can exist and ship on their own. They should gain complete ownership of their work and make a shift in their mindset.
If the company’s structure doesn’t change the software will slowly evolve into something that mirrors it. Even if you start with solid planning and a diagram of what you’re aiming for, once it’s time for the implementation things will change.
Teams will cut corners and add functionality to existing services because of the cost and ease of implementation. Distributed teams may prefer to split more logic out into services so it can be owned by the appropriate teams.
The effects of Conway’s law will slowly move the team to an implementation that fits its structure.
When Architecture Changes Organizations
Things work the other way around as well. The architecture style you decide to use will have an impact on your company. You will communicate most with the people you work with. Teams using microservices are independent on one another. They will have their own release schedules and ways to build.
But that could create silos. You have lunch with the people whose schedule matches yours. You hold your own team buildings. The teams work independently but they celebrate independently as well. A company needs to find ways to keep the communicational channels open and encourage knowledge sharing in order to prevent teams from encapsulating.
Software is subject to constant evolution and iteration so when you’re building something for change you need to consider teams and communication. You will find more success if the organisation is willing to change its structure to match the system that you’d like to build.
But it works the other way around. Companies should use Conway’s law to their advantage and aim for architectures that reflect their communication structure.
