Conway's Law a Team Topologies

05.01 Conway's Law#

V dubnu 1968 vyšel v časopise Datamation krátký esej Melvina Conwaye s názvem How Do Committees Invent? [1]. Conway v něm formuloval pozorování, kterému se později začalo říkat Conway's Law:

„Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.“

– Melvin E. Conway, 1968

Česky: organizace, které navrhují systémy, jsou nuceny vytvářet návrhy kopírující jejich komunikační strukturu. Conway nic nepředepisuje, popisuje pozorování: oddělený frontendový a backendový tým vyrobí oddělený frontend a backend i v kódu.

Tezi Conway dokládá strukturně. Každému uzlu návrhu odpovídá jedna návrhová skupina a každé větvi mezi uzly rozhraní, na kterém se dvě skupiny dohodly. Matematicky řečeno: mezi grafem systému a grafem organizace, která ho navrhuje, existuje homomorfismus. Rozhraní v kódu tedy zapisuje dohodu dvou skupin lidí.

Komunikační struktura není organizační diagram

Conway mluví o komunikační struktuře, ne o tom, kdo komu podléhá. Obojí splývá jen tam, kde formální hierarchie skutečně určuje, kdo s kým smí mluvit. Sám tím vysvětluje, proč vojensky řízené organizace vyrábějí systémy podobné svému organizačnímu diagramu. Jinde rozhoduje, kdo s kým denně řeší práci.

V celé kapitole proto „týmová hranice“ znamená tým, který doručuje a drží pohotovost, ne políčko v organizačním diagramu. Team Topologies staví na stejném rozlišení: první kapitola knihy se jmenuje The Problem with Org Charts.

Tři případy z praxe

1. Tým rozdělený podle vrstev → Layered Architecture. Společnost s 30 vývojáři rozdělená na „frontend tým“, „backend tým“ a „DBA tým“ vyrobí třívrstvou architekturu. Každý tým má vlastní release cyklus, vlastní CI/CD pipeline, vlastní sprint review. Bounded Context je v lepším případě interní záležitostí backend týmu; frontend a DBA o něm nevědí. Důsledek: změna jednoho doménového požadavku projde všemi třemi týmy a třemi sprinty.

2. Tým rozdělený podle produktu/streamu → microservice nebo modul na každý BC. Stejná organizace přeorganizovaná na „Catalog tým“, „Ordering tým“, „Billing tým“ a „Warehouse tým“ vyrobí 4 microservices nebo 4 izolované moduly v monolitu, jeden na každý Bounded Context. Každý z týmů je plně end-to-end: frontend, backend, DB, devops. Conway's Law platí dál, jen dostal jiné vstupy.

3. Tým bez vnitřních hranic → Big Ball of Mud. 8 vývojářů, kteří všichni sahají do všeho, žádné Bounded Contexts nevytvoří. Vznikne jeden monolit, ve kterém je Customer ve fakturaci tatáž třída jako Customer v marketingu, jen s víc atributy. Klasický důsledek: po 18 měsících si nikdo netroufne nic změnit, protože „to může mít vliv kdekoli“.

FIG. 05.1-A Conway vs. Inverse Conway Maneuver

+ − ⤢ ⛶

05.02 Bounded Context = týmová hranice#

Vaughn Vernon v knize Implementing Domain-Driven Design (2013, kap. 2) [2] formuluje doporučení, které je možná nejužitečnějším praktickým výstupem celého DDD: Bounded Context má patřit jedinému týmu. Opačně to podle Vernona jde: jeden tým může mít na starosti více Bounded Contexts. V Domain-Driven Design Distilled (2016, kap. 2) to zopakoval: více týmů nemá sdílet jeden kontext.

Vernon to ovšem nepodává jako zákon. Píše, že pravidlo jednoho týmu na kontext nemá omezovat pružnost organizace týmů, a hned dodává, že firma má lidi využívat tak, jak potřebuje. Členové jednoho týmu mohou vypomáhat na jiných projektech. Jde tedy o preferenci („it is best for“), ne o zákaz sdílet lidi. Kontext vlastní tým jako celek, ne každý jeho člen na plný úvazek.

Doporučení má dvě části, které se často chybně čtou jako jedna:

• Jeden Bounded Context = jeden tým (výchozí stav). Když dva týmy sdílejí jeden BC, Conway's Law se projeví okamžitě. Buď vznikne neoficiální vnitřní hranice, tedy fakticky dva BC, které nikdo nepřiznal. Nebo sdílené vlastnictví: BC nikdo nevlastní a degraduje na Big Ball of Mud. Prakticky: sdílený BC je dočasný stav s koncovým datem, ne cílová podoba. Kód, který dva týmy skutečně potřebují sdílet, patří do malého Shared Kernelu mezi dvěma oddělenými BC. I ten je ale drahý vztah, ne výchozí volba.

• Jeden tým = jeden nebo více Bounded Contexts (povoleno). Malý tým (5–9 lidí) může vlastnit 1–2 menší BC, výjimečně 3. Limit plyne z kognitivní zátěže, kterou rozebírá sekce 05.06. Tým, který vlastní 5+ BC, je signál k rozdělení.

Pro mnoho organizací je důsledek nepříjemný: Context Map a Team Map jsou ve zdravém stavu téměř izomorfní. Při 7 BC a 4 týmech máte buď nesoulad (3 BC nemají vlastníka), nebo jeden tým vlastní 2+ BC (vědomé rozhodnutí, ne nedopatření). Vztahy na Context Mapě podrobně rozebírá kapitola o Context Mappingu.

