Koder kodzi, architekt architekci

Na 4Developers odbył się Panel dyskusyjny nt. architektury, architektów i architekcenia:). Trudno powiedzieć, żebyśmy udzielili odpowiedzi na jakieś konkretne pytania, ale było miło. Chociaż padało pytanie o rolę/stanowisko architekta i jego miejsce w procesie, to wydaje mi się, że byłem odosobniony w zdaniu, że bez tradycyjnego architekta można się obejść. Podłapałem tę myśl od Scotta Amblera i po moich doświadczeniach z różnymi zespołami jestem przekonany, że to ma sens.

Ankietowałem kiedyś obsesyjnie, architektów (różne stanowiska różnie się się w firmach nazywają i mimo istniejących jakichś tam typologii, każdy nazywa je sobie po swojemu), aby namierzyć, co konkretnie robi osoba określana jako "architekt". Zbiorcze zestawienie przedstawiam poniżej.

Jaki jest Twój zakres obowiązków jako Architekta?

Odpowiadanie na pytania dotyczące struktury systemu Definiowanie interfejsów do/z systemów powiązanych Decydowanie o wykorzystywanej technologii na poziomie systemu Projektowanie deploymentu systemu Decydowanie o organizacji i rozmieszczeniu komponentów? Który kod umieszczany jest w bibliotekach, programach, gdzie są zewnętrzne biblioteki, co jest ładowane statycznie co dynamicznie? Utrzymywanie dokumentacji dotyczącej architektury system Zdefiniowanie struktury dokumentacji Określenie, które domeny biorą udział w danej funkcjonalności (co zapisują, co trzeba odczytać), jakie nowe interfejsy trzeba udostępnić, a jakie zmienić Prowadzenie prac R&D

Z jakimi pytaniami należy zwracać się do Architekta?

Ja ma odbywać się interakcja pomiędzy modułami/częściami systemu? Jakiej technologii najlepiej jest użyć do dostępu do bazy danych? Jak zabezpieczać pliki konfiguracyjne w systemie/aplikacji? Jaki model konfiguracji serwerów (np. Tomcat) przyjąć dla produktów/aplikacji webowych? Jak należy definiować zewnętrzne interfejsy systemu? Jakie elementy systemu i według jakich kryteriów mają podlegać walidacji? Jakie są główne komponenty systemu? Czy wymiana danej technologii mogłaby wspomóc działanie systemu? Jakich zmian wymagać będzie wprowadzenie danej funkcjonalności? Jak wygląda flow w danym komponencie (np. przetworzenie wiadomości w kolejce)? Jakie są wymagania funkcjonalne dla danego produktu Jak konkretny proces biznesowy realizowany jest w architekturze? Jak wygląda zużycie zasobów sprzętowych i programowych w danym okresie czasu? Jakie narzędzia i skrypty należy wdrożyć, aby usprawnić proces wytwarzania oprogramowania? Jak zorganizowana jest infrastruktura sprzętowa (jakie hosty? jak są powiązane?) i programowa (jakie wersje? gdzie?) systemu?

Z jakimi pytaniami NIE należy zwracać się do architekta?

Czy ta funkcjonalność działa poprawnie? Jakie projekty idą na najbliższy realese? Jaki będzie koszt projektu X? Jak działa ta funkcjonalność? Jak z korzystać z tego pakietu/biblioteki? Do jakich zadań planowany jest Pan X? Kiedy wypada deadline testów systemowych Jaki algorytm wykorzystać do…? Czy następujące zachowanie systemu jest poprawne?

Jeśli popatrzeć na wymienione obowiązki, to trudno oprzeć się wrażeniu, że z niemal wszystkimi z nich może sobie poradzić zespół jako taki i nie potrzeba do tego wydzielonego architekta. Jedyna różnica między w/w architektem a "zwykłym" programistą jest taka, że ma on architekt większe doświadczenie (ale nie to mierzone w latach) i większą wiedzę o systemie.

Wydaje się, że potrzeba powołania osoby w randze architekta wynika z potrzeby rozwiązania następujących problemów:

• niedostateczne komunikowanie architektury w zespole i pomiędzy zespołami
• brak nazwanego procesu rozwoju architektury działającego obok procesu dostarczania; o tym procesie pisaliśmy/mówiliśmy w Ewolucyjna architektura: Jak zorganizować proces rozwoju architektury?
, Ewolucyjna architektura, Ewolucyjna architektura
• Brak użytecznej (nie wciąganej z kodu przez EA) dokumentacji architektury; o tym pisaliśmy nieco w Dokumentowanie architektury, Dokumentowanie architektury cz.2

Można odnosić wrażenie, że tego typu architekt został wymyślony po to, aby wyousourcować w/w problemy. Sęk w tym, że staje się on wąskim gardłem procesu. Po prostu nie nadąża z pracą. Wtedy trzeba powołać kolejnego i kolejnego i kolejnego. Po pewnym czasie okazuje się, że architekci zajmują się głównie sprawami organizacyjno-konfiguracyjno-spotkaniowymi, a programiści przestają czuć się odpowiedzialni za architekturę, gdyż ta "należy" do architektów. I wtedy koder zaczyna kodzić, architekt zaczyna architekcić, a architektura zaczyna dryfować.