Budowaliście dom? Ja nie. Urządzaliśmy jedynie swoje mieszkanie. Ale bez pomocy architekta wnętrz.
Zanim do tego doszło, to mieszkanie jakoś powstało. Ktoś je zaprojektował jako całość, potem ktoś wykonał, pracując nad różnymi elementami. Ktoś tym wszystkim zarządził.

Wszystko jednak zaczęło się od architekta, który całość wymyślił i zaprojektował. Potem teoretycznie też dbał nad jego wykonaniem (jak to jest w praktyce – nie wiem).

A co, gdyby ten dom projektował ktoś inny? Powiedzmy – elektryk? Ale genialny elektryk! Mistrz w swojej dziedzinie!

(…) An architect is someone who plans, designs, and reviews the construction of buildings. To practice architecture means to provide services in connection with the design of buildings and the space within the site surrounding the buildings, that have as their principal purpose human occupancy or use. (…)  

(Wikipedia)

Zapewne instalacja elektryczna byłaby top-notch. A reszta? Pewnie jakoś by też powstała… W końcu elektryk, obarczony zadaniem zaprojektowania domu, poskrobałby się po głowie, odświeżył matematykę, poczytał trochę książek o architekturze, w końcu zajrzałby na stack overflow … OK, może nie w tym przypadku.

Co to ma do rzeczywistości projektów informatycznych?

Ekspert to nie architekt

Ustalmy – domu nie zbudowałem i nie zbuduję.

Większość z nas, pracujących w branży, spotkała się z ekspertami. Takimi z krwi i kości, którzy swoją dziedzinę znają na wylot. Potrafią odpowiedzieć na każde pytanie, zwymiarować wszystkie serwery w infrastrukturze w mgnieniu oka lub przedstawić wady i zalety danego podejścia w programowaniu, jednocześnie przegryzając bułkę.

Eksperci. Wiedzą dużo, mają doświadczenie w swojej dziedzinie. Znają ją na wylot.

Ze względu na tę wiedzę i ilość dostarczonych projektów – mają dobrze ugruntowaną pozycję. Znają się.

Z tego powodu, gdy uruchamiany jest nowy projekt, mający na celu stworzenie nowego systemu lub rozwiązania – często zostają architektami.

Nawiązując do sytuacji opisanej wcześniej – genialny elektryk zostaje nagle architektem domu. Nic dziwnego więc, że często w efekcie powstanie dom z genialną elektryką, ale kulejący w kilku innych aspektach. Wiedza elektryka zastosowana do planowania kanalizacji lub projektowania układu mieszkania może nie do końca się sprawdzać.

Wtedy w ruch idzie (również wspomniany wcześniej) Stack Overflow, Stack Exchange itp. Korzystając z gotowych kawałków planów, jakoś uda się całość złożyć.

Uda się?

Co robi architekt?

Złośliwi twierdzą, że przez 60% czasu zajmuje wymyślaniem się tego, co robi… Co na to Wikipedia?

(…) The systems architect is a professional figure in ICT. Systems architects define the architecture of a computerized system (i.e., a system composed of software and hardware) in order to fulfill certain requirements. Such definitions include: a breakdown of the system into components, the component interactions and interfaces, and the technologies and resources to be used in the design. (…) (Wikipedia)

Proste. Architekt definiuje system tak, aby spełniał wymagania.

Weźmy na warsztat taki system do zarządzania dowolnym procesem wdrożony w chmurze, który musi zapewnić interakcję z użytkownikiem końcowym przez aplikację internetową, a z drugiej strony – wymianę danych z pięcioma innymi systemami zewnętrznych dostawców. Część on-premises, a część w chmurze.

Co musimy zapewnić? Proste:

  • interfejs użytkownika w aplikacji
  • interfejs aplikacji do danych
  • infrastrukturę aplikacji
  • strukturę danych i wybór sposobu ich przechowywania (bazę danych)
  • komunikację z pięcioma różnymi systemami, potencjalnie na pięć różnych sposobów
  • połączenia sieciowe pomiędzy tymi systemami
  • połączenie pomiędzy chmurą a on-premises
  • bezpieczeństwo aplikacji

Lista robi się coraz dłuższa, a każdy z wymienionych elementów można rozbić na jeszcze mniejsze.

Kto to wszystko ogarnie? Architekt!

Specjalista w danej dziedzinie nie zawsze nadaje się na architekta.

Jeżeli ustawimy w roli architekta powyższego systemu wybitnego specjalistę od UI, to będziemy mieli piękny i funkcjonalny UI i połatane gdzieś pomiędzy sobą elementy wymiany danych (to się przerzuci plikami CSV).