A obráceně: při 4 BC a 7 týmech hranice nevznikly podle DDD, ale z historické organizační struktury, kterou nikdo neaktualizoval. Na řadu přichází Inverse Conway Maneuver (sekce 05.05).

Co dělat, když Context Map a Team Map nesedí

Nesoulad mezi Context Mapou a Team Mapou má čtyři podoby a každá vyžaduje jinou akci:

Žádný z těchto scénářů není akutní krize. Conway's Law dává systému dost setrvačnosti, aby s nesouladem fungoval měsíce. Dlouhodobě se ale projeví: prodlužuje se lead time, roste podíl nasazení s incidentem, klesá morálka. Přímé měření tohoto řetězce žádný z citovaných zdrojů nenabízí, jde o pozorování z praxe.

05.03 Team Topologies – 4 typy týmů (Skelton & Pais 2019)#

V roce 2019 vydali Matthew Skelton a Manuel Pais knihu Team Topologies: Organizing Business and Technology Teams for Fast Flow [3]. Poprvé v ní systematicky popsali, jaké typy týmů má organizace mít a jak spolu mají komunikovat. Proces jako SAFe nebo LeSS kniha nepředepisuje. Dodává slovník pro organizační návrh, který DDD u Vernona chybí.

Druhé vydání vyšlo 23. září 2025 [4]. Podtitul se změnil z „business and technology teams“ na „business and technology“ a rámec tím míří i mimo IT. Kognitivní zátěž v něm autoři povýšili na hlavní designový princip a spolu s Dr. Laurou Weis k ní publikovali model s více než dvaceti faktory ve čtyřech skupinách. Následující text vychází z prvního vydání, na kterém stojí zavedená terminologie.

Skelton v roce 2024 doplnil, co v knize podle něj zapadlo: nejdůležitější nejsou statické čtyři typy týmů, ale interakce mezi nimi a vývoj topologie v čase. Čtyři typy si čtenáři pamatují, protože se dobře kreslí do slidu. Rozhodují ale interakční módy ze sekce 05.04 a ochota topologii po půl roce přepsat.

Skelton a Pais rozlišují 4 typy týmů. Cokoliv jiného (klasický „enterprise architecture team“, „QA tým“, „Center of Excellence“) je buď maskovaná varianta jednoho z nich, nebo organizační anti-vzor.

Stream-aligned team

Vlastník end-to-end value streamu, typicky jednoho Bounded Contextu. Stream-aligned tým má všechny role, aby mohl sám dodávat změny koncovému uživateli: vývojáře (frontend i backend), QA, designéra, někdy product ownera. Sám rozhoduje, nasazuje a provozuje v produkci, nic nepředává jinému týmu.

• Velikost: 5–9 lidí. Hranici autoři neodvozují od objednávky pizzy, ale od Dunbarových hranic důvěry (5, 15, 50, 150).
• Vlastnictví: 1 BC (typicky), maximálně 2–3 související malé BC.
• Cíl: minimalizovat kognitivní zátěž a maximalizovat flow hodnoty.
• Měření: DORA metriky, aktuální sadu rozebírá sekce 05.09.

Ve zdravé technologické organizaci je většina týmů stream-aligned. Skelton a Pais k tomu dávají tip: poměr stream-aligned týmů k ostatním má být zhruba 6:1 až 9:1. Číslo nevzešlo z měření, opírá se o to, co o sobě hlásí úspěšné organizace. Jako řádová kontrola ale stačí. Organizace s deseti týmy, z nichž jsou stream-aligned tři, typicky trpí některým z anti-vzorů ze sekce 05.08.

Platform team

Poskytuje self-service platformu pro stream-aligned týmy. Platform team spravuje interní vývojářskou platformu (IDP – Internal Developer Platform). Patří sem CI/CD šablony, observability stack (Prometheus, Grafana, Sentry), Kubernetes, secrets management, šablony pro nové BC, vývojářský portál.

Rozhoduje slovo self-service. Stream-aligned tým si na platformu nezadává ticket („potřebuju nový Postgres“) a nečeká týden. Databázi si naklikne sám přes portál nebo nasadí přes IaC modul, který Platform team udržuje. Když platforma funguje jako ticketová fronta, stane se z ní úzké hrdlo (anti-vzor v sekci 05.08).

Platformu autoři nedefinují jako jeden tým, ale jako seskupení dalších týmů, které stream-aligned týmům dodává přesvědčivý interní produkt. Velká platforma tak může mít uvnitř vlastní stream-aligned týmy pro jednotlivé služby. Poměr typu „jeden platform tým na sto vývojářů“ kniha neuvádí.

Rozsah platformy určuje koncept Thinnest Viable Platform: platforma má být jen tak tlustá, jak je nutné. Nejmenší funkční TVP je wiki stránka se seznamem schválených služeb a návodem k jejich použití. Teprve když přestane stačit, přidává se automatizace a s ní lidé.

• Charakter: platforma je produkt. Má roadmapu, interní zákazníky a měřenou adopci. Bez toho je to sdílená infrastruktura s novým jménem.
• Měření: NPS od stream-aligned týmů, adoption rate, time-to-first-deploy pro nový BC.
• Anti-charakter: Platform team změny neschvaluje. Práci ostatních umožňuje, nestojí v ní jako gatekeeper.

Enabling team

