Ja, Architekt!

Jak i dlaczego zostać architektem:) ? Można zrobić to z kilku powodów. Pierwszym i wydaję mi się, że dość popularnym powodem jest niechęć starszych, technicznych pracowników (senior developerów, specjalistów, inżynierów itp.) do obejmowania roli projekt managera. W przeszłości spędziłem trochę czasu, pracując jako manager projektu i na bazie własnego doświadczenia rozumiem, że całodzienne odpisywanie na maile, generowanie ton dokumentów i ciągłe przepychanki (tzn. „negocjacje”) z klientami, związane najczęściej z zakresem projektu i zarządzaniem zmianą, nie są rzeczami, które wszystkich w życiu bawią. Innym z powodów jest setup organizacji, który wprowadza przysłowiowy szklany sufit na ścieżce rozwoju osób o zacięciu technicznym. Ponieważ senior konsultanta lub senior developera nie bardzo jest gdzie awansować*, a z drugiej strony stanowisko to można w Polsce osiągnąć, posiadając często zaledwie 2-3 lata doświadczenia w danej technologii (co w takim razie zrobić z jegomościem posiadającym ich paręnaście?) – stanowisko architekta wydaje się kolejnym, naturalnym i logicznym etapem rozwoju pracownika w ramach firmy.

Piszę o tym, ponieważ jakiś czas temu ponownie zostałem (tytularnie i faktycznie ;)) architektem. Mniej więcej w tym samym czasie, pod wpisem jednego z obserwowanych przeze mnie kont w serwisie Twitter, wybuchła dyskusja dotyczące tego, czy architekt powinien uczestniczyć w procesie sprzedażowym w organizacji dostarczającej oprogramowanie dla klientów. Okazało się wówczas, że praktycznie każdy uczestnik rozmowy posiada nieco inną, własną definicję tejże roli.

Powyższe wydarzenia skłoniły mnie do pewnych przemyśleń oraz do próby usystematyzowania odpowiedzialności oraz „typów” architektów, napotykanych przeze mnie w czasie mojej kariery zawodowej. Wybaczcie stosowane, angielskojęzyczne nazewnictwo, ale nie mam ochoty na wymyślanie polskich odpowiedników wszystkich wymienionych poniżej stanowisk.

Wyniki moich rozmyślań znajdziecie w poniższej tabeli:

Rola Odpowiedzialność
Software architect Osoba odpowiedzialna za szeroko pojęte projektowanie oprogramowania. Często posługująca się w swojej pracy językiem UML (ulubionym językiem tzw. „biznesu”) oraz rozmaitymi narzędziami Case (Enterprise Architect uber alles!), niestety z uwagi na ogromną ilość czasu spędzaną w towarzystwie ukochanych diagramów („Czy tu powinna być strzałka otwarta i ciągła linia czy linia przerywana i strzałka zamknięta?”) tracąca z oczu inne ważne obszaru systemu, takie jak np. sens biznesowy, „używalność” itp.

 

Solution architect Osobnik odpowiedzialny za rysowanie tzw. „klocków” na tablicy. „W tym miejscu będzie CRM, tu SharePoint, a tam usługa sieciowa, bla, bla, bla„.
Business process architect W ten sposób określamy nieco bardziej ogarniętego i często starszego (wiekiem) i doświadczonego analityka.
Enterprise architect Podstawowym zadaniem osoby w tej roli jest uzasadnianie wydatków na IT w organizacji przed zarządem. Również pokazywanie się w towarzystwie firmowych decydentów i łajanie wszystkich niekompetentnych (wg architekta) osobników, którzy znajdą się akurat w pobliżu.
Infrastructure architect Osoba odpowiedzialna za projektowanie rozwiązania na poziomie hardware’u, żyjąca w świecie macierzy dyskowych, przełączników oraz hardware’owych firewalli.  Z uwagi na ekspansje chmury jest to gatunek „wymierający” i być może w ciągu najbliższych lat równie pożądany, jak np. programista Cobola.
Tzw. “architekt od wizji” 😉 Rzecz spotykana u pewnego dużego producenta oprogramowania.

