Programování a vývoj SWNěco málo o programování a světě vývojářů

IT-architekt pohledem programátora

Publikováno 02.10.2017 v 13:57 v kategorii Postřehy a komentáře, přečteno: 53x

Kromě programátorů v pravém slova smyslu existuje vícero povolání IT s různými méně či více ezoterickými názvy. IT-expert, IT-manažer, IT-specialista, IT-analytik, IT-konzultant, IT-engineer atp. Jedním z nich je i IT-architekt. Necháme stranou prozatím všechna ostatní a zaměříme se právě na povolání IT-architekta. Pokusím se zde shrnout své postřehy v této oblasti a nastínit, jak old-school programátor IT-architekty vnímá.





Nejprve, kdo je IT-architekt
Učebnicové definice říkají, že IT-architekt navrhuje řešení informačních systémů, zohledňuje požadavky, které jsou na ně kladeny, navrhuje vhodné postupy pro realizaci, dohlíží na jejich dodání a design, kontroluje, zda nejsou systémy v nějaké kolizi nebo zda neduplikují nějaké činnosti. Volí údajně také výslednou platformu i programovací jazyk. Zabývá se mj. otázkami bezpečnosti systémů, legislativou nebo problematikou zpracování osobních dat v nich.

Jinými slovy, má toho v ideálním případě na starosti celkem dost, jeho povolání vyžaduje na první pohled značnou odbornost a jisté komplexní poznání "ekosystému" těch informačních systémů, se kterými má pracovat či do kterých má zakomponovat systém další, nový.

Co se obvykle říká
Na internetu si obvykle každé moderní či módní povolání - s výjimkou těch naprosto zřejmých či klasických - vymezuje nějaké ospravedlnění. O IT-architektech se tak lze dočíst (většinou přirozeně od IT-architektů), že musejí neustále držet krok s moderními technologiemi, musí se tedy permanentně učit a přizpůsobovat novým trendům. Musí mít nadhled a silné analytické schopnosti. Jejich práce spočívá v tom propojit technickou stránku s managementem a případně legislativním pozadím a stát se mostem mezi objednatelem a dodavatelem.

Bývalý programátor, bývalý ajťák
Jeden druh legitimizace se dá zaslechnout poměrně často. Lidé od fochu, kteří nějakým rychlým způsobem přeskočili do kategorie IT-architektů (ale týká se to obecně IT-pracovníků všeho druhu) používají několik opakujících se frází. V tom lepším případě jde o připomenutí, že je "bývalý programátor", v horším třeba "bývalý ajťák", "vystudovaný ajťák" apod.

Na první pohled to nemusí člověka napadnout, protože to zní seriózně; ale na druhý pohled si musíte položit otázku - proč to vlastně říká? Žádný vývojář o sobě veřejně neřekne, že je "bývalý ajťák", nebo že "to vystudoval". Žádný programátor neřekne, že je "bývalý IT-architekt". Dokonce snad žádný majitel autodílny, který už dělá spíše management a řídí lidi pod sebou, že je "bývalý automechanik". Nic bývalého není - buď tím jste, nebo tím nejste.

Z toho je mj. zřejmé, jak účelové je tu ospravedlnění, získání respektu a autority. Chce tím snad říci, že spousta jiných IT-architektů - na rozdíl od něho - nejsou ani ajťáci, natož bývalí programátoři? Ano, to je jistě pravda. Nebo, že než jsem začal působit v této "manažerské pozici", vím něco i o té "provozní"? Také dobré. Ovšem hlásit se k tomu, že jsem někdy v minulosti něco dělal nebo to studoval, ale nyní už mi ujel vlak, tak tomu "šéfuji", mi přijde poněkud zoufalé. U bývalých programátorů je navíc situace podobná jako u programátorů současných: Vždy se můžete jednoduše zeptat, co konkrétně naprogramoval, co vytvořil? Jaké produkty, které on sám vytvořil nebo na kterých se podílel, jsou na trhu? Nemůže se prakticky stát, že něco programoval a neví co. Pokud tomu tak je, buď lže, nebo byl extrémně neúspěšný programátor.

Jaké postavení mají
Nezkoumám teď nějaké mezilidské vztahy v kolektivech, ale spíše společenský aspekt. Ačkoli firmy i státní sféra pořád naříkají nad nedostatkem vývojářů, jsou navzdory tomu ochotny platit IT-management i mnohem lépe než vývojáře samotné. Už samo rozlišování na "IT-architekt-programátor" není nejvhodnější, neboť inklinuje k (obrazně řečeno) "architekt-dělník", což je z pochopitelných důvodů dehonestující pro všechny, kdo nejsou na straně "architekta". Tím spíše, když nejde v konečném důsledku jen o názvy, ale o reálné postavení, které toto rozlišování zakládá.

V jedné firmě mi na pohovoru otevřeně tvrdili, že můžu začít na pozici programátora a "vypracovat se postupem času na IT-architekta". Tím jasně říkají, jak mají zařazené tyto pozice. Málokterý vývojář má ambice stát se "architektem" a "někam se vypracovávat" mimo další programovací jazyky. On chce psát kód. Jsou to dvě cesty, které se nesbíhají, byť k sobě mohou mít velmi blízko - třeba jako elektronika a informatika. Zkušenosti architekta se můžou hodit programátorovi a zkušenosti programátora architektovi. To se nedá popřít. Ale aby se člověk lineárně někam posouval od jednoho k druhému a přitom to chápal tak, že jde od něčeho nižšího k něčemu vyššímu, je absurdní. Elektronik není "výš" než informatik a informatik není "výš" než elektronik.

Jak to vidí programátor
Jeden zásadní rozdíl mezi snad jakýmkoli IT-povoláním a povoláním programátora spočívá v tom, že IT-povolání lze s větší či menší šikovností a s jistou mírou úspěchu provozovat bez skutečné znalosti věci nebo jen z určitého druhu nadšení pro věc.

Je tak mnoho různých IT-specialistů včetně IT-architektů, kteří mají široký přehled o problematice, odebírají odborné časopisy i sami publikují, přednášejí, mají skvělé rétorické schopnosti a často i vzdělání, zajímají se o novinky v oboru a jsou silně podpořeni také tím, že zastávají tuto poměrně vysokou profesní funkci, nezřídka špatně placenou. Ovšem je otázkou, nakolik je to vše rozhodné pro postavení (dobrého) systému. Nechápejte mě špatně, nemyslím si, že by se nedalo poučit od někoho či fundovaně konzultovat s někým, kdo takové zkušenosti má. Pro mě jako pro vývojáře - pokud mám postavit systém - to ale není přesně ten druh znalostí, které v danou chvíli potřebuji nebo apriori vyhledávám; je to spíše přidaná hodnota, asi jako pro lékaře může být přidanou hodnotou nějaký hlubší vhled do toho, jak funguje zdravotnictví v jeho kraji a jaké jsou možnosti jeho dalšího rozvoje. S medicínou samotnou to ale nemá moc co dělat.

Čili programátor nikdy nemůže dělat programátora, pokud neumí programovat. IT-povolání lze naopak provozovat s různou dávkou umu, znalostí problematiky a konečně i štěstí, neboť to nevyžaduje žádný ověřitelný praktický výstup ani exaktní ověření znalostí v krátkodobém horizontu. Navrhnout informační systém, který tu bude za 5-7 let a na jehož realizaci bude pracovat dalších 15 fluktuujících lidí a 3 firmy, mě prostě chtě nechtě zbavuje jisté míry odpovědnosti za výsledek.

Praktické výstupy jsou ostatně prubířským kamenem. Relativně snadno můžete mluvit o tom, jak mají věci ideálně být, jak se má udělat ten který systém, co by měl obsahovat a umět. Možná si i poradíte s jeho designem i případným dohledem nad tím, zda to vývojáři dělají podle vašich představ. Podlehnete i dojmu, že systém svým způsobem tvoříte.

