More than 45 years ago, Melvin Conway stated that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations” – a statement which became famous as Conway’s law.
Meanwhile we figured out that Conway’s statement is not only true but that it also works in the opposite direction: A given system design constrains the communication structure of the organization that implements the system.
If communication structure and system design are not isomorphic, efficiency of effectiveness of the organization usually decline.
What does that mean for architectural design?
First we will have a look at the drivers, most IT organizations are confronted with: Complex environment, quick delivery speed, high flexibility, increasing availability demands.
Then we will have a look at system theory and other disciplines how to address those drivers: Self-organization, autonomous teams, quick feedback cycles, etc. are usually some of the answers. On the other hand there is still some need for governance to make sure all those autonomous teams are still aligned with the overall goals and objectives.
After having understood how we can respond to the IT drivers we have seen before, we apply Conway’s law and try to figure out architectural principles which support the communication structure needs of the IT organization well:
What about Microservices? And what else do we need? REST? Resilience? Containers? Cloud? And how can we govern that? EAM? And if yes, how should it look like? A little spoiler upfront: All of the things mentioned (and more) are important, but maybe in a different way than you thought before.