Według Manifestu Agile najlepsze „rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów”. Gdzie w takim ujęciu miejsce dla architektury korporacyjnej? Odpowiedzi na to pytanie udzielił Michał Mroczek, kierownik Biura Zarządzania Danymi w AXA, podczas zorganizowanej przez „Computerworld” w Warszawie konferencji „VIII Forum architektów IT”.

Rola architekta IT

Zdaniem Michała Mroczka rolą architekta IT w zwinnej organizacji jest rozwój jej kompetencji poznawczych oraz wsparcie w podejmowaniu kierunkowych decyzji. Z przekonaniem podkreśla, że zwinna organizacja potrzebuje stabilnych fundamentów.

Zobacz również:

• Partnerstwo w zakresie rozwoju oprogramowania - 5 najlepszych praktyk

Wsparcie w podejmowaniu decyzji należy przy tym odróżnić od implementacji konkretnych rozwiązań – te w dalszym ciągu powinny pozostać domeną poszczególnych zespołów scrumowych. W takim ujęciu głównymi klientami architektów IT są menedżerowie produktów, kształtujący wizję rozwiązań opracowywanych przez wspomniane zespoły. Architekt powinien być usługodawcą na ich rzecz, organizacyjnie usytuowanym tam, gdzie podejmowane są decyzje biznesowe, a nie tam, gdzie następuje ich późniejsza realizacja.

Takie podejście zapewnia wiele potencjalnych korzyści, zarówno finansowych, jak i organizacyjnych, product ownerom zarządzającym zespołami. „Jeżeli product ownerowi zależy na długofalowym rozwoju produktu, architekt IT będzie mu potrzebny np. z racji na modułowość czy reużywalność” – wyjaśnia Michał Mroczek. Dzięki systemowej i całościowej wiedzy na temat prac poszczególnych zespołów scrumowych, architekt IT będzie w stanie dystrybuować wiedzę i zasoby w zależności od wskazywanych przez nie potrzeb. Przykład? Możliwość uniknięcia dublowania pracy. „Architekt przyjdzie i powie: użyjmy komponentu, który w zeszłym roku przygotował inny zespół” – mówi Michał Mroczek. „Product owner widzi wartość biznesową w rozmowie z architektem pod warunkiem, że ten powie mu, iż jego produkt będzie tańszy, szybciej dostarczony czy prostszy, a w ogóle to nie musi poświęcać pół miliona złotych na rozwój danego komponentu, bo ten sfinansował już inny product owner na rzecz swojego projektu. To jest ta wartość”.

Architekt IT w organizacji działającej na podstawie metodyk zwinnych powinien pełnić rolę wewnętrznego konsultanta, centrum doskonalenia i drugiej linii wsparcia. Dzięki całościowemu spojrzeniu na organizację architekt wspiera zespoły scrumowe, gdy nie mogą poradzić sobie same.

Architekt IT nie musi być przy tym konkretną, pojedynczą osobą w organizacji. „Należy oderwać się od myślenia kategorią architekta na rzecz ról w organizacji, które myślą architektonicznie” – precyzuje Michał Mroczek. Jego zdaniem nie tylko architekt IT, ale tak naprawdę wszyscy członkowie zespołów agile'owych – od scrum masterów, poprzez product ownerów i product managerów, aż po deweloperów – muszą myśleć architektonicznie, tj. starać się dekomponować problemy na elementy, moduły, a później na tej podstawie proponować holistyczne rozwiązania.

Najważniejsze umiejętności architekta IT

Przywołując raport McKinesya, Michał Mroczek wymienia umiejętności kluczowe dla architekta IT działającego w zwinnych organizacjach. Są to:

• alokacja zasobów, w tym kompetencji i zasobów technologicznych, niezbędnych do stworzenia produktów, a także sposobów ich pozyskiwania;
• budowa procesów obejmująca mapy drogowe produktów oraz możliwie jak najdalej posunięte wielokrotne wykorzystywanie poszczególnych posiadanych zasobów (osób, procesów, zasobów IT, danych);
• wypracowywanie decyzji angażujących IT na rzecz realizacji założeń wyznaczanych przez przyjęte mapy drogowe produktów oraz ich późniejszego rozwoju;
• delegowanie decyzji oraz skupianie się na tych, gdzie praca dostarczy największej wartości;
• przegląd prac i usprawnianie procesów decyzyjnych dzięki umiejętnemu wyciąganiu wniosków z popełnianych błędów i zdobywanych doświadczeń.