Architektura je tvar týmu: proč hranice v kódu kopírují hranice ve firmě

Položte si vedle sebe dva obrázky. Jeden je diagram architektury vašeho systému, druhý je org schéma firmy. Když se na ně chvíli díváte, začnou se podezřele překrývat. Tři služby — protože systém staví tři týmy. Podivná integrační vrstva přesně tam, kde spolu dvě oddělení v běžném provozu nemluví. Modul, který nikdo pořádně nevlastní, leží na pomezí dvou skupin. To není náhoda a není to ani vada. Je to zákonitost — a má jméno.

01Conwayův zákon

V roce 1967 napsal Melvin Conway článek How Do Committees Invent? a zformuloval v něm pozorování, které dnes známe jako Conwayův zákon: organizace, které navrhují systémy, jsou nuceny produkovat návrhy, jež jsou kopiemi komunikačních struktur těchto organizací. Samotné označení „Conwayův zákon“ se rozšířilo až později, mimo jiné díky knize Freda Brookse The Mythical Man-Month.

Je důležité, čím ten zákon není. Není to morální soud a není to doporučení. Je to pozorování — a jako pozorování drží zhruba šedesát let. Statisticky, ne deterministicky: v doménách, kde silné externí omezení (regulace, otevřené protokoly, tvrdé výkonové požadavky) přebije vnitřní komunikační strukturu, se zákon ohýbá. V běžném produktovém vývoji ale platí spolehlivě. Proč platí, se dá vysvětlit jednoduchou úvahou. Rozhraní mezi dvěma moduly vyžaduje, aby se dvě skupiny, které ty moduly staví, na něčem dohodly. Dohoda vyžaduje komunikaci. A komunikační cesty, které firma reálně má, se stávají rozhraními, která software reálně dostane.

Z toho plyne nepříjemný důsledek. Systému nevyroste čistá hranice tam, kde organizace nevede žádný rozhovor. Můžete si na wiki nakreslit libovolně elegantní řez — pokud mu neodpovídá žádná dvojice lidí, kteří spolu mluví, v běžícím systému se ten řez prostě neobjeví.

02Architektura není jen technické rozhodnutí

Důsledek Conwayova zákona je hlubší, než vypadá. Když kreslíte architekturu, implicitně kreslíte i strukturu týmů — a naopak. Hranice mezi moduly není jen technická čára; je to zároveň hranice mezi skupinami lidí. Tyhle dvě věci nejde oddělit, i když to tak na papíře vypadá.

A když si ty dvě hranice neodpovídají, jedna z nich prohraje. Skoro vždycky je to architektura. Org schéma má svoji setrvačnost — výplaty, reporting, kdo s kým chodí na oběd — a tu setrvačnost diagram v repozitáři nepřebije. Architektura se proto deformuje, aby seděla na komunikační realitu. Diagram na wiki zůstane čistý. Běžící systém ale postupně přijme tvar org schématu — a ten rozdíl mezi nimi je přesně to, co později nikdo nechápe.

03Jak se to projeví v kódu

Zákonitost zní abstraktně, ale v kódu má velmi konkrétní příznaky. Modul, který nevlastní žádný tým, hnije — nikdo nemá důvod ani mandát se o něj starat. Hranice mezi dvěma týmy, které spolu pořádně nemluví, se zvrhne do jednoho ze dvou extrémů: buď je z ní rigidní, přeinženýrovaný kontrakt, kterým se obě strany jistí, nebo je naopak děravá a každý si přes ni sahá, kam potřebuje.

Sdílený kód, který editují dva týmy, se stává konfliktní zónou bez vlastníka — místem, kde se merge requesty hromadí a nikdo necítí zodpovědnost za celek. A naopak: jeden tým, který vlastní tři „mikroslužby“, je potichu sváže k sobě, protože je k tomu nic nebrzdí — uvnitř jednoho týmu nestojí komunikace mezi službami nic, takže hranice mezi nimi přestane být skutečná.

Funguje to oběma směry a dá se to použít jako diagnostika. Architektura vám prozradí org schéma. Org schéma vám předpoví architekturu. Když mi někdo ukáže jedno, docela přesně odhadnu druhé.

04Inverzní Conwayův manévr

Tady přichází obrat, který z pozorování dělá nástroj. Když struktura organizace formuje architekturu, pak chcete-li určitou architekturu, musíte nejdřív vytvarovat organizaci. Tomu se říká inverzní Conwayův manévr.

Postup je opačný, než jak se to obvykle dělá. Nejdřív se rozhodněte, jakou cílovou architekturu chcete — kde mají vést hranice. Teprve potom kolem přesně těch hranic poskládejte týmy. Conwayův zákon pak nepracuje proti vám, ale pro vás: komunikační struktura, kterou jste záměrně postavili, sama tlačí systém do tvaru, který jste si přáli.

