Hvorfor organiseringen næsten altid vinder over arkitekturen

Om Conway’s lov, friktion og ledelsesmæssige trade-offs

Conway’s lov bliver ofte citeret, men sjældent taget helt alvorligt. Den beskriver, at organisationer ender med at designe systemer, der afspejler deres kommunikationsstrukturer. Med andre ord bliver arkitekturen et spejl af den måde, vi organiserer os og arbejder sammen på.

Det lyder simpelt. Men i praksis forklarer det meget præcist, hvorfor arkitekturer bliver komplekse, tæt koblede og svære at ændre, også selvom intentionen oprindeligt var en helt anden.

Gennem mange år har jeg oplevet, at arkitektur sjældent fejler af tekniske årsager. Den fejler, fordi organiseringen trækker i en anden retning. Når teams er organiseret omkring systemer, teknologier eller funktioner, vil arkitekturen over tid blive opdelt på samme måde. Når ansvar er fragmenteret, bliver snitfladerne uklare. Og når koordinering på tværs er dyr, opstår der løsninger, som lokalt giver mening, men som samlet set gør organisationen langsommere.

Alligevel møder jeg ofte ønsket om at "løse "fikse" arkitekturen først og organiseringen bagefter. Man vil gerne designe den rigtige arkitektur og derefter tilpasse teams og ansvar. Problemet er bare, at det næsten aldrig er muligt i praksis.

De fleste organisationer har rigeligt at gøre med at:

• levere på roadmapet

• holde driften stabil

• håndtere eksisterende teknisk og organisatorisk gæld

Der er sjældent overskud til samtidig at splitte systemer op, etablere nye snitflader og forberede en reorganisering, der matcher den fremtidige arkitektur. Resultatet bliver ofte, at man bliver stående i et vadested, hvor alle ved, at noget skal ændres, men hvor ingen helt kan se, hvordan man kommer derhen uden at miste fremdrift undervejs.

Det er her, vi bør stifte perspektiv. I stedet for at forsøge at fjerne al friktion, bør vi som leder spørge os selv:

• hvor meget friktion kan vi håndtere?

• hvor opstår den mest hensigtsmæssigt?

• og hvor bliver den direkte skadelig?

Jeg husker tydeligt en samtale med en CIO for en stor dansk virksomhed, som jeg var sparringspartner for. Ambitionen var at organisere værdistrømsteams tæt på kunderne og levere hele vejen fra behov til løsning. Midt i dialogen stopper han op og konstaterer, at hvis man reelt skal levere fra jord til bord, så involverer det 12 forskellige systemer, 12 teknologier og et tilsvarende antal kompetencer.

Med en ønsket teamstørrelse på fem til ni personer, som vi mente var gav en fornuftig balance mellem overhead, samarbejde og produktivitet, var det åbenlyst umuligt at samle hele arkitekturstakken i ét team. Enten ville man skabe urimelige krav til kompetencebredden i teamsne, eller også ville man ende med massive afhængigheder mellem teams.

Valget stod derfor ikke mellem en perfekt løsning og en dårlig løsning. Det stod mellem at gøre ingenting og blive i en klassisk systemorganisering med lang afstand til slutbrugeren og utallige afhængigheder, eller bevidst at strække elastikken.

Vi valgte det sidste.

Organisationen blev ændret til fem kundevendte teams, som hver dækkede tre til fem arkitekturlag. De resterende dele blev samlet i komponentteams. Det skabte friktion, men det reducerede koordineringen markant i forhold til den skridt. Mere dekobling. Stærkere kundefokus. Og ny midlertidig friktion, indtil organisation og arkitektur fandt et nyt leje.

Det er et mønster, jeg har set igen og igen. Og hver gang jeg taler med CIO’er eller CTO’er om Conway’s lov, er der aldrig nogen, der er uenige. Alle ved godt, at organiseringen spiller en afgørende rolle for den arkitektur, man ender med at bygge. Udfordringen er ikke erkendelsen. Udfordringen er at handle på den i en hverdag med højt tempo og stramme deadlines.

For mig peger erfaringen på, at vejen frem kræver et langsigtet målbillede, hvor man som ledelse bliver enige om:

• Hvad er den forretningsmæssige ambition?

• Hvilken systemisk understøttelse kræver den?

• Hvordan bør arkitekturlandskabet se ud på sigt?

Og derefter accepterer, at vejen dertil ikke er friktionsfri.

Man må vælge sit udgangspunkt. Reorganisere for at understøtte bevægelsen. Tage nogle skridt. Følge tæt med i, hvordan det påvirker samarbejde, beslutninger og leverancer. Justere undervejs, når man bliver klogere. Og så tage næste skridt. Indtil man gradvist står med en løsere koblet arkitektur, der faktisk understøtter den forretningsagilitet, man ønsker.