Team Topologies - de omgekeerde Conway-manoeuvre

Uit het boek “Team Topologies” van Matthew Skelton en Manuel Pais komt een interessante remedie tegen de wet van Conway:

Organisaties die systemen ontwerpen, kunnen niet anders dan ontwerpen opleveren die kopieën zijn van hun eigen communicatiestructuren.

Laten we beginnen met een korte samenvatting van wat die wet betekent. En dan vooral de keerzijde, de blinde vlek van organisaties: een organisatie die is ingedeeld in functionele silo's (waarbij teams zich specialiseren in één functie, zoals QA, DBA of security) zal vrijwel nooit softwaresystemen opleveren die goed ontworpen zijn voor end-to-end doorstroom.

Om de kans te vergroten dat een organisatie effectieve softwaresystemen bouwt die geoptimaliseerd zijn voor end-to-end doorstroom, kun je een “omgekeerde Conway-manoeuvre” (of inverse Conway manoeuvre) uitvoeren: je herschikt de onderlinge communicatie tussen teams vóórdat de software af is.

Nicole Forsgren schreef hier als eerste over, al in 2015, in haar uitstekende boek Accelerate.

Ons onderzoek ondersteunt wat soms de 'inverse Conway manoeuvre' wordt genoemd: organisaties zouden hun team- en organisatiestructuur moeten laten meegroeien met de gewenste architectuur. Het doel is dat je architectuur teams in staat stelt hun werk af te maken — van ontwerp tot uitrol — zonder dat daar veel overleg tussen teams voor nodig is.

Laten we kijken naar een bewust vereenvoudigde weergave van de wet van Conway in een organisatie die software maakt. In de eerste van vier figuren zie je vier teams, elk met front-end- en back-enddevelopers. Ze werken aan verschillende delen van een systeem en dragen die daarna over aan een centrale databasebeheerder (DBA) voor de databasewijzigingen. De stroom van wijzigingen ziet er dan uit als in figuur 1.

Volgens de wet van Conway zou de software-architectuur die vanzelf uit zo'n teamindeling ontstaat, per team aparte front-end- en back-endcomponenten hebben, plus één gedeelde centrale database (figuur 2). Met andere woorden: een gedeeld DBA-team drijft het ontstaan van één gedeelde database aan. Andersom geldt hetzelfde voor gescheiden front-end- en back-enddevelopers: dat leidt tot losse UI- en applicatielagen, zie figuur 2.

Nu passen we de omgekeerde Conway-manoeuvre toe en ontwerpen we onze teams naar de gewenste software-architectuur: een aparte developer voor de clientapplicaties en voor de API, en een databasedeveloper binnen het team in plaats van daarbuiten, zie figuur 3.

Volgens de wet van Conway levert deze teamindeling het meest 'vanzelf' de gewenste software-architectuur op. Elk team heeft een systeem dat op eigen benen staat, er is geen centrale database, en doordat het team end-to-end capaciteiten heeft met client- en API-developers én kennis van de datastore binnen handbereik, zijn team én architectuur geoptimaliseerd voor end-to-end doorstroom. Zie figuur 4.

De wet van Conway geldt niet alleen voor het ontwikkelen van software: ook het leveren en uitrollen ervan kan eronder lijden.

Bekijk je de volgende pipeline met een centrale QA- en beheerafdeling (van vóór DevOps), dan krijg je 'interessante' releases van je product.

Optimaliseren voor end-to-end doorstroom, en de organisatie daarop aanpassen, is standaardpraktijk sinds continuous delivery rond 2012 populair werd. In dat scenario maken we QA en beheer onderdeel van de nieuwe 'deliveryteams'. We vormen de centrale QA- en beheerafdeling om tot een verdeeld team dat binnen de verschillende end-to-end geoptimaliseerde teams werkt (DevOps, BizDevOps enzovoort).

Wat overblijft zijn de platformen: die worden onderhouden door de platformteams. Daar schreven we een goed artikel over op onze site: Hoe zet je een succesvol cloud-platformteam op.

Voor zowel software-architectuur als software delivery geldt dat de organisatie en de communicatielijnen daarbinnen het best verklaard worden door de wet van Conway. Door de omgekeerde Conway-manoeuvre uit te voeren verander je de organisatie, en optimaliseer je daarmee je architectuur en levering voor optimale doorstroom.

Het observeren en sturen van end-to-end doorstroom zit in de kern van ons product. Agile Analytics geeft cruciaal inzicht in de softwareontwikkeling van je organisatie.