Tým specialistů, který pomáhá stream-aligned týmu osvojit si novou techniku nebo technologii. Klasické úkoly: „naučte je TDD“, „zaveďte CQRS“, „pomozte s migrací na K8s“, „rozjeďte s nimi event sourcing“.

Časově omezená je spolupráce, ne tým. Kniha mluví o závislosti, která má po několika týdnech či měsících skončit. Enabling tým jako útvar trvá dál a přesune se k dalšímu stream-aligned týmu, který právě něco přebírá.

Enabling team se často zaměňuje s Center of Excellence, ačkoli se podstatně liší:

Complicated-subsystem team

Vlastní algoritmicky náročnou doménu, kterou by stream-aligned tým nezvládl bez vyhrazených specialistů. Typické příklady: risk engine v reálném čase v bance, ML scoring model, video transcoder, fyzikální simulátor, kompilátor, kryptografická knihovna. Tým soustřeďuje specializované znalosti (PhD v matematice, fyzice nebo CS, hluboké know-how v doméně), které nejde rozprostřít přes 6 stream-aligned týmů.

• Vznik: jen tehdy, když stream-aligned tým objektivně narazí na strop.
• Komunikace: obvykle X-as-a-Service vůči stream-aligned týmům.
• Past: ze stream-aligned týmu se stane „complicated subsystem“ jen proto, že má seniornější obsazení. Seniorita důvod není, rozhoduje specializace.

Mapování DDD subdomén na typy týmů

Klasifikace subdomén (Core / Supporting / Generic) se na typy týmů převádí přímo. Co jednotlivé kategorie znamenají a jak je rozpoznat, rozebírá kapitola o subdoménách; zde zůstává jen týmový pohled:

05.04 Tři interakční módy mezi týmy#

Skelton a Pais vedle typů týmů definují i 3 (a jen 3) povolené módy interakce mezi nimi. Cokoliv jiného („tak ti tam někdo pomůže“, „domluvte se nějak“, „pošli ticket a uvidíme“) je neformální vztah, který Conway's Law okamžitě otiskne do kódu jako ad hoc rozhraní.

Collaboration

Dva týmy společně, intenzivně řeší problém. Sdílejí backlog, plánují spolu, navzájem si dělají code review. Mód je vysoce produktivní, ale drahý: zdvojuje porady, rozmazává odpovědnost, zvyšuje kognitivní zátěž obou týmů. Proto je výslovně časově omezený.

• Kdy: při objevu nového problému (discovery), při zásadním refaktoringu, při bootstrapu nového BC.
• Kdy ukončit: jakmile je rozhraní jasné, přechází se na X-as-a-Service.
• Mapování na DDD: Partnership / Shared Kernel z Context Mapy.
• Past: trvalá Collaboration → oba týmy jsou fakticky jeden tým a sloučení to jen přizná.

X-as-a-Service

Jeden tým používá službu druhého jako černou skříňku přes stabilní API nebo kontrakt. Konzument nezná interní strukturu ani sprint plán poskytovatele. Má jen SLA, dokumentaci a release notes. Ve zralé organizaci je to výchozí stav většiny vztahů mezi týmy.

• Mapování na DDD: Customer/Supplier nebo Open Host Service z Context Mapy.
• Měření: SLA, error rate, dostupnost API, breaking-change rate.
• Cíl: minimální komunikace nutná k používání služby. Žádný společný stand-up.
• Past: X-as-a-Service vyžaduje vyspělé API a verzování. Poskytovatel, který mění API každý sprint, provozuje faktickou Collaboration s falešnou nálepkou.

Facilitating

Enabling team pomáhá stream-aligned týmu osvojit si nové know-how. Mód trvá týdny až měsíce, s koncem dohodnutým na začátku. Probíhá interaktivně: pair programming, code review, workshopy. Cíl: stream-aligned tým to bude umět sám. Pak Enabling team odejde k jinému stream-aligned týmu.

Facilitating nemá přímý ekvivalent v Context Mapě, která řeší vztahy mezi BC, ne dovednosti uvnitř BC. Pozor na časový limit: Facilitating, který trvá rok a déle, se z definice mění v Center of Excellence.

Mapování na Context Map má hranice

Překryv mezi interakčními módy a vzory z Context Mapy je užitečná zkratka, ne rovnítko. Alberto Brandolini [5] rozdíl formuluje takto: Team Topologies popisují žádoucí cílový stav, zatímco Context Mapping nabízí jemnější vzory pro posouzení stavu současného. Context Map proto umí pojmenovat i patologie jako Big Ball of Mud nebo nechtěný Conformist, pro které v Team Topologies žádný mód neexistuje.

Mód také není trvalý štítek. Collaboration při bootstrapu nového BC má přejít v X-as-a-Service, jakmile je rozhraní stabilní. Pohyb opačným směrem, z X-as-a-Service zpět do Collaboration, signalizuje, že hranice mezi kontexty nesedí.

05.05 Inverse Conway Maneuver#

Conway's Law říká „struktura kopíruje organizaci“. Inverse Conway Maneuver obrací směr: kdo chce jinou strukturu, musí nejdřív změnit organizaci. Conway's Law se tím z překážky stává nástrojem.

Termín Inverse Conway Maneuver zavedli konzultanti ThoughtWorks Jonny LeRoy a Matt Simons v článku pro Cutter IT Journal (prosinec 2010); Skelton a Pais (2019, kap. 2) ho rozpracovali s odkazem na výzkum Forsgren, Humble a Kim v Accelerate (2018). Postup lze shrnout do 4 kroků:

