Wstęp
Pracujesz jako analityk i zastanawiasz się, co dalej?
A może dopiero wchodzisz do IT i próbujesz zrozumieć, czym te role różnią się w praktyce?
Zakres kompetencji w IT bywa rozmyty. Te same stanowiska w różnych firmach potrafią oznaczać zupełnie inne odpowiedzialności. Dlatego zamiast skupiać się na nazwach, warto zrozumieć rdzeń roli.
Sam przeszedłem tę drogę. W tym artykule pokazuję różnice między rolami i konkretne kroki, które mi pomogły w tym przejściu.
Kim jest analityk?
Rola analityka jest silnie zależna od organizacji. W jednych firmach to rola czysto biznesowa, w innych techniczna, a czasem hybrydowa.
Jedno jest wspólne: analiza powstaje przed kodem.
To jeden z najważniejszych etapów w SDLC. Błędy na etapie wymagań są najdroższe, im później zostaną wykryte, tym większy koszt ich naprawy.
Możemy wyróżnić trzy główne typy ról:
- analityk biznesowy
- analityk systemowy
- analityk biznesowo-systemowy
Analityk biznesowy
Skupia się przede wszystkim na:
- zbieraniu wymagań
- prowadzeniu warsztatów
- identyfikacji interesariuszy
- modelowaniu procesów (np. BPMN)
- tworzeniu user story
- walidacji pomysłów biznesowych
Kluczową odpowiedzialnością jest upewnić się, że rozwiązujemy właściwy problem.
Analityk biznesowy weryfikuje sens inicjatywy, spójność wymagań i ich wartość biznesową.
Jest pierwszą linią walidacji pomysłów.
Nie projektuje jeszcze architektury technicznej.
Projektuje logikę biznesową i zakres rozwiązania.
Analityk systemowy
Skupia się na tym, jak wymagania zostaną przełożone na system.
Odpowiada za:
- projektowanie integracji
- model danych
- kontrakty między systemami
- szczegóły techniczne realizacji
- doprecyzowanie wymagań dla zespołu developerskiego
Współpracuje blisko z programistami i często uczestniczy w rozwiązywaniu problemów produkcyjnych.
Można powiedzieć:
- analityk biznesowy odpowiada za „co i dlaczego”
- analityk systemowy za „jak w ramach danego systemu”
Rola łączona
W wielu organizacjach jedna osoba łączy oba obszary.
Wymaga to szerszych kompetencji zarówno biznesowych, jak i technicznych.
Niezależnie od wariantu, analiza skupia się na:
- zrozumieniu problemu
- zdefiniowaniu wymagań
- zapewnieniu ich spójności
- dopilnowaniu, aby rozwiązanie miało sens biznesowy
Analiza odpowiada na pytanie:
Co budujemy i dlaczego?
Kim jest architekt?
W momencie, gdy wymagania są już znane, pojawia się inny poziom decyzji.
Nie chodzi już o to, co budujemy.
Chodzi o to, w jaki sposób i w jakim kontekście organizacyjnym.
Architekt nie zastępuje analityka.
Ich praca się uzupełnia, dopiero razem tworzą kompletne rozwiązanie.
Architekt odpowiada za:
- wybór podejścia (budować vs kupić vs rozszerzyć istniejące systemy)
- styl architektoniczny
- podział systemu na komponenty / moduły / konteksty
- charakterystyki jakościowe (skalowalność, dostępność, bezpieczeństwo)
- długofalową spójność rozwiązania
To on musi odpowiedzieć na pytania:
- Czy budujemy monolit czy mikroserwisy?
- Jak system będzie skalowany?
- Jak będzie integrowany z innymi systemami?
- Jak ograniczyć ryzyko technologiczne?
Architekt operuje na poziomie systemu jako całości, nie pojedynczej funkcjonalności.
Architektura to zarządzanie trade-offami:
- prostota vs skalowalność
- szybkość wdrożeń vs jakość
- autonomia zespołów vs centralna kontrola
Jeśli analityk odpowiada na pytanie:
Czy to ma sens biznesowy?
to architekt odpowiada na pytanie:
Czy to rozwiązanie ma sens techniczny i organizacyjny w perspektywie czasu?
Kluczowa różnica
Analityk koncentruje się na problemie.
Architekt koncentruje się na strukturze rozwiązania.
Analityk myśli kategoriami wymagań.
Architekt myśli kategoriami ograniczeń, zależności i konsekwencji.
Analityk projektuje wartość.
Architekt projektuje trwałość.
Co łączy obie role?
W obu przypadkach kluczowe jest zrozumienie problemu biznesowego i opracowywanie rozwiązania, które dostarczy wartość biznesową.
Komunikacja i umiejętność porozumiewania się zarówno z biznesem jak i developerami jest kluczowa w obu przypadkach. Pomimo że produkt pracy każdej roli jest inny, zdolność do płynnego porozumiewania się z różnymi osobami w projekcie jest wymagana.
Korzystanie z narzędzi CASE także łączy obie role. Diagramy i modele tworzone przez analityka i architekta są różne, jednak repozytorium jest wspólne co ułatwia współpracę.
Dokumentacja, która powstaje, tworzy wspólny obraz rozwiązania.
Obie role występują w procesie SDLC zaraz po sobie. Kontynuacja działań, ścisła współpraca oraz odpowiedzialność za projekt są wspólne.
Jak przejść z analityka na architekta?
Przejście z analizy do architektury zajęło mi kilka lat. Oto kroki, które mi w tym pomogły.
Krok 1: Poszerzaj perspektywę
Poszerzaj swoją wiedzę o projekcie. Jeżeli masz możliwość, czytaj dokumentację architektoniczną, sprawdzaj dostępne materiały. Zadawaj pytania, które pomogą Ci lepiej zrozumieć sposób działania systemu.
Krok 2: Zadbaj o fundamenty
Zgłębianie wiedzy teoretycznej. Czytanie książek, blogów. Poznawanie różnic pomiędzy stylami architektury. Czym jest architektura monolityczna, czym jest architektura mikroserwisowa. W jakich przypadkach lepiej sprawdza się konkretny styl architektoniczny.
Krok 3: Poszerzaj kompetencje
Jeśli masz taką możliwość, poproś o małe zadania architektoniczne w ramach zespołu. Nie trzeba odpowiadać od razu za wybór konkretnej architektury, czy podejmować decyzje.
Ale stworzenie modelu architektury po wcześniejszych ustaleniach będzie możliwe.
Poproszenie o możliwość uczestniczenia w spotkaniach architektów, czy gildiach w firmie jeżeli takie istnieją też jest dobrym pomysłem. Można się osłuchać z językiem jaki jest używany oraz zobaczyć w jaki sposób podejmowane są decyzję architektoniczne.
Zapoznaj się z tym, jak dokumentowane są decyzje. Czy jest ADR i jak jest wykorzystywany.
Krok 4: Certyfikaty
Zdania są tutaj podzielone co do tego, czy warto robić certyfikat bez doświadczenia. Część osób twierdzi, że certyfikat jest potwierdzeniem posiadania umiejętności i powinno się go robić jak się ma doświadczenie w danej dziedzinie.
Ja uważam, że jest to dobry sposób na zdobycie nowej wiedzy i poznanie terminów powiązanych z danym tematem.
Ja zdobyłem certyfikaty TOGAF oraz AWS Cloud Practitioner i pomimo tego, że nie pracowałem wcześniej z wykorzystaniem tych podejść i technologii to pozwoliło mi to na pogłębienie wiedzy w tym temacie.
Z TOGAFem było trochę inaczej, podczas poznawania szczegółów dostrzegam, że na przestrzeni lat korzystałem nieświadomie z tego podejścia w różnych firmach.
Od czego zacząć?
Jeśli jesteś analitykiem i myślisz o architekturze — nie musisz zmieniać kariery. Musisz zacząć myśleć szerzej.
Zacznij od podstaw architektury IT — w ścieżce Architektura na tym blogu znajdziesz artykuły ułożone od fundamentów do bardziej zaawansowanych tematów.
Poprzedni artykuł: