Architekt w podejściu zwinnym

W ostatnim wpisie opisałem co myślę o roli analityka w podejściu zwinnym. Drugą rolą, o której chciałbym wspomnieć jest rola architekta. Rola ta określona jest w klasycznym podejściu do wytwarzania oprogramowania. Natomiast w zwinnym podejściu o architekturze i architektach nie wspomina się zbyt wiele. Jedynie w założeniach manifestu programowania zwinnego pojawia się (podkreślenia moje):

Najlepsze rozwiązania architektoniczne, wymagania i projekty
pochodzą od samoorganizujących się zespołów.

I tu zaczyna się problem, gdyż samoorganizujący się zespół może być najlepszy z najlepszych, ale opracowanie złożonej architektury wymaga czasem trochę szerszych kompetencji. Potrzebne jest spojrzenie na rozwiązanie z innej, szerszej  perspektywy.  Ta perspektywa może obejmować architekturę aplikacji, ale również architekturę biznesową. To szersze spojrzenie jest konieczne szczególnie w dużych organizacjach, gdzie mamy nie tylko zwinne zespoły, ale także dostawców zewnętrznych, zespoły pracujące bardziej klasycznie. Poza tym mamy wiele toczących się równolegle przedsięwzięć oraz technologie, których nie można zmienić itd. itp.

Teoretycznie, gdy zespół opracuje samodzielnie architekturę to zwiększa to zrozumienie i akceptację architektury dla wszystkich, ponieważ pracowali nad tym razem jako zespół. W przypadku wielu współpracujących zespołów możemy mieć już zbyt wiele punktów widzenia i może nastąpić totalny kryzys. Idąc dalej, w większych aplikacjach i rozwiązaniach złożonych z wielu aplikacji, nacisk na wczesne dostarczanie funkcjonalności może prowadzić do istotnych problemów z koordynacją. Zbyt duża zwinność może prowadzić do chaosu. Zapanowanie nad sytuacją zaczyna wymagać współpracy wielu różnych zespołów.

Potrzebna jest koordynacja prac.

Szczególnie trzeba zwrócić uwagę na to, by nie tylko nie dublować wszystkich funkcji, ale także zapewnić ich dostępność w odpowiednim momencie. Co więcej, poza architekturą aplikacji nie można zapominać o architekturze biznesowej.  Planowane zmiany w  procesach biznesowych muszą być spójne z harmonogramem zmian w aplikacjach. 

Mówiąc najprościej, żaden zespół w większym przedsiębiorstwie nie jest w stanie zobaczyć całego obrazu ani racjonalnie przewidzieć wszystkich zmian w czasie. Wiele ze wspomnianych zmian pojawia się poza zakresem ich prac. Z tego powodu zespoły potrzebują pewnej intencjonalnej architektury, rozumianej jako zestawu celowych, planowanych wytycznych architektonicznych, które dbając o projekt rozwiązania, jego wydajność i użyteczność będą drogowskazem dla zespołów podczas synchronizacji implementacji.

W tym właśnie miejscu pojawia się miejsce dla architekta.

Architekci mogą pomóc w zdefiniowaniu „zasad”, które pomogą połączyć zespoły. Istnieje bowiem różnica między projektowaniem oprogramowania a architekturą. Architekci nie zajmują się architekturą pojedynczej aplikacji a raczej powinni przedstawiać wytyczne odnośnie tego jak aplikacje powinny działać razem by zapewnić realizację procesów biznesowych, także tzw. procesów „end-to-end”.

Architekci wyznaczają granice funkcjonalne poszczególnych aplikacji. Architekci powinni rozumieć na wysokim poziomie abstrakcji, jakie funkcje ma dostarczyć aplikacja. Powinni także rozumieć ograniczenia technologiczne wynikające z przeszłych decyzji, jak i aktualnych decyzji organizacji.

Architekci nie muszą znać dokładnie wszystkich atrybutów w tabelach baz danych lub operacji interfejsów. Muszą natomiast wiedzieć jakie usługi oferują poszczególne aplikacje i jakie grupy danych przetwarzają. Architekci muszą także wspierać jakość rozwiązań poprzez nadzór nad realizacją szeregu wymagań poza funkcjonalnych.   