1. Definovat cílovou architekturu. Typicky Context Map z DDD, tedy seznam Bounded Contexts a vztahů mezi nimi. Bez tohoto kroku není co kopírovat. Detail v kapitole o Context Mappingu.

2. Spočítat počet stream-aligned týmů. Hrubé pravidlo: 1 BC = 1 tým. Šest BC znamená šest stream-aligned týmů. Při současných třech týmech (frontend, backend, DBA) z toho plyne reorganizace na šest vertikálních týmů, z existujících lidí nebo náborem.

3. Reorganizace: rozpustit horizontální týmy, poskládat vertikální stream-aligned týmy. Na tomto kroku manévr obvykle selže. Frontendoví lidé nechtějí být „v Catalog týmu“, chtějí sedět s ostatními frontendisty. Manažeři nechtějí vyměnit tým 12 lidí za tým 7 lidí. Tato fáze potřebuje silnou podporu CTO/VP Engineering.

4. Vyřešit platformu. Vznikne typicky z bývalých „infrastructure“ lidí a 1–2 seniorů z každého stream-aligned týmu. Rozsah se odvozuje od potřeby (Thinnest Viable Platform), ne od počtu vývojářů. Cíl: do 6 měsíců self-service, ne dokonalý IDP.

Skelton a Pais výslovně varují: Inverse Conway Maneuver bez podpory managementu neuspěje. Reorganizace je politický akt. Když CTO řekne „udělejte to, ale beze změny org chartu“, čeká vás 6 měsíců práce, která nikam nevede. Conway's Law pak při každém refaktoru vrátí architekturu k původní komunikační struktuře.

Praktická past: reorganizace bolí. Lidé ztrácejí senioritu, manažeři pravomoci a zaběhnuté zvyky týmů (frontendový kávovar, backendový stand-up) se rozbijí. Team lead, který zvažuje Inverse Conway Maneuver bez výslovného zadání od CTO, si ho nejdřív vyžádá. Komunikaci s managementem rozebírá sekce 05.09.

Kdy Inverse Conway nefunguje

Manévr funguje jako změna směru, ne jako jednorázový zásah. Martin Fowler [6] k němu dodává výhradu: u existujícího systému se zabetonovanou architekturou nepřinese reorganizace okamžitou nápravu. Spíš vznikne nesoulad mezi vývojáři a kódem, který další úpravy brzdí. Fowler proto doporučuje postupovat malými kroky a bedlivě sledovat zpětnou vazbu. Podle něj musí vývoj architektury a reorganizace lidí jít ruku v ruce po celou dobu života firmy.

U existujících systémů jde kritika dál. Komunikační struktura se změní dnem reorganizace, kódová báze ne. Organizace tedy projde obdobím, kdy je měřitelně horší než před zásahem. Týmy se prodírají cizím kódem, lead time se prodlouží a podíl nasazení s incidentem stoupne. Kdo s tímto propadem nepočítá, vyloží po třech měsících čísla jako důkaz neúspěchu a reorganizaci vrátí.

Ke checklistu níže tedy patří ještě jedna otázka, kterou nikdo nerad pokládá nahlas: jak dlouho propad potrvá a kdo ho bude vysvětlovat vedení.

Praktický checklist před spuštěním Inverse Conway Maneuver

Před zahájením reorganizace projděte následující seznam. Odpověď „ne“ na kterýkoli bod znamená, že Inverse Conway je předčasný a zpravidla selže:

1. Existuje kanonická Context Map? Bez ní chybí cílová architektura: krok 1 selhal a kroky 2–4 nemají kam směřovat. Začněte tedy u ní (kapitola o Context Mappingu).

2. Má reorganizace výslovnou podporu CTO / VP Engineering? Reorganizace je politický akt. Bez podpory shora odpor nepřekonáte. Lidé budou hledat výjimky a starou strukturu obnoví neoficiálně.

3. Máte 6 měsíců času? Reorganizace kratší než 6 měsíců typicky nefunguje. Lidé potřebují čas na přesun, na nové domény i na nové vztahy.

4. Existuje plán pro Platform team? Bez self-service platformy se stream-aligned týmy zaseknou na infrastruktuře. Platform team musí mít před reorganizací připravenou alespoň minimální IDP (založení nového BC jedním kliknutím, CI šablona, výchozí observability).

5. Změřili jste DORA metriky před reorganizací? Bez baseline neumíte obhájit úspěch ani odhalit regresi. Stačí čtyři čísla: lead time od commitu do produkce, deployment frequency, change failure rate (podíl nasazení, která způsobí incident) a čas zotavení po nasazení, které něco rozbilo.

6. Má organizace generativní kulturu podle Westruma? V patologické či byrokratické kultuře reorganizace formálně proběhne, ale provozní vztahy se vrátí (sekce 05.09).

7. Je obsazená pozice „topology owner“? Někdo musí reorganizaci vést každý den, typicky staff engineer + manažer. Bez vlastníka se rozplyne v běžných sprintových prioritách.

S odpovědí „ano“ u všech sedmi bodů máte vyšší šanci než průměr.

05.06 Cognitive Load – limit pro velikost týmu/BC#

Pojem kognitivní zátěž (cognitive load) převzali Skelton a Pais z teorie učení Johna Swellera. Ten ji zavedl v roce 1988 studií o řešení problémů; trojici typů, kterou dnes teorie používá, doplnili Sweller, van Merriënboer a Paas až v roce 1998. Na softwarové týmy se dají vztáhnout všechny tři:

