Conway's Law a Team Topologies

05.01 Conway's Law – gravitační zákon softwarové architektury

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é se později stalo známé jako Conway's Law:

„Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.“

– Melvin E. Conway, 1968

V překladu: jakákoli organizace, která navrhuje systém, vytvoří takový design, jehož struktura kopíruje komunikační strukturu této organizace. Není to architektonická preskripce, ale empirické pozorování. A je vysoce spolehlivé. Oddělený frontend a backend tým? Dostanete oddělený frontend a backend v kódu. Oddělený DBA tým? V kódu se objeví vrstva, která jen obsluhuje databázi. A jeden tým bez sub-hranic vyrobí Big Ball of Mud.

Tři reálné případy Conway's Law v praxi

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“ nevyhnutelně vyprodukuje třívrstvou architekturu. Každý tým má vlastní release cyklus, vlastní CI/CD pipeline, vlastní sprint review. Bounded Context se stane 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 se obtočí přes všechny tři týmy a tři sprinty.

2. Tým rozdělený podle produktu/streamu → mikroservis nebo modul per BC. Stejná organizace přeorganizovaná na „Catalog tým“, „Ordering tým“, „Billing tým“ a „Identity tým“ – každý tým plně end-to-end (frontend, backend, DB, devops) – vyprodukuje 4 mikroservisy nebo 4 izolované moduly v monolitu, jeden per Bounded Context. Conway's Law funguje, jen dostala jiné vstupy.

3. Tým bez interních hranic → Big Ball of Mud. 8 vývojářů, kteří všichni sahají do všeho, nevyprodukují žádné Bounded Contexts. Vyprodukují jeden monolit, ve kterém Customer ve fakturaci je tatáž třída jako Customer v marketingu, jen s víc atributy. Klasický důsledek: po 18 měsících si nikdo netroufne změnit nic, 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 pravidlo, které je možná nejdůležitějším praktickým výstupem celého DDD:

„A Bounded Context should be owned by a single team. The reverse – multiple Bounded Contexts owned by a single team – is sometimes acceptable.“

– Vaughn Vernon, Implementing DDD (2013)

Pravidlo má dvě části, které se často chybně čtou jako jedno:

• Jeden Bounded Context = jeden tým (vždy). Pokud dva týmy sdílejí jeden BC, Conway's Law okamžitě vstoupí – buď vznikne neoficiální sub-hranice (a tedy fakticky dva BC, ale nikdo to nepřiznal), nebo vznikne sdílené vlastnictví, které znamená, že BC nikdo nevlastní a degraduje na Big Ball of Mud se Shared Kernel režií. Pravidlo: nikdy nesdílejte BC mezi týmy bez explicitního Shared Kernel vztahu – a Shared Kernel sám je 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 2–3 menší BC. Důvodem k limitu je kognitivní zátěž – viz sekci 05.06. Velký tým, který by vlastnil 5+ BC, je signál, že tým má být rozdělen.

Důsledek je nepříjemný pro mnoho organizací: 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í). Detail vztahu mezi Context Map a Team Map je v kapitole o Context Mappingu.

A obráceně: při 4 BC a 7 týmech BC nestavěl někdo, kdo používal DDD. Spíš historická organizační struktura, kterou nikdo neaktualizoval. Zde přichází Inverse Conway Maneuver (sekce 05.05).

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

V praxi narazíte na 4 typy nesouladu mezi Context Mapem a Team Mapem. Každý vyžaduje jiný typ akce:

Žádný z těchto scénářů není akutní krize – Conway's Law dává systému dostatek setrvačnosti, aby s nesouladem fungoval měsíce. Ale dlouhodobě se nesoulad projeví v rostoucích lead time, rostoucí change failure rate a klesající morálce týmů. Nesoulad je pomalý jed, ne explozivní porucha.

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é systematicky popsali, jaké typy týmů má organizace mít a jak mezi sebou mají komunikovat. Team Topologies dodává slovník pro organizační návrh, nepředepisuje proces jako SAFe nebo LeSS. A pro DDD je to chybějící doplněk Vernona.

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

Stream-aligned team

