I have always been fascinated with the link between software architecture and a company’s organizational structure. For the companies I have worked for so far, I found that the company’s structure can conflict with the software architecture that would work best. For example, a software development department might be organized into separate teams, where each team is working on a separate part of the software. Usually, the software architecture clearly reflects the team structure: the software interfaces have grown to represent the borders between the parts where each team is working on. Suppose the product has evolved over the years, while the teams remained the same. At some point, the existing interfaces might become a major burden to implement new features. This seems to be a common problem, where the software design reflects the initial team structure, while the product is screaming for a new and more appropriate architecture reflecting the evolved product’s structure. As a result, team organization becomes detrimental for product progression.
This concept is known as Conway’s Law, named after Mel Conway, who published a paper called “How Do Committees Invent?”. Fred Brooks cited Conway’s paper in his classic “The Mythical Man Month”, and invented the name “Conway’s Law”. Here’s the definition from Conway’s own website (which also has the original paper in full):
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.
As Conway himself writes, “Brooks recognized that the law has important corollaries in management theory”. Here is one stated in the paper:
Because the design that occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.”
For example, there are many cases, where you want to improve a product and there’s no other way than to redesign its architecture. According to Conway’s Law, that means you will need to start reconsidering your development team organization: it might have to become more software (product) centered.
As a corollary to Conway’s Law I would say: don’t hold on to existing organization structures, if they are in the way. In a software company, it’s the product that sells. So if you want to improve the product and go forward, you will need to be flexible and willing to change: the company and its product should evolve together.