Cytat z pamięci: „Ja się na technologii nie znam, bo jestem architektem od wizji„.

A może chodziło po prostu o faceta znającego Microsoft Visio? 😉

Cloud architect „Solution architect”, tyle że specjalizujący się w szeroko pojętych technologiach „chmurowych”. Niezwykle chwytliwy tytuł, gwarantujący prawdopodobnie w najbliższych czasach wysokie dochody i rozpoznawalność.
Pre-Sales architect Osoba odpowiedzialna za projekt rozwiązania na etapie sprzedaży. W częstych przypadkach będąca generatorem bólu głowy dla zespołu technicznego (developerzy, konsultanci), który musi na etapie implementacji i wdrożenia dostarczyć sprzedane rozwiązanie.

 

Mam nadzieję, że powyższy, w moim zamierzeniu lekko żartobliwy ton powyższej listy nie uraził nikogo. Żeby nie było… sam wielokrotnie wcielałem się w niektóre z wymienionych poniżej ról i odnajdywałem się w nich lepiej lub gorzej.

Teraz będzie trochę poważniej :P. W kolejnej części tekstu chciałbym przedstawić podstawowe cechy oraz odpowiedzialności architekta w projektach wdrożeniowych systemów opartych o platformę Dynamics 365 Customer Engagement. Zastrzegam, że poniższa lista jest jedynie wynikiem moich przemyśleń opartych o praktyczne doświadczenia, wiedzę z pochodzącą z literatury fachowej („Czysta architektura”,  „Software Craftsman”, „Technical Leadership”) oraz innych materiałów, uznanych przeze mnie w czysto subiektywny sposób za wartościowe.

Dogłębna znajomość funkcjonalnych oraz technicznych możliwości i ograniczeń platformy

Architekt rozwiązań budowanych w oparciu o platformę Dynamics 365 CE powinien możliwie głęboko znać możliwości funkcjonalne oraz techniczne omawianego systemu. Powinien być w stanie rozpoznać sytuację, w której możliwe będzie użycie standardowej funkcjonalności systemu lub jej dostosowanie, a w którym przypadku powinniśmy budować rozwiązanie od podstaw. Jak powszechnie wiadomo – „Szansa sprzedaży, szansie sprzedaży nie równa”, a katalog produktowy w systemie Dynamics 365 CE nadaje się do wszystkiego, czyli tak naprawdę do niczego ;).

Znajomość technicznych możliwości (oraz przede wszystkim ograniczeń) platformy jest również swoistym „must have”. Architekt musi ocenić, kiedy do implementacji danej funkcjonalności powinien być wykorzystany plugin, workflow (synchroniczny lub asynchroniczny), a kiedy Flow. Musi znać również możliwości integracji systemu z innymi platformami (dostępnymi w chmurze lub utrzymywanymi po stronie klienta). W końcu w powiązaniu z wymienionymi powyżej obszarami musi zaprojektować rozwiązanie, które będzie z jednej strony spełniać wymagania klienta (czyli, ogólnie mówiąc: działać!), a z drugiej powinno być rozszerzalne w prosty sposób (znałem przykłady systemów dostarczonych w bardzo krótkim czasie, które z uwagi na wiele czynników były bardzo trudno modyfikowalne, a każda zmiana generowała ogromne koszty dla klienta) oraz tworzone zgodnie z najlepszymi, znanymi praktykami.

Znajomość szerokiego spektrum technologii na ogólnym poziomie

