Teamstructuur als onderdeel van de Doelarchitectuur

In april 1968 publiceert Mel Conway in Datamation het artikel “How do committees invent?”^[1] waarin hij de relatie onderzoekt tussen het organigram van een organisatie en de systemen die de organisatie voortbrengt. Hij baseerde zich hierbij op organisaties die vroege elektronische computersystemen bouwden.

In zijn conclusie schrijft hij de zin die bekend is geworden als de wet van Conway (Conway’s Law): “The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations” oftewel “Systeemontwerpen weerspiegelen de communicatiestructuren binnen een organisatie”.

We kunnen volgens Conway een architectuur niet zien als een autonoom concept dat geisoleerd ontworpen en geimplementeerd kan worden door een willekeurige samenstelling van teams. De vraag die iedere architect zich daarom moet stellen is of er een betere architectuur bestaat die niet als oplossing beschikbaar is door de inrichting van de organisatie. Door de samenstelling van een team te veranderen wordt deze betere architectuur beschikbaar.

Dit laatste zijn James Lewis, technisch directeur van Thoughtworks, en anderen een “omgekeerde Conway manouvre” gaan noemen en vormt de basis voor het boek Team Topologies van Matthew Skelton en Manuel Pais^[2]. Een team topologie is een bewust ontworpen team structuur met de bedoeling zo effectief en efficient mogelijk architectuur te implementeren door team-autonomie en flow na te streven en tegelijk rekening te houden met de grootte van de organisatie, de vak volwassenheid van de mensen, de grootte van de oplossing en de mentale inspanning die de teams maximaal kunnen leveren.

Veel van de problemen die voorkomen in de ontwikkeling en levering van software komen nog altijd voort uit onduidelijke grenzen tussen de verschillende teams en hun verantwoordelijkheden. 

Conway’s Law leert ons dat deze onduidelijke grenzen een architectuur veroorzaken met een sterke koppeling tussen de verschillende onderdelen (zelfs als de architectuur op papier zeer modulair bedoeld is). Deze systemen noemen we monolieten.

Er zijn verschillende soorten systeem monolieten, ook monolieten die lastig te herkennen zijn, zoals een applicatie monoliet, een ‘samen in dezelfde database’ monoliet, een gigantische ‘continuous integration’ monoliet en monolitische releases.

Monolitische structuren kunnen ontstaan uit bijvoorbeeld een monolitisch model waarbij (in grotere organisaties) een overkoepelende domein taal wordt geforceerd in hele verschillende contexten of uit monolitsch denken waarbij teams onnodige beperkingen opgelegd krijgen door standaardisatie van bijvoorbeeld technologie en implementatie aanpak. 

Natuurlijk leert Conway’s Law ons tot slot vooral dat onduidelijke grenzen tussen teams  en hun verantwoordelijkheden ook kunnen voortkomen uit monolitsche werkplekken, zoals een open kantoorindeling waarbij er geen expliciete grenzen zijn tussen de werkplekken van de verschillende teams, wat bijvoorbeeld kan resulteren in onwenselijke samenwerkingen.

Hoewel monolitische structuren veroorzaakt kunnen worden door onduidelijke grenzen tussen teams zijn er risico’s bij het opsplitsen van teams met als doel om monolitische architecturen te voorkomen. De consistentie tussen de verschillende onderdelen van de architectuur kan onder druk komen te staan en het kan toevallige, onbedoelde data duplicatie tussen subsystemen tot gevolg hebben. Ook de totale gebruikerservaring kan minder worden en de complexiteit van de architectuur kan flink toenemen.

Er zijn logische breukvlakken waar de architectuur gemakkelijk gesplitst kan worden in twee of meer delen. Vaak is het verstandig om systemen in lijn te brengen met de verschillende organisatie domeinen, maar er zijn ook andere logische breukvlakken zoals op basis van wet- en regelgeving, de verander cadans van systemen, de geografische locatie van gebruikers, risico’s, technologie keuzes of type gebruikersgroepen.

Matthew Skelton en Manuel Pais doen in Team Topologies een hink-stap-sprong van de DevOps team structuren catalogus^[3] die Matthew in 2013 maakte – en later werd uitgebreid door Manuel – naar vier fundamentele team structuren die nodig zijn om moderne, modulaire software systemen te ontwikkelen en beheren op basis van logische breukvlakken:

• Stream aligned teams
• Enabling teams
• Complicated subteams
• Platform teams

Stream-aligned Teams (Waardestroom Teams)

Deze teams zijn afgestemd op specifieke waardestromen of klantbehoeften. Ze zijn van begin tot eind verantwoordelijk voor het leveren van een bepaald product of een bepaalde dienst, kunnen zelfstandig functioneren en hebben focus op de waarde die ze aan de klant leveren.

Bijvoorbeeld een team dat verantwoordelijk is de oplossing die gebruikt wordt voor de ondersteuning van het CRM (klantrelatie beheer) proces.

Enabling Teams (Ondersteunende Teams)

Deze teams helpen andere teams door obstakels te verwijderen en hun bekwaamheid te vergroten. Ze bieden bijvoorbeeld expertise, hulpmiddelen en advies om andere teams efficiënter te maken.

