Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
Słów kilka o roli architekta

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


  1. Esposito, Dino and Saltarello, Andrea. Microsoft® .NET: Architecting Applications for the Enterprise. Microsoft Press, 2008.
  2. Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2003.
  3. Wiegers, Karl E. More About Software Requirements: Thorny Issues and Practical Advice. Microsoft Press, 2005.
  4. Bass, Len, Clements, Paul and Kazman, Rick. Architektura Oprogramowania w praktyce. WNT, 2006.
  5. Kralj, Miha. Architectures: the Good, the Bad and the Ugly. Prezentacja na konferencji TechEd EMEA 2008.
  6. Akenine, Danie. A Study of Architect Roles by IASA Sweden. The Architecture Journal, numer 15.

Opublikowane 26 stycznia 2009 18:59 przez simon

Filed under: ,

Komentarze:

# re: Słów kilka o roli architekta @ 27 stycznia 2009 00:35

1. Wyjasnij to moze:

- Najpierw napisales "Architekt strategii (...) blisko z zarządem". Potem piszesz "W dalszej części tej notki termin „architekt”, jeśli użyty sam, będzie odnosił się do architekta oprogramowania". A potem: "Jego (analityka) głównym zadaniem jest zapewnienie płynnej komunikacji z: - Zarządem i klientem.". To jak to finalnie bys opisal? Z etgo co pisze to na razie wynika ze Solution Architect robi to co Enterprise Architect i jeszcze wiecej. Albo czegos  nie zrozumialem...

2. Zacytowales 2 skrajnosci "Dino i Andrea" oraz "Miha Kralj". Zaraz potem odnosisz sie do tego mowiac ze jestes posrodku, ale przesuwasz granice skrajnosci. Przesuwasz z "wywodzić się ze środowiska deweloperskiego oraz że powinien pisać kod" do "superdeweloperem". Pomiedzy "pisac kod" a "superdeweloper" jest jeszcze kawal do przeskoczenia...

3. "Starałem się przedstawić Wam swój pogląd na ten temat na tle opinii wyrażanych przez pewne autorytety architektury oprogramowania oraz .NET.". Jakos nie widze tego ostatniego elementu (.NET) ale wcale go nei oczekiwalem :-) [ chyba ze .net oznacza aplikacje "webowe"/"sieciowe" ;-) - ale to chyba jeszcze gorsze ograniczenie niz konkretna techologia ]

Ale ogolnie ciekawy artykul...

Wojciech Gebczyk

# re: Słów kilka o roli architekta @ 27 stycznia 2009 07:02

Główną różnicą między Enterprise a Solution Architect a _kontekście tego artykułu_ jest to, że działają zwykle w różnych organizacjach: EA u klienta dla którego nasza firma buduje software, a SA u nas. Oczywiście SA może także pracować w organizacji nie budującej oprogramowania (np. w dziale IT), ale wtedy, jak słusznie zauważyłeś, bez sensu jest przydzielanie mu roli komunikacji z zarządem.

Z tymi dwoma skrajnościami rzeczywiście się zagalopowałem. Wątek z superdeweloperem może jeszcze kiedyś rozwinę, na dziś wprowadziłem poprawkę, że zgadzam się z Dino jesli chodzi o SA, natomiast o wyższe/bardziej asbtrakcyjne role architektoniczne - z Miha. Chociaż to też nie fair, bo jestem przekonany, że Dino, pisząc o architekturze i architektach, miał na myśli tylko SA.

Ostatnia sprawa - wyciąłem ".NET". Moją intencją było zaznaczenie, że część osób na które się powołuje (np. Dino) są autorytetami bardziej technologicznymi (.NET), niż czysto architektonicznymi. Doszedłem jednak do wniosku, że skoro koleś pisze o architekturze książę, która zbiera całkiem niezłe recenzje, to mogę do wciągnąć do worka autorytetów w tej sprawie.

Dzięki wielkie za uwagi:)

simon

# re: Słów kilka o roli architekta @ 27 stycznia 2009 12:11

W pełni się zgadzam z teorią, która mówi, że architekt powinien pisać kod. W innym przypadku będzie on narzucał rozwiązania, które często mogą się nie sprawdzić. W końcu architektura tak jak mówisz jest związana z technologią, a ta zaś rozwija się bardzo szybko. Nie pisząc kodu przez dłuższy czas architekt nie jest w stanie ocenić czy dana (nowa) technologia rozwiąże jego i jego zespołu problemy.  

Moim zdaniem kolejną bardzo ważną cechą dobrego architekta jest sposób w jaki wybiera technologię. W nowym wydaniu The Architecure Journal jest wywiad z Udi Dahanem,  który trafia w same sedno problemu. Jego zdaniem architekt nie powinien rozważać co dana technologia oferuje, lecz jakie problemy ona rozwiązuje. To z kolei prowadzi do tego, że architekt musi się solidnie zapoznać z technologią zanim ją zastosuje.

Jedną z głównych zalet architekta powinna być również praca zespołowa. Architekt, który nie potrafi pracować w zespole prędzej czy później wzbudzi do siebie niechęć zespoły, która będzie powodowała poważne problemy w projekcie. Zespół zacznie stosować swoje rozwiązania, które nie będą tymi proponowanym przez architekta. Również należy zwrócić uwagę na to, że architekt nie powinnien podejmować decyzji bez zgody zespołu. Załóżmy przypadek, w którym architekt narzuci zespołowi korzystanie z OR mappera. Zespół nie znając tego rodzaju technologii może wykorzystać ją w nie odpowiedni sposób, co z kolei doprowadzi do poważnych problemów wydajnościowych, sprzężenia logiki biznesowej z mapperem, itd. Oczywiście można dopuścić do takiej sytuacji w przypadku gdy architekt pomaga zespołowi i uczy ich używania tej technologii. To znów wymaga z jego strony pracy zespołowej - więc koło się zamyka.

Nie zgodzę się z teorią, która mówi, że architekt nie powinien mieć styczności z pisaniem kodu domenowego. Tworzenie jedynie diagramów koncepcyjnych architektury aplikacji może szybko doprowadzić to tzw. Big Design Up Front. W efekcie końcowym powstanie wiele modeli abstrachujących architekturę, nie odzwierciedloną (zaimplementowaną) w samej aplikacji. Powracając do modelu domeny biznesowej. Model ten jest sercem każdej aplikacji więc wręcz wskazane jest by architekt brał udział w jej tworzeniu. Brak stosowania odpowiednich wzorców projektowych w ramach modelu domeny doprowadzi do zbyt skomplikowanej architektury aplikacji.

Architekt, musi znać biznesowe wymagania, dlatego że definują one rodzaj architektury systemu. Nie znając problemów biznesowych nigdy nie będziemy w stanie stowrzyć odpowiedniej architektury systemu.

Zachęcam również do zapoznania się z zdaniem Arnona Rotem Gal-Oz na temat cech architekta http://www.rgoarchitects.com/nblog/2008/10/26/ArchitectSoftSkills.aspx

Roman Jendrusz

Komentarze anonimowe wyłączone