Conway’s Law in Team Topolgies: Did you really get it?
According to Wikipedia, this is what Melvin Conway wrote in around 1967:
"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
Fast forward to 2019, the Team Topologies book mentions another quote from Melvin Conway:
"Is there a better design that is not available to us because of our organisation?"
While the first is an almost sad statement, the second makes us exercise our critical thinking. Have you thought that your org might be impeding the ability to innovate in your software architecture?
Ruth Malan, mentioned in the Team Topolgies book, provides what could be seen as the modern version of Conway’s law:
"If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins."
Simply put, the Conway's law states that the architecture of a system is a reflection of the communication patterns between the teams that built it.
There are many valid historical reasons for certain org sizes or setups, that culminate into their respective software architectures. Factors vary from project orientation, cost cutting, less experienced work force, business decisions, among others.
For example, let’s say we have built an organisation with a cross-functional stream-aligned teams who built applications on top of a single database. These teams would be focused on product development, so they will require additional support from an experienced ops team. This organisational setup points to a software architecture similar to what's in the image below, due to the nature of the communication lines taking place:
If that's the software architecture we want for the long term, then all is well. However, organizations need to grow, evolve and scale in order to attend business needs, which brings additional complexity and bottlenecks in software development eventually. Here's what the Team Topologies book has to say around this context (p.17):
"In particular, an organization that is arranged in functional silos is unlikely to produce software that is well-architected for end-to-end flow. Similarly, an organization that is arranged primarily around sales channels for different geographic regions is unlikely to produce effective software architecture that provides multiple different software services to all global regions."
This implies that for an organization aspiring towards a more promising future, they need not only improved architectural practices but also actual team structures and compositions that resonate with innovative approaches.
How to implement such changes? And why it is so hard to discover, implement and sustain innovation? Let's go back to another Conway's quote:
"Given any team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths *do not exist*."
Read "communication paths" as how teams and engineers interact with each other. This, together with formal reporting lines have the power to restrict innovative solutions and perspectives. However, there's light in the end of the tunnel.
If we want to discourage certain kinds of designs and encourage an organization to discover and adopt innovative designs, we can make use of a different tactic.
Reverse Conway Maneuver
The Reverse or Inverse Conway Maneuver implies that we should design our teams (not the software yet) to “match” the required software architecture. That means reconfiguring the team intercommunications before the software is finished.
The Reverse Conway Maneuver gained traction around 2015 and has been applied in many organizations since. The book "Accelerate: The Science of Dev Ops" supports the importance of this strategy for high-performing organizations (p.18):
"Our research lends support to what is sometimes called the "inverse Conway maneuver", which states that organizations should evolve their team and organizational structure to achieve the desired architecture. The goal is for your architecture to support the ability of teams to get their work done — from design through to deployment — without requiring high-bandwith communication between teams"
Important to mention that the Conway’s law makes us reason about the required software architecture before we organize our teams, otherwise the communication paths and incentives in the organization will end up dictating the software architecture randomly and at will, which isn’t good.
Software architectures should resemble the flows of change they enable. Therefore, a new system architecture requires a good team foundation that enables and encourages fast flow, autonomy and accountability within each team. The Team Topologies book mentions that although the Reverse Conway Maneuver might get an initial push back, "with sufficient willpower from management and awareness from teams, this approach can and does work.” (p.18)
The Team Topologies book encourages everybody to follow proven software-architecture good practices:
- Loose coupling: components do not hold strong dependencies on other components
- High Cohesion: components have clearly bounded responsibilities, and their internal elements are strongly related
- Clear and appropriate version compatibility
- Clear and appropriate cross-team testing
By keeping things team sized with end-to-end ownership, we'll be promoting junior friendly architectures that are easy to understand and to contribute to, reflecting a minimal propagation of design changes. In other words: it becomes a team-first software architecture that maximizes people's ability to work with.
How to choose a basic team organization?
The Team Topologies book mentions some interaction modes that we won't cover in this article, but we can summarize at least the 3 essential ones:
- Collaboration: working closely together with another team
- X-as-a-Service: consuming or providing something with minimal collaboration
- Facilitating: helping (or being helped by) another team to clear impediments
With a deep understanding of how each interaction mode should operate, we can choose an initial organisation design that is likely to help produce the software architecture required.
IBM’s case study (p.146) highlights the company’s initiative to promote the adoption of modern work practices by appointing “advocates", some full-time, some part-time, to help drive the necessary transformation. These advocates encouraged and educated others, helping the ideas to diffuse throughout the organization. IBM's approach included formal training for teams and their executives, with a huge positive impact to the organization. We can easily say that they used a mix of a Collaboration and Facilitating interaction modes, at least.
While this case study sounds compelling, let's be down-to-earth: a new architecture cannot be expected to emerge as soon as a new team structure has been devised and implemented. The existing software architecture will initially "push back" against the new team structures.
A tip to make the new organizational structure work is to use temporary but explicit collaboration modes between the teams building the software, along with one or more enabling teams acting in facilitating mode. Therefore, any problems with the new responsibility boundaries can be quickly identified, giving the team the opportunity to adjust the design earlier, before too much has been built.
Conclusion
It's important to understand that the Conway's law states the fact that the structure of the organization reflects the structure of the system being developed. But that should not be a final statement. Depending on where your company is heading to, the Reverse Conway Maneuver might be at a choice in order to foment the change of the communication patterns and to encourage the desired software architecture.
References: