V té době časopis Harvard Business Review odmítl jeho původní článek na základě toho, že neprokázal svou hypotézu. Nicméně tento postřeh se stal známým jako Conwayův zákon a kolektivní zkušenosti mých kolegů i mé osobně opakovaně potvrzují pravdivost tohoto tvrzení. Ale nemusíte nás chytat za slovo!“
V rámci studie „Exploring the Duality between Product and Organizational Architectures“ (Zkoumání duality mezi produktovou a organizační architekturou) provedla The Harvard Business School analýzu různých databází kódů, aby zjistila, zda může prokázat Conwayovu původní hypotézu aplikovanou na softwarové systémy. Vzali v ní několik příkladů softwaru vytvořeného k řešení stejného účelu (například software pro zpracování textu, správu financí a databázový software) a porovnali kódové základny vytvořené volně spřaženými open source týmy a kódové základny vytvořené úzce spřaženými týmy. Jejich studie zjistila, že často společně působící týmy zaměřené na produkty vytvářely software, který více inklinoval k těsně spřaženým, monolitickým kódovým základnám. Zatímco v projektech s otevřeným zdrojovým kódem vznikaly spíše modulární, dekomponované kódové báze.
Organizace již několik let chápou tuto souvislost mezi organizační strukturou a vytvářeným softwarem a přijímají nové struktury, aby dosáhly požadovaného výsledku. Například společnosti Netflix a Amazon se strukturují na základě několika malých týmů, z nichž každý má na starosti malou část celkového systému. Tyto nezávislé týmy mohou vlastnit celý životní cyklus služeb, které vytvářejí, což jim poskytuje větší míru autonomie, než je možné u větších týmů s monolitičtějšími kódovými základnami. Tyto služby se svými nezávislými zájmy se mohou měnit a vyvíjet odděleně jedna od druhé, což vede k možnosti rychleji dodávat změny do výroby. Pokud by tyto organizace přijaly větší týmy, vzniklé větší monolitické systémy by jim neposkytovaly stejnou schopnost experimentovat, přizpůsobovat se a nakonec udržovat své zákazníky spokojené.
Možná vidíte napětí ve svých vlastních organizacích, kde vaše struktura a software nejsou v souladu. Možná jste viděli například problémy spojené s tím, když se distribuované týmy snaží pracovat na stejné monolitické kódové základně. Zde jsou komunikační cesty, na které Conway odkazuje, v kontrastu se samotným kódem, kdy jednotná kódová základna vyžaduje jemnozrnnou komunikaci, ale distribuovaný tým je schopen pouze hrubozrnné komunikace. Tam, kde se objeví takové napětí, přinese hledání příležitostí k rozdělení monolitických systémů kolem organizačních hranic často značné výhody.
V předchozích technologických radarech jsme upozorňovali na rostoucí popularitu mikroslužeb, které stále častěji přijímají organizace, jež chtějí zlepšit autonomii svých týmů a zvýšit rychlost změn. Článek Martina Fowlera a Jamese Lewise se tomuto tématu věnuje hlouběji a zdůrazňuje skutečnost, že tyto architektury umožňují organizacím mnohem větší flexibilitu při slaďování architektury jejich systémů se strukturou jejich týmů, aby bylo zajištěno, že Conwayův zákon bude fungovat pro vás. V příštím vydání Tech Radaru se budeme zabývat odrazem rostoucího vlivu mikroslužeb, od infrastrukturních technologií, jako je Packer nebo Docker, až po nástroj pro zjišťování služeb Consul nebo mikrokontejnery, jako je populární DropWizard nebo poměrně nový SpringBoot. Probereme také opačnou stranu – organizace měnící strukturu svých týmů tak, aby vyhovovala jejich IT systémům.
Plně očekáváme, že se objeví další techniky a podpůrné technologie umožňující architektury mikroslužeb, a budeme je v následujících měsících sledovat. Pokud se mezitím chcete dozvědět více, přihlaste se k odběru nejnovějšího Tech Radaru, přečtěte si článek Martina a Jamese o mikroslužbách nebo mou knihu z nakladatelství O’Reilly Building Microservices.
.