personal<IT>y: „Architektura je tichý design neviditelných věcí,“ říká softwarový architekt o modelování systémů, hranicích systému a kráse skrytých rozhodnutí

Tam, kde se rodí neviditelná města

Jak bys vysvětlil svou roli softwarového architekta někomu, kdo se vůbec nepohybuje v IT?

To je výborná otázka. Myslím, že nejjednodušeji se to vysvětluje na přirovnání k architektovi v tom běžném světě. Představ si člověka, který přijde na prázdný pozemek a řekne: tady postavíme obytný komplex. Tady budou bytovky, tady dětské hřiště, tam bude fontána, dole služby, obchůdky, možná parkoviště, případně nějaký menší bar či kavárna.

A vlastně přesně tohle se děje i ve světě softwaru. Na začátku je koncept. Někdo přijde s vizí, co a kde má být. A potom, podobně jako u fyzické stavby, jdeš do detailů. Architekt v běžném světě nakonec nakreslí i poslední dveře v každém bytě. V softwaru to není jinak, architekt jde až do takové hloubky návrhu, aby to vývojáři dokázali přesně implementovat.

Takže softwarový architekt nezůstává jen u konceptu, ale jeho práce zahrnuje i podrobné návrhy, výběr vhodných technologií, standardů, zohledňuje různá omezení a očekávání. Nakonec předává podrobnou specifikaci vývojářům, kteří už podle ní kódují. A i když se občas stane, že si někdo věci „vylepší“ po svém, ne vždy to dopadne dobře, jako když zjistíš, že se dveře otevírají jen po hranu schodů.

Když systém přestane být jen softwarem

Mluvil jsem i s analytikem a ten mi říkal, že jeho úloha je zjišťovat požadavky od klienta, překládat je do technického jazyka a předávat vývojářům. Kde v tomto koloběhu je místo architekta?

V praxi je to často ještě o něco složitější. Kromě analytika a vývojáře do toho vstupuje i role návrháře. V ideálním případě je návrhář někde mezi analytikem a vývojářem, ale jeho práce je velmi blízká práci architekta. V podstatě jde jen o jinou úroveň abstrakce.

Zkušený návrhář by časem mohl mít ambici stát se architektem, podobně jako když architekt v běžném světě nejdřív kopíruje cizí projekty, pak navrhne vlastní rodinný dům a časem, když je opravdu dobrý, svěří mu celou obytnou čtvrť. Rozdíl mezi návrhářem a architektem je v tom, že architekt koncipuje řešení shora – má vizi, přemýšlí nad celkovou koncepcí systému. Vývojář už řeší konkrétní implementaci. Takže návrh je most mezi nimi.

S kým tedy nejvíc spolupracuješ?

To hodně závisí na velikosti firmy. V menších firmách se role často prolínají, lidé musí zastávat více funkcí najednou. Ve větších firmách už je více specializace. Já jako osoba spolupracuji se širokým spektrem lidí, i proto, že v naší firmě zastávám více rolí – ne všechny mám sice napsané na vizitce, ale dělám je.

Z pohledu architekta je klíčová spolupráce s analytikem, ten nosí vstupy od zákazníka. Potom určitě s projektovým manažerem, ten řídí organizaci projektu. A v závislosti na velikosti týmu buď přímo s vývojáři, nebo je mezi námi ještě návrhářská vrstva. Důležití jsou i testeři, nejen kvůli tomu, že vývojáři s nimi ladí testovací scénáře, ale i proto, že testeři potřebují chápat architekturu a koncept systému, aby dokázali efektivně pokrýt celý systém testy.

Nejtěžší rozhodnutí jsou ta, která nikdo nevidí

V kterých fázích vývoje tedy architekt nejčastěji vstupuje?

Teoreticky by měl architekt vstupovat do cyklu co nejdřív, ještě během analýzy. Protože architektonická rozhodnutí zásadně ovlivňují celý výsledek. Ale jak to bývá i v reálném světě, často se používají osvědčené šablony, stereotypy, taková ta „socialistická sídliště“. Jednou se to vymyslí a pak se to jen kopíruje. V takovém případě architekt vstupuje až v momentě, kdy něco „vybočuje z normy“, například když se objeví požadavek, který naše existující řešení nepokrývají.

Tehdy je potřeba buď rozšířit existující architekturu, nebo navrhnout nové řešení. A ano – v menších firmách to znamená, že později přecházím i do jiných rolí: návrhář, vývojář, nebo i konzultant. Ne proto, že by to bylo principiálně úkolem architekta, ale proto, že firma není tak velká, abych se věnoval jen architektuře.

Takže architekt navrhne, schválí řešení a potom dohlíží na jeho dodržování během vývoje?

Přesně tak. Architektura by měla být co nejjasnější ještě před začátkem vývoje, minimálně v hrubých rysech, ideálně už ve velké míře detailně promyšlená. Vývoj se totiž potom dělá v rámci této architektury. A úkolem architekta je dohlížet, aby se návrh a implementace od architektury neodklonily. Je to jako když někdo řekne: tady má být obytná čtvrť – a nemůžeš tam jen tak postavit sklad nebo hangár, protože se ti to zrovna hodí.

Zmínil jsi spolupráci s testery, jak konkrétně vypadá?

Ve velké míře jde o konzultace. Často se totiž stává, že konceptuální informace se v týmu časem vytrácejí. Čím víc se někdo soustředí na detaily, tím víc může ztratit širší pohled. A ne každý má potřebu chápat souvislosti, proč je něco navržené tak, jak je. To pak způsobí, že když takový člověk předává svou práci dál, koncept se úplně ztratí. A někdo další v týmu už nevidí širší obraz. Proto je důležité, aby tam byl někdo – typicky architekt – kdo ten obraz do týmu opakovaně vnáší.

Chaos, který je potřeba rozplést, aby dostal tvar

A co zákazníci? Do jaké míry se setkáváš i s nimi?

Záleží to na typu zákazníka i typu projektu. Většinou ano – software musí fungovat v konkrétním prostředí zákazníka, s konkrétními požadavky na bezpečnost, integraci a podobně. Občas zákazník tyto požadavky vysloví velmi přesně, jindy jen něco naznačí a ty musíš zjišťovat, proč to vlastně chce? Co tím sleduje? Co mu to přinese? A někdy i dobře míněná „malá změna“ z pohledu zákazníka, například jedno nové pole ve formuláři, může rozbít celý koncept systému. A tehdy je mojí úlohou vysvětlit, že ta „drobnost“ je ve skutečnosti zásah do základů. Někdy realizovatelný, jindy ne.

Znamená to, že chodíš i přímo na schůzky se zákazníky?

Ano, docela často. Hlavně tehdy, když se ukáže, že už nejde o byznysové požadavky, ale o problém v samotném konceptu řešení. Tehdy často vstupuji do hry já, vysvětluji, konzultuji, argumentuji.

A daří se ti to vysvětlit tak, aby to zákazník pochopil a přijal?

Doufám. Zákazník jen navrší množství ne vždy konzistentních požadavků a ty ty podmínky začneš rozmotávat, snažíš se pochopit, co vlastně znamenají. No a teď je na tobě, tedy v této roli, začít hledat, jak je poskládat do konzistentního řešení. A někdy se právě v této fázi objeví něco, co mě fakt baví. Že se z toho chaosu, z té množiny požadavků, které navenek ani nemusí dávat smysl, zrodí něco, co má tvar, strukturu a hlavu i patu.

A když to člověk rozmotá, vyformuluje ten koncept, udělá návrh a následně sleduje, jak se podle něj software začne skládat, jako když podle plánů staví dům – to je ten „wau moment“. Protože tehdy víš, že jsi udělal rozhodnutí, která reálně ovlivnila směr celého projektu. A když to jde podle toho návrhu, když se vývojáři dokážou opřít o tu architekturu, když to testerům dává smysl, když se zákazník začíná chytat... tak to je satisfakce. A i když je opožděná, o to je hlubší.