Poza dogłębną znajomością wybranej technologii (w naszym przypadku będzie to oczywiście Dynamics 365 Customer Engagement) architekt powinien posiadać również ogólną wiedzę na temat innych obszarów IT. Oczywiście zdobycie dogłębnej, eksperckiej wiedzy na temat wszystkich dostępnych na rynku platform programistycznych lub systemów jest w praktyce niemożliwe. Podstawowa, chociażby teoretyczna wiedza jest jednak mile widziana. Architekt powinien znać postawy bezpieczeństwa systemów IT, wiedzieć, w jaki sposób działają np. systemy ERP, hurtownie danych lub systemy służące do zarządzania obiegiem dokumentów. Powinien również znać modele oraz sposoby integracji międzysystemowej oraz programistyczne wzorce projektowe. Najlepiej, gdyby ww. informacje nie pochodziły jedynie z książek lub innych, dostępnych obecnie powszechnie materiałów, ale z praktycznych doświadczeń pochodzących ze wdrożeń systemu Dynamics 365 CE.

Umiejętność oraz „wyczucie” w dobieraniu technologii do projektu

Co tu dużo mówić, wspomniana w tytule akapitu umiejętność opiera się jedynie na wiedzy eksperckiej, swoistym „otrzaskaniu” oraz umiejętności zadawania pytań. Do tego dochodzi bagaż doświadczeń oraz szeroka wiedza nt. antywzorców projektowych oraz praktyk, których powinniśmy unikać (zarówno technicznych, jak i projektowych). Architekt powinien zdawać sobie sprawę, z tego, że system CRM nie jest najlepszym miejscem do przechowywania dokumentów, synchroniczne pobieranie danych z 3 rozproszonych systemów w momencie ładowania formatki nie jest dobrym pomysłem, a szyna danych niezintegrowana z Active Directory i niewspierająca Windows Authentication niekoniecznie ułatwi życie w firmie, gdzie standardem jest Windows. W końcu powinien wiedzieć, że nie powinno się przydzielać kluczowych, trudnych zadań w projekcie junior-developerowi i oczekiwać ich bezbłędnego wykonania oraz perfekcyjnej jakości kodu bez udzielenia mu jakiegokolwiek wsparcia. Oczywiście są to jedynie przykłady, ale (o zgrozo!) wszystkie prawdziwe i pochodzące z rzeczywistych projektów, w których miałem okazję uczestniczyć na różnych etapach kariery. Architekt powinien być wyczulony na tego typu sytuacje i stanowczo protestować w momencie ich napotkania.

Umiejętność „poukładania” projektu od strony technicznej

Moje doświadczenia w projektach wdrożeniowych systemów Dynamics CRM/365 pokazuję, że prowadzący je managerowie często nie mają niezbędnej wiedzy nt. organizacji technicznej strony projektu. Wiele organizacji chwali się obecnie pracą w metodykach zwinnych. Niestety adopcja tych metodyk często polega jedynie na zmianie procesu organizacyjnego (np. poprzez adopcję metodyki Scrum), zapominając zupełnie o technicznej stronie przedsięwzięcia. Pominięcie kwestii związanych z techniczną stroną projektu (TDD, programowanie w parach, ciągła integracja i refaktoring, automatyzacja tworzenia nowych wersji oraz wdrożeń) powoduje, że w dłuższej perspektywie nie wzrasta jakość wytwarzanego oprogramowania, co z kolei stwarza wrażenie, że adopcja metodyk zwinnych wcale nie przynosi organizacji dodatkowych korzyści. W tym miejscu na scenę powinien wkroczyć właśnie mityczny architekt ;). Powinien być on w stanie udowodnić korzyści płynące z wymienionych przeze mnie powyżej zwinnych praktyk oraz obronić (w ramach zespołu oraz przed zewnętrznym klientem) decyzję o konieczności ich wdrożenia. Dodatkowo powinien również być w stanie wspomóc zespół projektowy w tematach związanych z adopcją wybranych praktyk oraz najlepszymi wzorcami (lub antywzorcami) związanymi z ich wdrożeniem.

Pragmatyzm

Poprzez pragmatyzm rozumiem w tym przypadku nieuleganie chwilowym modom („Ukazał się nowy framework Javascript? Użyjmy go na projekcie!”, „Wykorzystajmy w naszym projekcie konteneryzacje! To nic, że do niczego jej nie potrzebujemy”), dobranie odpowiednich rozwiązań technicznych do problemu biznesowego oraz (uwaga, istotne!) terminu dostarczenia projektu.

