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 voor organisaties. Een organisatie die is ingericht in functionele silo’s — teams die elk in één functie gespecialiseerd zijn, zoals QA, DBA of security — zal zelden softwaresystemen opleveren die goed zijn ontworpen voor end-to-end flow.

Wilt u de kans vergroten dat een organisatie systemen bouwt die op end-to-end flow zijn ingericht, pas dan een “Reverse Conway Manoeuvre” toe (ook wel Inverse Conway Manoeuvre). Dat betekent: richt de communicatie tussen teams opnieuw in 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: een gedeeld DBA-team stuurt aan op één gedeelde database. In omgekeerde richting geldt hetzelfde voor aparte front-end- en back-endontwikkelaars: dat leidt tot aparte UI- en app-lagen (figuur 2).

We passen nu de Reverse Conway Manoeuvre toe en ontwerpen onze teams passend bij de gewenste architectuur. Elk team krijgt een ontwikkelaar voor de clientapplicaties, een voor de API en een databaseontwikkelaar binnen het team in plaats van in een apart team (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 (de automatische build- en testrun waar elke wijziging doorheen gaat) 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 (het automatisch bouwen, testen en uitrollen van elke wijziging) 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.

De vier DORA-metrics — deployment frequency, lead time for changes, change failure rate en time to restore — laten zien of een Reverse Conway Manoeuvre daadwerkelijk terugkomt in de leverdata.