Tento článok je tlačová správa a je publikovaný bez redakčných úprav.

Michal Vanický je súčasťou medzinárodného tímu architektov koncernu Deutsche Telekom. V Košiciach sa podieľa na návrhu podnikových riešení, zároveň je aj ambasádorom za oblasť IT architektúry. Aké najväčšie výzvy vidí v tejto sfére?

V čom spočíva rola architekta?

Michal Vanický

Z mojej pozície Solutions Architecta tvorím, dá sa povedať, most medzi biznisom a IT stranou. Zákazník, v našom prípade ide o Deutsche Telekom v Nemecku, zadá, čo potrebuje, a s kolegami pripravíme návrh, poprípade aspoň čiastočne implementáciu komplexného riešenia. Je za tým množstvo práce, ako napr. príprava a spracovanie požiadaviek, prieskum technických a netechnických možností, príprava PoC (proof of concept), atď…  V Košiciach sme skupina ľudí, ktorá je súčasťou medzinárodného tímu v rámci koncernu.

Ja osobne som momentálne zodpovedný za návrh aplikácie, ktorá funguje v cloude a má komunikovať s viacerými systémami, prevažne so SAP systémami. Mojou úlohou ako architekta je, okrem iného, navrhnúť komplexné technické riešenie aj to, ako bude vyvíjaný produkt v podnikovom prostredí komunikovať s ďalšími systémami. Musí byť, samozrejme, konzumovateľný klientom, preto ho potrebujem integrovať tak, aby bol schopný dáta získavať, spracovávať a poskytovať na ďalsie spracovanie. Musím pritom zohľadniť možnosti, obmedzenia, výkon, cenu a pod…

Riešime dnes už aj komplexné, veľké projekty, ktoré kedysi pre nás neboli samozrejmé…

Prečo? 

Súvisí to s transformáciou spoločnosti. Ja som v Deutsche Telekom IT Solutions Slovakia, s ročnou prestávkou, od roku 2009. Venoval som sa v tom čase developmentu v SAP prostredí a naša práca spočívala hlavne v tom, že sme dostali konkrétne zadanie, špecifikáciu, čo treba naprogramovať alebo konfigurovať a podľa toho sme robili. V Košiciach sme vtedy nechyrovali o tom, aby bol niekto spomedzi nás dizajnér či architekt. Časom sa u nás začali rozbiehať zaujímavé projekty, už to nebolo prevažne iba o reportingu, monitoringu a práci len na základe špecifikácií, ale postupne sme boli prizývaní k návrhu IT riešení a získavali know-how. Spoločnosť sa začala transformovať smerom k orientácii na produkty. Zvyšovali sme svoje kompetencie a skúsenosti a začali sa nás už pýtať na návrh. Dostávali sme čoraz viac zodpovednosti a logicky aj dôveru.

Dnes pracujeme prevažne v agilnom móde, sme pre nemeckých kolegov v rámci koncernu Deutsche Telekom partnermi a sme súčasťou aj komplexných a veľkých projektov, kde zastupujeme prakticky už všetky typy rolí.

Prečo je architektúra IT riešení dôležitá?

Prirovnal by som to k stavaniu domov – základy a následne stavbu nepostavíte rovnaké v rôznych prírodných podmienkach, ale upravujú sa prostrediu, v ktorom vzniknú a zákaznickým špecifikám. Podobne to je pri architektúre riešení. Príde požiadavka na aplikáciu či portál, ktorý ma fungovať v istom prostredí a musí spĺňať nejaké pravidlá. Pripravíme celú kostru riešenia a do nej následne pridávame komponenty podľa želania klienta a možností, ktoré sú dostupné. Dobre navrhnutá IT architektúra zabezpečí flexibilné, bezpečné a finančne nenáročné narábanie s dátami. Bez kvalitnej architektúry nebude dobre fungovať žiadna IT služba.

Čo považujete za najväčšiu výzvu v rámci architektúry?

Spomenul by som dve. Prvá je to, že táto práca si vyžaduje prehľad vo viacerých oblastiach. Je potrebné vedieť, čo s čím vie a môže komunikovať, čo s čím nie, ako napríklad zabezpečiť prenos dát do a z legacy systémov (napríklad zo SAP-u) spôsobom, ktorý je vyhovujúci v modernom API prostredí, ako aplikovať návrhové vzory v enterprise prostredí, v ktorom aplikácie bežia na rôznych platformách. Človek potrebuje mať široký záber a musí si vedieť vybudovať sieť kontaktov. To je však podľa mňa aj to pekné – IT architekt určuje riešenie, je to na jeho rozhodnutí. Samozrejme, máme vo firme isté požiadavky, ktoré musíme spĺňať – aplikácie musia byť škálovateľné, výkonné, flexibilné, znovu použiteľné…

Dnes je obrovské množstvo možností a nástrojov. Je treba sa v tom orientovať, vedieť, aké sú trendy a hlavne aká je ich relevantnosť. Nie všetko nové je automaticky to najlepšie.

Druhou je bezpečnosť a ochrana, na ktorú koncern veľmi dbá, čo je niekedy veľmi náročné. Je to však dôležitá téma, keďže aplikácie pracujú s citlivými údajmi.

