Zawód: Architekt Systemów. Michał Hoffmann

Celem pracy projektanta/architekta systemów teleinformatycznych jest zaprojektowanie systemu spełniającego przedstawione przez zamawiającego wymagania funkcjonalne i niefunkcjonalne. Tyle jeśli chodzi o definicję Architekta Systemów pochodzącą z klasyfikacji zawodów i specjalności o numerze 251103. Jak w rzeczywistości wygląda praca architekta systemów? O tym opowiedział nam Michał Hoffmann z Atena Usługi Informatyczne i Finansowe.

Michał Hoffmann. Architekt Systemów w Atena Usługi Informatyczne i Finansowe S.A.. Magister informatyki, absolwent Wojskowej Akademii Technicznej w Warszawie. Karierę rozpoczynał w 1998 roku jako programista Clipper. Od 2001 roku z krótkimi przerwami związany z firmą Atena Usługi Informatyczne i Finansowe S.A. W Atenie rozpoczynał jako programista Oracle/Sybase PowerBuilder. Od 2005 związany z rozwojem oprogramowania w języku Java na platformie Java Enterprise Edition.

W kontekście pracy architekta systemów, dużo mówi się o technologii, a za mało o kompetencjach miękkich. A trzeba wiedzieć, że Architekt to nie facet z brodą siedzący w piwnicy i malujący jakieś kwadraciki. Jesteśmy wyznacznikiem tego, co i jak będzie w projekcie realizowane.

Najbardziej, co przeszkadza w moim zawodzie, to zdarzający się od czasu do czasu brak dobrej organizacji pracy w projekcie. Przez to, w przypadku sytuacji kryzysowych, następuje niepotrzebny chaos i stres. Każdy biega z przysłowiową “pustą taczką”, ale nie zdąża jej załadować.

Trudność sprawiają także ludzie, którzy żyją w przekonaniu, że ich problem jest najważniejszy i kluczowy. Potrafią oni skutecznie zdezorganizować całe przedsięwzięcie. Ale zanim o zaletach i wadach tej pracy, przejdźmy do listy zadań, które wykonuję na co dzień.

Lista zadań Architekta Systemów

• Weryfikacja poprawności funkcjonowania systemów produkcyjnych, które mam w opiece (jira, kontakt z bezpośrednimi opiekunami, rzut oka na logi),
• Weryfikacja postępu prac w aktualnie rozwijanych projektach lub w zgłoszeniach produkcyjnych (bezpośrednie rozmowy z wykonawcami, indywidualnie lub na spotkaniach projektowych),
• Współpraca z PM-ami oraz managerami, planowanie prac i szacowanie pracy na wysokim poziomie,
• Przeglądy kodu, wspólna analiza z realizującymi go programistami, wyznaczenie dalszego kierunku działania, wsparcie merytoryczno-techniczne,
• Architektura i projektowanie:
  • Projektowanie i modelowanie wewnętrznej architektury systemu: wybór i zastosowanie metodyki, frameworków, podział na komponenty, model bazy danych, prototypy GUI itp.,
  • Projektowanie i modelowanie integracyjnej architektury systemu: modele integracyjne, co, z czym, kiedy, jak i po co będzie się komunikować oraz spotkania i wypracowywanie modeli integracyjnych z innymi właścicielami komponentów uczestniczących w integracji,
  • Projektowanie i modelowanie technicznej architektury systemu: bazy danych, serwery aplikacyjne, message brokery, sizing tych elementów,
  • Współpraca z analitykami, wsparcie ich w modelowaniu funkcjonalności, wskazywanie możliwości i ograniczeń.
• Ogólnie pojęta dokumentacja techniczna,
• Kontakty z klientem: prezentacje architektury systemu będącego przedmiotem oferty, kontakt z działami IT, wspólne rozwiązywanie problemów wdrożeniowych i po-wdrożeniowych,
• Badanie “nowości technicznych” i ich wdrażanie, nowe narzędzia, metodyki itp.,
• Implementacja.

Codzienność Architekta Systemów

Wiele mówi się na temat automatyzacji pracy, ale są elementy mojego dnia, których nie da się zautomatyzować. Właściwie wszystko co związane z architekturą i modelowaniem można zaliczyć do kategorii procesów nie dających się w stu procentach zautomatyzować. Dlaczego? Ponieważ wbrew pozorom, okazuje się, że każdy dedykowany system jest inny i wymaga innego podejścia. W Atenie od ponad 25 lat budujemy systemy obsługujące ubezpieczenia. Pozornie każda firma ubezpieczeniowa działa w tych samych warunkach prawnych, zatem można by założyć, że można wszystkim wdrożyć sparametryzowanego “gotowca”. Wchodząc w szczegóły biznesu każdego klienta okazuje się, że jednak tak się do końca nie da.

Jest oczywiście pewien parametryzowany “core” systemu. Cały czas pracujemy nad nim, aby obejmował jak najwięcej funkcjonalności. Jest to jednak branża, w której klienci mają dużo pomysłów. My również pracujemy nad tym, aby nowymi funkcjonalnościami wspierać biznes klienta.