• Intrinsic load (vnitřní) – komplexita samotné domény. „Bankovní risk engine“ má vyšší intrinsic load než „katalog produktů“. Odstranit ji nejde; lze ji snížit zaškolením a volbou technologií, nebo rozdělit mezi víc týmů.

• Extraneous load (zbytečná) – zátěž z prostředí, ne z domény: nestabilní CI, špatná dokumentace platformy, 5 různých deploy procesů, chaos ve Slack kanálech. Odstranit ji je úkol Platform teamu.

• Germane load (rozvojová) – energie, kterou tým vkládá do učení a zlepšování. O tu jde. Když tým přetíží intrinsic a extraneous zátěž, germane zmizí a do zlepšování už nikdo neinvestuje.

Cíl podle Skeltona a Paise: intrinsic zátěž minimalizovat, extraneous odstranit a uvolněný prostor nechat germane. Tým, který tráví 80 % energie zápasem s CI a deploy procesem, nemá kapacitu zlepšovat doménový model.

Jak zátěž měří sami autoři

Skelton a Pais přiznávají, že přesná míra kognitivní zátěže neexistuje. Nabízejí místo ní dvě věci. První je jediná otázka položená týmu: „Do you feel like you are effective and able to respond in a timely fashion to the work you are asked to do?“

Druhá je relativní odhad podle složitosti domén. Domény se roztřídí na simple, complicated a complex a pak platí několik heuristik. Každá doména patří jedinému týmu. Je-li doména na tým velká, dělí se doména, ne odpovědnost za ni. Jeden tým unese dvě až tři simple domény. Tým s complex doménou nedostane nic dalšího. Dvě complicated domény na jeden tým jsou špatný nápad.

Pro DDD je převod přímočarý: doména se v této úvaze chová jako Bounded Context. Klasifikaci komplexity nabízí kapitola o subdoménách, kandidátní hranice pak workshop popsaný v kapitole o Event Stormingu.

Pravidlo cognitive load pro počet BC na tým

Následující tabulka je autorské zobecnění této kapitoly, v Team Topologies takto není. Počítá kontexty místo domén a přidává druhý rozměr, velikost týmu:

Jak změřit cognitive load (jednoduchá rubrika)

Rubrika níže je nástroj této knihy, ne nástroj z Team Topologies. Autoři publikují šablonu Team Cognitive Load Assessment pod CC BY-SA, její veřejná verze ale znění otázek neobsahuje. Rubrika stojí na téže myšlence: sbírá vnímání členů týmu, ne technická čísla.

Použití je nenáročné: jednou za kvartál 30minutový workshop. Každý člen ohodnotí na škále 1–5 pět oblastí – doménovou a technickou komplexitu (intrinsic), stabilitu platformy a kvalitu dokumentace (extraneous, inverzně) a prostor na učení (germane).

Vysoké body 1+2 znamenají, že tým má intrinsic zátěž pod kontrolou. Vysoké body 3+4, že Platform team funguje a extraneous load je nízký. Vysoký bod 5 ukazuje kapacitu na germane.

Je-li průměr bodu 5 pod 3, tým je v krizovém režimu: žádné nové BC, žádné nové technologie. Nejdřív stabilizovat extraneous load.

Šablonu stačí vložit do docs/cognitive-load.md v repozitáři týmu. Vejde se na stránku A4 a slouží jako vstup pro retrospektivu:

1# Cognitive Load Rubric – Q?/YYYY2 3Tým: <název týmu>4Bounded Contexts ve vlastnictví: <seznam BC>5Velikost týmu: <N> lidí6Datum měření: YYYY-MM-DD7 8## 1. Doménová komplexita (intrinsic)9Otázka: „Rozumím kompletně doméně, kterou náš tým vlastní?“10Skóre 1–5: __11Komentář: ____________________________________________12 13## 2. Technická komplexita (intrinsic)14Otázka: „Rozumím všem technologiím, které používáme (jazyk, framework, DB, broker)?“15Skóre 1–5: __16Komentář: ____________________________________________17 18## 3. Stabilita platformy (extraneous, inverze)19Otázka: „Můžu se spolehnout na CI/CD, observability, deploy bez ad hoc oprav?“20Skóre 1–5: __ (5 = stabilní, 1 = každý deploy je dobrodružství)21Komentář: ____________________________________________22 23## 4. Kvalita dokumentace (extraneous, inverze)24Otázka: „Najdu v interní dokumentaci potřebné info do 5 minut?“25Skóre 1–5: __26Komentář: ____________________________________________27 28## 5. Prostor na učení (germane)29Otázka: „Mám každý sprint alespoň 2 hodiny na zlepšení / learning / refaktoring?“30Skóre 1–5: __31Komentář: ____________________________________________32 33## Vyhodnocení (vyplní team-lead po sběru od všech členů týmu)34 35Průměr 1+2 (intrinsic kapacita): __36Průměr 3+4 (extraneous tlak):    __37Bod 5 (germane prostor):         __38 39## Akce na další kvartál40 41- [ ] Pokud bod 5 < 3 → zastavit přírůstek BC.42- [ ] Pokud body 3+4 < 3 → eskalovat na Platform team (extraneous load).43- [ ] Pokud body 1+2 < 3 → zvážit rozdělení BC nebo přidání člena týmu.44- [ ] Pokud > 4 BC ve vlastnictví → naplánovat rozdělení do 2 kvartálů.