Vedeli by ste uviesť nejaké tipy z praxe pre ochranu dát v architektúre? 

Uvediem aspoň zopár… Páči sa mi tzv. Zero trust architecture, čiže žiaden komponent v architektúre nemá od základu dôveru k žiadnemu ďalšiemu. Moderná architektúra mnohokrát pozostáva z veľkého množstva komponentov, často bežiacich na rôznych platformách. Granularita je teda vysoká a dáta už nie sú spracovávané len na jednom stroji, v jednej službe. Dáta sú často štruktúrované komplexne a jednotlivé služby/komponenty majú rôzne práva k spracovaniu takýchto dát. Je teda veľmi dôležité, aby komunikácia medzi jednotlivými časťami celku bola bezpečná, aby existovala stratégia umožňujúca implementáciu rôznych typov a stupňov zabezpečenia.

Ďalej už len spomeniem napríklad to, že každá komunikácia musí byť autorizovaná a kryptovaná, databázy musia byť tiež kryptované, užívatelia majú mať len tie role, ktoré sú pre nich nevyhnutné a len na nevyhnutný čas a samozrejme, periodicky sa meniace kľúče a heslá.

Na akom najťažšom riešení ste zatiaľ pracovali v Košiciach?

Je to aktuálny projekt. Ten je vlastne akýmsi vyvrcholením snahy našej organizácie za posledných pár rokov. Pre mňa osobne bol najťažší preto, lebo ako pôvodne úzko profilovaný  SAP ABAP developer som mal možnosť pracovať a učiť sa viaceré technológie, architektonické návrhové vzory a samozrejme, stakeholder management. Za posledný rok a niečo som pracoval so: SAP Enterprise Portal EJB, SAPUI5, ABAP, Red Hat Openshift, Spring Boot, Apache Kafka, Docker, Gitlab, NodeJS, Keycloak,certifikoval som sa ako AWS Certified Solutions Architect – Associate, pracoval som s AWS API Gateway, EC2, ELB, S3, Lambda functions,DynamoDB,SNS,SQS. To všetko sú len nástroje, ktoré sa stále učím správne používať. Takisto sa učím na projekte správne aplikovať napríklad microservice architecture, domain driven design, event driven architecture. Boli dni, kedy som potreboval programovať v SAPe (ABAP), potreboval som pripraviť integračný servis v JAVE (spring boot) a k tomu nakoniec frontend (html, css, javascript). Popritom všetkom sú komunikácie na niekoľko strán – zákazník, projektový tím, kolegovia z koncernu, ak bolo treba riešiť korporátne závislosti a pod…

Aký vývoj v oblasti architektúry očakávate do budúcna?

Budúcnosť a vlastne aj prítomnosť je po technickej stránke jednoznačne v cloude, ktorý má flexibilitu, bezpečnosť a finančnú nenáročnosť  vo svojej DNA. Aj my vo firme kladieme veľký dôraz na to, aby boli aplikácie migrované alebo vyvíjané priamo v cloude. Napríklad ak nastane veľký dopyt po nejakom servri, architekt ho identifikuje (ideálne to urobí automat), určí, ktorú virtuálnu mašinu je potrebné vyškálovať a o 10 minút je problém vyriešený. Avšak ani cloud nie je riešenie na všetky problémy a aj v ňom je možné robiť veci zle, draho a nezabezpečene.

Po netechnickej vidím budúcnosť architektov v tom, že ich rola nebude vymedzená prevažne k technickej stránke veci, ale budú pokrývať viacero rolí. Ono to tak viacmenej bolo vždy, len si myslím, že IT sféra si stále viac vyžaduje, aby bol človek schopný plniť viacero rolí. Čiže architekt by mal vedieť robiť aj konzultanta, mal by vedieť do väčšej miery implementovať svoj návrh, v závislosti od zamerania a domény by mal mať niečo z developera, DevOps inžiniera, testera a pod…

Spomenuli ste cloud, aké zmeny prinieslo navrhovanie architektúry priamo v ňom?

Hlavne ide o peniaze a flexibilitu. V cloude si vieme zaobstarať potrebné množstvo zdrojov na čas nevyhnutný pre správne fungovanie našich služieb. Nie je treba kúpiť stroje, ktoré idú na plný výkon 10% času.

Cloud nám dáva možnosti, ako si život uľahčiť keďže množstvo nástrojov je manažovaných a nie je treba sa o ne tak veľmi starať, ako napr. EKS, čo je managed kubernetes v AWS, podobne je to s databázami, sieťovými záležitosťami a pod… Tých manažovaných služieb je neúrekom. Ďalej je to možnosť agilne škálovať. Nehovorím, že škálovať mimo cloudu sa nedá, ale v cloude je to predsa len jednoduchšie. Spomeniem množstvo serverless nástrojov, ktoré majú svoje výhody a tiež podporu pre IaC (infrastructure as code). To všetko je dobrou bázou pre návrh aplikácií, ktoré vieme vybudovať rýchlejšie, lacnejšie.

Značky: