You know how the CAP theorem is frequently misunderstood and abused to justify any random design space decision in distributed systems? Of course you do, there is so much written about it. Well there is another, much easier to understand, much weaker but equally abused “result” [1], Conway’s law.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. -— M. Conway
Interestingly, Conway’s law is an impossibility statement, just like CAP, and it must be used in that way. There shouldn’t be need for clarification, but since I see the principle used to justify pretty much any design and organization decision, I want to state in the most concrete terms I can think of. I’ll give weaker restatements that are, hopefully, directly applicable to software development organizations.
The architecture of your system cannot have any other shape but the shape of your development team
In this sense Conway’s is an impossibility result. If you accept the law, you will say that doesn’t matter how much you try, eventually the structure of your software will reflect the communication structure of the company.
The most important part to understand here is that in no way is Conway saying that this is a good thing. It is in fact a bad thing, it takes out degrees of freedom from the design space. It means that it doesn’t matter how hard we try, we can’t do better than the organizational structure. You don’t need to be proud of being “Conway compliant”, if Conway is actually a law you will get there eventually, want it or not.
Given the previous, it’s pretty obvious what companies that want to have good software architectures should do:
Adapt your communication and organizational structure, to have the shape of the software architecture your system needs.
Conway being an impossibility law, this advice is not really a way to use Conway in your favor, there is no way to do that, just like there is no way to use the light speed limit to make a faster spaceship. But, what you can do, is stop wasting time and money trying to build a ship that goes faster than c.
You have to accept Conway’s impossibility, and work around it the best you can, trying to achieve what, at least for now, it’s not known to be impossible. Just like with (the right interpretation of) the CAP theorem.
- It’s almost always wrong to use Conway’s law to justify design decisions. Conway is a well known pre-condition to any software architecture project. Use the law for your organizational decisions, for your architecture decisions use software engineering practices.
- Many times Conway’s law is ignored when making organizational decisions. Do this and your architecture will no longer be dictated by the problem, but by the organization’s structure, you won’t have the architecture you need, you will have the architecture you can have.
- It’s frequent to see companies putting the cart before the horse, particularly medium to big companies. Your org structure must be tailored to your architecture. You are trying to solve a problem, the management structure is a medium not a goal.
- Corollaries to the previous point:
- Don’t try to solve different problems with a single communication structure (which means a single architecture)
- Don’t imitate organization structures from companies with completely different problems and architectures
- If your problem or your solution change in time, your architecture will probably need to change, and your organization structure will need to follow. Flexible structures are good, they can adapt to changing problems.
[1] Obviously Conway’s is not a theorem or a scientific law. I’m not even sure how much evidence there is to support it. Unlike with the CAP theorem, you are welcome to disagree with and ignore Conway’s adage. The rest of the article is written for those of you who believe there is a kernel of truth to the “law”, at least for sufficiently large and mature organizations and architectures