To właśnie ta wiedza wraz z mapą rozwoju aplikacji pozwala na uspójnienie i koordynację prac wielu zwinnych zespołów.  Architekt w ujęciu zwinnym to jedna z tych ról, które mają za zadanie, by ograniczyć skutki nadmiernej czasem „złej” zwinności. Architekt to osoba, która musi mieć długoterminową wizję wychodzącą poza kolejne sprinty. 

Gdy patrzymy rolę architekta z punktu widzenia SCRUM, to taka rola nie istnieje. Zapewne część kompetencji architekta aplikacji przejmie bardziej doświadczony członek zespołu. Architekci rozwiązań, korporacyjni, biznesowi nie mieszą się w tych zespołach, gdyż ich zakres prac wykracza poza sprint. Z tego też powodu rola architektów powinna być skonstruowana obok zespołów. Być może w dużych firmach pow stanie zespół ds. architektury. Zwróć uwagę, że napisałem obok, a nie nad zespołami.

Architekt to osoba, której kompetencje i doświadczenie ma wspierać i wzmacniać organizację. Rolą architekta nie jest planowanie prac zespołów a jedynie lub aż wzmacnianie i koordynacja ich pracy. Z tego też powodu architektów, właścicieli produktów, zespół można postawić w jednej linii, jako osoby, które współpracując powinny dostarczyć jak najlepsze rozwiązanie. 

Czy wobec powyższego, architektura powinna powstać na samym początku przedsięwzięcia?

To raczej trudne. Jest zbyt wiele czynników by można było być pewnym, że nic się nie zmieni.  Wydaje się, ze sensownie jest najpierw zbudować architekturę inicjalną oraz określić cele rozwoju architektury. Być może uda się przygotować zgrubną, docelową mapę aplikacji. Taką „mapę drogową”, która pozwoli na prezentację zespołom i innym interesariuszom kierunek, do którego zmierza architektura.

Wspomniana „mapa drogowa” może, a nawet powinna dotyczyć także procesów biznesowych. Warto by wiedzieć, które z procesów zamierzamy zrobotyzować, które zautomatyzować, a które wygasić.    W kolejnych iteracjach, w kolejnych sprintach architekci uszczegóławiają architekturę pomagając zespołom podjąć decyzję lub definiując wytyczne odnośnie do sposobów  komunikacji pomiędzy aplikacjami oraz zakresu przetwarzania danych. 

Pisząc o wytycznych warto jest wspomnieć o szerszym katalogu produktów architektury.

W moim przekonaniu produkty architektury należy rozpatrywać w kontekście strategicznym i operacyjnym. Z punktu widzenia strategii  architekci powinni, zgodnie ze strategią biznesową, strategią IT opracować i zakomunikować  technologie i pryncypia architektoniczne dotyczące współpracy pomiędzy aplikacjami. Powinny to być treściwe krótkie dokumenty.  Wizja architektury docelowej i przejściowej w notacji UML lub ArchiMate są mile widziane. Powiązania pomiędzy wysokopoziomowymi procesami biznesowymi a aplikacjami wręcz wskazane.

Operacyjnie, w zależności od organizacji, architekci minimalnie wytyczne architektoniczne lub w bardziej złożonych sytuacjach architekturę wysokiego poziomu (ang. High Level Design). Diagramy komponentów i sekwencji mile widziane. Architekci także podczas planowania sprintów powinni „na żądanie” podejmować decyzje architektoniczne. Rejestr decyzji i odstępstw architektonicznych jest wskazany. Przydatny jest on zwłaszcza w sytuacji, gdy decyzje mają charakter okresowy.    

Reasumując. Rola architekta w podejściu zwinnym, w moim odczuciu jest ważna. Architekci co prawda nie występują jako członkowie zespołu, ale mogą wspierać te zespoły. Koordynacja zmian „globalnych” zarówno w warstwie biznesowej, jak i aplikacyjnej nie jest też łatwa. W moim odczuciu jest jednak konieczna. Myślę, że to właśnie architekci są tymi, którzy są w stanie „ogarnąć chaos” i mam nadzieję, że właśnie to robią 🙂