Vlastník end-to-end value streamu – typicky jeden Bounded Context. Stream-aligned tým má všechny role pro samostatné doručení hodnoty koncovému uživateli: vývojáře (frontend i backend), QA, designéra, někdy product ownera. Tým rozhoduje, doručuje a provozuje v produkci – žádné „předání“ do jiného týmu.

• Velikost: 5–9 lidí (Two-Pizza Rule).
• 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 (lead time, deployment frequency, change failure rate, MTTR).

Většina týmů v každé zdravé technologické organizaci jsou stream-aligned týmy. Při 10 týmech a méně než 7 stream-aligned se podíváme na anti-vzory v sekci 05.08.

Platform team

Poskytuje self-service platformu pro stream-aligned týmy. Platform team vlastní 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.

Hlavní atribut Platform teamu je slovo self-service. Stream-aligned tým si na platformu nezadává ticket („potřebuju nový Postgres“) a nečeká týden. Naklikne ho sám přes portál nebo nasadí přes IaC modul, který Platform team udržuje. Platform team, který funguje jako ticketová fronta, se mění v úzké hrdlo infrastruktury – anti-vzor v sekci 05.08.

• Velikost: 1 Platform team na 50–150 vývojářů; obvykle 5–9 lidí.
• Měření: NPS od stream-aligned týmů, adoption rate, time-to-first-deploy pro nový BC.
• Anti-charakter: Platform team nesedí na změnách – má roli enabler, ne gatekeeper.

Enabling team

Time-boxed 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“. Enabling team se po předání rozpustí, typicky po 3–6 měsících. Žádný permanentní útvar.

Enabling team se často zamění s Center of Excellence. Rozdíl je podstatný:

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 drží vysokou koncentraci specializovaných znalostí (PhD v matematice, fyzice nebo CS, hluboké know-how v doméně), které nelze 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í. To není důvod – pravým důvodem je objektivní specializace.

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

Klasifikace subdomén z kapitoly o subdoménách (Core / Supporting / Generic) přirozeně mapuje na typy týmů:

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

Skelton a Pais nedefinovali jen typy týmů, ale 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“) = neformální vztah. Conway's Law ho okamžitě začne tvarovat ad hoc interfacem v kódu.

Collaboration

Dva týmy společně, intenzivně řeší problém. Sdílí backlog, plánují spolu, code-review napříč. Mód je vysoce produktivní, ale drahý – duplikuje meetingy, rozmazává odpovědnost, zatěžuje cognitive load obou týmů. Proto je explicitně č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 interface jasný – přejít na X-as-a-Service.
• Mapování na DDD: Partnership / Shared Kernel z Context Mapu.
• Past: permanentní Collaboration → tyto dva týmy mají být jeden tým. Spojte je.

X-as-a-Service

Jeden tým konzumuje druhý jako černou skříňku přes stabilní API/kontrakt. Konzument nezná ani interní strukturu, ani sprint plan poskytovatele. Má pouze SLA, dokumentaci a release notes. Toto je výchozí stav většiny mezi-týmových vztahů ve zralé organizaci.

• Mapování na DDD: Customer / Supplier nebo Open Host Service z Context Mapu.
• Měření: SLA, error rate, dostupnost API, breaking-change rate.
• Cíl: minimální komunikace nutná k používání služby. Žádný stand-up napříč týmy.
• Past: X-as-a-Service vyžaduje vyspělé API a versionování – pokud poskytovatel mění API každý sprint, je to faktická Collaboration s falešnou nálepkou.

Facilitating

Enabling team pomáhá stream-aligned týmu osvojit si nové know-how. Mód je dočasný (3–6 měsíců) a interaktivní (pair programming, code review, workshopy). Cíl: stream-aligned tým to bude umět sám. Po dosažení cíle Enabling team odejde k jinému stream-aligned týmu.

• Mapování na DDD: nemá přímý ekvivalent v Context Mapu (Context Map řeší vztahy mezi BC, ne dovednosti uvnitř BC).
• Cíl: autonomie stream-aligned týmu po předání.
• Past: Facilitating, který trvá rok+, se z definice mění na Center of Excellence.

05.05 Inverse Conway Maneuver

Conway's Law říká „struktura kopíruje organizaci“. Inverse Conway Maneuver obrací směr: pokud chceme jinou strukturu, MUSÍME nejdřív změnit organizaci. Místo bojování s Conway's Law ji použijeme jako nástroj.

