Kort fortalt
Conways lov hævder, at organisationer designer systemer, der afspejler deres egne kommunikationsstrukturer. Teamgrænser bliver ofte til systemgrænser.
Hvad betyder princippet?
Melvin Conway formulerede observationen i 1968: de grænseflader, teams har til hinanden, former de grænseflader, systemet får. Hvis fire siloer bygger et produkt, får man typisk et system med fire større dele og besværlige overgange.
Idéen bruges i dag som argument for inverse Conway maneuver: organisér teams, så den ønskede arkitektur bliver den naturlige konsekvens.
Du skibber din org chart — med eller uden vilje.
Et konkret eksempel
Frontend-, backend- og data-teams arbejder isoleret. Resultatet bliver tre lag med tunge handoffs, selv om brugerrejsen kræver tværgående flow. Reorganisering omkring værdistrømme gør arkitekturen mere sammenhængende over tid.
To virksomheder fusionerer uden at ændre teamstruktur. Deres produkter forbliver to systemer med et limlag imellem — spejlbilledet af de to organisationer.
Hvornår er princippet nyttigt?
- Når arkitekturproblemer egentlig er organisationsproblemer.
- Når man designer teams og ansvar.
- Når integrationer er kronisk smertefulde.
- Når man planlægger platforme og modulgrænser.
Begrænsninger og kritik
Loven er en tendens, ikke et deterministisk bud. Gode abstraktioner, stærke interfaces og bevidst arkitekturstyring kan svække spejlingen. Omorganisering er heller ikke gratis.
Brug Conways lov diagnostisk: når systemet ser underligt ud, så kig på, hvem der taler med hvem.
Kilder
- Melvin E. Conway, “How Do Committees Invent?” (1968).
- Bemærkning: Begrebet er standard i softwarearkitektur og organisationsteori om socio-tekniske systemer.