Czy Architekt IT to rola… HR-owa?

Tytuł nieco clickbaitowy, chociaż zaspoileruję Ci, że wcale tak bardzo z nim nie żartuję! Ale do rzeczy. 

Z kim kojarzy Ci się Architekt IT? Pewnie dużo zależy od Twoich doświadczeń – ale upraszczając, zapewne z kimś kto projektuje system, jego klasy/komponenty, funkcje, schodząc od wymagań biznesowych aż po wzorce technicznej implementacji. W zależności od tego, jak zwymiarujemy ów system, mamy architektów rozwiązań, architektów korporacyjnych, architektów biznesowych czy po prostu, szeroko – architektów IT. Jedni zajmują się systemem w skali makro, dotyczącym całej organizacji lub jej procesów (architekci korporacyjni i biznesowi). Inni schodzą do poziomu kilku lub jednej aplikacji projektowanej do zaspokojenia konkretnej potrzeby (architekci rozwiązań, system, IT). Mi osobiście długi czas architekt kojarzył się z kimś, kto pracuje na poziomie komponentów technicznych, projektując ich strukturę i cykl życia. A dziś uważam, że to było podejście niekompletne. Dlaczego?

Prawo Conwaya 

Zacznijmy od pewnego uproszczenia i przykładu. Załóżmy, że w ogóle nie mamy architekta – i mamy trzy zespoły którym zleciliśmy zrobienie systemu rezerwacji salek. Dla uproszczenia, w organizacji jeden dział odpowiada za budynek, a więc z jednego miejsca idą wymagania. Chcemy, by system powstał szybko – a więc prace zespołów muszą być w miarę niezależne, tak by nie było przestojów. Naturalnym trendem będzie to, że pierwszy zespół zrobi samo rezerwowanie, drugi silnik do zarządzania salkami – a trzeci silnik do zarządzania rezerwacjami. A gdybyśmy mieli dwa zespoły? No to pewnie rezerwacje byłyby w jednym module (zarówno zarządzanie jak i sam proces rezerwacji) a salki w kolejnym. Właśnie w skrócie wytłumaczyłem Wam Prawo Conwaya. Parafrazując, mówi ono o tym, że firmy produkują oprogramowanie będące odbiciem struktury komunikacji i zespołów, które je tworzą. I tu uwaga – niezależnie jak bardzo architekt się temu sprzeciwi! Owe prawo było już niejednokrotnie udowadniane na przykładach – a jego implikacje wychodzą za każdym razem, gdy kupujemy gotowy produkt IT, którego struktura nie pasuje do tego jak działa firma. Albo gdy systemy nie nadążają za transformacją, ciągnąc firmę w dół. Przykładów można mnożyć.

Miękkie skille architekta IT vs architektura zorientowana rzeczownikowo

To może nie warto zatrudniać architektów w ogóle? Przecież skoro zespoły same się poorganizują – to każdemu wyjdzie to na dobre! No cóż, zmartwię Cię. Prawo Conwaya wykracza daleko poza dział IT i projekty systemów – i jeśli w organizacji między IT a Biznesem następuje asymetria, jej symptomy pojawią się w problematycznym rozwoju aplikacji biznesowych. I wcale nie będzie to od razu oczywiste do wykrycia.

Tutaj podam kolejny przykład oraz przybliżę Ci coś, co osobiście nazywam architekturą zorientowaną rzeczownikowo. Powiem, dlaczego moim zdaniem jest ona tak problematyczna, a jednocześnie tak powszechna. Wprowadzę dwóch architektów do naszej historii, a potem przedstawię Ci jaką architekturę stworzyli – i która moim zdaniem była znacznie lepsza.

Ok, to znamy już Ludka i Rzecza. Obydwaj pracują w bankach, w których dostali po cztery zespoły do zbudowania strony, na której klienci mogą zamawiać karty kredytowe. W banku mamy dział korporacyjny i dział retail, które zgłaszają wymagania co do procesu zakupowego. Pewnie już na tym etapie wiesz do czego zmierzam – ale dla formalności, zakładam, że Panowie następująco zaproponują architekturę rozwiązania:

Co z tego wynika?

Zacznę od wyjaśnienia – i nakreślenia problemów architektury Rzecza:

