Tytułem wstępu
Istnieje wiele różnych definicji roli architekta. Z drugiej strony, niektórzy w ogóle uparcie pomijają tę rolę w definiowaniu procesu tworzenia oprogramowania. Odpowiedzią na ten stan rzeczy jest znaczny, w ostatnim czasie, wzrost aktywności środowiska architektów dążących do stworzenia jednej spójnej definicji roli architekta. Wyrazem tej wzmożonej pracy jest chociażby wybór tematu dla piętnastego numeru
The Architecure Journal: "The role of an architect". Opierając się na nim, a w szczególności na
tym artykule, możemy wyróżnić następujące role architektoniczne:
- Enterprise Architect (architekt strategii)
- Business Architect (architekt biznesowy)
- Solution Architect (architekt rozwiązań)
- Software Architect (architekt oprogramowania)
Zasługują one na krótkie omówienie.
Architekt strategii odpowiedzialny jest za tworzenie strategii rozwoju oprogramowania w swojej organizacji. W tym celu współpracuje blisko z zarządem. Rola ta ma sens w bardzo dużych organizacjach komercyjnych, które utrzymują na potrzeby własnej działalności gospodarczej dziesiątki systemów informatycznych.
Zadaniem
architekta rozwiązań jest zapewnienie, że pojedyncze systemy tworzone dla organizacji wpasowują się w ogólną strategię budowy systemów informatycznych. Innymi słowy architekt rozwiązań implementuje strategię tworzoną przez architekta strategii.
Architekt biznesowy jest terminem nieco mylącym. Powinno się raczej powiedzieć „analityk biznesowy” . Jego rolą jest analiza procesów biznesowych oraz sporządzanie wymagań dla systemów informatycznych.
Architekt oprogramowania to najmniej biznesowa z ról architektonicznych. Obszarem zainteresowanie architekta oprogramowania jest pojedynczy system informatyczny. Osoba taka jest zwykle pracownikiem firmy tworzącej oprogramowanie na zamówienie innych organizacji, dlatego jest szczególnie dla mnie interesująca. W dalszej części tej notki termin „architekt”, jeśli użyty sam, będzie odnosił się do architekta oprogramowania.
Proponowana wizja roli architekta
Nie istnieje wiele gotowych opracowań roli architekta w firmie wytwarzającej oprogramowanie na zamówienie. Można jednak na podstawie obserwacji pewnych trendów spróbować taką rolę zdefiniować na podstawie ogólnych przemyśleń na temat architekta i architektury zaczerpniętych z prac autorytetów w tej dziedzinie.
Architekt w takiej firmie powinien być osobą godzącą ze sobą wszystkie aspekty tworzenia systemu informatycznego. Jego głównym zadaniem jest zapewnienie płynnej komunikacji z:
- Zarządem i klientem. W tym celu architekt musi porozumiewać się na płaszczyźnie biznesowej przedstawiając zalety budowanego systemu, argumentując konieczność zmian, umiejętnie przedstawiając konsekwencję podejmowanych decyzji projektowych.
- Analitykami. Główną odpowiedzialnością analityków w kontekście powstającego systemu oprogramowania jest stworzenie dobrej (spójnej, kompletnej) listy wymagań. Architekt powinien współpracować z analitykami zwracając uwagę na potencjalne problemy, białe plamy itp. Niektórzy autorzy, jak Karl Wiegers, mają tendencję do przeceniania roli analityka i całkowitego pomijania roli architekta. Osobiście uważam to za duże nadużycie. Swoją drogą książka, jeśli pominąć ideologiczne wstawki gloryfikujące analityka, jest bardzo dobra:)
- Deweloperami. W komunikacji z nimi rolą architekta jest przekazanie w zrozumiały sposób wskazówek dotyczących sposobu projektowania komponentów budowanego systemu. W zależności od specyfiki systemu architekt powinien bardziej lub mniej uczestniczyć w fazie projektowania szczegółowego.
- Project Managerem. Rzadko kiedy wymagania biznesowe są niezmienne podczas trwania projektu. Architekt musi współpracować z PM’em, aby nie dopuścić do nadmiernego spadku jakości systemu kosztem nowych funkcji, które mają być zaimplementowane. Współpraca ta może mieć różną postać, w zależności m.in. od środowisk, z których pochodzą PM i architekt. Dino i Andrea w swojej książce sugerują, że to PM powinien np. podejmować ostateczną decyzję o wyborze technologii. Moje doświadczenie podpowiada mi jednak, aby być w tej kwestii ostrożnym: jeśli PM jest zupełnie "nietechniczny", pozwólmy zdecydować architektowi.
Powyższy paragraf można podsumować krótko: rolą architekta jest wypracowywanie dobrych kompromisów podczas całego cyklu tworzenia systemu informatycznego. Architekt jest kanałem komunikacyjnym pomiędzy wszystkimi zaangażowanymi osobami. Od niego zależy jakość komunikacji. Spośród osobistości, na które się powołuje, Miha Kralj kładzie największy nacisk na ten właśnie aspekt pracy architekta.
Z drugiej strony architekt ma także czysto techniczne zadanie: w zakresie jego obowiązków jest dekompozycja koncepcyjnego modelu systemu na moduły i komponenty, czyli zdefiniowanie
architektury. Realizacja tego zadania wymaga od architekta następujących cech:
- Umiejętność patrzenia na problem całościowo. Architekt musi widzieć pełen obraz tworzonego systemu informatycznego, aby podejmować trafne decyzje. Nikt inny nie jest w stanie wykonać tego zadania. W tej kwestii zgadzają się wszystkie autorytety dziedzinowe, na które się powołuje.
- Wiedza techniczna. Oczywiście nie można być na bieżąco ze wszystkimi nowikami technicznymi, ale architekt powinien znać możliwości i ograniczenia poszczególnych technologii, bo nie jest możliwe zaprojektowanie systemu informatycznego w oderwaniu od technologii. Co ciekawe, wymaganie wiedzy technicznej wydaje się być kością niezgody pomiędzy wizjami architekta lansowanymi przez największe autorytety w tej kwestii. Dino i Andrea są zdania, że architekt musi wywodzić się ze środowiska deweloperskiego oraz że powinien pisać kod. Na drugim biegunie jest Miha Kralj, który uważa, że rola architekta nie jest związana z inżynierią i nie wymaga wiedzy technicznej. Ja osobiście skłaniam się ku wersji Dino, przynajmniej jeśli chodzi o rolę architekta rozwiązań. Jestem w stanie uwierzyć, że bardziej "abstrakcyjne" z ról architektonicznych mogą być z powodzeniem wypełniane przez nie-informatyków.
- Myślenie wzorcami. Istnieje cała gama sprawdzonych schematów budowy systemów, nazywanych wzorcami architektonicznymi. Architekt musi umieć stosować opracowane wzorce w swoich projektach, jak również ekstrahować wzorce ze swoich poprzednich projektów. Szczególnie ważne jest to ostatnie stwierdzenie. Jak słusznie zauważają Len, Paul i Rick, prawdziwa wartość architektury objawia się, kiedy jest ona użyta ponownie w kolejnych systemach.
Len, Paul i Rick w swojej książce wyróżniają spełnienie wymagań niefunkcjonalnych jako główny cel definiowania i utrzymywania architektury. Jest zestawem perspektyw (diagramów), które opisują różne aspekty systemu w kontekście spełnienia wymagań niefunkcjonalnych. To niewątpliwie interesujące podejście, ale według mnie pomija
samo sedno tworzenia oprogramowania, czyli osiągnięcie przewagi
biznesowej. Na nic nie zda się nawet najbezpieczniejszy i
najwydajniejszy system, który nie wykonuje przeznaczonych dla niego
funkcji.
Dino i Andrea definiują, w pierwszym przybliżeniu, architekturę
jako zbiór decyzji, które są trudne do zmiany w późniejszych etapach budowy systemu. Jest to dosyć popularna definicja, akceptowana przez wielu. Ciekawą jej krytykę zawarł w swojej znakomitej książce Martin Fowler. Zauważa on, że w dziedzinie oprogramowania każdy aspekt systemu można zmieniać. Idąc tym tropem stwierdza, że nie
podjęcie trudnych do zmiany decyzji jest istotą architektury, ale sam
wybór tych decyzji (spośród wszystkich decyzji, które podjąć należy).
Na koniec warto także wyraźnie zdefiniować czym architekt napewno się nie zajmuje, a co niektórzy mylnie tej roli przypisują. Po pierwsze,
nie należy do obowiązków architekta
analiza procesów biznesowych. Zadanie to wymaga bardzo mocnej wiedzy domenowej, które architekt nie posiada. Z drugiej strony architekt
nie zajmuje się projektowaniem klas w poszczególnych modułach – nie powinien schodzić „poniżej” diagramów komponentowych, aby nie stracić dobrego całościowego widoku systemu.
Chciałbym usłyszeć (zobaczyć?) Wasze zdanie na ten temat. Kto jest według Was architektem? Czy widzicie siebie w tej roli? Starałem się przedstawić Wam swój pogląd na ten temat na tle opinii wyrażanych przez pewne autorytety architektury oprogramowania. Być może moja koncepcja jest zbytnio przesiąknięta moimi własnymi doświadczeniami i tym, co ja chciałbym robić w przyszłości. Jeśli tak, powiedzcie mi o tym koniecznie.
Bibliografia
- Esposito, Dino and Saltarello, Andrea. Microsoft® .NET:
Architecting Applications for the Enterprise. Microsoft Press,
2008.
- Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2003.
- Wiegers, Karl E.
More About Software Requirements: Thorny Issues and Practical Advice. Microsoft Press,
2005.
- Bass, Len, Clements, Paul and Kazman, Rick. Architektura Oprogramowania w praktyce. WNT, 2006.
- Kralj, Miha. Architectures: the Good, the Bad and the Ugly. Prezentacja na konferencji TechEd EMEA 2008.
- Akenine, Danie. A Study of Architect Roles by IASA Sweden. The Architecture Journal, numer 15.