Jeżeli rolę głównego architekta będzie pełnił ktoś, kto ma super doświadczenie w zarządzaniu danymi, będziemy mieli idealnie zaprojektowane struktury danych i ich wymianę, ale jedyna część UI, która będzie się nadawała do używania, to raporty z tych danych.

Super. Weźmy więc genialnego człowieka od UI, genialnego człowieka od baz danych i od każdego innego elementu i pozwólmy im robić swoją robotę. Problem rozwiązany. W końcu każdy z nich jest ekspertem w swojej dziedzinie i da radę.

Mamy to!

Niestety, to też grozi katastrofą. Każdy z nich wykona swoją robotę najlepiej jak potrafi, ale w efekcie powstanie kilka niezależnych projektów, które zostaną sklejone, aby działać razem (któż nie zna glue and tape…).

Po drugiej stronie skali mamy sytuację, gdy do wytworzenia systemu zatrudniani są architekci, którzy od dawna nie tworzyli niczego praktycznie. Posiadają certyfikację, znają metodyki, wiedzą, jak wszystko powinno wyglądać. Brakuje im tylko tej jednej rzeczy – doświadczenia.

Powstaje ryzyko, że powstanie coś, co będzie posiadało idealne proporcje, idealnie zaprojektowane interfejsy i diagramy procesów, tylko za cholerę nie da się tego wykonać lub potem używać.

Mix!

Ekspert dziedzinowy nie zawsze jest dobrym architektem. Przynajmniej nie za pierwszym razem. Patrzy na problem z perspektywy swojej dziedziny. Wzorce projektowe, używane w jednej dziedzinie lub produkcie, nie muszą przystawać do innego problemu.

Architekt bez praktycznej wiedzy o developmencie, wdrożeniach i praktycznych wadach i zaletach rozwiązania również nie gwarantuje sukcesu. W idealnych proporcjach zgubi gdzieś użyteczność.

Idealnie sprawdza się mix – architekt, widzący problem szeroko, posiadający doświadczenie i wiedzę z różnych dziedzin. Potrafiący rozmawiać z użytkownikami biznesowymi czy końcowymi o ich wizjach i przekładający to na architekturę systemu. Nie musi posiadać głębokiej wiedzy w każdej dziedzinie. Wystarczy tyle, aby potrafił szybko odrzucić pomysły bez szans na realizację. Idealnie, gdy potrafi przygotować prosty prototyp.

Architekt systemu działa szeroko, niekoniecznie głęboko.

Z architektem działają specjaliści dziedzinowi. Ten od metod kodowania, ten od baz danych, ten od komunikacji. To oni znają wszystkie bity i bajty. To do nich należy wybór technologii i sposobu jej użycia. Nie oznacza to samowolki – całość musi zgrywać się z projektem.

Tam, gdzie architekt potrzebuje wiedzy, sięga po specjalistę. Najważniejsze – słucha go. A tenże specjalista ma argumenty, żeby coś wykonać tak czy inaczej.

To nie tytuły!

Nie chodzi o tytuły w projekcie czy na wizytówkach. Nie chodzi o formalne role. W takim zespole często widać od razu kto jest architektem, nawet jeżeli formalnie nie pełni takiej roli.

Z drugiej strony – często widać, jak osoba będąca architektem z nadanej roli, w tej roli się nie spełnia i nie sprawdza.

Jeżeli architekt się nie sprawdza, to poszczególni specjaliści zaczynają ciągnąć rozwiązanie każdy we własną stronę. Jak to się kończy, wie duża część uczestników projektów IT.

Miałem szczęście pracować z kilkoma świetnymi architektami. Z czasów pracy w Microsofcie wspominam Roberta Powałkę – gdybyście mieli okazję z nim popracować, łapcie ją! Szczerze polecam.

Jeden z projektów w Danii realizowałem z kolegą z duńskiego oddziału Microsoftu – odczucia podobne.

W takich wypadkach wiecie, że ktoś nad tym panuje i ma kontrolę. Jeżeli zespół to wie – to i projekt idzie w dobrym kierunku.

Jeżeli tego nie ma, w projekt i zespół wkrada się niepewność.

 

Główny obrazek: patentboy via Visualhunt.com / CC BY-NC-ND

About Author