• Po pierwsze, jeśli procesy w ramach pionów będą się różniły – trzeba będzie obydwu tych procesów nauczyć Zespół A (odpowiedzialny za Lending Service). Może to spowodować natłok poznawczy dla takiego zespołu i pewną dezorientację (cognitive load) – a w skrajnym przypadku niemożliwość wprowadzenia zmian zgłoszonych przez jeden z pionów
• Po drugie – Lending Service zależy mocno od Customer Service (jako że proces dotyczy klienta). To, że klienci są różni, da się jeszcze jakoś opanować w ramach jednego serwisu, natomiast obydwa zespoły będą musiały bardzo ściśle współpracować i planować prace – co z kolei wpłynie na ich efektywność. Podobnie ma się rzecz z Delivery Service (odpowiedzialnym za dostarczenie karty – który to proces jest składową procesu lendingowego).

Problemy te rozwiązuje architektura zaproponowana przez Ludka. Reużywalne i niezależne od procesu komponenty – takie jak utworzenie i wydanie kart, tudzież techniczne elementy systemu jak autoryzacja zlecenia Klienta przeniósł do niezależnych zespołów – kolejno Card Service w zespole D i Authorization Service w zespole C. Zrobił to, ponieważ nie chciał, by te funkcjonalności się zduplikowały w ramach serwisów odpowiedzialnych za procesy dla poszczególnych domen. I tu dochodzimy do sedna: Ludek podzielił zespół A i zespół B pionami – tak, by proces lendingowy mógł zachować pełną niezależność z punktu widzenia interesariuszy. „Skoro biznes jest tak podzielony – to chyba system też powinien” pomyślał Ludek i moim zdaniem miał rację.

Jak więc widzisz, nawet mając takie same zespoły do dyspozycji, liczenie na to, że same się poukładają, może być ułudą. Bez zauważenia jak de-facto działa organizacja, jakie są jej zależności – i jak jej złożoność odzwierciedlić w systemach IT – dojście do optymalnego rozwiązania bez zatrudnienia świadomego architekta może być albo długotrwałe i problematyczne, albo wręcz nie nastąpić nigdy (bo na przykład cała inicjatywa z uwagi na koszty będzie anulowana).

Przykład, jaki pokazałem, jest oczywiście prosty – natomiast zastanów się, ile spotkałeś systemów, których interesariuszami była niemal cała organizacja. Ile widziałeś zespołów, które tonęły w sprzecznych wymaganiach. Ile widziałeś produktów IT, które wymusiły nieplanowaną zmianę organizacyjną w danym pionie biznesowym („musimy się trochę zrestrukturyzować, bo nie da się stworzyć takich grup w SAPie, jakie chcemy”). Sporo, nie? 

Wpływ architekta na strukturę organizacyjną

Czy zatem Architekt powinien zamiast działu HR pisać strukturę organizacyjną w dziale IT? Coż – to zależy od tego, do czego dana firma wykorzystuje strukturyzację. Podam dwa skrajne przykłady i pewnie większość organizacji jest gdzieś pomiędzy. 

Lewy koniec tego spektrum to opis struktury organizacyjnej dokładnie oddający to, jak pracują zespoły. I tutaj osobiście uważam, że to właśnie architekt powinien tą strukturę tworzyć w porozumieniu z HR i Biznesem, oraz nanosząc ją na swoją architekturę (niezależnie czy mówimy o dziale, pionie czy całej firmie). Ryzyko braku architekta na tym etapie to powstanie zespołów zorientowanych kompetencyjnie – jak frontendowcy, backendowcy, integracja, bazy danych etc. Architektura takiej organizacji będzie odzwierciedlać te poszczególne warstwy kompetencyjne, a systemy będą monolityczne, obsługujące wiele domen biznesowych jednocześnie. Coś, czego na pewno chcemy uniknąć. 

Prawy koniec tego spektrum to struktura oddająca jedynie raportowanie godzin czy decydująca o ścieżce awansu pracowników. W takim układzie niemal 100% organizacji realnej pracy spoczywa na architektach i delivery managerach. Bardzo ważne w tym modelu jest to, by Ci drudzy nie powinni być przez architektów opuszczeni. Inaczej jest ryzyko, że lądujemy z architekturą planowaną przez managerów, a nie przez architektów.

Team Topologies – lektura obowiązkowa Architektów 

Na sam koniec – gorąco polecam publikację „Team Topologies – Organizing Business and Technology Teams for Fast Flow”, napisaną przez Matthew Skelton i Manuel Pais. Autorzy zaproponowali trafny (moim zdaniem) podział zespołów na cztery typy – gdzie każdemu przyporządkowali jego cele, charakterystykę pracy i dostarczaną wartość dla organizacji:

