personal<IT>y: „Architektúra je tichý dizajn neviditeľných vecí,“ hovorí softvérový architekt o modelovaní systémov, hraniciach systému a kráse skrytých rozhodnutí
16.12.2025 | 17 min Anasofťáci
V sérii rozhovorov personal<IT>y nazrieme do zákulisia práce v IT očami odborníkov z ANASOFTu. Odhaľujú nielen svoj pracovný svet, ale aj ten osobný, lebo aj za architektúrou, analýzou a návrhom systémov stojí konkrétny človek so svojím spôsobom myslenia, prístupom k problémom a každodenným nasadením.
Softvérový architekt Rasťo sa pohybuje na pomedzí analýzy, návrhu, vývoja a konzultácií so zákazníkmi. V rozhovore opisuje, ako zo spleti požiadaviek skladá funkčný celok, prečo sa najväčšia časť jeho práce odohráva ešte predtým, než padne prvý riadok kódu, a akú rolu zohrávajú detaily, ktoré nik nevidí, no určujú smer celého projektu. Vysvetľuje, prečo architektúra nie je len technický návrh, ale modelovanie sveta s jeho obmedzeniami, kompromismi a živými procesmi, ktoré sa menia rovnako rýchlo ako ľudia, ktorí v ňom pracujú.
Jeho prístup pripomína spôsob uvažovania Jozefa Murgaša, vynálezcu a priekopníka bezdrôtovej komunikácie. Murgaš síce nestál v centre pozornosti, no rozumel tomu, že za každým pokrokom stojí neviditeľná, precízne navrhnutá štruktúra, koncept, ktorý umožní, aby systém fungoval a rástol. Podobne aj Rasťo buduje architektúru digitálnych riešení: navrhuje pravidlá, hranice a prepojenia, ktoré síce nie sú viditeľné na prvý pohľad, ale nesú celý softvérový svet.
Tam, kde sa rodia neviditelne mesta
Ako by si vysvetlil svoju rolu softvérového architekta niekomu, kto sa vôbec nepohybuje v IT?
To je výborná otázka. Myslím, že najľahšie sa to vysvetľuje na porovnaní s architektom v tom bežnom svete. Predstav si človeka, ktorý príde na prázdny pozemok a povie, tu postavíme obytný komplex. Tu budú bytovky, tu detské ihrisko, tam bude fontána, dolu služby, obchodíky, možno parkovisko, prípadne nejaký menší bar či kaviareň.
A vlastne presne toto sa deje aj vo svete softvéru. Na začiatku je koncept. Niekto príde s víziou, čo a kde má byť. A potom, podobne ako pri fyzickej stavbe, ideš do detailov. Architekt v bežnom svete nakoniec nakreslí aj posledné dvere v každom byte. V softvéri to nie je inak, architekt ide až do takej hĺbky návrhu, aby to vývojári vedeli presne implementovať.
Takže softvérový architekt nezostáva len pri koncepte, ale jeho práca zahŕňa aj podrobné návrhy, výber vhodných technológií, štandardov, zohľadňuje rôzne obmedzenia a očakávania. Nakoniec odovzdáva podrobnú špecifikáciu vývojárom, ktorí už podľa nej kódujú. A hoci občas sa stane, že si niekto „vylepší“ veci po svojom, nie vždy to dopadne dobre, ako keď zistíš, že sa dvere otvárajú len po hranu schodov.
Keď systém prestane byť len softvérom
Rozprával som sa aj s analytikom a ten mi hovoril, že jeho úloha je zisťovať požiadavky od klienta, prekladať ich do technického jazyka a odovzdávať vývojárom. Kde v tomto kolobehu je miesto architekta?
V praxi je to často ešte o niečo zložitejšie. Okrem analytika a vývojára tam vstupuje aj rola návrhára. V ideálnom prípade je návrhár niekde medzi analytikom a vývojárom, ale jeho práca je veľmi blízka práci architekta. V podstate ide len o inú úroveň abstrakcie.
Skúsený návrhár by časom mohol mať ambíciu stať sa architektom, podobne ako keď architekt v bežnom svete najprv kopíruje cudzie projekty, potom navrhuje vlastný rodinný dom a časom, keď je naozaj dobrý, zveria mu celú obytnú štvrť. Rozdiel medzi návrhárom a architektom je v tom, že architekt koncipuje riešenie zhora – má víziu, rozmýšľa nad celkovou koncepciou systému. Vývojár už rieši konkrétnu implementáciu. Čiže návrh je most medzi nimi.
S kým teda najviac spolupracuješ?
To veľmi závisí od veľkosti firmy. V menších firmách sa roly často prelínajú, ľudia musia zastávať viac funkcií naraz. Vo väčších firmách je už viac špecializácie. Ja ako osoba spolupracujem so širokým spektrom ľudí, aj preto, že v našej firme zastávam viacero rolí, nie všetky mám síce napísané na vizitke, ale robím ich.
Z pohľadu architekta je kľúčová spolupráca s analytikom, ten nosí vstupy od zákazníka. Potom určite s projektovým manažérom, ten riadi organizáciu projektu. A v závislosti od veľkosti tímu buď priamo s vývojármi, alebo je medzi nami ešte návrhárska vrstva. Dôležití sú aj testeri, nielen kvôli tomu, že vývojári s nimi ladia testovacie scenáre, ale aj preto, že testeri potrebujú chápať architektúru a koncept systému, aby vedeli efektívne pokryť celý systém testami.
Najťažšie rozhodnutia sú tie, ktoré nikto nevidí
V ktorých fázach vývoja teda architekt najčastejšie vstupuje?
Teoreticky by mal architekt vstupovať do cyklu čo najskôr, ešte počas analýzy. Pretože architektonické rozhodnutia zásadne ovplyvňujú celý výsledok. Ale ako to býva aj v reálnom svete, často sa využívajú osvedčené šablóny, stereotypy, také tie „socialistické sídliská“. Raz sa to vymyslí a potom sa to len kopíruje. V takom prípade architekt vstupuje až v momente, keď niečo „vybočuje z normy“, napríklad keď sa objaví požiadavka, ktorú naše existujúce riešenia nepokrývajú.
Vtedy je potrebné buď rozšíriť existujúcu architektúru, alebo navrhnúť nové riešenie. A áno – v menších firmách to znamená, že neskôr prechádzam aj do iných rolí: návrhár, vývojár, alebo aj konzultant. Nie preto, že by to bolo principiálne úlohou architekta, ale preto, že firma nie je tak veľká, aby som sa venoval iba architektúre.
Čiže architekt navrhne, odobrí riešenie a potom dohliada na jeho dodržanie počas vývoja?
Presne tak. Architektúra by mala byť čo najjasnejšia ešte pred začiatkom vývoja, minimálne v hrubých črtách, ideálne už vo veľkej miere detailne premyslená. Vývoj sa totiž potom robí v rámci tejto architektúry. A úlohou architekta je dohliadať, aby sa návrh a implementácia s architektúrou neodklonili. Je to ako keď niekto povie, tu má byť obytná štvrť, a nemôžeš tam len tak postaviť sklad alebo hangár, lebo sa ti to momentálne hodí.
Spomenul si spoluprácu s testermi, ako konkrétne vyzerá?
Vo veľkej miere ide o konzultácie. Často sa totiž stáva, že konceptuálne informácie sa v tíme časom vytrácajú. Čím viac sa niekto sústredí na detaily, tým viac môže stratiť širší pohľad. A nie každý má potrebu chápať súvislosti, prečo je niečo navrhnuté tak, ako je. To potom spôsobuje, že keď taký človek odovzdáva svoju prácu ďalej, ten koncept sa úplne stratí. A niekto ďalší v tíme už nevidí ten širší obraz. Preto je dôležité, aby tam bol niekto, typicky architekt, kto ten obraz do tímu opakovane vnáša.
Chaos, ktorý treba rozpliesť, aby dostal tvar
A čo zákazníci? Do akej miery sa stretávaš aj s nimi?
Závisí to od typu zákazníka aj typu projektu. Väčšinou áno, softvér musí fungovať v konkrétnom prostredí zákazníka, s konkrétnymi požiadavkami na bezpečnosť, integráciu a podobne. Občas zákazník tieto požiadavky vysloví veľmi presne, inokedy len niečo naznačí a ty musíš zisťovať, prečo to vlastne chce? Čo tým sleduje? Čo mu to prinesie? A niekedy aj dobre mienená „malá zmena“ z pohľadu zákazníka, napríklad jedno nové pole vo formulári, môže rozbiť celý koncept systému. A vtedy je mojou úlohou vysvetliť, že tá „drobnosť“ je v skutočnosti zásah do základov. Niekedy realizovateľný, niekedy nie.
Znamená to, že chodíš aj priamo na stretnutia so zákazníkmi?
Áno, dosť často. Hlavne vtedy, keď sa ukáže, že už nejde o biznisové požiadavky, ale o problém v samotnom koncepte riešenia. Vtedy často vstupujem do hry ja, vysvetľujem, konzultujem, argumentujem.
A darí sa ti to vysvetliť tak, aby to zákazník pochopil a prijal?
Dúfam. Zákazník iba naskladá množstvo nie vždy konzistentných požiadaviek a ty tie podmienky začneš rozmotávať, snažíš sa pochopiť, čo vlastne znamenajú. No a teraz je na tebe, teda v tejto roli, začať hľadať, ako ich poskladať do konzistentného riešenia. A niekedy sa práve v tejto fáze objaví niečo, čo ma fakt baví. Že sa z toho chaosu, z tej množiny požiadaviek, ktoré navonok ani nemusia dávať zmysel, zrodí niečo, čo má tvar, štruktúru a hlavu aj pätu.
A keď to človek rozmotá, vyformuluje ten koncept, spraví návrh a následne sleduje, ako sa podľa neho ten softvér začne skladať, ako podľa plánov stavajú dom, to je ten „wau moment“. Lebo vtedy vieš, že si urobil rozhodnutia, ktoré reálne ovplyvnili smer celého projektu. A keď to ide podľa toho návrhu, keď sa tí vývojári dokážu oprieť o tú architektúru, keď to testerom dáva zmysel, keď sa zákazník začína chytať... tak to je satisfakcia. A hoci je oneskorená, o to je hlbšia.
A pritom paradoxne, často sa tá najväčšia práca udeje dávno predtým, než sa napíše prvý riadok kódu. A nik o nej vlastne ani nevie. Lebo keď to funguje, tak nikto nespozná, že sa vôbec niečo mohlo pokaziť. Vieš, to je ako s dobrou infraštruktúrou, keď je dobre navrhnutá, nikto si ju nevšíma. Ale keď nie je, tak každý nadáva.
A táto „neviditeľná“ časť architektonickej práce, kde sa robí veľa rozhodnutí o tom, ako budú veci spolu hovoriť, kde budú hranice, ako sa čo bude správať v záťaži, čo má byť flexibilné a čo nie... to je presne to, čo mňa na tejto práci najviac drží. Lebo to nie je o tom, že len navrhneš niečo technické. Je to o pochopení systému ako celku, techniky, ľudí, procesu, požiadaviek aj reálnych obmedzení. A keď si to takto poskladáš, tak sa v tom objavuje tá krása. Architektúra je pre mňa vlastne taký tichý dizajn neviditeľných vecí, ktoré ale vo výsledku rozhodujú o všetkom.
A vieš, čo ešte? Niekedy aj keď sa niečo pokazí, a to sa občas stane, tak aj vtedy môžeš z toho mať pocit úspechu. Lebo keď dokážeš spätne analyzovať, kde to neklaplo, a nájsť spôsob, ako sa tomu nabudúce vyhnúť, tak si zase o krok ďalej. To je ten nekonečný proces učenia sa. A podľa mňa, ak v tomto procese stratíš záujem učiť sa, tak si skončil. Potom už si len správca nejakých starých rozhodnutí.
Takže ja sa vlastne teším aj z tých momentov, keď niečo nevyjde. Nie zo zlyhania samotného, ale z toho, že mám možnosť pochopiť, prečo sa to stalo. To je pre mňa osobne rovnako dôležité ako tie momenty, keď všetko zapadne a funguje. A to je možno tá črta, čo oddeľuje architekta od vývojára alebo testera. Architekt sa musí starať aj o to, čo sa stane „potom“, keď sa to pokazí, keď sa niečo zmení, keď bude treba systém rozšíriť, opraviť, prepojiť. Lebo systém sa nerodí raz, on žije. A architektúra je o tom, aby ho nezabila.
Takže áno, som nadšenec. A stále ešte mám pocit, že som v tom procese učenia. Že to neskončilo, že sa to hýbe. A keď cítim, že sa hýbem spolu s tým, že to rastie, že sa to mení a ja to dokážem chápať alebo ovplyvniť, tak vtedy viem, že to stále má zmysel.
Ak sa teda pozrieš späť, myslíš, že si sa tej ideálnej predstave softvérového architekta nejako priblížil?
Asi sa to tak úplne nedá povedať. Vieš, ono je to skôr o tom, že čo ti do toho pomôže. A často je to len o tom, že máš šťastie stretnúť správnych ľudí. Ľudí, ktorí ťa niekam posunú, aby si nemusel všetko biť hlavou o stenu. Vieš, že nie všetko sa musíš dozvedieť len vlastnými chybami, niekedy je fajn, keď ti niekto niečo povie dopredu.
Ja som mal šťastie, že som spolupracoval s niekoľkými naozaj šikovnými ľuďmi, či už to boli kóderi, analytici, návrhári, architekti... ľudia, ktorí vedeli a hlavne už aj niečo videli. A ukázali mi, ako veci robiť lepšie, efektívnejšie. Na čo sa pozerať, čo si všímať. A to boli perfektní ľudia. Určite vďačím za veľa aj im.
Spomenul si, že máš v tej práci aj určitú kreativitu, že je tam stále prítomná abstrakcia, aj nejaká matematika. Čo ťa na tom najviac baví?
Vieš čo, myslím si, že to má asi každý trochu inak. Ale pre mňa je najpovzbudivejšie, najpríjemnejšie, keď to, čo robíme, na konci reálne funguje. Keď sa ten výsledok podarí, keď tá realizácia, ten systém, ktorý sme navrhli, reálne spĺňa to, čo sme chceli. Hej, niekedy zákazník úplne nevidí, čo všetko tým získal, ale my to vidíme. Vidíme, že to funguje, že sa to správa tak, ako malo. A to je hrozne dobrý pocit. Silný.
Ale zároveň, ten „úspech“, to povzbudenie, to sa nedostaví hneď. Veľakrát je to vidno až neskôr. Napríklad dostaneš od zákazníka cez analytika zoznam požiadaviek. Niečo, čo má nejaký algoritmus alebo proces splniť. A teraz je na tebe, aby si to celé rozmotával, a navrhol dátové štruktúry, spôsoby implementácie, ktoré to všetko splnia.
A keď sa ti to podarí, keď vidíš, že to šliape ako hodinkym tak si spokojný. Je to veľmi povzbudzujúce. Len, samozrejme, cesta k tomu býva dosť frustrujúca. Lebo niekedy to proste nevieš nájsť. Niekedy máš pocit, že musíš každému vysvetľovať znova a znova, že „toto takto nepôjde, lebo to je v rozpore s tým a tým“. A zákazník si to často neuvedomuje, lebo to na prvý pohľad nevidno.
Vieš, on ti povie: „Chcem, aby ste vždy vybrali najstarší tovar zo skladu.“ OK. A potom povie: „A musí to ísť čo najrýchlejšie.“ No dobre, ale to nemusí ísť dokopy. Lebo keď chcem ísť hneď po najstarší tovar, tak si naň možno musím počkať, vyhrabať ho spod iného, alebo ísť cez pol skladu. Tak potom nemôžem očakávať najrýchlejší výdaj. Jednoducho nie všetky požiadavky sú zlučiteľné, je tam balans.
Je to ako v programovaní, keď máš úlohu určitej zložitosti, máš v zásade len dve možnosti. Buď máš obrovské množstvo priestoru, pamäte, a spravíš to rýchlo, alebo máš málo pamäte, a potom ťa to stojí veľa procesorového výkonu. Niekde musíš investovať, buď do výpočtovej kapacity, alebo do pamäte. Ale keď neurobíš ani jedno, tak to skrátka rýchle nebude. A je to to isté aj v realite, keď chceš, aby sklad fungoval rýchlejšie, tak si kúp väčší sklad. Ale to bude drahé.
A to je ten moment, kde do toho vstupuje softvérový architekt, že pri návrhu musí uvažovať nad všetkými procesmi, ktoré sa tam dejú. Nad komplexným obrazom toho, čo sa deje, čo sa bude diať, a aké kompromisy sú akceptovateľné. A niekedy je to len o tom, že zákazník chce „tlačidlo na všetko“, a ty mu musíš vysvetliť, že taký softvér neexistuje. Alebo teda, že existuje, ale bude stáť milión.
Takže ty pri tom návrhu musíš vlastne pochopiť celý systém, čo sa tam deje, nielen softvér, ale celý svet okolo?
No... hej. Len nie je možné držať si celý ten systém v hlave do úplného detailu. To nejde. Ten sklad, aj keď sa na prvý pohľad zdá jednoduchý, je zvnútra veľmi komplexný organizmus. A vieš, ono je to ako keby si mal vrecko s vodou. Tvoj mozog má nejakú kapacitu, nejaký objem, ktorý vie spracovať naraz. A máš okolo seba kopu údajov, informácií, procesov.
A niektoré sú blízko toho problému, ktorý práve riešiš, tie potrebuješ rozumieť do hĺbky. A iné sú ďalej, tie len tak „tušíš“, vieš, že existujú, ale neriešiš ich teraz detailne. A ako sa ponáraš hlbšie do jednej časti, tak iné časti ti z hlavy „vytláča“. Musíš teda robiť selekciu, čo potrebuješ mať v hlave práve teraz.
A keď sa pozrieš na tie procesy, sú rôzne typy interakcií. Máš dva procesy, ktoré robia to isté, ale v inej časti skladu. Máš dva procesy, kde výsledok jedného je vstupom pre druhý. A potom máš ľudskú vôľu, stochastické zásahy. Niečo sa stane, niekto zmení prioritu, niečo zablokuje... A ty v tom návrhu musíš tieto možnosti zohľadniť. Nemusíš ich vždy vyriešiť, ale musíš ich aspoň mať v hlave.
Možno aj my sme len dobre navrhnutý model
A keď si to celé premyslíš, spravíš návrh, ktorý pokrýva tie hlavné procesy... Máš pocit, že sa dá ten svet úplne pochopiť?
Ťažko. Nám to napríklad trvalo tak desať rokov, kým sme tomu začali reálne rozumieť. Tie prvé pokusy neboli úplne trefné. To boli skôr simulácie, také pokusy. A neviem, či je vôbec „simulácia“ to správne slovo.
Ale v zásade, musíš vidieť ten reálny svet, sledovať, čo sa v ňom deje. A potom rozmýšľať, čo z toho chceš dostať do svojho modelu. Čo je dôležité, a čo nie. Hej, mám tam skladníka, je dôležité, či je blondiak, alebo nie? Nie. Ale je dôležité, ako rýchlo vie reagovať, čo vie spraviť, ako zvláda výpadky systému... A to je dôležité do modelu.
Lebo model nie je opis reality v každom detaile, to je len výsek. Je to o tom, že pracovisko „vychystávanie“ vie robiť toto, na takéto podnety reaguje takto. Či to celé dá zmysel, keď sa to poskladá dokopy, to zistíš až neskôr. A niekedy to aj tak dáva zmysel len na papieri.
Čiže... keď to celé tak popisuješ, že ako architekt vytváraš modely reálneho sveta, ktoré fungujú v digitálnom prostredí, navrhuješ pravidlá, štruktúrú a sleduješ, ako sa tie entity správajú, tak to ma privádza na otázku, či si myslíš si, že je možné, že aj my žijeme v simulácii?
No... Rozmýšľam, ako na to odpovedať správne. Krátka odpoveď je, určite áno. Môže byť. Napríklad Matrix. Hej, to je akože ten jednoduchý kultúrny príklad, ale... ono to v sebe skrýva tú nekonečne starú filozofickú otázku, že čo je to slobodná vôľa, a či sme vlastne naozaj slobodní. Lebo ak by sme boli simulácia, tak to znamená, že slobodní nie sme. Robíme len to, čo nám bolo naprogramované. Hej, ako keď niekto vo "výrobe" nastavil naše gény a naše rozhodnutia sú vlastne len výpočtovo predurčené reakcie na nejaké vstupy.
Ale to je tá filozofická rovina. Že či máme pocit, že konáme slobodne, alebo len hráme rolu v nejakom scenári. A nevieme to dokázať ani vyvrátiť. Lebo aj keď sa pozrieš na to, ako funguje mozog, no my nevieme, či tie naše reakcie sú čisto biologické, alebo niečo viac. A zasa, na prvý pohľad sa to nezdá byť úplne deterministické. Veľa vecí robíme inak, aj keď sú okolnosti podobné. Niekedy reagujeme na tú istú situáciu raz tak, inokedy úplne inak. Takže otázka je, či ten systém, ak je to teda systém, obsahuje náhodu, alebo len chaos, ktorý nevieme zatiaľ vysvetliť.
Takže je to ťažká otázka, ale... áno, ja si viem predstaviť, že môžeme byť súčasťou niečoho takého. Že to, čo robím ja, že vytváram systém, v ktorom sa entity správajú podľa pravidiel a niekedy ma prekvapia, že to isté robí niekto s nami. A my sme len tie entity, ktoré si myslia, že majú slobodnú vôľu. Alebo, keď to poviem inak, my možno robíme to isté, čo ten „niekto“ robí s nami. Len v menšom. A cez to, čo robíme, sa to možno aj učíme chápať.
A nie, to ešte neznamená, že si myslím, že tu všetko riadi nejaký nadpozemský programátor. Ale tá predstava, že by náš svet mohol byť modelom, je podľa mňa úplne reálna. A možno nie celkom presne, ako to ukazuje sci-fi, ale v princípe... prečo nie? Nakoniec, keď sa pozrieš na to, ako robíme softvér, tiež to začína abstraktne. Návrh, pravidlá, modely... a potom to beží. A niekedy sa to správa tak, ako sme chceli, a niekedy nás ten systém sám prekvapí. Lebo sa v ňom objavia nové vzťahy, nové situácie. A možno aj my sami sme len taký zložitý výstup nejakého iného modelu. A niekde, možno, niekto ladí našu architektúru.
Ale to už je asi viac metafyzika ako softvér.
Chcete dostávať novinky e-mailom?
Vyberte si z tém, ktoré vás zaujímajú a prihláste sa k odberu noviniek