Kdo je "chytřejší", protřelejší, dovede tyto názory kultivovaně formulovat a velmi přesvědčivě působit. Ovšem zkuste si udělat nějakou složitější tabulku v Excelu, zkuste bezzávadně spojit dvě tabulky v Excelu, nebo tři. Zjistíte, že i taková banalita může být mnohem obtížnější, než produkovat a formulovat kvanta odborných názorů.

Neříkám to jen tak. Nejednou jsem byl svědkem toho, jak architekt vymyslel řešení, kde v databázi nebylo primárním klíčem číslo (ale řada číslic), nebo byla postavena špatně databázová struktura. Nakonec to značně prodraží a zneefektivní celý systém a musí se to předělat, přitom by stačilo, kdyby měl daný architekt už na začátku alespoň triviální praktickou zkušenost s tím, jak se databáze dělají.

Z toho také vyplývá, že za programátora se těžko může schovat člověk, který by neprogramoval. Tvrdím, že za IT-architekta se, bohužel, schovat může. Jakmile navíc působí více IT-architektů pohromadě (např. ve státní správě či velkých firmách), riziko využití takové funkce k pragmatickým účelům či osobní realizaci se zvyšuje. Je tím aktuálnější, čím méně programátorů (či odborníků s exaktními poznatky) je na pracovišti, neboť odpadá i elementární prvek kontroly nad jejich znalostmi.

Kdo vybírá jazyk?
Kuriózní mně přijde, že IT-architekt by měl vybírat programovací jazyk. Abych se vyjádřil přesněji: V ideálním případě by to tak mohlo a možná i mělo být, ale v praxi, kde IT-architekti mají běžně takřka nulové (či nějaké historické) zkušenosti s programováním, je taková kompetence doslova groteskní. Dovedu si představit, že je nutno hlídat kompatibilitu a následnou udržitelnost systémů. Jestliže mám 8 systémů v Javě a potřebuji další do jejich rodiny, bylo by asi záhodno mít ten další v Javě, aby náš tým byl akceschopný a mohl případně odstranit vyskytující se chyby atp. Taková situace ale skoro nikdy nenastává. Většinou se vymyslí nový systém, aniž by existovala důkladná znalost předchozích systémů, natož v jakém programovacím jazyce jsou napsané (opomíjím fakt, že těch jazyků může být více a že může být rozhodující kdejaký framework či knihovny nežli jazyk).

Je třeba také přihlédnout k tomu, že programovací jazyky jsou dnes velice variabilní (např. v určitém čase mají určité možnosti a v jiném jiné), konvertibilní, některé jsou zase značně přeceňované kvůli svému komerčnímu postavení na trhu. Existuje taky nějaká reverze, dekompilace, refactoring. Dva příklady za všechny: Architekt určí projekt ve VB.NET. Já ale budu umět jiný Basic, třeba PureBasic. Protože je VB.NET díky vlivu Microsoftu známý, možná nebude architekt o PureBasicu ani tušit. Přitom řešení, které nabízím všanc, může být mnohem vhodnější a také levnější. Výsledek včetně kompatibility bude 100% stejný. Druhý příklad: Architekt určí použít Javu tam, kde není moc vhodná. Na některé systémy se objektové programování ani nehodí. Ale vycházeje z předchozí praxe mu to přijde naopak příhodné. Tím však prohlubuje problém, který nastavil už někdo (možná i on) na začátku. Z těchto příkladů (a mohli bychom jich uvést více) je vidět, jak podstatné je programování znát, pokud chci o takové věci rozhodovat.

Státní správa
Situace ve státní správě má zajisté mnoho - jak pozitivních, tak negativních - specifik. Zdůrazním jedno, které mi přijde v souvislosti s IT povoláním podstatné.

