Tuesday, April 16, 2013

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:

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ć.

3 comments:

  1. Pierwszy punkt dlaczego potrzebujemy architekta: Żeby komunikował jaka jest architektura.
    Fajnie to brzmi :)
    Przynajmniej w kontekście, może źle pojmuję tezę, że architekta nie potrzeba.

    Może by uporządkować dyskusję na blogu zrezygnujesz po prostu z pojęcia architektury, bo to się jednoznacznie kojarzy z architektem. Taki problem z wykorzystywaniem ogólnie znanych słów.

    Ten sam problem mają testy. Było tego nie nazywać testem a specyfikacją miast dziwić się teraz, że każdy myśli o weryfikacji a nie projektowaniu korzystając z jakiegoś Xunita.

    ReplyDelete
  2. 100% zgody - plus pojawiają się problemy z outsourcingiem do konsultantów. Jeśli wybierani są na podstawie wiedzy i doświadczenia to w pewnym momencie pojawia się konflikt architekt w korporacji macierzystej vs. specjaliści w firmie consultingowej.

    ReplyDelete