Rubrika záměrně měří vnímání členů týmu. Kognitivní zátěž je psychologická kategorie a tvrdá metrika z Grafany ji nezachytí. Skelton a Pais (2019, kap. 3 „Team-First Thinking“) jdou dál: snahu určit kognitivní zátěž softwaru z jednoduchých měr, jako je počet řádků kódu, modulů, tříd nebo metod, označují doslova za misguided. Jazyky se podle nich liší v upovídanosti, takže počty řádků v polyglotním systému nejsou srovnatelné. Rozhoduje, kolik kognitivní kapacity má tým na efektivní změny systému, ne jak velký systém je.

05.07 Praktické scénáře (5 / 20 / 200+ lidí)#

Team Topologies nepředepisují zavést hned všechny čtyři typy týmů a tři módy. Slouží jako jazyk pro popis současného stavu a cíle. Konkrétní podoba závisí na velikosti organizace.

Scénář A – Startup, 5 lidí, 1 produkt

Doporučení: 1 stream-aligned tým, 2–3 malé BC v jednom monolitu (modulární monolit). Žádný Platform team, žádný Enabling team.

• Architektura: jeden Symfony monolit; BC jsou složky/moduly s explicitními rozhraními (kapitola DDD a microservices).
• Generic subdomény: nakoupit jako SaaS, žádná vlastní implementace. Argumenty a sourcing strategii build/buy rozebírá kapitola o subdoménách.
• Hosting: Upsun (dříve Platform.sh), Heroku, Railway, Fly.io. Managed services nahrazují Platform team.
• Čeho se vyvarovat: Kubernetes, vlastní observability stack, microservices. Na to je brzy.

Chyba startupů: kopírovat enterprise architekturu, „aby to bylo připravené na budoucnost“. Pětičlenný tým nemá kognitivní kapacitu na 6 microservices.

Scénář B – Scale-up, 20 lidí, 1 produkt s rostoucí komplexitou

Doporučení: 2–3 stream-aligned týmy podle BC + 1 mini-Platform team (3–5 lidí) na CI/CD a observability. Žádný permanentní Enabling team.

• Stream-aligned týmy: rozdělené podle hlavních value streamů. Např. Catalog tým (5 lidí), Ordering tým (6 lidí), Billing tým (4 lidi, sdílí 2 supporting BC: Billing a Warehouse). Identita je Generic: běží na externím IdP a tenký bridge k němu udržuje Platform team.
• Platform team: 4 lidi, vlastní CI pipeline šablonu, K8s cluster, Grafana/Sentry, šablonu pro nový BC. Self-service.
• Enabling team: ne na trvalo. Zavedení CQRS pokryje externí konzultant na 3 měsíce.
• Interakční módy: Stream-aligned týmy mezi sebou X-as-a-Service. Platform team se všemi v X-as-a-Service. Příležitostná Collaboration při bootstrapu nového BC.

Tato fáze je nejrizikovější. Organizace už není malá, ale na plný rozsah Team Topologies ještě nemá kapacitu. Klasická chyba: vznikne Center of Excellence („architektonický výbor“) a stane se úzkým hrdlem.

Scénář C – Enterprise, 200+ lidí, 10+ BC

Doporučení: plná Team Topologies struktura.

• 15–25 stream-aligned týmů po 6–9 lidech, každý vlastní 1 BC (případně 2 související supporting BC).
• 1–2 Platform teamy – typicky 1 hlavní (IDP, K8s, observability) + někdy specializovaný (data platform, ML platform).
• 1–3 Enabling teamy – rotující, time-boxed, podle aktuálních potřeb (např. „security enabling team“ na 6 měsíců, „event sourcing enabling team“ na 3 měsíce).
• 1–2 Complicated-subsystem teamy – jen pro objektivně specializované domény (např. risk engine v bance, video transcoder v médiích, ML scoring v ad-techu).
• Topology design: v této velikosti se osvědčuje malý topology team (1–2 lidi, není to Center of Excellence). Sleduje kognitivní zátěž týmů a navrhuje reorganizace. Často je to staff engineer + manažer.

I ve dvousetčlenné firmě mají stream-aligned týmy výrazně převažovat, orientačně tři čtvrtiny lidí. Připadá-li ze 200 lidí 100 na Platform/Enabling/CoE týmy a architekty, máte problém. Doménovou hodnotu nesou stream-aligned týmy, ostatní ji jen násobí.

05.08 Anti-vzory#

Následujících pět anti-vzorů patří v praxi k nejčastějším a nejdražším. Detailní katalog DDD anti-vzorů je v samostatné kapitole o anti-vzorech.

1. „Sdílíme jedno monorepo bez hranic modulů“

Více týmů commituje do jednoho repozitáře bez jasných hranic mezi moduly. Každá netriviální změna jednoho týmu pak vyžaduje code review od ostatních („jen abychom se ujistili, že to nic nerozbije“). Druhý tým má fakticky veto na změny prvního.

Řešení: hranice modulů vynucené v CI, ne dohodou na retru. V PHP na to slouží Deptrac nebo PHPArkitect: build pull requestu, který sáhne z modulu jednoho týmu do modulu druhého, spadne. Konkrétní pravidla ukazuje kapitola DDD a microservices. K tomu vlastnictví zapsané v CODEOWNERS. Alternativou jsou separátní repa pro každý BC. Princip „všichni do jednoho repa, nějak se domluvíme“ nefunguje.

2. „Frontend / Backend / Mobile týmy“