• „Stream-aligned Team” – czyli zespoły skupione na strumieniu wartości. Są to zespoły dostarczające wartość biznesową w ramach budowanego oprogramowania (na naszym przykładzie – każdy z zespołów zaplanowanych przez Ludka). Wg autorów, powinni oni stanowić większość zespołów w organizacji. 
• „Complicated sub-system Team” – czyli zespoły odpowiedzialne za specjalistyczne systemy. Mogą być to systemy legacy, lub wykonujące specyficzną funkcję (jak na przykład OCR). Autorzy kładą nacisk na to, by ilość takich zespołów była limitowana. Zauważają, że wiele z nich realnie powinna być type stream-aligned, natomiast zaszłości historyczne i architektura zastana powodują, że ich transformacja w tym kierunku jest złożonym procesem. 
• „Platform Team” – czyli zespoły budujące środowisko pracy dla pozostałych. Zespoły Platformowe powinny skupiać się na zdjęciu z wyżej wymienionych zespołów wszelkiego brzemienia poznawczego w zakresie technologii, procedur, organizacji pracy. Dobrymi przykładami Platform Teamów są zespoły platform DevOps (odpowiedzialne za narzędzia DevOps, reguły ich użycia i świadczące określone serwisy wokół tych narzędzi). Innym równie dobrym przykładem są zespoły API Management (tworzące platformę do publikacji i używania API – ale już nie wchodzące w logikę biznesową tego API stricte). Moja praktyka podpowiada, że jeśli jakiś zespół dostarczający software wspomagający procesy biznesowi robi coś, co mógłby robić zespół platformowy – to albo trzeba taki zespół platformy stworzyć / oddelegować jej te prace; albo stworzyć dedykowaną inicjatywę dla tego zajęcia (patrz niżej – „Enabling Team”).
• „Enabling Team” – czyli zespoły budowane dla określonego celu do dowiezienia w określonym czasie. Ten cel i czas są tutaj szalenie istotne – wiele razy widziałem różne „Zespoły Techniczne”, których jedynym zadaniem była zabawa technologią bez dużego pożytku dla organizacji. Zabrakło właśnie tej tymczasowości – elementu, który pozwala temu zespołowi skupić się na tym, do czego został powołany. Przykładem Enabling Team może być zespół powołany do upgrade Java do nowej wersji dla wszystkich systemów w organizacji. Jest to zadanie techniczne, które zespołów „Stream-aligned” czy „Complicated sub-system” nie powinno odciągać od ważniejszych zadań biznesowych. Takie prace można zlecić właśnie dedykowanemu „Enabling Team”. Zespoły „Enabling” pełnią również rolę R&D czy PoC, gdzie po opisaniu praktyk czy wprowadzeniu narzędzia ściśle współpracują przez jakiś czas z innymi zespołami, przekazując im wiedzę. 

Dlaczego warto sięgnąć po Team Topologies?

„Team Topologies” jest najlepszym rozwinięciem tematu Prawa Conwaya i układania zespołów w organizacji z jakim się dotychczas spotkałem. Napisana przystępnym językiem uporządkowała moją wiedzę oraz usystematyzowała sposób w jaki nazywam dzisiaj zespoły i ich rolę w organizacji. Wiedza z tej książki stanowi również o moich pierwszych lampkach ostrzegawczych o potencjalnych antypatternach. Wykorzystując tą wiedzę w praktyce unikam niezaplanowanej komunikacji między zespołami (autorzy mówią, jak ją projektować) i rozpoznaję zespoły nie pasujące do żadnego wzorca (co wskazuje mi problemy w ramach granic odpowiedzialności). Zespół pojęć i dobrych praktyk pozwala mi lepiej opisywać architekturę oprogramowania którą dziś projektuję z uwzględnieniem naniesienia jej na dostępne mi zespoły.

Podsumowanie

Odpowiadając na pytanie co do roli architekta w organizacji – i czy jest to rola HRowa – powiedziałbym „Nie tylko HRowa”. Dobry architekt potrafi wyjść ponad technologię i zauważyć ludzkie otoczenie systemu który buduje. To otoczenie też jest „systemem” – z którym nasz software musi grać! Z Prawa Conwaya wynika, że architekt nie powinien się skupiać tylko na komponentach technicznych. Dobry architekt musi perfekcyjnie rozumieć technologię, ale nie może mu ona przysłonić świata ani stanowić wyzwania jako takiego. Tylko tak architekt będzie w stanie patrzeć na inne aspekty szeroko.

Moim zdaniem dobry architekt to taki, który potrafi zauważyć jak struktura zespołów wpływa na architekturę. Projekt systemu dobrego architekta zawiera odniesienie do otoczenia. Tak powstają systemy, które zamiast blokować, wspomaga organizację w jej rozwoju.