Architekt w środowisku agile może być przez purystów uważany za wroga nr 1 zwinnego programowania. Mimo tego wiele organizacji, szczególnie posiadających większą ilość współpracujących zespołów, bądź przechodzących na agile z bardziej tradycyjnych metodyk decyduje się, niebezzasadnie, na zachowanie pozycji architekta. Jeśli już ma być architekt, to będzie architekt agilowy!
Zapomnijmy więc o architekcie, który charakteryzuje się własnym biurem, tym, że tworzy masę dokumentów, reguł i diagramów. Agile stawia na bezpośrednią komunikację międzyludzką, a dokumentacja jest pochodną działającego rozwiązania a nie odwrotnie. Zgodnie z powyższym architekt agilowy spędza większą część swojego czasu bezpośrednio współpracując z zespołami. Będąc na linii frontu może dobrze zrozumieć naturę problemów, z którymi na co dzień borykają się zespoły deweloperskie. Architekt agilowy nie narzuca swojego punktu widzenia, ale doradza, naprowadzając zespół na rozwiązania optymalne nie tylko w najkrótszym horyzoncie czasowym. Wartość dodana Architekta polega na tym, że ma on inną perspektywę niż zespół deweloperski. Pozwala mu to na dojrzenie rozwiązań przeoczanych przez zespół. Może on pokierować w stronę rozwiązania dającego ogromne korzyści w dłuższym terminie, ale wymagające sporego nakładu pracy w krótkim terminie.
Innym kluczowym obowiązkiem architekta jest pomoc w zawróceniu z drogi, która przy rozwiązywaniu problemu okazała się nieoptymalna. Swoim autorytetem pomaga podjąć trudną decyzję ograniczając dalsze straty.
Na etapie pozyskiwania wymagań czyli de facto uzupełniania product backlogu przez product ownerów architekt szacuje ryzyko poszczególnych zmian dla integralności projektu. Współpracuje szczególnie ściśle z zespołami zajmującymi się wymaganiami obarczonymi wysokim ryzykiem, a w przypadku najwyższych poziomów ryzyka zakasuje rękawy i przyłącza się do zespołu jako deweloper. Mając bezpośrednio do czynienia z kodem, architekt ponosi większą odpowiedzialność za wcześniej doradzone rozwiązania. Dzięki temu jego strategiczne decyzje są bardziej realistyczne, ma on bowiem na uwadze to, że może dojść do sytuacji, w której to on będzie bezpośrednio odpowiedzialny za implementację.
Spędzając dużo czasu z zespołami, pełni rolę mentora – wyjaśnia idee, wzorce, algorytmy, standardy, których członkowie zespołu nie znają. Nie jest przy tym alfą i omegą, ale stara zwrócić uwagę na pewne rzeczy i wyjaśnić wątpliwości. Będąc przez dłuższe okresy czasu zaangażowany w prace zespołu nie narzuca swoich pomysłów, ale zaszczepia je w zespole w ten sposób, aby zespół przyjmował jej jako swoje własne.
W świetle powyższych uwag Architekt 2.0 jawi się jako hybryda technicznego guru i cierpliwego nauczyciela. Architekt 2.0 równie swobodnie czuje się szukając synergii między systemami jak i pisząc skrypt automatyzujący.