Klasický anti-vzor přímo z Conway's Law: týmy rozdělené po vrstvách. Každá nová funkce vyžaduje koordinaci 3 týmů, 3 sprintů, 3 retrospektiv. Úprava na zhruba 3 dny práce má lead time přes 6 týdnů.

Řešení: Inverse Conway Maneuver. Rozpustit horizontální týmy a poskládat vertikální stream-aligned týmy. Každý tým má všechny potřebné role (frontend dev + backend dev + mobile dev + QA + designer). Je-li mobilní aplikace zásadní částí produktu, ne vedlejším kanálem, patří mobilní vývojáři do stream-aligned týmů, ne do separátního „mobile týmu“.

Výjimka: při jednom či dvou mobilních vývojářích na celou organizaci se hodí dočasná „mobile guild“ – ne jako tým s vlastním backlogem, ale jako komunita pro sdílení znalostí.

3. „Center of Excellence“ místo Enabling teamu

Permanentní útvar „architektů“ / „expertů“ / „vedoucího týmu“, který drží schvalovací pravomoc nad ostatními. Typická korporátní podoba: ARB (Architecture Review Board), který musí každou novou službu schválit.

Co je špatně: CoE typicky funguje jako kontrolní bod, ne jako expertní podpora. Schvalování ze své podstaty zpomaluje, vytváří frontu a zbavuje stream-aligned týmy odpovědnosti („to nám neschválili, nemůžeme za to“).

Řešení: CoE → Enabling team. Časově omezená spolupráce, mentoring místo schvalování, rozpuštění po předání. Je-li „schvalování“ nutné, dělá ho stream-aligned tým sám podle dokumentovaných standardů, ne externí výbor.

4. „Platform team jako gatekeeper / ticketová fronta“

Platform team funguje jako infrastrukturní ticket support. Stream-aligned tým potřebuje nový Postgres, vytvoří JIRA ticket a čeká 5 dnů. Potřebuje upravit CI pipeline, vytvoří ticket a čeká týden. Z Platform teamu se stalo úzké hrdlo celé organizace.

Řešení: Platform team musí dodávat self-service rozhraní (CLI, portál, IaC moduly). Když stream-aligned tým musí zadávat tickety, jde o chybu návrhu platformy, ne zadávajícího týmu.

Hlavní metrika: time-to-first-deploy pro nový BC. Ve zdravé organizaci pod 1 den. V nezdravé „ozkoušíme to za měsíc, jakmile bude mít Platform team kapacitu“.

5. „Sdílený Bounded Context mezi 2 týmy“

Dva stream-aligned týmy commitují do stejného Bounded Contextu, protože „to dává smysl“. Conway's Law zareaguje okamžitě. Vznikne neformální vnitřní hranice, čára „naše/vaše“ v kódu, ale bez formální Context Mapy. Čára ztvrdne a po půl roce je z ní Big Ball of Mud se dvěma vlastníky.

Řešení: rozdělit BC na 2 menší BC se Shared Kernelem (drahý, viz Context Mapping) nebo vztahem Customer/Supplier. Případně sloučit 2 týmy do 1 většího, pokud doména nejde rozdělit.

05.09 Komunikace s managementem – jak prodat reorganizaci#

Inverse Conway Maneuver je hluboká organizační změna: týmy se dělí, manažeři se přeřazují a lidé možná přijdou o senioritu nebo „svůj koutek“. Bez podpory managementu (CTO, VP Engineering, People Ops) neuspěje.

S managementem se mluví jeho jazykem, ne jazykem DDD. „Přesnější doménový model“ nebo „jasněji ohraničené Bounded Contexts“ manažeři neocení, metriky ano.

Argumenty, které fungují (DORA metriky)

Nicole Forsgren, Jez Humble a Gene Kim v knize Accelerate (2018) [7] zveřejnili 4 metriky (DORA). Měří efektivitu doručování softwaru a silně korelují s obchodními výsledky (zisk, růst, spokojenost zákazníků).

Sada se od roku 2018 posunula [8]. V roce 2023 se MTTR přejmenovala na failed deployment recovery time a změnila se i definice: metrika měří zotavení po selhání, které způsobila změna v produkci, ne po libovolném výpadku. V roce 2024 přibyla pátá metrika. Aktuální podoba:

• Change lead time – čas od commitu do produkce. Stream-aligned týmy: hodiny. Horizontální týmy: dny až týdny.
• Deployment frequency – jak často se nasazuje. Stream-aligned: víckrát denně. Horizontální: 1× za sprint.
• Failed deployment recovery time – čas zotavení po nasazení, které něco rozbilo. V Accelerate ještě pod historickým názvem MTTR.
• Change failure rate – podíl nasazení, která způsobí incident.
• Deployment rework rate – podíl neplánovaných nasazení vyvolaných incidentem.

První tři metriky popisují průtok, poslední dvě nestabilitu. Na ročníku sady tolik nezáleží. Podstatné je měřit stejně definovaná čísla dvakrát: před reorganizací a šest měsíců po ní. O kolik se čísla posunou, dopředu neví nikdo. Slíbit CTO konkrétní procento zlepšení znamená vyrobit si za půl roku problém. Slíbit lze baseline, termín druhého měření a rozhodnutí podle výsledku.

Argumenty, které nefungují

• „Eric Evans by to chtěl.“ Manažer v DDD komunitě není.
• „Je to elegantnější“ – eleganci nikdo neměří.
• „Bounded Contexts jsou kanonické.“ Kanoničnost manažera nezajímá.
• „Zlepší se to“, jenže bez metriky je „zlepší“ prázdné slovo.
• „Skelton a Pais to říkají.“ Autorita sama o sobě nestačí.

