From the book “Team Topologies” by Matthew Skelton and Manuel Pais comes an interesting fix to Conway’s Law:
Organisations, who design systems, are constrained to produce designs which are copies of the communication structures of these organisations.
So let's start with a quick recap of Conway’s law's implications. Specifically: the negatives/blind spot of organisations: An organisation that's arranged in functional silos (where teams specialise in a particular function: such as QA, DBA, or security) is unlikely ever to produce software systems that are well-architected for end-to-end flow.
The Reverse Conway Manoeuvre
To increase an organisation’s chances of building effective software systems optimised for end-to-end flow, a “Reverse Conway Manoeuvre” (or Inverse Conway Manoeuvre) can be undertaken to reconfigure the team intercommunications before the software is finished.
Nicole Forsgren wrote about this first, back in 2015, in her excellent book Accelerate.
Our research lends to support to what is sometimes called the 'inverse Conway maneuver,” which states that organizations should evolve their team and organizational structure to achies 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-bandwidth communication between teams
Before: Organisation (figure 1)
Let’s look at a deliberate simplification of Conway’s law in an organisation that develops software. In the first (out of 4) figure, you see four teams each comprised of front-end and back-end developers. They work on different parts of a system and then hand them over to a central database administrator (DBA) for database changes. The flow of changes may look like Figure 1.
Figure 1: Organisation Pre-Manoeuvre
Before: Architecture (figure 2)
According to Conway’s law, the software architecture that naturally emerges from such a team design would have separate front-end and back-end components for each team and a single, shared core database (Figure 2). In other words, the use of a shared DBA team is likely to drive the emergence of a single shared database; the same goes, in the opposite direction, for Front-end and Back-end developers: it will lead to separate UI and app tiers, see figure 2.
Figure 2: Architecture Pre-Manoeuvre
After: Organisation (figure 3)
We now apply the Reverse Conway Manoeuvre and design our teams to match the required software architecture by having a separate developer for the client applications and the API, and a database developer within the team rather than separate it, see figure 3.
Figure 3: Organisation using Microservices
After: Architecture (figure 4)
According to Conway’s law, this team design in the organisation will most ‘naturally’ produce the desired software architecture. Each of the separate teams has a self-sustaining system, no central database, and by having end-to-end capabilities using client and API developers in the team and datastore knowledge handy, the team and architecture are optimised for end-to-end flow! see figure 4.
Figure 4: Architecture, microservices and post Conway Manoeuvre
Software Delivery
Conway’s law is not exclusively applicable to Software development: software delivery and software deployment can suffer from Conway’s Law.
If we consider the following pipeline with a centralised QA and Operations (pre-DevOps) you will get ‘interesting’ releases of your product.
Optimising for end-to-end flow and changing the organisation because of this optimisation has been a standard practice since Continuous Delivery gained popularity in 2012. We make QA and Ops part of the new ‘delivery teams’ in this scenario. We transform the central QA and central Ops into a distributed team that operates inside the different end-to-end optimised teams. (DevOps, BizDevOps etc.)
What remains are the platforms: these are maintained by the platform teams. We’ve written a good article about this here on our site: How to setup a successful Cloud Platform Team.
Conclusion
For software architecture and software delivery, the organisation and communication lines in it are best explained by ‘Conway’s Law'. By performing the Reverse Conway Manoeuvre, you change the organisation to optimise your software architecture and delivery for optimal flow.
Observing and managing end-to-end flow is at the core of our product. Agile Analytics provides critical insights into your organisation’s software development operation.
At ZEN Software we can help your organisation with DevOps optimisations, Agile implementation and Cloud Transformation.
Want to know how? let’s get in touch!
