Dengang afviste Harvard Business Review hans oprindelige artikel med den begrundelse, at han ikke havde bevist sin hypotese. Ikke desto mindre er denne observation blevet kendt som Conways lov, og de kollektive erfaringer fra både mine kolleger og mig selv har gang på gang bekræftet sandheden i dette udsagn. Men du behøver ikke at tage vores ord for det!
I “Exploring the Duality between Product and Organizational Architectures” gennemførte en undersøgelse fra The Harvard Business School en analyse af forskellige kodebaser for at se, om de kunne bevise Conways oprindelige hypotese, som den blev anvendt på softwaresystemer. I undersøgelsen tog de flere eksempler på software, der er skabt til at løse det samme formål (f.eks. tekstbehandling, finansiel forvaltning og databasesoftware), og sammenlignede kodebaser skabt af løst koblede open source-teams med kodebaser skabt af stramt koblede teams. Deres undersøgelse viste, at de ofte samlokaliserede, fokuserede produktteams skabte software, der i højere grad tenderede mod tæt koblede, monolitiske kodebaser. Mens open source-projekterne resulterede i mere modulære, dekomponerede kodebaser.
Organisationer har i nogle få år nu forstået denne sammenhæng mellem organisationsstruktur og den software, de skaber, og har taget nye strukturer til sig for at opnå det ønskede resultat. Netflix og Amazon strukturerer f.eks. sig selv omkring flere små teams, der hver især har ansvaret for en lille del af det samlede system. Disse uafhængige teams kan eje hele livscyklussen for de tjenester, de skaber, hvilket giver dem en større grad af autonomi, end det er muligt for større teams med mere monolitiske kodebaser. Disse tjenester med deres uafhængige problemer kan ændres og udvikles separat fra hinanden, hvilket giver mulighed for at levere ændringer hurtigere til produktion. Hvis disse organisationer havde vedtaget større holdstørrelser, ville de større monolitiske systemer, der ville være opstået, ikke have givet dem den samme mulighed for at eksperimentere, tilpasse sig og i sidste ende holde deres kunder tilfredse.
Du kan måske se spændinger i dine egne organisationer, hvor din struktur og software ikke er på linje med hinanden. Du har måske f.eks. set de udfordringer, der er involveret, når distribuerede teams forsøger at arbejde på den samme monolitiske kodebase. Her står de kommunikationsveje, som Conway henviser til, i kontrast til selve koden, hvor en enkelt kodebase kræver finkornet kommunikation, men hvor et distribueret team kun er i stand til grovkornet kommunikation. Når sådanne spændinger opstår, vil det ofte give betydelige fordele at lede efter muligheder for at opdele monolitiske systemer omkring organisatoriske grænser.
I tidligere teknologiradarer har vi fremhævet den stigende popularitet af mikroservices, som i stigende grad bliver indført af organisationer, der ønsker at forbedre deres teams autonomi og øge hastigheden af ændringer. Martin Fowler og James Lewis’ artikel går mere i dybden med emnet og fremhæver, at disse arkitekturer giver organisationer meget mere fleksibilitet i forhold til at tilpasse deres systemers arkitektur til deres teams struktur for at sikre, at Conways lov virker for dig. I næste udgave af Tech Radar vil vi diskutere afspejlingen af Microservices’ voksende indflydelse, lige fra infrastrukturteknologi som Packer eller Docker til service discovery-værktøjet Consul eller micro-containere som det populære DropWizard eller det ret nye SpringBoot. Vi vil også diskutere det omvendte – organisationer, der ændrer deres teamstruktur for at passe til deres it-systemer.
Vi forventer fuldt ud at se flere teknikker og understøttende teknologi dukke op for at muliggøre Microservice-arkitekturer, og vi vil holde øje med disse i de kommende måneder. I mellemtiden, hvis du vil vide mere, kan du tilmelde dig den seneste Tech Radar, læse Martin og James’ artikel om microservices eller min bog fra O’Reilly, Building Microservices.