Den gången förkastade Harvard Business Review hans ursprungliga artikel på grund av att han inte hade bevisat sin hypotes. Ändå har denna observation blivit känd som Conways lag, och de kollektiva erfarenheterna hos både mina kollegor och mig själv har gång på gång förstärkt sanningen i detta påstående. Men du behöver inte ta oss på orden!
I ”Exploring the Duality between Product and Organizational Architectures”, en studie från Harvard Business School, genomfördes en analys av olika kodbaser för att se om de kunde bevisa Conways ursprungliga hypotes tillämpad på mjukvarusystem. I studien tog de flera exempel på programvaror som skapats för att lösa samma syfte (t.ex. ordbehandling, ekonomiförvaltning och databasprogramvara) och jämförde de kodbaser som skapats av löst kopplade open source-team med dem som skapats av tätt kopplade team. Deras studie visade att de ofta samlokaliserade, fokuserade produktteamen skapade programvara som tenderade mer mot tätt sammankopplade, monolitiska kodbaser. Medan projekten med öppen källkod resulterade i mer modulära, dekomponerade kodbaser.
Organisationer har sedan några år tillbaka förstått denna koppling mellan organisationsstruktur och den mjukvara de skapar, och har anammat nya strukturer för att uppnå det resultat de vill ha. Netflix och Amazon till exempel strukturerar sig själva kring flera små team, vart och ett med ansvar för en liten del av det övergripande systemet. Dessa oberoende team kan äga hela livscykeln för de tjänster de skapar, vilket ger dem en större grad av självständighet än vad som är möjligt för större team med mer monolitiska kodbaser. Dessa tjänster med sina självständiga intressen kan ändras och utvecklas separat från varandra, vilket gör det möjligt att leverera ändringar snabbare till produktionen. Om dessa organisationer hade antagit större teamstorlekar skulle de större monolitiska systemen som skulle ha uppstått inte ha gett dem samma möjlighet att experimentera, anpassa sig och i slutändan hålla sina kunder nöjda.
Du kanske ser spänningar i dina egna organisationer där din struktur och programvara inte är i linje. Du kanske till exempel har sett de utmaningar som uppstår när distribuerade team försöker arbeta med samma monolitiska kodbas. Här står de kommunikationsvägar som Conway hänvisar till i kontrast till själva koden, där en monolitisk kodbas kräver finkornig kommunikation, men ett distribuerat team bara klarar av grovkornig kommunikation. När sådana spänningar uppstår kommer det ofta att ge betydande fördelar att leta efter möjligheter att dela upp monolitiska system runt organisatoriska gränser.
I tidigare Technology Radars har vi lyft fram den ökande populariteten av mikrotjänster, som i allt större utsträckning antas av organisationer som vill förbättra teamens självständighet och öka förändringshastigheten. Martin Fowler och James Lewis artikel går djupare in på ämnet och lyfter fram det faktum att dessa arkitekturer ger organisationer mycket mer flexibilitet när det gäller att anpassa systemarkitekturen till teamens struktur för att se till att Conways lag fungerar för dig. I nästa nummer av Tech Radar kommer vi att diskutera speglingen av mikrotjänsternas växande inflytande, från infrastrukturteknik som Packer eller Docker till service discovery-verktyget Consul, eller mikrocontainers som det populära DropWizard eller det ganska nya SpringBoot. Vi kommer också att diskutera det omvända – organisationer som ändrar sin teamstruktur för att passa sina IT-system.
Vi förväntar oss helt och hållet att fler tekniker och stödteknik kommer att dyka upp för att möjliggöra Microservice-arkitekturer, och vi kommer att hålla koll på dessa under de kommande månaderna. Om du vill veta mer under tiden kan du anmäla dig till den senaste Tech Radar, läsa Martin och James artikel om mikrotjänster eller min bok från O’Reilly, Building Microservices.