A přitom paradoxně se často ta největší práce odehraje dávno předtím, než se napíše první řádek kódu. A nikdo o ní vlastně ani neví. Protože když to funguje, nikdo nepozná, že se vůbec něco mohlo pokazit. Víš, je to jako s dobrou infrastrukturou – když je dobře navržená, nikdo si jí nevšímá. Ale když není, tak každý nadává.

A tahle „neviditelná“ část architektonické práce, kde se dělá spousta rozhodnutí o tom, jak budou věci spolu mluvit, kde budou hranice, jak se co bude chovat v zátěži, co má být flexibilní a co ne... to je přesně to, co mě na téhle práci drží nejvíc. Protože to není o tom, že jen navrhneš něco technického. Je to o pochopení systému jako celku – techniky, lidí, procesu, požadavků i reálných omezení. A když si to takhle poskládáš, objeví se v tom ta krása. Architektura je pro mě vlastně takový tichý design neviditelných věcí, které ale ve výsledku rozhodují o všem.

A víš co ještě? Někdy i když se něco pokazí – a to se občas stane – tak i tehdy z toho můžeš mít pocit úspěchu. Protože když dokážeš zpětně analyzovat, kde to neklaplo, a najít způsob, jak se tomu příště vyhnout, tak jsi zase o krok dál. To je ten nekonečný proces učení se. A podle mě, když v tom procesu ztratíš zájem učit se, tak jsi skončil. Pak už jsi jen správce nějakých starých rozhodnutí.

Takže já se vlastně těším i z těch momentů, kdy něco nevyjde. Ne ze samotného selhání, ale z toho, že mám možnost pochopit, proč se to stalo. To je pro mě osobně stejně důležité jako ty momenty, kdy všechno zapadne a funguje. A to je možná ta vlastnost, která odlišuje architekta od vývojáře nebo testera. Architekt se musí starat i o to, co se stane „potom“ – když se to pokazí, když se něco změní, když bude potřeba systém rozšířit, opravit, propojit. Protože systém se nerodí jednou, on žije. A architektura je o tom, aby ho nezabila.

Takže ano, jsem nadšenec. A pořád mám pocit, že jsem v tom procesu učení. Že to neskončilo, že se to hýbe. A když cítím, že se hýbu spolu s tím, že to roste, že se to mění a já tomu dokážu rozumět nebo to ovlivnit, tak tehdy vím, že to pořád dává smysl.

Pokud se tedy podíváš zpět, myslíš, že ses té ideální představě softwarového architekta nějak přiblížil?

Asi se to tak úplně nedá říct. Víš, ono je to spíš o tom, co ti k tomu pomůže. A často je to jen o tom, že máš štěstí potkat správné lidi. Lidi, kteří tě někam posunou, abys nemusel všechno mlátit hlavou o zeď. Víš, že ne všechno se musíš dozvědět jen vlastními chybami, někdy je fajn, když ti někdo něco řekne dopředu.

Já jsem měl štěstí, že jsem spolupracoval s několika opravdu šikovnými lidmi, ať už to byli kodéři, analytici, návrháři, architekti... lidé, kteří věděli a hlavně už i něco viděli. A ukázali mi, jak dělat věci lépe, efektivněji. Na co se dívat, čeho si všímat. A to byli perfektní lidé. Určitě vděčím za hodně i jim.

Zmínil jsi, že máš v té práci i určitou kreativitu, že je tam pořád přítomná abstrakce, i nějaká matematika. Co tě na tom nejvíc baví?

Víš co, myslím si, že to má asi každý trochu jinak. Ale pro mě je nejpovzbuzující, nejpříjemnější, když to, co děláme, na konci reálně funguje. Když se ten výsledek povede, když ta realizace, ten systém, který jsme navrhli, reálně splňuje to, co jsme chtěli. Jo, někdy zákazník úplně nevidí, co všechno tím získal, ale my to vidíme. Vidíme, že to funguje, že se to chová tak, jak mělo. A to je strašně dobrý pocit. Silný.