Inverse Conway Maneuver popsali Skelton a Pais (2019, kap. 2) jako 4-krokový postup, navazující na výzkum Forsgren, Humble a Kim v Accelerate (2018):

1. Definovat cílovou architekturu. Typicky Context Map z DDD – 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. Pokud máte 6 BC, potřebujete 6 stream-aligned týmů. Pokud máte aktuálně 3 týmy (frontend, backend, DBA), znamená to reorganizaci na 6 vertikálních týmů – buď z existujících lidí, nebo nábor.

3. Re-org: rozpustit horizontální týmy, poskládat vertikální stream-aligned týmy. Klasický bod, kde implementace selže. Frontendoví lidé nechtějí být „v Catalog týmu“ – chtějí být s ostatními frontend kolegy. Manažeři nechtějí ztratit tým 12 lidí pro tým 7 lidí. Tato fáze potřebuje silnou podporu CTO/VP Engineering.

4. Vyřešit Platform team. Z definice 1 Platform team na celou organizaci (50–150 vývojářů). Vznikne typicky z bývalých „infrastructure“ lidí + 1–2 senior z každého stream-aligned týmu. Cíl: do 6 měsíců self-service IDP.

Skelton a Pais výslovně varují: Inverse Conway Maneuver bez podpory managementu neuspěje. Re-org je politický akt. Pokud CTO řekne „udělejte to, ale beze změny org chartu“, máte před sebou 6 měsíců práce, která nikam nevede. Conway's Law původní org chart vrátí každý refaktor.

Praktická past: reorganizace je bolestivá. Lidé ztrácejí seniority, manažeři ztrácejí pravomoci, domácí kultury týmů (frontend kávovar, backend stand-up) se rozbijí. Pokud jste team-lead a zvažujete Inverse Conway Maneuver bez výslovného zadání od CTO, raději se nejdřív zeptejte. Detail komunikace s managementem je v sekci 05.09.

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

Než zahájíte reorganizaci, projděte následující seznam. Pokud na kterýkoli bod odpovíte „ne“, Inverse Conway je předčasný a v 90 % případů selže:

1. Existuje kanonická Context Map? Bez ní není definovaná cílová architektura. Krok 1 selhal a kroky 2–4 nemají kam směřovat. Pokud nemáte Context Map, začněte tam (kapitola o Context Mappingu).

2. Má reorganizace výslovnou podporu CTO / VP Engineering? Reorganizace je politický akt. Bez podpory shora není odpor odolatelný – lidé budou hledat výjimky a starou strukturu obnoví neoficiálně.

3. Máte 6 měsíců času? Reorganizace pod 6 měsíců typicky nefunguje. Lidé potřebují čas se přesunout, naučit se nové domény, vybudovat 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 alespoň minimum-viable IDP připravený před reorganizací (1-click new-BC bootstrap, CI šablona, výchozí observability).

5. Změřili jste DORA metriky před reorganizací? Bez baseline neumíte obhájit úspěch ani identifikovat regresi. Jednoduché měření: lead time z PR-merge do produkce, deployment frequency, change failure rate (% deploy s rollbackem), MTTR (medián času na vyřešení P1 incidentu).

6. Je organizace v Westrum generative kultuře? V pathological / bureaucratic reorganizace formálně proběhne, ale operativní vztahy se vrátí (sekce 05.09).

7. Je obsazená pozice „topology owner“? Někdo musí reorganizaci vést na denní bázi – typicky staff engineer + manažer. Bez vlastníka se reorganizace rozplyne do běžných sprint priorit.

Pokud máte všech 7 bodů „ano“, máte vyšší šanci než průměr. Zbývá jen práce.

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 (1988). Sweller rozlišuje 3 typy zátěže, které se vážou i na softwarové týmy:

• Intrinsic load (přirozená) – komplexita samotné domény. „Bankovní risk engine“ má vyšší intrinsic load než „katalog produktů“. Toto se nedá snížit, jen 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 v Slack kanálech. Toto je úkol Platform teamu odstranit.

• Germane load (rozvojová) – energie, kterou tým vkládá do učení a zlepšování. Toto má být pozitivní – pokud má tým přetížený intrinsic + extraneous, germane mizí (tým přestane investovat do zlepšení).