6 Comments

  1. Ja mam szczerze mówiąc trochę odmienne zdanie 🙂 Może to kwestia kogo w roli ‘architekta’ spotkałem.
    Dla mnie ‘architektura’ to coś co się zmienia w funkcji czasu i wymagań, coś co żyje i co powinno być w ramach odpowiedzialności całego zespołu. I znów, to pewnie zależy od osoby, ale nic nie potrafi zabić radości ze startowania projektu (co mimo wszystko nie jest tak częste, większość pracy to jednak istniejące rzeczy, brownfield itp) niż człowiek, który z wyższością mówi Ci jak wszystko ma działać. W dużych firmach, gdzie jest dużo współpracujących projektów, oczywiście dobrze mieć człowieka, który jest w stanie ogarnąć ‘duży obrazek’, jak to wszystko ze sobą współgra, jak się komunikuje, w którą stronę będzie się rozwijać – ale dużo łatwiej mi myśleć o takim człowieku jak o ‘skarbnicy wiedzy’/pomocniku z którym mogę skonsultować pomysły/problemy, niż gościa który mówi jak ma być i tyle (co tutaj pokrywa się z Twoim postem).
    Dodatkowo, jeśli to ja wymyśliłem/zaprogramowałem, to jestem w to zaangażowany VS. nie zgadzam się z tym, nie chce tego robić, niech się wali, to ON tak wymyślił

    • Rolą architekta nie jest przyjście i powiedzienie “tak ma być, słuchać się” tylko właśnie ogarnięcie całości obrazka i dogadanie wszystkich strony, jednocześnie pilnując, żeby to co powstaje było spójne, nie powodowało ograniczeń w przyszlości itp.

      Na końcu to dobrze, że Ty wymyśliłeś i zaprogramowałeś, ale ktoś musi zadbać, żeby to co wymyśliłeś pracowało z tymi 10 innymi rzeczami, które każdy gdzieś tam wymyśla. Typowo nazywa się ich architektami, pewnie funkcjonują też inne określenia.

      Czyli w zasadzie to co napisałeś :). Czyli coś zgubiłem w przekazie :).

  2. Tomku, a jeżeli zapytałbym: jak zostać architektem w IT, to jaką ścieżkę proponujesz? 🙂 Z racji tego, że taka osoba powinna, tak jak napisałeś, “ogarniać” wiele różnych dziedzin, to jak dojść do takiego momentu? Skakać co dwa lata po różnych stanowiskach? Wejść głęboko w jedną “działkę”, a po zgłębieniu trochę zapoznać się z innymi? Jak to widzisz? Jakie rady mógłbyś dać młodej osobie wkraczającej w świat IT? 🙂

    • Hej Konrad,

      To bardzo dobre pytanie, aczkolwiek trudne do odpowiedzi. Szczególnie dla kogoś, kto jak napisałeś jest na początku drogi w IT. Różne zadania i zajęcia pojawiają się na różnych etapach kariery. Trochę wiąże się to z doświadczeniem – nawet nie takim czysto technicznym czy projektowym, ale ogólnie obyciu w otoczeniu.

      Do tego dochodzi teraz obecne szybsze tempo zmian w IT ale nie tylko.

      Kilka rad albo bardziej rzeczy, na które starałbym się zwrócić uwagę;

      – Interesuj się stroną biznesową przedsięwzięć. Nie tylko wykonuj wykonane zadania ale dowiedz się po co one sa robione, jakiej większej całości są częścią. Czy znasz ludzi w branży, którzy dzielą ludzi na “nas” i “tych z biznesu”? Nie bądź taki. To jest zła droga.

      – Czytaj literaturę z różnych dziedzin i zagadnień, nie tylko IT ale też związanych z organizacją, działaniem tych organizacji, zachowaniami ludzkimi. Szczerze – nawet trochę historii nie zawadzi. Rozmawiaj z ludźmi z branży i nie tylko spoza swojej dziedziny

      – Popracuj i nie zaniedbuj szkolenia się w umiejętnościach miękkich. Konwersacja, prezentacja, umiejętność zadawania pytań, umiejętność prostego opowiedzenia o trudnych zagadnieniach, przełożenie technologii na zrozumiały język, rysowanie … to są rzeczy, które Cię będą wyróżniały.

      – Technicznie, na początku, zainwestuj w nauke wybranej dziedziny mocno ale też nie zaniedbując innych rzeczy, orientuj się w technologii ogólnie. Popatrz na to co jest teraz i co wg Ciebie będzie przydatne za lat 5. Ja bym teraz stawiał na public cloud + rozwiązania oparte na PaaS \ Serverless. Do tego nie pomiń tak zwanych “basics”, zdziwiłbyś się jak wiele osób nie potrafi w tej chwili odpowiedzieć na proste pytania jak coś działa.

      I tak to … trzymałbym się tych kilku rzeczy i szedł konsekwentnie do przodu :). Zobacz też na vlogu Mirka Burnejko odcinki o karierze, dobrze IMO oddają to co trzeba robić :).

      I oczywiście czytaj bloga pewnego 🙂

Leave A Reply

Share This

Share This

Share this post with your friends!