Ale zároveň, ten „úspěch“, to povzbuzení, to nepřijde hned. Často je to vidět až později. Například dostaneš od zákazníka přes analytika seznam požadavků. Něco, co má nějaký algoritmus nebo proces splnit. A teď je na tobě, abys to celé rozmotával a navrhl datové struktury, způsoby implementace, které to všechno splní.

A když se ti to podaří, když vidíš, že to šlape jako hodinky, tak jsi spokojený. Je to velmi povzbuzující. Jenže samozřejmě cesta k tomu bývá dost frustrující. Protože někdy to prostě nedokážeš najít. Někdy máš pocit, že musíš každému vysvětlovat znovu a znovu, že „tohle takhle nepůjde, protože je to v rozporu s tím a tím“. A zákazník si to často neuvědomuje, protože na první pohled to není vidět.

Víš, on ti řekne: „Chci, abyste vždy vybrali nejstarší zboží ze skladu.“ OK. A potom řekne: „A musí to jít co nejrychleji.“ No dobře, ale to nemusí jít dohromady. Protože když chci hned po nejstarším zboží, tak si na něj možná musím počkat, vyhrabat ho spod jiného, nebo jít přes půl skladu. Tak potom nemůžu očekávat nejrychlejší výdej. Jednoduše ne všechny požadavky jsou slučitelné, je tam balanc.

Je to jako v programování, když máš úlohu určité složitosti, v zásadě máš jen dvě možnosti. Buď máš obrovské množství prostoru, paměti, a uděláš to rychle, nebo máš málo paměti, a pak tě to stojí hodně procesorového výkonu. Někde musíš investovat – buď do výpočetní kapacity, nebo do paměti. Ale když neuděláš ani jedno, tak to prostě rychlé nebude. A je to stejné i v realitě: když chceš, aby sklad fungoval rychleji, tak si kup větší sklad. Ale to bude drahé.

A to je ten moment, kde do toho vstupuje softwarový architekt – že při návrhu musí uvažovat nad všemi procesy, které se tam dějí. Nad komplexním obrazem toho, co se děje, co se bude dít, a jaké kompromisy jsou akceptovatelné. A někdy je to jen o tom, že zákazník chce „tlačítko na všechno“, a ty mu musíš vysvětlit, že takový software neexistuje. Nebo tedy že existuje, ale bude stát milion.

Takže ty při tom návrhu musíš vlastně pochopit celý systém, co se tam děje – nejen software, ale celý svět okolo?

No... jo. Jen není možné držet si celý ten systém v hlavě do úplného detailu. To nejde. Ten sklad, i když se na první pohled zdá jednoduchý, je uvnitř velmi komplexní organismus. A víš, je to jako kdybys měl sáček s vodou. Tvůj mozek má nějakou kapacitu, nějaký objem, který dokáže zpracovat najednou. A máš kolem sebe hromadu údajů, informací, procesů.

A některé jsou blízko toho problému, který právě řešíš – těm potřebuješ rozumět do hloubky. A jiné jsou dál – ty jen tak „tušíš“, víš, že existují, ale teď je detailně neřešíš. A jak se ponořuješ hlouběji do jedné části, tak ti jiné části z hlavy „vytlačuje“. Musíš tedy dělat selekci, co potřebuješ mít v hlavě právě teď.

A když se podíváš na ty procesy, jsou různé typy interakcí. Máš dva procesy, které dělají to samé, ale v jiné části skladu. Máš dva procesy, kde výsledek jednoho je vstupem pro druhý. A pak máš lidskou vůli, stochastické zásahy. Něco se stane, někdo změní prioritu, něco zablokuje... A ty v tom návrhu musíš tyto možnosti zohlednit. Nemusíš je vždy vyřešit, ale musíš je aspoň mít v hlavě.

Možná i my jsme jen dobře navržený model