Umiejętność pracy z klientem. Znajomość domeny biznesowej

Jest to kolejna ważny element omawianej roli. Architekt nie może być już przysłowiowym „gościem siedzącym w piwnicy”. Musi mieć on chęci oraz ochotę do bezpośredniej pracy z ludźmi (co nie zawsze jest „oczywistą oczywistością” w przypadku osób o zacięciu technicznym). Co więcej, często będą to ludzie nietechniczni, pochodzący z zupełnie innej bajki (właściciele biznesowi projektu, sponsorzy, managerowie, analitycy itp.). Do tego dochodzi często oczekiwana znajomość biznesu klienta. Wiedza na temat zasad rządzącymi procesami sprzedaży lub obsługi klienta oraz popularnych technologii w określonych branżach będzie na pewno dodatkowym atutem. Oczywiście, przy jednoczesnej realizacji kolejnego projektu w firmie z tejże branży.

Odwaga!

A jakże! Często w pracy architekta napotykamy sytuacje, w których musimy iść „pod prąd” lub w poprzek ustaleń poczynionych na poziomie biznesowym lub technicznym. Klienci oraz nietechniczni decydenci w projektach wdrożeniowych często dokonują rozmaitych założeń w oparciu o ogólne dostępne informacje lub nawet materiały marketingowe (!) producenta. Niestety podjęte na ich podstawie decyzje, często wymagają „wyprostowania” na etapie projektowania lub implementacji faktycznego rozwiązania. Okazuje się często wtedy, że (przykłady z „autopsji”) codzienne, nocne ładowanie danych do systemu nie ma szansy zakończyć się w zakładanym czasie, on-line’owa integracja Dynamicsa z systemem księgowym nie ma sensu, standardowy proces sprzedaży nijak nie pasuje do wymagań klienta, a oczekiwane podejście „no-code” nie ma szans realizacji wobec stawianych przed systemem wymagań.  Niestety osoby zarządzające projektami (zarówno po stronie dostawcy, jak i klienta) często mają skłonności do obrony podjętych na etapie sprzedaży lub wstępnego projektu systemu nawet w przypadkach, kiedy są one nieprawidłowe i w krótkim lub długim terminie doprowadzą do klapy projektowej. Rolą architekta jest w tym przypadku obrona prawidłowych rozwiązań (lub też proponowanie alternatyw wobec błędnych decyzji), nawet jeżeli prowadzą one do krótkoterminowego konfliktu lub niezadowolenia klienta i osób zarządzających projektem po stronie dostawcy.

Szacowanie czasu dostarczenia

Architekt rozwiązań Dynamics 365 musi być w stanie oszacować czas trwania zadań w projekcie. Powinien w tym przypadku brać pod uwagę nie tylko czas implementacji lub wdrożenia danego rozwiązania, ale również czas trwania wszystkich czynności okołoprojektowych związanych z danym zadaniem oraz występujące ryzyka. Pomimo tego, że w literaturze opisana szereg metod oraz sposobów wycen projektów, w moim przekonaniu w przypadku małych lub średniej wielkości wdrożeń w dalszym ciągu najlepiej sprawdza się metoda ekspercka, bazująca na doświadczeniu w realizacji podobnych zadań, znajomości wymagań biznesowych oraz warunków technicznych realizacji danego rozwiązania. W przypadku projektów dużych (przyjmijmy, że takim projektem jest wdrożenie, którego czas przekracza 1000 roboczo-dni), gdzie koszt rozwiązania wiąże się z wieloma, często nietechnicznymi warunkami, szacowanie projektu nie powinno polegać już jedynie na sumowaniu czasów realizacji poszczególnych zadań, ale to już temat na zupełnie inną dyskusję…

Kodowanie

