Architekt w IT jest czasem jest jak Boromir – pojawia się dokładnie wtedy, kiedy trzeba, staje na pierwszej linii frontu i mówi: Tę funkcjonalność obronimy. Tego obejścia nie przepuścimy. Nie rzuca zaklęciami, a realizmem, doświadczeniem i architekturą, która trzyma cały projekt w ryzach.
A analityk? Ten gada. O biznesie. O procesach. O ludziach. O tym, czego chcą klienci i dlaczego to w ogóle robimy. I dopiero kiedy to wszystko wyleje na stół to wchodzi cały na biało architekt i mówi: Dobra. To zróbmy to tak.
Wtedy dzieje się rzecz najważniejsza. Architekt powołuje część analityczną do życia. To właśnie w tym momencie wizja, procesy, ryzyka i scenariusze przestają być dokumentem, a zaczynają być systemem. I to działa. Dlaczego?
Bo wiemy, gdzie są nasze granice.
Nie wchodzimy sobie w paradę. Analityk nie udaje, że zna każdy backend świata. Architekt nie udaje, że rozumie każdy niuans procesu sprzedaży u klienta. Mamy jasny podział ról i wzajemny szacunek. Analityk mówi o ludziach, procesach i ryzykach, a architekt mówi o systemach, integracjach i konsekwencjach technicznych.
I to jest punkt, w którym połowa projektów IT odpada z gry.
Analityk daje treść i sens
Architekt może mieć arsenał technologii, ale bez dobrych wejściowych materiałów od analityka nic z tego nie sklei. No dobrze, to co analityk właściwie wnosi na stół architekta?
Kontekst biznesowy
Analityk tłumaczy, po co ten system w ogóle istnieje oraz jaką decyzję ma wspierać, jaki problem rozwiązać i co się stanie, jeśli go nie będzie. Bez tego architekt projektuje dobry system, który może być kompletnie niepotrzebny.
Scenariusze użycia
Nie chodzi tutaj o happy path z prezentacji handlowej, tylko prawdziwe sytuacje, które pokazują co robi użytkownik, kiedy coś pójdzie nie tak, co się dzieje przy wyjątkach, obejściach i półśrodkach. To właśnie te scenariusze decydują, czy architektura wytrzyma produkcję.
Wymagania
Nie jako lista życzeń, tylko jako spójny zestaw potrzeb z definition of done, z jasno zaznaczonymi granicami, priorytetami i zależnościami. Analityk filtruje chaos oczekiwań zanim trafi on do decyzji technicznych.
Procesy
Analityk pokazuje, jak organizacja naprawdę działa, a nie jak chciałaby działać według procedur. To pozwala architektowi zaprojektować system, który pasuje do ludzi, a nie dopasować ludzi do systemu.
Ograniczenia regulacyjne
Prawo, compliance, audyty, obowiązki raportowe, czyli wszystkie rzeczy, których nie da się dodać później. Analityk wnosi je, zanim architektura stanie się kosztownym błędem.
Ryzyka i zależności
Co jest krytyczne, co się sypnie przy zmianie, co zależy od systemów zewnętrznych, ludzi lub decyzji biznesowych. To dzięki temu architekt wie, gdzie musi być konserwatywny, a gdzie może pozwolić sobie na odwagę i odrobinę finezji.
Architekt daje strukturę i decyzję
Architekt pojawia się z tym, czego nikt inny nie wniesie, czyli zdolnością przełożenia sensu na system, który da się zbudować, utrzymać i rozwijać. Co architekt wnosi do projektu?
Projektuje architekturę
Nie chodzi o rysowanie diagramów dla slajdów. Architekt projektuje sposób działania systemu, czyli jak elementy będą ze sobą współpracować, gdzie będą granice odpowiedzialności i które decyzje będą trudne do cofnięcia. To projektowanie konsekwencji, nie obrazków.
Wybiera technologie i integracje
Nie dlatego, że są modne albo sprawdzone u innych. Architekt dobiera je do celu biznesowego, skali rozwiązania, ograniczeń organizacyjnych i ryzyk, które system będzie musiał unieść. Każda technologia to zobowiązanie. Każda integracja to dodatkowa odpowiedzialność.
Wskazuje ograniczenia
Mówi wprost, czego nie da się zrobić sensownie technicznie, kosztowo albo operacyjnie. Nie po to, żeby blokować pomysły, ale po to, żeby projekt nie obiecywał czegoś, czego system nie będzie w stanie dowieźć.
Ocenia ryzyka i koszty
Nie tylko te widoczne w budżecie, ale też te ukryte: operacyjne, utrzymaniowe i techniczne. Architekt potrafi wskazać miejsca, w których decyzje na skróty wrócą później jako awarie, dług techniczny albo frustracja zespołu.
Pilnuje spójności
Między systemami, modułami, danymi i decyzjami projektowymi. Dba o to, żeby rozwiązanie było całością, a nie zlepkiem lokalnie dobrych, ale wzajemnie niespójnych pomysłów.
Głosem architekta
System, którego architektura nie odpowiada jasno sprecyzowanym potrzebom, wynikającym z analizy, zaciąga Dług Technologiczny przed postawieniem pierwszej linijki kodu. Co ważniejsze, jest to najgorszy rodzaj długu, ponieważ powstaje na poziomie Decyzji, a nie Wykonania.
Wersję biblioteki można podbić, ale stworzenie zbyt skomplikowanej Architektury, w stosunku do problemu, może być spłacane latami.
Upraszczając współpracę, można stwierdzić, że para Analityk i Architekt, to uzupełniający się ludzie zadający pytania: CO i DLACZEGO budujemy – Analityk oraz JAK i CZYM budujemy – Architekt. Jednak należy pamiętać, że podział nie może być wymówką dla Analityka, by nie znał ograniczeń technologicznych oraz dla Architekta, by ignorował sens powstawania systemu.
– Krzysztof Mazur , Architekt IT
A jak to wygląda w praktyce?
W praktyce ten podział jest prosty i cholernie trudny do utrzymania.
Analityk mówi CO i DLACZEGO.
Architekt mówi JAK i CZY TO MA SENS.
I tak, czasem się na siebie wkurzamy. Czasem wchodzimy sobie na ogródek. Czasem ktoś mówi za dużo, a ktoś inny za szybko ucina. I paradoksalnie to bardzo dobrze.
Jak to się rozkłada między role?
Dlaczego ten duet działa?
Współpraca analityka i architekta jest… szalenie trudna. Analityk chciałby czasem wybrać technologię. Architekt chciałby czasem ustawić priorytety. I prędzej czy później każdy to robi. Ale to właśnie dzięki temu pilnujemy się nawzajem, szybciej widzimy luki, doprecyzowujemy logikę, weryfikujemy założenia i dopiero wtedy projekt zaczyna mieć realny kształt.
Jak mawiał kiedyś jeden z moich ulubionych developerów:
Rozmawiajmy ze sobą.
I to naprawdę jest klucz do sukcesu.
Rozmowa, współpraca i wzajemny szacunek.