Cíl: maximalizovat intrinsic + germane, minimalizovat extraneous. Tým, který tráví 80 % energie zápasem s CI a deploy procesem, nemá kapacitu zlepšovat doménový model.

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

Skelton a Pais doporučují praktickou heuristiku:

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

Skelton a Pais doporučují jednou za kvartál spustit s týmem 30-minutový workshop, kde každý člen ohodnotí na škále 1–5 následující:

1. Doménová komplexita (intrinsic) – „Rozumím kompletně doméně, kterou náš tým vlastní?“
2. Technická komplexita (intrinsic) – „Rozumím všem technologiím, které používáme?“
3. Stabilita platformy (extraneous, inverze) – „Můžu se spolehnout na CI/CD, observability, deploy?“
4. Kvalita dokumentace (extraneous, inverze) – „Najdu potřebné info do 5 minut?“
5. Prostor na učení (germane) – „Mám každý sprint 1–2 hodiny na zlepšení/learning?“

Body 1+2 vysoké = tým má pod kontrolou intrinsic. Body 3+4 vysoké = Platform team funguje a extraneous load je nízký. Bod 5 vysoký = tým má kapacitu na germane.

Pokud je 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.

Níže je rubrika ve formátu, který stačí vlepit do docs/cognitive-load.md v repu týmu. Vejde se na 1 stránku A4, vyplní se za 30 minut na konci sprintu a je dobrým vstupem pro retro:

# Cognitive Load Rubric – Q?/YYYY

Tým: <název týmu>
Bounded Contexts ve vlastnictví: <seznam BC>
Velikost týmu: <N> lidí
Datum měření: YYYY-MM-DD

## 1. Doménová komplexita (intrinsic)
Otázka: „Rozumím kompletně doméně, kterou náš tým vlastní?“
Skóre 1–5: __
Komentář: ____________________________________________

## 2. Technická komplexita (intrinsic)
Otázka: „Rozumím všem technologiím, které používáme (jazyk, framework, DB, broker)?“
Skóre 1–5: __
Komentář: ____________________________________________

## 3. Stabilita platformy (extraneous, inverze)
Otázka: „Můžu se spolehnout na CI/CD, observability, deploy bez ad hoc oprav?“
Skóre 1–5: __ (5 = stabilní, 1 = každý deploy je dobrodružství)
Komentář: ____________________________________________

## 4. Kvalita dokumentace (extraneous, inverze)
Otázka: „Najdu v interní dokumentaci potřebné info do 5 minut?“
Skóre 1–5: __
Komentář: ____________________________________________

## 5. Prostor na učení (germane)
Otázka: „Mám každý sprint alespoň 2 hodiny na zlepšení / learning / refaktoring?“
Skóre 1–5: __
Komentář: ____________________________________________

## Vyhodnocení (vyplní team-lead po sběru od všech členů týmu)

Průměr 1+2 (intrinsic kapacita): __
Průměr 3+4 (extraneous tlak):    __
Bod 5 (germane prostor):         __

## Akce na další kvartál

- [ ] Pokud bod 5 < 3 → zastavit přírůstek BC.
- [ ] Pokud body 3+4 < 3 → eskalovat na Platform team (extraneous load).
- [ ] Pokud body 1+2 < 3 → zvážit rozdělení BC nebo přidání člena týmu.
- [ ] Pokud > 4 BC ve vlastnictví → naplánovat rozdělení do 2 kvartálů.

Rubrika záměrně měří vnímání členů týmu; tvrdá metrika z Grafany cognitive load nezachytí. Důvod: cognitive load je psychologická kategorie, žádná metrika z Grafany ji nezachytí. Skelton a Pais (2019, kap. 3 „Team-First Thinking“) výslovně varují před snahou cognitive load „objektivizovat“ přes počet řádků kódu, count of services, nebo ticket throughput. Tyto proxy metriky nemají korelaci s tím, jak se tým reálně cítí.

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