Z drugiej strony wiemy, że to wszystko wydaje się być ostatecznie powtarzalne, zatem możliwe, że dojdzie kiedyś do tego, że te czynności będzie robić uczące się AI. Będzie ono “podrzucać” nam gotowe schematy, a my będziemy je rozszerzać gdy ludzka fantazja wytworzy coś nowego. Nieoceniona pozostaje także werbalna komunikacja z wszystkimi uczestnikami przedsięwzięcia. To jest coś czego pewnie długo nie da się zastąpić.

Umiejętności

W codziennej pracy oprócz tzw. nowych projektów, w których wszystko możemy zbudować od zera, rozwijają mnie napotkane problemy, a szczególnie te niespodziewane. Mocno inspirują one do poszukiwania wiedzy: przecież na pewno ktoś już taki problem miał. Naszą wartość podnoszą także kontakty z ludźmi o różnej mentalności – oczywiście pod warunkiem, że jesteśmy otwarci na rozwijanie umiejętności miękkich.

Przyznam, że zaskakuje mnie podejście niektórych młodych ludzi wchodzących do zawodu. Pojawiają się osobnicy, którzy mają postawę mocno roszczeniową. Stoją w przekonaniu, że skoro pracodawca ich zatrudnił i oczekuje od nich, że będą coraz efektywniejsi to ma on obowiązek również zapewnić im pełen pakiet rozwojowy w godzinach pracy oraz spokojnie i cierpliwie przyglądać się popełnianym przez nich błędom.

Chcę być dobrze zrozumiany: szkolenia, wyjazdy na eventy itd. to standard, którego powinniśmy oczekiwać, ale uważam, że należy też włożyć dużo od siebie. Jak ktoś mi mówi, że nie ma czasu po pracy pogłębiać wiedzy, to myślę sobie, że powinien zmienić zawód na jakiś mniej wymagający.

Architekt Systemów, w mojej opinii, powinien mieć:

• Doświadczenie z różnych szczebli: młodszy programista, programista, projektant,
• Doświadczenie z realizacji na różnych szczeblach paru systemów, najlepiej w różnych technologiach z innymi założeniami,
• Szerokie kompetencje techniczne (niekoniecznie w super szczegółach, aczkolwiek im więcej, tym lepiej): bazy danych, serwery aplikacyjne, narzędzia integracyjne, frameworki, metodyki,
• Kompetencje miękkie. Dużo rozmawiamy i ustalamy z wszystkimi na około. Od programistów, project managerów do zarządu. Należy też mieć gotowość do rozmowy z klientem który nie zawsze bywa łatwy w obyciu.

O tym co najtrudniejsze w pracy Architekta

Lata doświadczeń nauczyły mnie, że każdy dzień może być na tyle trudny, na ile pozwolimy nim być. Należy trenować w sobie wewnętrzny spokój i nie dopuszczać do siebie zbędnego stresu. Zdecydowaną większość problemów w naszej branży da się rozwiązać. Problemem jest zazwyczaj dotarcie do wiedzy jak to zrobić. Oczywiście nie jest tak, że zawsze udaje się uniknąć stresu. Pojawia się on przeważnie przed wdrożeniem, gdy coś co miało działać nie działa, gdy okazuje się, że coś co miało być zrobione nie jest zrobione, gdy popełniliśmy błędy a popełniają je wszyscy. W tym kontekście cenne są retrospektywy, gdzie na chłodno możemy spojrzeć co poszło nie tak i jak temu przeciwdziałać w przyszłości. Opiszę jeden z trudniejszych dni w pracy, który miał miejsce lata temu i przydarzył się jeszcze takiemu mid programiście, którym byłem.

W czasach, kiedy proces wytwarzania był mało skomplikowany, mało kto słyszał o czymś takim jak TDD, a testy jednostkowe pisał gdzieś, ktoś tam. Analitycy dostarczali materiał, programiści kodowali, a testerzy testowali i zasadniczo wszystko wtedy było oczywiste, jak w waterfallu. Byłem w dniu wdrożenia, a odpowiadałem za proces, który generował “tony” dokumentów. Podziwiając swój kawałek kodu, przyglądałem się jednemu IF-owi i wydawał mi się brzydki. Ze względu na to, że warto dbać o czystość kodu i jego czytelność, zabrałem się za poprawianie.

Teraz był ładniejszy, a przecież nic w logice nie zmieniłem, więc postanowiłem wypuścić zmianę. Nikt nie zwrócił na nią uwagi, więc poszła z przygotowywaną wersją na produkcję. Jednak logika zmieniła się i kilka ryz papieru u klienta poszło do kosza. Funkcjonalność była elementem tego wdrożenia, zatem klient delikatnie mówiąc nie był zadowolony. Następny dzień był jednym z moich najtrudniejszych. Spędziłem go w gabinecie czerwonego ze złości kierownika. Przeżyłem i wiele się wtedy nauczyłem.

Oferty pracy z