Státní správa jako by nepotřebovala mnoho programátorů, postačí si (kromě provozu ICT samozřejmě) s IT-architekty, IT-poradci a IT-konzultanty. Ti vymyslí a zkonzultují zakázku, systém, doporučí jej vedení a prostřednictvím outsourcingu se tento systém zrealizuje.

Možná se to zdá být normální, protože taková je praxe. Možná na tom nikdo, kdo pořádně neprogramoval, nevidí nic dalece závadného. Avšak tento přístup nese různá rizika, o nichž se strana zadavatele dozvídá obvykle až po výsledné realizaci a dodání. Tyto vady se pak nákladně minimalizují, např. změnovými požadavky.

Jde především o to, že se zde tím pádem více než jinde lehce kumulují týmy těch IT-povolání, která nemají reálný základ. Celé oddělení IT-poradců vyžaduje v podstatě posuzovat IT-zakázky v kontextu s již existujícím prostředím informačních systémů plus třeba legislativním prostředím a nějakým způsobem se pohybovat mezi státem a firmami; ale na druhou stranu neprodukovat žádnou vlastní hodnotu. Jestli je v týmu 10 konzultantů nebo 12 je - uznejte sami - nakonec jedno. Je přitom otázka, jestli erudice oněch 10 nebo 12 lidí může dát erudici jednoho programátora. Analogicky, jestli dovednosti 10 nebo 12 sportovních komentátorů či znalců sportu mohou dát dohromady dovednost jednoho fotbalisty.

Z tohoto důvodu jsem napsal slovo "jako by" nepotřebovala mnoho programátorů. Domnívám se ale, že ve skutečnosti potřebuje naopak skoro výhradně programátory, kteří by i konzultační servis dokázali suplovat fundovaněji než týmy "IT-specialistů" nemajíce za sebou žádný reálný výstup a nemajíce tedy ani s žádným reálným procesem valné zkušenosti. To, že splňují nějaké formální parametry (které se navíc zpravidla zakládají na téže praxi, kterou dělají a ta je také generuje), nemá v IT žádný nosný význam. (Tím je myšleno: Dosadí mě jako vedoucího do nového IT oddělení, kde pobudu 2 roky; pak můžu navždy v CV uvádět, že jsem byl vedoucím IT oddělení 2 roky. Na další místo mě vezmou proto, že mám praxi v IT 2 roky. Takto se mi postupně během 10 a více let hezky naplní CV. Přitom to nedokládá jedinou kvalifikaci v IT.)

Dochází rovněž k vytváření kruhu - řekněme nadneseně - s "okultními" prvky. Tým IT-specialistů si brzy vytvoří své ptydepe, umělý jazyk, kterému rozumí jen oni a nerozumí mu ani programátor. Neobsahuje často ani správné pojmy z informatiky. Jednak vytvoří určitý druh specializace, do které se obtížně proniká. A do třetice, vytvoří unikátní "ekosystém" informačních systémů, které mezi sebou mají různé vztahy a lze je zvnějšku velice obtížně zmapovat a pochopit. Asi jako když si nechám postavit bludiště, do něho další bludiště, a do něho další; a nakonec se stanu jediným, kdo ví, jak se tato bludiště stavěla a také jediným, kdo má tušení, kde co najít. A ačkoli vy umíte stavět sebelépe bludiště, budete v něm něco hledat věčnost.

Ideální tým
Podle mého soudu je ideální tým - v případě stavby velkých systémů - vždy tvořen několika programátory a jedním IT-architektem. Tento architekt by měl splňovat však jisté normy, zejména být skutečně zkušeným programátorem a současně být manažersky či legislativně zdatný. Potud by jeho role byla vskutku exkluzivní a drahá. Jestliže ale jedno z toho nesplňuje, je pro programátory i projekt spíše přítěží.

Čím více lidí do problému mluví, aniž by kdy jeden z nich programoval, zvyšuje se pravděpodobnost na zaručeně chaotický výsledek. Chaos je větší, pokud jsou pracovní místa navíc nestabilní a lidé se na nich často mění.

V jakémkoli týmu se není třeba obávat, že nějaký vývojář jako jedinec totálně přestřelí svoje možnosti, technické možnosti nebo navrhne řešení, které je úplně nepřijatelné. Takové případy se asi jistě budou vyskytovat, ale rozhodně budou výjimečné. Můžete se maximálně obávat, že nerozumí legislativě, licencím a obchodním vztahům s třetími stranami.

Každého programátora, kterého se zeptáte, jak má vypadat nějaký nový informační systém a jak zajistit jeho kompatibilitu mezi ostatními systémy, bude mít celkem jasnou představu a nebude ani fantazírovat, ani se unášet povrchními znalostmi, které nabyl při čtení odborných časopisů nebo na internetu. Zda k tomu potřebuje pomoc IT-architekta, jehož erudice za jeho přesně v tomto směru zaostává, je značně diskutabilní. O tom, kdo má větší kompetenci, nemá rozhodovat postavení či pracovní místo, ale reálná znalost problému. A pokud IT-architekt patří spíše ke specialistům, kteří nemají o programování potuchy, můžou s klidem malovat různá schémata a diagramy, které však budou mít jen omezenou hodnotu. Papír snese všechno.

Závěrem
Chtěl jsem nabídnout pohled z druhé strany, z praxe, tj. nikoli jen pohled učebnicového, ideálního světa. Nic více, nic méně. Jde o mou subjektivní perspektivu a mohu se mýlit. Jsem stará škola a možná přestávám rozumět novým trendům. Jisté zkušenosti ve mně také vyvolávají předpojatou nedůvěru. Ale jedno vím jistě. Všude, kde jsou lidé, budou také podobné tendence. Jestliže určité povolání nevyžaduje exaktní měřitelnou znalost, můžete se spolehnout na to, že se kolem něho budou množit lidé různé kvality, vzdělání, postavení, znalostí i zájmů. Tyto týmy si nakonec samy určí hladinu kvality, kvalifikace a dalších kritérií a vstoupit k nim bude vyžadovat jimi stanovený "rituál".

Exaktní měřitelná znalost toto nedovoluje. Z místa programátora si trafiku neuděláte. A z místa IT-poradce? - odpovězte si sami ;-)

Rovněž je mi proti srsti přeceňování společenského postavení. Jestliže se stanu IT-architektem, tj. dostanu pracovní smlouvu na takové místo, nedělá to ze mě ještě žádného experta. Připomíná mi to historku, kterou vyprávěl R. P. Feynman (nositel Nobelovy ceny za fyziku), jenž vyšetřoval katastrofu Challengeru. Všichni před ním se ptali těch nejvýše postavených lidí v NASA, jak k tomu mohlo dojít. Nakonec běžní inženýři, kteří dávali raketoplán dohromady a za kterými nikdo nešel, věděli o problémech raketoplánu nejvíc. Věděli i to, jak se to mohlo stát.

Samozřejmě, že mezi IT-pracovníky lze najít velmi zkušené i nanejvýše potřebné IT-architekty. Ale musíte být velice obezřetní. Možná i ti sami budou bojovat o své místo na výsluní, aby ukázali, že jsou lepší než ostatní. Zkrátka a znovu, kde se nedá něco změřit, musí se přistoupit k přesvědčování - což může být (třeba pro introvertní jedince) problém.

Úplný závěr - sečteno, podtrženo :)
Podle mého názoru existuje v oboru IT jediný smysluplný požadavek - ukažte nám vaše portfolio, vaše produkty. Všechno ostatní (skvělá CV, certifikáty, zastávané funkce) mívá většinou spektakulární význam. Jediná věc, která zakládá skutečnou kvalifikaci, je vaše dílo.

Komentáře

Celkem 0 komentářů

  • Neregistrovaný uživatel

    Jméno: Přihlásit se

    Blog:

    Obsah zprávy*:

    Kontrolní kód*:
    Odpovězte na otázku: Co je dnes za den?