A když si to celé promyslíš, uděláš návrh, který pokrývá ty hlavní procesy... Máš pocit, že se dá ten svět úplně pochopit?

Těžko. Nám to například trvalo asi deset let, než jsme tomu začali reálně rozumět. Ty první pokusy nebyly úplně trefné. To byly spíš simulace, takové pokusy. A nevím, jestli je vůbec „simulace“ to správné slovo.

Ale v zásadě musíš vidět reálný svět, sledovat, co se v něm děje. A potom přemýšlet, co z toho chceš dostat do svého modelu. Co je důležité a co ne. Jo, mám tam skladníka – je důležité, jestli je blondák, nebo ne? Ne. Ale je důležité, jak rychle dokáže reagovat, co dokáže udělat, jak zvládá výpadky systému... A to je důležité do modelu.

Protože model není popis reality v každém detailu, to je jen výsek. Je to o tom, že pracoviště „vychystávání“ umí dělat tohle, na takové podněty reaguje takhle. Jestli to celé dává smysl, když se to poskládá dohromady, to zjistíš až později. A někdy to stejně dává smysl jen na papíře.

Takže... když to celé tak popisuješ, že jako architekt vytváříš modely reálného světa, které fungují v digitálním prostředí, navrhuješ pravidla, strukturu a sleduješ, jak se ty entity chovají, tak mě to přivádí k otázce, jestli si myslíš, že je možné, že i my žijeme v simulaci?

No... Přemýšlím, jak na to odpovědět správně. Krátká odpověď je: určitě ano. Může být. Například Matrix. Jo, to je takový jednoduchý kulturní příklad, ale... ono to v sobě skrývá tu nekonečně starou filozofickou otázku, co je to svobodná vůle a jestli jsme vlastně opravdu svobodní. Protože kdybychom byli simulace, znamenalo by to, že svobodní nejsme. Děláme jen to, co nám bylo naprogramováno. Jo, jako když někdo ve „výrobě“ nastavil naše geny a naše rozhodnutí jsou vlastně jen výpočetně předurčené reakce na nějaké vstupy.

Ale to je ta filozofická rovina. Jestli máme pocit, že jednáme svobodně, nebo jen hrajeme roli v nějakém scénáři. A nedokážeme to ani dokázat, ani vyvrátit. Protože i když se podíváš na to, jak funguje mozek, my nevíme, jestli jsou naše reakce čistě biologické, nebo něco víc. A zase, na první pohled to nevypadá úplně deterministicky. Spoustu věcí děláme jinak, i když jsou okolnosti podobné. Někdy reagujeme na tu samou situaci jednou tak, jindy úplně jinak. Takže otázka je, jestli ten systém, pokud je to tedy systém, obsahuje náhodu, nebo jen chaos, který zatím neumíme vysvětlit.

Takže je to těžká otázka, ale... ano, umím si představit, že můžeme být součástí něčeho takového. Že to, co dělám já – že vytvářím systém, ve kterém se entity chovají podle pravidel a někdy mě překvapí – že to samé dělá někdo s námi. A my jsme jen ty entity, které si myslí, že mají svobodnou vůli. Nebo když to řeknu jinak: my možná děláme to samé, co ten „někdo“ dělá s námi. Jen v menším. A skrze to, co děláme, se to možná i učíme chápat.

A ne, to ještě neznamená, že si myslím, že tu všechno řídí nějaký nadpozemský programátor. Ale ta představa, že by náš svět mohl být modelem, je podle mě úplně reálná. A možná ne úplně přesně tak, jak to ukazuje sci-fi, ale v principu... proč ne? Nakonec, když se podíváš na to, jak děláme software, taky to začíná abstraktně. Návrh, pravidla, modely... a potom to běží. A někdy se to chová tak, jak jsme chtěli, a někdy nás ten systém sám překvapí. Protože se v něm objeví nové vztahy, nové situace. A možná i my sami jsme jen takový složitý výstup nějakého jiného modelu. A někde, možná, někdo ladí naši architekturu.

Ale to už je asi víc metafyzika než software.