Team Topologies není doktrína „udělejte všech 4 typy týmů a 3 módy hned“. Je to jazyk, kterým se popisuje aktuální stav a cíl. 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 o architektonických stylech).
• Generic subdomény: SaaS – Auth0 nebo Clerk pro identity, Stripe pro fakturaci, SendGrid pro e-mail. Žádná vlastní implementace.
• Hosting: Heroku, Vercel, Railway, Fly.io – managed services nahrazují Platform team.
• Čeho se vyvarovat: nepouštět se do Kubernetes, vlastní observability stack, mikroservisy. Předčasné.

Chyba startupů: kopírovat enterprise architekturu „aby to bylo připraveno na budoucnost“. Cognitive load 5-členného týmu nemá kapacitu na 6 mikroservisů. Modulární monolit je správná volba.

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í), Identity+Billing tým (4 lidi, sdílí 2 supporting BC).
• Platform team: 4 lidi, vlastní CI pipeline šablonu, K8s cluster, Grafana/Sentry, šablonu pro nový BC. Self-service.
• Enabling team: ne na trvalo. Pokud potřebujete zavést CQRS, najměte si externího konzultanta 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 ještě nemá kapacitu na plný rozsah Team Topologies. Klasická chyba: vznikne Center of Excellence („architektonický výbor“), který se stane bottleneckem.

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

Doporučení: plná Team Topologies struktura.

• 10–15 stream-aligned týmů, 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: Skelton a Pais doporučují, aby v této velikosti existoval malý topology team (1–2 lidi, není to Center of Excellence). Sleduje cognitive load týmů a navrhuje reorganizace. Často je to staff engineer + manažer.

Důležité: i v 200-členné firmě by mělo být aspoň 75 % lidí ve stream-aligned týmech. Pokud máte 200 lidí a 100 z nich je v Platform/Enabling/CoE/architekti, máte problém – stream-aligned týmy nesou doménovou hodnotu, ostatní jsou multiplikátory. Multiplikátorů nemá být víc než multiplicandů.

05.08 Anti-vzory

Než se dostaneme k tomu, jak to udělat, je užitečné vědět, jak to nedělat. Následujících pět anti-vzorů je ze zkušenosti autorů Team Topologies nejčastějších a nejdražších. Detailní katalog DDD anti-vzorů je v samostatné kapitole o anti-vzorech.

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

Více týmů commituje do jednoho repozitáře bez jasných hranic mezi moduly. Důsledek: každá netriviální změna jednoho týmu 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í: buď jasné hranice modulů v monorepu (Nx, Bazel, Turborepo pro JS, Symfony Bundles pro Symfony) s explicitním ownership v CODEOWNERS, nebo separátní repa per BC. Nikdy ne princip „všichni do jednoho repa, nějak se domluvíme“.

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. Lead time přes 6 týdnů na úpravu, která si vyžádá zhruba 3 dny práce.

Ř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). Pokud je mobile aplikace zásadní část produktu, ne vedlejší kanál, mobile vývojáři patří do stream-aligned týmů, ne do separátního „mobile týmu“.

Výjimka: při jediném mobilním vývojáři na celou organizaci má dočasná „mobile guild“ smysl. Ne jako tým s vlastním backlog, 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. Klasická corporate inkarnace: ARB (Architecture Review Board), který musí každou novou službu schválit.

Co je špatně: CoE typicky drží kontrolní bod, ne expertní podporu. 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. Time-boxed, mentoring místo schvalování, rozpuštění po předání. Pokud je „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, který funguje jako infrastructure ticket support: stream-aligned tým potřebuje nový Postgres, vytvoří JIRA ticket, čeká 5 dnů. Potřebuje upravit CI pipeline, vytvoří ticket, čeká týden. Reálně se z Platform teamu stalo úzké hrdlo pro celou organizaci.

Řešení: Platform team má povinnost dodávat self-service rozhraní (CLI, portál, IaC moduly). Pokud stream-aligned tým musí zadávat tikety, je to chyba designu platformy, ne chyba zadávajícího týmu.

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

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

Dva stream-aligned týmy oba commitují do stejného Bounded Contextu, protože „to dává smysl“. Conway's Law okamžitě reaguje – vznikne neformální sub-hranice (čára „naše/vaše“ v kódu), ale bez formální Context Map. Tato čára se petrifikuje a po 6 měsících je z toho de facto Big Ball of Mud s dvěma vlastníky.