Bijvoorbeeld een team dat hulp biedt bij het implementeren van de best-practices voor Continuous Integration en Continuous Deployment (CI/CD).

Complicated Subsystem Teams (Gecompliceerde Subsysteem Teams)

Deze teams werken aan complexe of specialistische onderdelen van het systeem die speciale technische kennis of expertise vereisen. Door deze kennis of expertise af te splitsen wordt de mentale belasting verminderd van een team. 

Bijvoorbeeld een team dat zich richt op het ontwikkelen en onderhouden van een geavanceerd algoritme of technische componenten die gespecialiseerde kennis vereisen.

Platform Teams (Platform teams)

Deze teams bieden een interne dienst of een platform aan de andere teams. Ze beheren de gedeelde infrastructuur en tools die andere teams gebruiken om hun werk te doen. Het doel is om de complexiteit van het beheren van infrastructuur en tooling weg te nemen bij teams, zodat ze zich kunnen concentreren op het leveren van waarde aan de klant.

Bijvoorbeeld een team dat een interne cloud-infrastructuur beheert of een ontwikkelplatform biedt aan andere teams in de organisatie.

Er is niet meer nodig dan een combinatie tussen deze 4 team structuren om effectieve en snelle software levering mogelijk te maken, maar inzicht in de verschillende manieren waarop de teams met elkaar samen werken is cruciaal voor het bevorderen van effectieve software levering:

• Samenwerkingsmodus: Teams werken nauw samen om een probleem op te lossen of een functie te leveren,
• X-als-een-dienstmodus: In deze modus biedt één team een interne dienst of platform aan andere teams binnen de organisatie,
• Ondersteuningsmodus: Teams helpen andere teams door hen te ondersteunen bij het vergroten van hun bekwaamheid of het oplossen van problemen.

Elke andere samenwerking is een indicatie dat de team verantwoordelijkheden verkeerd gekozen zijn en het doel van ieder team niet goed begrepen wordt.

Sommige van onze klanten, zoals het CAK, zijn zich bewust van de mogelijkheid dat betere architectuuroplossingen beschikbaar komen door het werk anders te verdelen. Daarom gebruikt het CAK onder andere de kennis en ervaring van de teams om het werk zó te verdelen dat afhankelijkheden tussen teams worden geminimaliseerd. Deze omgekeerde Conway manouvre heeft zijn weerslag in de architectuuroplossingen die beschikbaar komen, en dus in de software die gerealiseerd wordt. Hierdoor vermindert uiteindelijk overbodige communicatie tussen de teams en wordt (de verwerking van) irrelante informatie in de teams voorkomen.

Stelselwijzigingen, koerscorrecties en reorganisaties lijken logische momenten voor het (her)inrichten van teams, want daarna is het effect het grootst, maar draagvlak voor extra complexiteit in hectische tijden is juist op die momenten laag. Het is daarom erg belangrijk om in rustig vaarwater een groot draagvlak te creeren voor het opnemen van de team samenstelling in de (doel) architectuur en om een goed gedragen aanpak te ontwikkelen op basis waarvan team wijzigingen doorgevoerd kunnen worden als de kans zich voordoet.  

Natuurlijk blijft een herinrichting van de organisatie ook in rustig vaarwater een uitdaging, want de teams kunnen niet zonder meer even opgeschud worden. Medewerkers moeten hun nieuwe of veranderende rol begrijpen en over de capaciteiten beschikken om deze uit te voeren. Ook moeten organisaties soms wennen aan het idee dat de architect in overleg wil over de samenstelling van de (IT) teams. 

Nog uitdagender is het om de teams tijdens een omgekeerde Conway manouvre direct te schikken naar de vier fundamentele team structuren en de samenwerkingsvormen tussen de nieuwe teams blijvend te beperken tot de drie modi zoals voorgesteld in Team Topologies.

In Team Topologies wordt daarom een aanpak in vijf stappen beschreven die de basis kan vormen voor een op maat gemaakte aanpak in de context van de organisatie. Ook worden een aantal situaties beschreven die (daarna) vragen om een herijking van de teams met de architectuur, zoals:

• De software is te groot geworden voor een team,
• De leveringscadans wordt trager,
• Verschillende organisatie onderdelen zijn afhankelijk van dezelfde grote set aan onderliggende diensten.

Conway overtuigt ons dat er een duidelijke samenhang is tussen de structuur van de teams en de architectuur van de systemen die deze teams voortbrengen en Matthew Skelton en Manuel Pais geven ons met hun vier topologieen houvast voor een inrichting van de teams met als doel om communicatie tussen de teams te verminderen en irrelante informatie in de teams te voorkomen.

Onze vele praktijkervaringen hebben ons geleerd dat het continu sturen op samenhang het bestuurlijk vermogen van een organisatie verbetert en vergroot. Door de team samenstellingen onderdeel te maken van de doel architectuur vergroot het bestuur van een organisatie daarom wat ons betreft de kans dat het haar doelstellingen realiseert.

^[1] https://www.melconway.com/Home/pdf/committees.pdf

^[2] Skelton, M. Team Topologies (2019). It Revolution Press.

^[3] https://web.devopstopologies.com/