Many years ago, Melvin Conway had observed that how organizations were structured would have a strong impact on any systems they created. In his “How Do Committees Invent" he wrote:
Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure
At the time, the Harvard Business Review rejected his original paper based on the fact that he hadn’t proved his hypothesis. Nonetheless, this observation has become known as Conway’s Law, and the collective experiences of both my colleagues and myself have time and again reinforced the truth of this statement. But you don’t have to take our word for it!
In "Exploring the Duality between Product and Organizational Architectures", a study by The Harvard Business School carried out an analysis of different codebases to see if they could prove Conway’s original hypothesis as applied to software systems. In it, they took multiple examples of software created to solve the same purpose (for example word processing, financial management and database software), and compared the code bases created by loosely-coupled open source teams, and those created by tightly-coupled teams. Their study found that the often co-located, focused product teams created software that tended more towards tightly-coupled, monolithic codebases. Whereas the open source projects resulted in more modular, decomposed code bases.
Organizations for a few years now have understood this link between organizational structure and software they create, and have been embracing new structures in order to achieve the outcome they want. Netflix and Amazon for example structure themselves around multiple small teams, each one with responsibility for a small part of the overall system. These independent teams can own the whole lifecycle of the services they create, affording them a greater degree of autonomy than is possible for larger teams with more monolithic codebases. These services with their independent concerns can change and evolve separately from one another, resulting in the ability to deliver changes to production faster. If these organizations had adopted larger team sizes, the larger monolithic systems that would have emerged would not have given them the same ability to experiment, adapt, and ultimately keep their customers happy.
You may see tensions in your own organizations where your structure and software are not in alignment. You may have seen for example the challenges involved where distributed teams try and work on the same monolithic codebase. Here, the communication pathways that Conway refers to are in contrast to the code itself, where single codebase requires fine-grained communication, but a distributed team is only capable of coarse-grained communication. Where such tensions emerge, looking for opportunities to split monolithic systems up around organizational boundaries will often yield significant advantages.
In previous Technology Radars we have highlighted the growing popularity of Microservices, which are increasingly being adopted by organizations looking to improve the autonomy of their teams and increase the speed of change. Martin Fowler and James Lewis’ article goes into more depth on the subject, highlighting the fact that these architectures allow organizations much more flexibility in aligning the architecture of their systems to the structure of their teams in order to ensure that Conway’s law works for you. In the next edition of the Tech Radar, we’ll be discussing the reflection of Microservices’ growing influence, from infrastructure technology like Packer or Docker to the service discovery tool Consul, or micro-containers like the popular DropWizard or fairly new SpringBoot. We’ll also discuss the reverse - organizations changing their team structure to fit their IT systems.
We fully expect to see more techniques and supporting technology emerge to enable Microservice architectures, and we will be keeping track of these over the coming months. In the meantime if you want to know more, sign up for the latest Tech Radar, check out Martin and James’ article on microservices, or my book from O’Reilly, Building Microservices.