Demystifying Conway’s Law | ThoughtWorks

Op dat moment verwierp de Harvard Business Review zijn oorspronkelijke artikel, omdat hij zijn hypothese niet had bewezen. Desalniettemin is deze observatie bekend komen te staan als de Wet van Conway, en de collectieve ervaringen van zowel mijn collega’s als mijzelf hebben de waarheid van deze uitspraak keer op keer versterkt. Maar u hoeft ons niet op ons woord te geloven!

In “Exploring the Duality between Product and Organizational Architectures” werd in een studie van de Harvard Business School een analyse uitgevoerd van verschillende codebases om te zien of zij Conway’s oorspronkelijke hypothese konden bewijzen bij de toepassing ervan op softwaresystemen. In de studie namen zij verschillende voorbeelden van software die was gemaakt om hetzelfde doel op te lossen (bijvoorbeeld tekstverwerking, financieel beheer en databasesoftware), en vergeleken de codebases die waren gemaakt door losjes gekoppelde open-sourceteams, met die welke waren gemaakt door strak gekoppelde teams. Uit hun studie bleek dat de vaak op dezelfde locatie gevestigde, gerichte productteams software maakten die meer neigde naar strak gekoppelde, monolithische codebases. Terwijl de open source-projecten resulteerden in meer modulaire, gedecomponeerde codebases.

Organisaties hebben dit verband tussen organisatiestructuur en de software die ze maken al een paar jaar begrepen, en hebben nieuwe structuren omarmd om het resultaat te bereiken dat ze willen. Netflix en Amazon bijvoorbeeld structureren zichzelf rond meerdere kleine teams, elk met verantwoordelijkheid voor een klein deel van het totale systeem. Deze onafhankelijke teams kunnen eigenaar zijn van de hele levenscyclus van de diensten die ze creëren, wat hen een grotere mate van autonomie geeft dan mogelijk is voor grotere teams met meer monolithische codebases. Deze diensten met hun onafhankelijke concerns kunnen afzonderlijk van elkaar veranderen en evolueren, wat resulteert in de mogelijkheid om wijzigingen sneller in productie te nemen. Als deze organisaties grotere teams hadden aangenomen, zouden de grotere monolithische systemen die dan zouden zijn ontstaan, hen niet dezelfde mogelijkheden hebben gegeven om te experimenteren, zich aan te passen en uiteindelijk hun klanten tevreden te houden.

U ziet wellicht spanningen in uw eigen organisaties waar uw structuur en software niet op elkaar zijn afgestemd. U hebt bijvoorbeeld gezien welke uitdagingen er zijn wanneer gedistribueerde teams proberen te werken aan dezelfde monolithische codebase. Hier staan de communicatiepaden waar Conway naar verwijst in contrast met de code zelf, waar een enkele codebase fijnkorrelige communicatie vereist, maar een gedistribueerd team slechts in staat is tot grofkorrelige communicatie. Waar dergelijke spanningen ontstaan, zal het zoeken naar mogelijkheden om monolithische systemen op te splitsen rond organisatiegrenzen vaak aanzienlijke voordelen opleveren.

In eerdere Technologieradars hebben we gewezen op de groeiende populariteit van Microservices, die steeds vaker worden overgenomen door organisaties die de autonomie van hun teams willen verbeteren en de snelheid van verandering willen verhogen. Het artikel van Martin Fowler en James Lewis gaat dieper in op het onderwerp en benadrukt het feit dat deze architecturen organisaties veel meer flexibiliteit bieden in het afstemmen van de architectuur van hun systemen op de structuur van hun teams, om ervoor te zorgen dat de wet van Conway voor u werkt. In de volgende editie van de Tech Radar bespreken we de weerspiegeling van de groeiende invloed van Microservices, van infrastructuurtechnologie zoals Packer of Docker tot de service discovery tool Consul, of micro-containers zoals het populaire DropWizard of het vrij nieuwe SpringBoot. We bespreken ook het omgekeerde – organisaties die hun teamstructuur aanpassen aan hun IT-systemen.

We verwachten dat er meer technieken en ondersteunende technologie zullen ontstaan om Microservice-architecturen mogelijk te maken, en we zullen deze de komende maanden op de voet blijven volgen. Als u in de tussentijd meer wilt weten, kunt u zich aanmelden voor de nieuwste Tech Radar, het artikel van Martin en James over microservices lezen, of mijn boek van O’Reilly, Building Microservices.

Plaats een reactie