Architektúru vášho produktu kreslí vaša organizačná schéma

V roku 1968 si Melvin Conway všimol niečo na kompilátoroch. Firma dala piatich ľudí na kompilátor COBOL-u a troch na kompilátor ALGOL-u. Kompilátor COBOL-u mal päť fáz. Kompilátor ALGOL-u mal tri.

Nikto to tak nenavrhol. Štruktúru softvéru rozhodlo to, ako boli rozdelení ľudia.

Conway z toho vyvodil pravidlo, ktoré dnes nesie jeho meno: organizácie, ktoré navrhujú systémy, vyrábajú návrhy kopírujúce ich vlastnú komunikačnú štruktúru. Kde sa dva tímy musia dohodnúť, vznikne rozhranie. Kde spolu nehovoria, rozhranie nevznikne, alebo vznikne zle.

Odtiaľ je blízko k tvrdeniu, že architektúra softvérového produktu je to isté umenie ako dizajn organizácie. Ako opis spôsobu uvažovania to sedí. Ako tvrdenie o tom istom umení to neplatí, a práve tam, kde to neplatí, sa pri navrhovaní organizácie robia najdrahšie chyby.

Ten istý druh problému

Obe disciplíny delia jeden systém na časti. Rozhodujú, kde budú hranice, čo cez ne prechádza a koľko prepojenia (coupling) medzi časťami ešte znesú. Súdržnosť vnútri časti, závislosti medzi časťami, rozhrania, kompromisy bez jediného správneho riešenia, návrh, ktorý sa bez údržby rozpadá: architekt aj ten, kto navrhuje organizáciu, pracujú s rovnakými pojmami.

Conway ukazuje ešte viac. Tie dve disciplíny sa podobajú, lebo opisujú jeden systém z dvoch strán. Conway ten vzťah nazval homomorfizmom, teda zobrazením, ktoré zachováva štruktúru: od grafu organizácie ku grafu systému. Keď zmeníte jedno, meníte aj druhé, či ste to plánovali, alebo nie.

Christopher Alexander to v roku 1977 napísal o budovách. V knihe A Pattern Language (pattern 205) tvrdí, že budova sa ľuďom v nej nikdy nebude zdať správna, kým fyzický priestor nezodpovedá sociálnemu.

Potiaľto analógia drží.

Časti systému reagujú

Modul nereaguje na to, že ho niekto navrhol. Ľudia áno. Keď im zmeníte hranice, začnú ich obchádzať. Keď im zmeníte ciele, optimalizujú na ne. Učia sa, vyjednávajú, odchádzajú.

Softvérová architektúra pracuje so systémom, ktorý je komplikovaný: dá sa rozložiť, pochopiť a jeho správanie sa dá do veľkej miery predpovedať. Organizácia je komplexný systém. Návrh mení správanie toho, čo opisuje, a čo návrh spôsobil, sa ukáže až v prevádzke.

Organizácia sa mení po krokoch

Kód sa dá prepísať, otestovať a vrátiť. Refaktoring, ktorý nevyšiel, stojí pár dní. Reorganizácia míňa dôveru, identitu ľudí a ich kariéry, a nič z toho sa nedá vrátiť commitom. Žiadna testovacia sada vám pred nasadením nepovie, či nová štruktúra funguje.

Preto sa organizácia mení po malých krokoch, pričom po každom sa sleduje, čo spôsobil. Softvér si evolučný prístup môže vybrať. Organizácia inú možnosť nemá.

Tímy potrebujú viac ciest k sebe

David Parnas v roku 1972 sformuloval princíp, na ktorom stojí dobrá modularita: každý modul skrýva svoje rozhodnutia pred ostatnými (information hiding) a hranice sa kreslia tak, aby cez ne prechádzalo čo najmenej. Zmena v jednom module sa nemá rozliať do ostatných. V softvéri je to správne.

Preneste ten princíp na tímy a dostanete komponentové tímy. Každý tím vlastní svoju časť, rozhrania medzi tímami sú úzke a formálne a komunikácie cez hranice je málo, presne ako to modularita chce. Zákazník si však objednáva feature, a tá prechádza cez päť komponentov, teda cez päť tímov, päť backlogov a päť priorít. Každá taká feature sa stáva koordinačným projektom. Tímy čakajú jeden na druhý, integruje sa až na konci a ownership výsledku nemá nikto.

LeSS ide zámerne opačne. Feature tímy pracujú naprieč celým produktom, kód je spoločný a tímy spresňujú backlog spolu. Komunikačných ciest medzi tímami tým pribúda. Organizácia, ktorá sa má prispôsobovať, potrebuje, aby sa ľudia vedeli dohodnúť kdekoľvek v produkte, lebo vopred nevie, kam príde ďalšia zmena.

Conway v závere svojho článku odporučil to isté: organizáciu treba štruktúrovať podľa toho, kto s kým potrebuje komunikovať. Keď je cieľom rýchlosť a prispôsobivosť, táto potreba ide naprieč komponentmi.

Najlepší zvyk architekta, šetriť komunikáciou cez hranice, teda v organizácii vyrába presne ten problém, ktorý má dizajn organizácie riešiť.

Organizácia tvaruje architektúru

Conway tvrdí, že organizácia obmedzuje architektúru. Veta „je to to isté umenie“ zvádza tento smer obrátiť: navrhneme cieľovú architektúru a tímy poskladáme podľa nej. Tento ťah dostal meno Inverse Conway Maneuver a rozšírila ho kniha Team Topologies, podľa ktorej sa tímy majú navrhnúť tak, aby zodpovedali požadovanej architektúre.

V tom istom článku z roku 1968 však Conway píše, že návrh, ktorý vznikne ako prvý, takmer nikdy nie je najlepší možný. Keď tímy natvrdo priviažete k prvej architektúre, jej chyby zafixujete v organizačnej schéme. Každá neskoršia oprava architektúry bude zároveň reorganizáciou, a tá nemá revert.

Organizácia má viac grafov naraz

Softvér má v podstate jednu štruktúru závislostí. Organizácia ich má niekoľko súčasne: kto komu podlieha, kto s kým naozaj hovorí, ako tečú peniaze, čo sa odmeňuje, kto má akú moc. Tieto grafy sa navzájom často nezhodujú.

Conwayov zákon sleduje skutočnú komunikáciu. Tá sa od organizačnej schémy odkláňa všade tam, kam ju ťahajú ostatné grafy.

Dva pohľady na jeden systém

Presnejšia veta by znela takto: softvérová architektúra a dizajn produktovej organizácie sú dva pohľady na ten istý systém. Rovnaký druh problému, rôzne materiály. Vaša organizačná schéma kreslí architektúru vášho produktu.

Dá sa to overiť na vašich vlastných dátach. Adam Tornhill v knihe Your Code as a Crime Scene (2015) opísal postup: z histórie verzií zistíte, ktoré moduly sa menia spolu, a ku každému z nich, kto ho mení najčastejšie. Potom porovnáte, či majú títo ľudia k sebe ľahkú cestu. Kde ju nemajú, pribúda chýb.

Skúste to na svojom produkte:

• Ktoré moduly sa menia spolu, hoci ich vlastnia rôzne tímy?
• Hovoria ľudia, ktorí ich menia, spolu priamo, alebo cez manažéra, iné mesto či iný backlog?
• Hromadia sa chyby práve na týchto miestach?

Kde sa kód mení spolu a ľudia spolu nehovoria, tam vám organizácia práve navrhuje architektúru. Nikto o tom nerozhodol.