GFT PiąTech #9: Kim jest Architekt IT?


Architekt Oprogramowania – to brzmi dumnie! Ale kim tak naprawdę jest Technical Architect? Dowiecie się tego z dziewiątego odcinka GFT PiąTech, czyli naszego tech-talkshow bez PPT. Zapraszamy do obejrzenia nagrania z rozmowy Marcina Kowalskiego, Head of Development, z Jarkiem Szczepankiewiczem, szefem Architektury w GFT Poland.

Kliknij, aby obejrzeć nagranie

Podczas spotkania zadaliście mnóstwo fantastycznych pytań – dziękujemy! Nie na wszystkie wystarczyło czasu podczas sesji, dlatego spieszymy z odpowiedzią poniżej.

Czy stosujecie jakieś metodologie i frameworki architektoniczne lub języki modelowania architektury?

Jarosław Szczepankiewicz: Większość z nas w GFT nie używa jakichś rozbudowanych formalnych metodyk dokumentowania (TOGAF etc.). Najczęściej stosujemy diagramy komponentów, sekwencji. Na wysokim poziomie abstrakcji widzę duże korzyści z używania DDD jednak nie jest robione w pełnym tego słowa znaczeniu (podział na domeny i komunikację między nimi bez implementacji agregatów).

Nie kodując nawet na poziomie integracji usług, w jaki sposób jesteś w stanie określić ile pracy zajmie zespołowi dev, czy dane rozwiązanie sprawdzi się? Chodzi nawet o wybór pomiędzy użycie EKS a np. Lambda.

JS: Mam wystarczające doświadczenie i obeznanie w technologii żeby rozumieć implikacje. Poza tym, obu rzeczy używałem i stawiałem samodzielnie, nie robię tego na co dzień, ale to nie znaczy że znam pojęcia jedynie z dokumentacji :). Poza tym, sprawę ułatwia fakt bycia doświadczonym inżynierem. Pamiętajmy, że jeśli architekt nie zna szczegółów, to zawsze może zapytać specjalisty w temacie, a estymaty zazwyczaj i tak pochodzą od teamu implementującego.

Czy w chmurze nie jest tak, iż rola software architect jest mniej znacząca, zwłaszcza gdy korzysta się z rozwiązań Cloud Native ?

JS: Według mnie rola software architekta (jeżeli zdefiniujemy go jako modelera BC, integracji i komunikacji) jest raczej niezmienna z uwagi na rosnące zastosowania K8S, który uabstrakcyjnia problemy środowiska. Nie powiedziałbym raczej, że jego rola jest mniej znacząca. Problemy są raczej te same lub podobne co on-prem.

A nie obawiasz się, że Twoje decyzje są dalekie od optymalnych merytorycznie ? Odejście od konkretnych doświadczeń niesie za sobą brak dogłębnego zrozumienia tematu. Jak uzupełniasz tą wiedzę ?

JS: Jeżeli porównamy wymagany poziom znajomości szczegółów danej technologii, to rola architekta vs inżyniera wymaga szerokiej, ale nie tak głębokiej wiedzy do sprawnego podejmowania decyzji. Dlatego często szczegóły implementacyjne pozostawia się w gestii inżyniera specjalizującego się w danej technologii. Inżynier specjalizujący się w danych rozwiązaniach z kolei nie ma często wystarczającej wiedzy cross-technologicznej do całościowego zaprojektowania rozwiązania (bo nie można się specjalizować w takiej liczbie tematów w jakiej często jest wymagane od architekta). Oczywiście upraszczam, ale staram się pokazać że architekt vs inżynier to trochę inne spektrum wymagań. Dodałbym do tego, że większość architektów, których znam, była kiedyś inżynierami – co znacznie ułatwia pracę. Przykładowo, do pracy architekta nie jest niezbędne znanie na wylot Springa, wystarczy wiedzieć że jest to IoC + biblioteki integracyjne. Inżynier już powinien znać sposób konfiguracji Springa żeby sprawnie implementować. Architekt natomiast powinien rozumieć konsekwencje wyboru Spring vs np. serverless (lambdy) przy wyborze tego, w jaki sposób implementować mikrousługi. 

Czy architekci narzekają na design innych architektów, tak jak programiści narzekają na kod innych programistów?

JS: Zdarza się to, ale raczej rzadko, nie ma procesu code review typowego lub kolaboracji architektów o tej samej specjalizacji, częściej zdarza się, że architekt networkingu współpracuje z security i architektem infrastruktury. To naturalnie powoduje pewne uzupełnianie się i raczej wszyscy doceniają taką współpracę cross-domenową. Oczywiście, tak jak wszędzie, jeżeli widać brak wiedzy/doświadczenia, to zawsze będzie przeszkadzać i utrudniać sprawna pracę.

Jarosław Szczepankiewicz ma kilkanaście lat doświadczenia komercyjnego w IT i bogaty track record w projektowaniu aplikacji opartych na JVM dla sektora finansowego. To nasz guru architektury – odpowiada za stabilność skomplikowanych konstrukcji software’owych w wielu projektach dla globalnych klientów. A przy okazji ma aktywny wpływ na rozwój globalnego partnerstwa naszej firmy z AWS i rozwija społeczność AWS Cloud w GFT Poland. Ma w kieszeni pozwolenia na budowę drapaczy chmur (np. prestiżowe AWS Certified DevOps Engineer Professional) i bogate doświadczenie w skutecznym łączeniu działań na linii DevOps – Development.