To je jádro myšlenky, kterou popisují Matthew Skelton a Manuel Pais v knize Team Topologies: návrh týmů je třeba brát jako vědomou součást architektury, ne jako něco, co se „nějak stane“ v HR. Je ale poctivé říct i druhou stranu. Je to dobře známá a doporučovaná praxe, ale organizačně drahá. Týmy nejde přeskládat každý sprint — měníte jimi lidem nadřízené, projekty i kontext, a to má svoji cenu.

05Tým je jednotka architektury

Team Topologies navrhuje několik typů týmů — stream-aligned týmy, které dodávají hodnotu, a k nim platformní, enabling a complicated-subsystem týmy, které je podporují — plus omezenou sadu způsobů, jak spolu týmy interagují. Důležitá tu ale není ta taxonomie. Důležitý je předpoklad, na kterém stojí.

Tým má strop kognitivní zátěže. Dokáže vlastnit jen tolik systému, kolik si udrží v hlavě. Když týmu naložíte víc architektury, než je jeho kognitivní kapacita, část za hranicí začne degradovat — ne proto, že by byli lidé v týmu špatní, ale proto, že na tu část už nikomu nezbývá pozornost.

Otázka „jak velký systém tenhle tým unese?“ je proto otázka architektonická, ne personální. Hranice se mají vést tak, aby se každý kus vešel do kognitivní zátěže jednoho týmu. To je konkrétní, měřitelné kritérium pro to, kudy řez vést.

06Conwayův zákon a technický dluh

Nesoulad hranic je generátor strukturálního dluhu. Když hranice modulu neodpovídá hranici týmu, každá změna na tom švu vyžaduje koordinaci napříč týmy — a to je úrok, který platíte navždy. Nejde o jednorázovou cenu; je to trvalá daň z každé úpravy v té oblasti. Výzkum DORA (Accelerate, Forsgren et al.) konzistentně ukazuje, že volnost mezi týmy — schopnost dodat bez koordinace přes hranice — je jedním z nejsilnějších prediktorů výkonu.

Nejhorší na tom je, že je ten dluh v code review neviditelný. Každý pull request vypadá v pořádku, protože cena nesedí v kódu — sedí ve schůzkách, v čekání na druhý tým, v e-mailech kolem dohody. Recenzent kódu tu cenu nikdy neuvidí, protože se neodehrává v diffu. Je to stejná čára, jakou vede článek Technický dluh není bordel v kódu — ten nebezpečný dluh není ošklivý kód, ale rozhodnutí o struktuře, které nikdo nepojmenoval.

A když už týmy nebo hranice přeskládáte, je přesně tahle volba tím druhem nosného rozhodnutí, které stojí za to zapsat. Proč hranice vede zrovna tady, proč tým vlastní zrovna tohle — to je „proč“, které jinak odejde s lidmi. Zapište ho jako ADR: architektonická paměť týmu.

07Co s tím prakticky

Čtěte org chart jako diagram architektury

Než padne velké architektonické rozhodnutí, podívejte se na org schéma. Hranice, které dokážete dlouhodobě udržet, jsou ty, které vaše komunikační struktura podpoří. Návrh, který jí neodpovídá, je přání, ne plán.

Hranici modulu veďte po hranici týmu

Jeden vlastník na jednu hranici. Tým, který se modulu vejde do kognitivní zátěže. Když hranice modulu sedí na hranici týmu, sama se brání rozpadu — komunikační realita ji drží.

Chcete jinou architekturu? Změňte nejdřív týmy

Inverzní Conwayův manévr funguje, ale není zadarmo. Přeskládat týmy je pomalé a politické — počítejte s tím a naplánujte si na to rozpočet i čas. Není to věc jednoho sprintu.

Pojmenujte týmovou hranici jako rozhodnutí

Hranice týmu je nosná — drží na ní tvar systému. Zapište ji jako ADR: proč vede zrovna tudy a co se tím vědomě získalo i ztratilo. Týmy se navíc přeskládávají rychleji než moduly, takže původní záměr odejde s lidmi, pokud ho explicitně nezapíšete.

Nedávejte týmu víc systému, než unese

Kognitivní zátěž je reálné omezení, ne výmluva. Když tým přestává svoji oblast udržet v hlavě, je čas ji rozdělit — dřív, než ta část za hranicí začne hnít.

08Závěr

Architektura je tvar týmu. S Conwayovým zákonem můžete bojovat a pomalu prohrávat, nebo ho můžete použít a nechat organizaci, ať architekturu sama drží na místě. Druhá cesta je levnější a trvanlivější — protože pracuje se setrvačností firmy, ne proti ní.

Diagram architektury a org schéma by se měly překrývat tam, kde to jde — a tam, kde to nejde, by měl mít nesoulad jméno a důvod. Ten překryv musí vzniknout záměrně — ne být objeven o dva roky později ve troskách systému, který se rozpadl podle hranic, jež nikdo vědomě nenavrhl.

Conwayův zákon si nevyberete. Vyberete si jen, jestli pracuje pro vás, nebo proti vám.