Na czym polega praca Enterprise Architecta? “Zadaję pytania i poszukuję odpowiedzi – robię to zawodowo”

Kiedy produkuje się puzzle, najpierw, jeszcze przed wykrojeniem wzajemnie pasujących elementów, na arkuszu kartonu maluje się obrazek. Jeśli na początku wykroi się elementy białego kartonu, zaś dopiero potem na każdym z nich namaluje się linie i kolor – szanse, że po złożeniu zobaczymy spójny obrazek są znikome. I rola Enterprise Architecta jest właśnie taka, by przy budowaniu indywidualnych rozwiązań rozumieć, jaki jest ich szerszy kontekst i zależności z punktu widzenia procesów biznesowych, danych i technologii.

Za co odpowiada Enterprise Architect, albo inaczej mówiąc – co by było, gdyby go nie było w firmie?

Rola Enterprise Architecta polega na całościowym spojrzeniu na transformacje biznesowe wspierane przez rozwiązania IT i zapewnieniu, że jednostkowe inicjatywy są elementami większego, spójnego systemu. Dla przykładu, większość projektów IT zaczyna się od pojedynczego problemu i ogólnego zarysu rozwiązania. Z czasem ten zarys jest wzbogacony o szczegóły. Specjaliści projektują komponenty techniczne, infrastrukturalne, modele danych i wygląd ekranów. W końcu powstaje kompletny projekt rozwiązania pierwotnego problemu.

Jednak takich rozwiązań w firmie takiej, jak Danone jednocześnie powstają setki. Rozwiązania powstawały w podobny sposób przez dziesięciolecia, więc są ich tysiące, ale – co oczywiste – nic nie istnieje w próżni, wszystko jest częścią większego systemu i każda aplikacja ma wpływ na dziesiątki innych. Dane przepływają między aplikacjami, komponenty techniczne są współdzielone, fundusze na inwestycje i czas użytkowników są ograniczone, itd.

Podam prosty przykład. Kiedy produkuje się puzzle, najpierw, jeszcze przed wykrojeniem wzajemnie pasujących elementów, na arkuszu kartonu maluje się obrazek. Jeśli na początku wykroi się elementy białego kartonu, zaś dopiero potem na każdym z nich namaluje się linie i kolor – szanse, że po złożeniu zobaczymy spójny obrazek są znikome. I rola Enterprise Architecta jest właśnie taka, by przy budowaniu indywidualnych rozwiązań rozumieć, jaki jest ich szerszy kontekst i zależności z punktu widzenia procesów biznesowych, danych i technologii. Czyli nadrzędne pytanie, jakie zadaje sobie osoba na tym stanowisku brzmi: „Jaki końcowy obrazek chcemy zobaczyć po złożeniu wszystkich elementów?”.

Na czym polega Twoja codzienna praca?

Najlepszą metodą na przełamanie barier i zrozumienie zależności między inicjatywami prowadzonymi przez różne zespoły jest zwyczajne zadawanie pytań oraz wspólne poszukiwanie odpowiedzi. Dlatego Architect znaczną część dnia spędza na spotkaniach i rozmowach, które pozwalają na wydobycie ukrytych relacji i większego obrazka z elementów puzzli. Poznawanie kilku projektów dziennie umożliwia też odkrycie nowatorskich rozwiązań albo technologii w jednym projekcie i rekomendowanie ich ponownego użycia w innych. Wspólne wyjaśnianie niewiadomych jest też zawsze bardziej odkrywcze i skuteczniej budujące konsensus niż forsowanie własnych idei.

Oczywiście Enterprise Architect tworzy też dużą ilość dokumentacji architektonicznej w formie diagramów, katalogów rozwiązań czy matryc zależności. Jednak ta dokumentacja jest tylko zwieńczeniem pracy, której celem jest zrozumienie wspomnianych zależności.

Drugim aspektem roli Architecta jest rozumienie tego, jakie są: cele i strategia firmy, istniejące rozwiązania, problemy oraz trendy w technologii i praktykach operacyjnych. Czyli mówiąc ogólnie oznacza to bycie na bieżąco z szerszym kontekstem dla projektów. Bardzo obrazowo przedstawia to anegdota o Albercie Einsteinie. Student zapytał go kiedyś, dlaczego drugi rok z rzędu zadaje te same pytania na egzaminie. „Ponieważ zmieniły się odpowiedzi” – usłyszał wyjaśnienie. Dziś odpowiedź na pytanie: „Jakie technologie powinniśmy zastosować, żeby pozostać konkurencyjni?” zmienia się nawet nie szybko, ale stale. Dlatego żeby móc zadawać właściwe pytania i rozumieć odpowiedzi, Architect zwyczajnie spędza dużo czasu na nauce. Istotną pomocą są szkolenia i certyfikaty, a także konferencje i literatura specjalistyczna.

Oba te aspekty mają jedną cechę wspólną: dziedzina, w której pracuje Architect jest zawsze złożona, nowa i dynamiczna. Strefa powtarzalności jest minimalna, a doświadczenie i wiedza zdobyte w przyszłych projektach mogą być jedynie referencją.

Dlatego odpowiedź jednym zdaniem na pytanie: „Na czym polega Twoja codzienna praca?” brzmi: „Jestem ciekawy, więc zadaję pytania i poszukuję odpowiedzi – i robię to zawodowo”.

Od czego zaczynałeś w IT? Jaka była Twoja ścieżka kariery do miejsca, w którym jesteś obecnie?

Moja ścieżka kariery, podobnie jak wielu moich kolegów po fachu, rozegrała się można powiedzieć w trzech aktach. Zacząłem karierę w IT od hiperspecjalizacji w jednej dziedzinie. Byłem konsultantem SAP dla modułów Planowania Produkcji i Utrzymania Fabryki. Najpierw zgłębiałem swoją wiedzę w tych dziedzinach na zasadzie analizy: moją pasją było zrozumienie coraz większej ilości szczegółów i wstępowanie na coraz wyższe poziomy ekspertyzy.

Jednak po kilku latach zaczęła się we mnie budzić ciekawość świata poza SAP. W 2010 roku przestawiłem się na skrajne przeciwieństwo: zacząłem pracować w audycie korporacyjnym IT. Co dwa miesiące zaczynaliśmy nowy audyt dotyczący nowego systemu, rynku albo dostawcy oprogramowania. Każdy audyt dotyczył białej plamy na mapie firmy, która wymagała odkrycia, zrozumienia i ocenienia potencjalnego ryzyka dla interesu akcjonariuszy i kondycji firmy. Zaczynałem od tygodnia intensywnej analizy dokumentacji, dwóch tygodni prowadzenia wywiadów dotyczących procesów i rozwiązań IT, kolejnych dwóch tygodni testowania zidentyfikowanych kontroli i analizy danych, aby zakończyć podsumowaniem i rekomendacją. To były fascynujące 17 audytów na 4 kontynentach i w 13 krajach. Po audycie systemu zarządzania zasobami ludzkimi w Japonii, sprawdzałem ogólne kontrole w HUB IT w Buenos Aires, po czym leciałem do Tel Awiwu, żeby przeanalizować bezpieczeństwo systemów sprzedażowych.

Po czterech latach, w 2014 roku, zaczął się we mnie na nowo pojawiać bardziej dojrzały głód specjalizacji. Już nie hiperspecjalizacji w jednym systemie, ale wielosystemowych rozwiązań wspierających transformacje biznesowe. Od tego czasu moja kariera jako Architect rozwijała się wokół Zarządzania Łańcuchem Dostaw. To wyjątkowo fascynujący temat, który z natury polega na zoptymalizowaniu sieci powiązanych elementów, przez które przepływają materiały, informacja i fundusze: dostawcy, zaopatrzeniowcy dostawców, magazyny, transport, fabryki, klienci, itd. Jeśli jeden element nie działa prawidłowo, bez względu na to, jak wydajnie pracują pozostałe, cała sieć się zacina. To wszystko dzieje się w dynamicznym otoczeniu zmieniających się kosztów paliwa, regulacji, ceł i preferencji klienta. Dlatego to w tej domenie znalazłem swoją pasję i „profesjonalny” port.

Oferty pracy z

Jak znalazłeś się w Danone? Od kiedy tu pracujesz?

Do Danone dołączyłem w kwietniu 2022 r., po 15 latach spędzonych w Philip Morris International. Jakkolwiek praca w poprzedniej firmie była fantastyczna i bogata w doświadczenia i możliwości, po tak długim okresie zaczynają się pojawiać w głowie pytania: „Jak wygląda świat poza?”. We wrześniu 2021 r. skontaktował się ze mną Danone z propozycją stanowiska EA dla Design to Deliver. W kontekście ciekawości, jak wygląda świat poza, chęci budowania czegoś nowego i mojej naturalnej potrzeby autonomii, dołączenie do nowego zespołu było wyjątkowo atrakcyjne. Dział EA w warszawskim IT&DATA Hubie w Danone właśnie powstaje i wiele procesów, metod i dopasowań do organizacji jest w trakcie samodefinicji.