Westrumova kultura organizace

Sociolog Ron Westrum v roce 2004 publikoval typologii organizačních kultur [9], kterou později Forsgren v Accelerate použila jako prediktor výkonu doručování softwaru. Westrum rozlišuje 3 typy:

Team Topologies funguje jen v generativní kultuře. V patologické kultuře (manažer trestá za chyby, hierarchie je vše) stream-aligned týmy nedostanou autonomii. Vedení chce mít kontrolní bod, takže se z Platform teamu stane gatekeeper. V byrokratické kultuře (přesné role, formální procesy) reorganizace projde, ale provozní vztahy zůstanou. Conway's Law se vrátí přes formální schvalování.

V patologické nebo byrokratické organizaci proto změna nezačíná Inverse Conway Maneuverem, ale kulturou. Případně změnou pracoviště.

05.10 Shrnutí#

Conway's Law z roku 1968 říká: architektura kopíruje komunikační strukturu organizace. Pro DDD z toho plyne: Bounded Context bez vlastnícího týmu je fikce. Kontexty v Context Mapě, ke kterým neumíte jmenovat tým, jenž je doručuje, neexistují. Jsou jen napsané v dokumentaci.

Team Topologies (Skelton & Pais, 2019) je rámec pro vědomý návrh týmů, který doplňuje DDD tam, kde Vernon a Evans mlčí. Hlavní poznatky:

• 4 typy týmů: Stream-aligned (vlastní BC end-to-end, výchozí), Platform (self-service produkt, ne jeden tým), Enabling (mentoring s dohodnutým koncem spolupráce), Complicated-subsystem (objektivně specializovaná doména).
• 3 interakční módy: Collaboration (drahá, časově omezená), X-as-a-Service (výchozí vyspělý vztah), Facilitating (mentoring time-boxed).
• Vernonova preference: 1 BC = 1 tým; BC sdílený mezi týmy je dočasný stav, ne cílový. Kolik kontextů jeden tým unese, Vernon nečísluje – rozmezí 1–2, výjimečně 3, je autorské zobecnění této knihy.
• Subdomény → typy týmů: Core → stream-aligned (nejlepší tým) / complicated-subsystem; Supporting → stream-aligned (sdílí tým s jiným supporting BC); Generic → SaaS, Platform team integruje.
• Inverse Conway Maneuver: nejdřív definovat cílovou architekturu, pak postavit týmy tak, aby ji přirozeně vyprodukovaly. Bez podpory CTO neuspěje.
• Cognitive load: 1–2 BC (výjimečně 3) na 5–9 lidí. 5+ BC na tým = signál pro rozdělení. Měří se kvartálně.
• Proporce: orientačně 75 % stream-aligned, 15 % platform, 10 % enabling
  • complicated-subsystem (autorské zobecnění, viz 05.07).
• Komunikace s managementem: DORA metriky, ne DDD filozofie. Westrumova generativní kultura je předpoklad, ne výstup.

Bounded Context je závazek konkrétního týmu vyvíjet, nasazovat a v noci opravovat svou část domény. Bez toho závazku zůstává složkou v repu.

K hlubšímu studiu slouží Team Topologies od Skeltona a Paise [3] a kapitoly 2 a 3 z Vernonova Implementing Domain-Driven Design [2]. DORA metriky a Westrumovu typologii rozebírá Accelerate od Nicole Forsgren a kolektivu [7]. Conwayův původní esej z roku 1968 má jen 4 strany a stojí za přečtení [1].

05.11 Další četba a citované zdroje#

Číslování odpovídá odkazům v textu; položky 10–14 jsou doplňková četba.

1. Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(4), 28–31. melconway.com

2. Vernon, V. (2013). Implementing Domain-Driven Design. Addison-Wesley. Kap. 2 (Domains, Subdomains, Bounded Contexts) a kap. 3 (Context Maps). amazon.com

3. Skelton, M. & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press. teamtopologies.com

4. Skelton, M. & Pais, M. (2025). Team Topologies: Organizing business and technology for fast flow of value, 2. vydání. IT Revolution Press. itrevolution.com

5. Brandolini, A. (2021). About Team Topologies and Context Mapping. Avanscoperta Blog. blog.avanscoperta.it

6. Fowler, M. Conway's Law. Bliki – atribuce Inverse Conway Maneuveru a výhrady k jeho účinnosti. martinfowler.com

7. Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. itrevolution.com

8. DORA. A history of DORA's software delivery metrics. Vývoj sady metrik od roku 2018. dora.dev

9. Westrum, R. (2004). A typology of organisational cultures. Quality and Safety in Health Care, 13(suppl_2), ii22–ii27. qualitysafety.bmj.com

10. Yegge, S. (2011). Stevey's Google Platforms Rant. Zdroj podání Bezosova API mandátu z roku 2002. gist.github.com

11. Vernon, V. (2016). Domain-Driven Design Distilled. Addison-Wesley. Kap. 2 (Strategic Design with Bounded Contexts and the Ubiquitous Language).

12. Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.

13. Tune, N. & Perrin, J.-G. (2024). Architecture Modernization: Socio-technical alignment of software, strategy, and structure. Manning. Kombinuje strategický DDD, Event Storming a Team Topologies do jednoho postupu.

14. Související kapitoly: subdomény, context mapping, architektonické styly, anti-vzory.