Team Topologies – de Reverse Conway Manoeuvre

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

Organisaties die systemen ontwerpen, zijn ertoe gedwongen ontwerpen te maken die kopieën zijn van de communicatiestructuren van die organisaties.

Laten we daarom kort de implicaties van de wet van Conway doornemen. Met name de blinde vlek/nadelen voor organisaties: een organisatie die is ingericht in functionele silo’s (waar teams zich specialiseren in een bepaalde functie, zoals QA, DBA of security) zal zelden softwaresystemen opleveren die goed zijn ontworpen voor end-to-end flow.

Om de kans te vergroten dat een organisatie effectieve softwaresystemen bouwt die geoptimaliseerd zijn voor end-to-end flow, kunt u een “Reverse Conway Manoeuvre” (ook wel Inverse Conway Manoeuvre) toepassen: herconfigureer de teamcommunicatie voordat de software af is.

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

Ons onderzoek ondersteunt wat soms de ‘inverse Conway maneuver’ wordt genoemd: organisaties zouden hun team- en organisatiestructuur moeten laten evolueren om de gewenste architectuur te bereiken. Het doel is dat uw architectuur teams in staat stelt hun werk te doen — van ontwerp tot en met deployment — zonder dat er intensieve communicatie met hoge bandbreedte tussen teams nodig is

We bekijken een bewuste vereenvoudiging van de wet van Conway in een organisatie die software ontwikkelt. In de eerste (van 4) figuur ziet u vier teams, elk met front-end- en back-end-ontwikkelaars. Ze werken aan verschillende delen van een systeem en dragen die vervolgens over aan een centrale database administrator (DBA) voor de databasewijzigingen. De flow van wijzigingen ziet er dan uit zoals in figuur 1.

Volgens de wet van Conway ontstaat uit zo’n teamopzet vanzelf een softwarearchitectuur met gescheiden front-end- en back-endcomponenten per team en één gedeelde centrale database (figuur 2). Met andere woorden: het inzetten van een gedeeld DBA-team stuurt naar het ontstaan van één gedeelde database; en in omgekeerde richting geldt voor front-end- en back-end-ontwikkelaars dat dit leidt tot aparte UI- en app-lagen, zie figuur 2.

We passen nu de Reverse Conway Manoeuvre toe en ontwerpen onze teams passend bij de gewenste softwarearchitectuur: met aparte ontwikkelaars voor de clientapplicaties en de API, en een databaseontwikkelaar binnen het team in plaats van die te scheiden, zie figuur 3.

Volgens de wet van Conway zal deze teamindeling in de organisatie ‘vanzelf’ de gewenste softwarearchitectuur opleveren. Elk van de afzonderlijke teams heeft een zelfvoorzienend systeem, zonder centrale database. Doordat de teams end-to-end-capaciteiten hebben — met client- en API-ontwikkelaars in het team en datastore-kennis binnen handbereik — zijn team en architectuur geoptimaliseerd voor end-to-end flow. Zie figuur 4.

De wet van Conway is niet uitsluitend van toepassing op softwareontwikkeling: ook software delivery en software deployment kunnen er last van hebben.

Als we kijken naar de volgende pipeline met gecentraliseerde QA en Operations (pre-DevOps), krijgt u ‘interessante’ releases van uw product.

Optimaliseren voor end-to-end flow en de organisatie hierop aanpassen is gangbaar sinds Continuous Delivery in 2012 populair werd. In dit scenario maken we QA en Ops onderdeel van de nieuwe ‘delivery teams’. De centrale QA en centrale Ops transformeren we naar een gedistribueerd team dat binnen de verschillende end-to-end geoptimaliseerde teams opereert (DevOps, BizDevOps, enz.).

Wat overblijft zijn de platforms: die worden beheerd door de platformteams. We schreven hierover een goed artikel op onze site: How to setup a successful Cloud Platform Team.

Voor zowel softwarearchitectuur als software delivery worden de verhoudingen en communicatielijnen in de organisatie het best verklaard door de wet van Conway. Door de Reverse Conway Manoeuvre toe te passen, verandert u de organisatie zodat uw softwarearchitectuur en delivery geoptimaliseerd worden voor optimale flow.

Het observeren en sturen van end-to-end flow staat centraal in ons product. Agile Analytics biedt cruciale inzichten in de softwareontwikkeling van uw organisatie.