Jakie umiejętności techniczne musi posiadać Enterprise Architect? Jakie powinien mieć doświadczenie zawodowe?

Enterprise Architect potrzebuje szerokiego pojęcia o różnych dziedzinach. Zdecydowanie świadomość istnienia różnych rozwiązań, ogólnego ich zrozumienia i różnorodnych zastosowań jest ważniejsza niż głęboka ekspertyza w jednej dziedzinie. To nie są tylko kwestie techniczne, ale też biznesowe. Krótko mówiąc, Architect powinien umieć rozmawiać z ekspertami od procesów biznesowych, środowiska rozwoju aplikacji, integracji aplikacji, cyberbezpieczeństwa, itd. Podczas gdy każda z tych domen ma swoich ekspertów, rolą Architecta jest zrozumieć ich propozycje. Nie da się tego osiągnąć, nie mając samemu przynajmniej ogólnej wiedzy w tych tematach. Cytując W. Edwards Deminga: „Don’t ask questions without knowledge”. Świetnym sposobem na utrzymywanie odpowiedniego poziomu wiedzy są kursy i profesjonalne certyfikaty.

A co z umiejętnościami miękkimi na tym stanowisku? Które są najważniejsze i dlaczego?

Najważniejszymi cechami Enterprise Architecta są: niegasnąca ciekawość, umiejętność prowadzenia rozmowy i synteza wielu pozornie niepowiązanych ze sobą elementów w spójną, większą całość. Bardzo też pomaga małe ego. Mając do czynienia z ekspertami w ich indywidualnym dziedzinach, będąc samemu jedynie pasjonatem-amatorem, trzeba uważać, by nie forsować swoich idei, a jedynie pomagać budować konsensus.

Twoja rola wiąże się z odpowiedzialnością i decyzyjnością. Jak sobie z tym radzisz?

Pierwszą lekcją w budowaniu złożonych systemów jest porzucenie perfekcjonizmu i poszukiwania rozwiązania idealnego. Przy wystarczająco dużych systemach architektura nigdy nie jest skończona i często koniecznością jest rozpoczęcie pracy, mając dokładnie zaplanowane kilka przyszłych miesięcy i zaledwie zarys całej dalszej drogi. Z jednej strony, podejmowanie decyzji o rozpoczęciu prac, gdy ma się więcej pytań niż odpowiedzi wydaje się niekomfortowe. Jednak z innego punktu widzenia świadomość, że można skorygować swoje plany, gdy posiada się więcej informacji, w przyszłości pozwala na odważniejsze stawianie kroków.

W Wariacjach Goldbergowskich Jana Sebastiana Bacha jest 75 730 nut. Podobną liczbę nut gra improwizujący pianista jazzowy w trakcie 45-minutowego koncertu. Myślę, że jeśli powiedzielibyśmy improwizatorowi, że musi się nauczyć na pamięć 75 tysięcy nut i zagrać je bez błędu, powiedziałby nam, że jesteśmy szaleni. A jeśli powiedzielibyśmy klasycznemu wirtuozowi, że ma grać przez 45 minut, wymyślając samemu każdą kolejną nutę, powiedziałby że… upadliśmy na głowę. Wszystko jest kwestią odpowiedniego punktu widzenia.

Jakie było Twoje największe wyzwanie zawodowe w obecnej pracy?

Nie ma jednego projektu, który byłby wyjątkowy. Każdy nowy ma swoje specyficzne wyzwania. Czasami to jest rozmiar, jak globalne wdrożenie systemu do Zarządzania Łańcuchem Dostaw. Zbudowanie systemu, który przewiduje sprzedaż, planuje produkcję oraz dystrybucję i poziomu zapasów w 40 fabrykach, 550 magazynach i 150 krajach było olbrzymim przedsięwzięciem. Czasami wyzwanie jest związane z małą ilością czasu na zbudowanie systemu w związku z narzuconą regulacją prawną, a innym razem nawet małe rozwiązanie podlega tak wielkiej ilości zależności, że budowanie koncepcji przypomina zaawansowane ćwiczenia z jogi.

W jaki sposób rozwijasz swoje kompetencje zawodowe?