Architekt jest już zbyt ważną personą, żeby zajmować się tak trywialną czynnością, jaką jest pisanie kodu”. Jest to oczywiście mit, szczególnie popularny wśród absolwentów wszelakich biznesowych szkół, którzy zajęli się z różnych przyczyn IT. Stety-niestety, bez umiejętności programowania (ze szczególnym naciskiem na dobre praktyki, wzorce projektowe oraz znajomość docelowej platformy) nie ma mowy o zapewnieniu żadnej gwarancji jakości powstającego oprogramowania.  Oczywiście, pisanie oraz czytanie istniejącego kodu nie będzie na pewno jedynym zajęciem architekta specjalizującego się w systemach budowanych na platformie Dynamics 365. Wymyślenie architektury, standardów projektowych oraz ich późniejsza weryfikacja to z całą pewnością jedno z zadań architekta. Nie widziałem jeszcze wdrożenia systemu Dynamics 365, w którego czasie nie zostałaby napisana ani jedna linia kodu (pomimo tego, że jest to mokry sen wielu decydentów oraz osób odpowiedzialnych za biznesowy aspekt przedsięwzięcia). Widziałem natomiast wiele wdrożeń, które zostały spartolone przez słabo napisany, nieutrzymywalny kod.

Dbanie o jakość dostarczanego rozwiązania

Wspomniałem już o nieco o tym aspekcie w akapicie związanym z kodowaniem. W tym miejscu dodam tylko, że na „rozwiązanie” nie składa się jedynie powstający kod, ale również dostosowania systemu, dokumentacja i jeszcze kilka innych rzeczy, charakterystycznych dla różnych projektów.

„Technical leadership”

Ostatnia z rzeczy, o których chciałem wspomnieć, jest „przywództwo techniczne” (jakkolwiek by to nie brzmiało), którego to ciężar architekt musi wziąć zazwyczaj na swoje barki. Przydają się tym przypadku umiejętności negocjacji, argumentacji, a także doświadczenie w prowadzeniu zespołu. Architekt jest często osobą skazaną na ustalanie i negocjowanie wymagań technicznych z klientem („Po co nam, aż tyle serwerów? Sprzedawca z XXX twierdził, że wszystko da się zainstalować na 2 maszynach wirtualnych”), osobami zarządzającymi projektem („Nie ma potrzeby refaktoryzacji tej części kodu. I tak za chwilę kończymy projekt i będzie to wtedy problem kogoś innego”) oraz samym zespołem („Panie, koduje od 10 lat, nigdy nie napisałem testu jednostkowego, a wszystko zawsze działało… No prawie wszystko”). Na pewno przydaje się w tym przypadku odrobina charyzmy oraz przede wszystkim bagaż doświadczeń, związany z poprzednimi projektami.

Czy więc warto wchodzić w buty architekta w projektach IT? Moim zdaniem jak najbardziej tak. Jest to bowiem rola łącząca w sobie konieczność posiadania „twardych” umiejętności technicznych z umiejętnościami „miękkimi”. Czyli z jednej strony nie porzucamy tego, co najbardziej kochamy (praca z technologią, pisanie kodu, rozwiązywanie skomplikowanych problemów), a z drugiej mamy możliwość osobowego rozwoju (częste kontakty z klientem, zarządzanie zespołem, większa decyzyjność i odpowiedzialność). Oczywiście jest to również często rola wymagająca oraz związana z pewną ilością stresu i większą odpowiedzialnością. Alternatywą dla niej w perspektywie rozwoju zawodowego jest zarządzanie (projektem i/lub zespołem) lub rola eksperta technicznego w jakiejś wąskiej dziedzinie. Architekt stoi gdzieś pośrodku, co być może nie wszystkim będzie odpowiadać. Jest to już jednak temat na osobny artykuł i dyskusję…

*Senior-senior developer? Ok, może być jeszcze tak zwany „Principal”.

Total Views: 1244 ,
This Article Has 1 Comment
  1. Pingback: dotnetomaniak.pl

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *