Team Topologies - The Reverse Conway Manoeuvre

Crowds of fun-seekers exploring a city on foot, "

Published on 28 June 2022 by Arjan Franzen

"Technology-focused team-building: AppNeta helps solve top

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.

A parallel diagram of teams: A, B, C, D,

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.

A graphical diagram of #numPatterns in symmetrical rectangles with

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.

Fun circle diagram with electric-blue pattern, numeric rectangles & font

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.

Rectangle of electric-blue font displaying #s & words: "

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.

Text-filled electronic device w/ parallel rectangles showing customer journey from

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.)

Rectangle Font Line Slope Parallel: "Flow of new features ft

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.

"Font art uses body, rect., circle & magenta to capture

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.