Najlepszą szkołą jest sama praca. Rozmawiając codziennie z ekspertami, którzy mają wspaniałe pomysły – uczę się od nich. Każda rozmowa to lekcja. Każdą nowa ideę, jaką mam okazję usłyszeć, staram się zintegrować z moimi aktualnymi paradygmatami i dodać do mojej wewnętrznej biblioteki. Drugim źródłem wiedzy jest systematyczna nauka. Żeby zapewnić ciągłość, każdego roku celuję w trzy profesjonalne certyfikaty z technologii bądź procesów biznesowych. Codziennie, ze stoperem w ręku spędzam 30 minut przygotowując się do egzaminu. Zaraz po zdaniu zaczynam kolejny temat. Egzaminy pomagają mi utrzymać dyscyplinę i w klarowny sposób oznaczyć metę, jednak największą wartością są codzienne sesje. Trzecim sposobem jest słuchanie wykładów bądź ciekawych kanałów na YouTube podczas ćwiczeń albo zakupów, oraz czytanie profesjonalnej literatury.

Mam wrażenie, że Enterprise Architect to dość niszowa rola, nie każda firma otwiera takie stanowisko. Co traci firma, nie zatrudniając EA?

Początkowo rola Enterprise Architecta nie była właściwie rozumiana przez rynek pracy. Często widziałem oferty, które pod tytułem Enterprise Architecta opisywały bardzo doświadczonego, hiperwyspecjalizowanego eksperta od infrastruktury bądź środowisk programistycznych. Dopiero niedawno zauważyłem, że firmy zaczęły rozumieć, że w tak szybko zmieniającym się świecie dodawanie rozwiązań IT bez spojrzenia systemowego jest bardzo ryzykowne. Problemami są: niekontrolowane zwiększenie złożoności i fragmentacja przepływu informacji w firmie, nieoptymalne lokowanie inwestycji IT czy przeciągające się wdrożenia wynikające z niezidentyfikowanych zależności. Również w sferze mediów społecznościowych, profesjonalnych publikacji i konferencji dostrzegam wzrastające zrozumienie znaczenia i wartości Enterprise Architectów dla współczesnych korporacji.

Jak wygląda zapotrzebowanie na Enterprise Architectów w polskich firmach (lub takich, które mają w Polsce swoje oddziały)?

Widzę gwałtowny wzrost zapotrzebowania na Enterprise Architectów w dużych firmach. To jest efekt budzącego się zrozumienia, że malowanie wzorków na pojedynczych elementach puzzli nie prowadzi do spójnej wizji wspierającej strategię firmy. Dekadę temu większość firm inwestowała w monolityczne rozwiązania ERP, CRM, SRM i hurtownie danych. Jednak od tego czasu rynek IT zaczął oferować olbrzymią ilość wyspecjalizowanych systemów, które obiecywały łatwe rozwiązanie pojedynczych problemów. Jednak z czasem fakt istnienia w firmach tysięcy wyspecjalizowanych rozwiązań stał się problemem samym w sobie. Ten problem jest wspólny dla większości firm, a dyscyplina Enterprise Architectów jest przeciwwagą dla problemu fragmentacji środowiska rozwiązań IT.

Podsumowując, jakie są najważniejsze korzyści i wyzwania w byciu Enterprise Architectem?

To jest fantastyczna rola dla tych, których motywatorem do codziennej pracy są ciekawość, pasja poszukiwania odpowiedzi i rozwiązywania problemów. Moim ulubionym stwierdzeniem jest: „Nie wiem, muszę się dowiedzieć”. Pisarz SF Robert Heinlein napisał wspaniałe zdanie: „Droga do wiedzy zaczyna się od uświadomienia sobie niewiedzy”. Jeśli jesteś osobą, która co rano budzi się z myślą: „Dzisiaj dowiem się czegoś ciekawego”, 8 godzin pracy jako Enterprise Architect to tylko realizowanie pasji.

---

Jacek Socha. Enterprise Architect pomagający firmom FMCG w globalnych wdrożeniach systemów Zarządzania Łańcuchem Dostaw i szeroko pojętym budowaniu wielosystemowych rozwiązań IT wspierających transformacje biznesowe. W ciągu 18 lat kariery w IT brał udział w kilkudziesięciu projektach wdrożeniowych i integracyjnych aplikacji biznesowych, takich jak SAP, hurtownie danych oraz specjalistyczne rozwiązania IT dla krytycznych procesów.