Řešení: rozdělit BC na 2 menší BC se Shared Kernel (drahý, viz Context Mapping) nebo Customer/Supplier vztahem. 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 bude třeba rozdělit, manažery přealokovat, lidé možná ztratí senioritu nebo „svůj koutek“. Bez pochopení a podpory managementu (CTO / VP Engineering / People Ops) Inverse Conway selže. Reorganizace bez podpory shora se v praxi neudělá vůbec.

Podstatné je mluvit jazykem, kterému management rozumí – ne jazykem DDD. Manažeři neumí ocenit „přesnější doménový model“ nebo „jasněji ohraničené Bounded Contexts“. Umí ocenit metriky.

Argumenty, které fungují (DORA metriky)

Nicole Forsgren, Jez Humble a Gene Kim v knize Accelerate (2018) [4] zveřejnili 4 metriky (DORA). Ty měří efektivitu doručování softwaru a silně korelují s obchodními výsledky (zisk, růst, customer satisfaction):

• Lead time for changes – čas od commitu do produkce. Stream-aligned týmy: hodiny. Horizontální týmy: dny–týdny.
• Deployment frequency – kolikrát za den/týden deploy. Stream-aligned: víckrát denně. Horizontální: 1× za sprint.
• Change failure rate – % deploymentů, které způsobí incident. Stream-aligned: pod 15 %. Horizontální: 30–60 %.
• Mean time to restore (MTTR) – čas zotavení z incidentu. Stream-aligned: hodina. Horizontální: dny.

Před reorganizací změřte 4 DORA metriky. Po reorganizaci změřte znovu po 6 měsících. Pokud Inverse Conway funguje, lead time se zkrátí o 30–80 %, change failure rate se sníží o 30–50 %. Tato čísla CTO chápe.

Argumenty, které nefungují

• „Eric Evans by to chtěl“ – manažer není v DDD komunitě.
• „Je to elegantnější“ – manažer neměří eleganci.
• „Bounded Contexts jsou kanonické“ – manažer neměří kanoničnost.
• „Zlepší se to“ – bez metriky je „zlepší“ prázdné slovo.
• „Skelton a Pais to říkají“ – autorita argumentem nestačí.

Westrumova kultura organizace

Sociolog Ron Westrum v roce 2004 publikoval typologii organizačních kultur [5], kterou později použila Forsgren v Accelerate jako hlavní prediktor úspěchu DevOps transformací. Westrum rozlišuje 3 typy:

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

Pokud poznáte, že vaše organizace je pathological nebo bureaucratic, Inverse Conway Maneuver není první krok. První krok je změna kultury (nebo i změna pracoviště). To je smutná, ale realistická diagnóza.

05.10 Shrnutí

Conway's Law z roku 1968 říká: architektura kopíruje organizační strukturu. Pro DDD to znamená jednu věc – Bounded Context bez vlastnícího týmu je fikce. Pokud máte 7 BC v Context Mapu a 3 týmy v org chartu, vaše BC neexistují, jen jsou 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 IDP), Enabling (time-boxed mentoring), 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).
• Vernonovo pravidlo: 1 BC = 1 tým. 1 tým může vlastnit 1–3 BC, ale BC sdílený mezi týmy = porucha.
• 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: ≤ 2 BC na 5–9 lidí. 4+ BC na tým = signál pro rozdělení. Měřte kvartálně.
• Proporce: 75 % stream-aligned, 15 % platform, 10 % enabling
  • complicated-subsystem.
• Komunikace s managementem: DORA metriky, ne DDD filozofie. Westrumova generative kultura je předpoklad, ne výstup.

Pokud z této kapitoly odejdete s jednou větou, ať je to tato: Bounded Context je závazek konkrétního týmu vyvíjet, nasazovat a v noci opravovat svou část domény. Bez tohoto závazku zůstává jen složkou v repu.

Pro hlubší studium doporučujeme Skelton & Pais – Team Topologies [3], Vernon – Implementing Domain-Driven Design, kap. 2 a 3 [2], a Forsgren et al. – Accelerate [4] pro DORA metriky a Westrumovu typologii. Originální Conway 1968 esej je krátká (4 strany) a stojí za přečtení [1].

05.11 Další četba a citované zdroje

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. Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. itrevolution.com

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

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

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