“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”Melvin E. Conway 1967
As many other cases, although was a long time ago, the law today is still valid.
Basically: organization structure equals system design.
Real life example
An organization based on the division of specialized departments like Front-end, Back-end, DBA, Infrastructure and so on probably will design and deliver systems the same way.
That means each department will work on their area and deliver they “part” of the system.
Work like that requires a lot of control, follow-up and synchronization. And creates a strong dependency between these departments.
Nowadays many companies want to migrate to microservices and many times they think that is just about break they systems into “small” services.
But before touching the code is necessary important changes on company’s mindset and organization to achieve independent teams with Ownership and Responsibility.
If the company is not keen to change (or adapt) won’t work with microservices and won’t get the real benefits from microservices. Maybe will have a lot of “small services” but not microservices in the essence. (see Microservices Manifesto)
To get there, the company needs (to get started):
- Dissolve those specialized isolated teams/departments
- Build cross-functional teams
- Eliminate bureaucracy
- Define the strategy to adopt (ci/cd, testing, accessibility, observability, scalability…)
About me and you
Most of engineers want to work with microservices. And also is getting prepared to work with it.
So how the Conway’s law affect us?
If we expect to be happy working with microservices but our company is not really doing the necessary changes, at the end we will be just working with a lot of “small services” on the worst possible scenario.
If you are looking for a job to work with microservices, try do know about the company during the interviews and find out if the company is really ready or getting ready to work with microservices. Some specific questions could help:
- How the teams are organized/divided?
- Traditional divisions by “technology” (front, back, database…) — Is Bad
- Division by business area, or by service(s) — Is Good
- What is the teams average size? (of course depending on the company size)
- Large teams — Is Bad
- Small teams — Is Good
- Who or which team is usually responsible for the deployment?
- Another specific team or person deploy — Is Bad
- The team deploys and scale its own service — Is Good
- How many teams work in one single service?
- Multiple teams can change or work on a single service — Is Bad
- A single service is maintained only by one team — Is Good
- If a team detects the need to change something in their service – like the database type for instance – can the team do it? or who should the team talk to?
- The team doesn’t have autonomy and has to ask another team do the change — Is Bad
- The team is autonomous; decide and execute change on its own service — Is Good
Conway’s law alerts us that if we are interested in work with some methodology, technology or pattern, maybe won’t be possible if the company’s structure/organization is not compatible.
Agile / Scrum and Microservices are a good example of cases that are only possible if the company changes its mindset and organization.