… parafrazując słowa Bena Parkera, wujka Spidermana (wiem, że dla niektórych to żenada tego nie wiedzieć, lecz mimo to wyjaśniam)…

Temat wyszedł z moich refleksji o architekturze oprogramowania, więc postanowiłam zrobić z niego prezentację, którą przedstawiłam po raz pierwszy w Białymstoku na grupie .Net. Wiele wątków, które tu umieszczę pochodzi od słuchaczy, post będzie więc kumulacją naszych wspólnych przemyśleń.

O co więc chodzi z tą władzą i odpowiedzialnością? Zacznę od tego, że każdy z nasz developerów chce lub kiedyś chciał zostać architektem (ew. managerem, ale nie o tym odłamie programistów chcę teraz pisać). Jeśli nigdy nie chciałeś i nie chcesz, to podejrzewam, że jesteś na początku swej drogi i wizja ciebie jako architekta jawi ci się jako cos jeszcze zbyt nieosiągalnego.

Otóż jest taki moment w życiu programisty, w którym ktoś obdarza nas i nasze kompetencje zaufaniem. Powierza nam odpowiedzialność w postaci decyzji architektonicznej. Możemy mieć wpływ na kształt projektu, być może tylko na wybór frameworka, a jednak w efekcie uderza nad woda sodowa do głowy. Teraz, myślimy, pokażemy wszystkim jak to się robi dobrze…

Architektura?

Ale zanim o rządach, to może słów kilka o tym, czym właściwie jest architektura. Jak się pogógla, to znajdziemy tysiąc definicji i perspektyw na zjawisko. Dla jednych to fizyczne komponenty systemu – serwery, szyny, chmury, dla innych podział systemu na warstwy, dla jeszcze innych pewne niefunkcjonalne wymagania, jak bezpieczeństwo czy niezawodność.

Z jedną rzeczą wszystkie te strony zazwyczaj się zgadzają – architektura, niezależnie od obecności pilnującej jej osoby – zawsze jest. Na domiar złego, to że nie jest nadzorowana, może doprowadzić do kłopotów. Makaronowy kod to najmniejsza z konsekwencji. Architektura dotyczy takich zagadnień jak niezawodność, bezpieczeństwo czy skalowalność. Polega na nadaniu kierunku implementacji systemu i komunikowaniu tego kierunku wszystkim osobom zaangażowanym w realizację. Architektura to fundamenty, wysokopoziomowe, trudne do zmiany w późniejszych etapach decyzje. Albo … jak podsunął mi jeden ze słuchaczy z Białegostoku: decyzje, które pozwolą reszcie zespołu na łatwiejsze rozwiązywanie problemów w przyszłości.

Po co?

Po co w ogóle zajmować się architekturą? Ano po to, by popatrzeć się na system pod kilkoma kątami. A w każdym z nich chodzi o jakość. Tylko cóż to jest ta jakość? Pominę tym razem internety i powiem nieco asekurancko – to zależy. Zależy m. in. od tego, kto tej jakości wymaga. Jeśli pod uwagę weźmiemy projekt systemu, ważne okażą się takie cechy jak integralność, reużywalność i utrzymywalność. Rozważając działanie trzeba pomyśleć o dostępności, wydajności, niezawodności, skalowalności czy bezpieczeństwie. Wdrożeniowców z pewnością zaciekawi łatwość serwisowania, czy testowalność. Dla użytkowników jakość to przede wszystkim użyteczność systemu, szeroko rozumiane UX.

O czym należy pamiętać budując architekturę? Przede wszystkim o tym, że nie jest ona tworzona raz, tak jak i całe oprogramowanie. Musi być zmieniana i musi być tak budowana by zmiany w łatwy sposób umożliwiać. Po drugie należy się skupić zarówno na modelach (które są uproszczeniem rzeczywistości) jak i kodzie (by w tych chmurach nie pozostać). Po trzecie należy wszystkie te decyzje komunikować, bo model, nawet najlepszy, jeśli nie zostanie przekazany, to nie zostanie użyty. Po czwarte i ostatnie, projekt powinien koncentrować się na kluczowych decyzjach, nie da się zamodelować wszystkiego, bo wtedy model przestaje być modelem, a staje się implementacją.

Jak się ocenia architekturę?

Jest kilka metod tzw. formalnych, które pozwalają na ocenę tego, czy nasz architekt dobrze wykonał swoją robotę. Takie metody jak ATAM, SAAM czy ARID polegają z grubsza na analizie scenariuszy. Pierwszą rzeczą jaką należy zrobić jest stworzenie tych scenariuszy i nadanie im wag/punktów/priorytetów. Ten etap sam w sobie jest wartościowy dla projektu, gdyż efektem są wymagania systemu.

W SAAM oceniane jest to, czy scenariusz jest możliwy do zaimplementowania w danej architekturze systemu bez wysiłku. Jeśli tak nie jest, to pytanie brzmi ile komponentów należy zmienić by to osiągnąć i jak trudne to będzie. ATAM bazuje na atrybutach powiązanych z danym scenariuszem. Rozważa się takie aspekty jak wydajność, czy bezpieczeństwo i określa się tzw. sensibility points, czyli punkty istotne z punktu widzenia tych aspektów. ARID z grubsza polega na zabawie jak za pomocą danej architektury zrealizować dany scenariusz i czy jest on w ogóle wykonalny.

Z mojego doświadczenia wynika jednak, iż architektura oceniana jest głównie “na oko” i na dodatek subiektywnie. Istnieje zbiór dobrych praktyk, które gdy się je stosuje, pozwalają nam, z w miarę wysokim prawdopodobieństwem, założyć, że architektura powstałej aplikacji jest dobra. Niekoniecznie trzeba podążać sformalizowanym procesem, żeby to zauważyć. Najważniejsze zwykle jest zdanie interesariuszy projektu, którym jest każdy kto ma jakikolwiek związek z budowaną aplikacją – klient, PM, developer, architekt, tester, gość od platformy systemowej czy deploymentu, oficer bezpieczeństwa. Każdy z nich ma swoją perspektywę i swoje priorytety. Architektura jest dobra jeśli żadnego z nich nie uwiera.

Rola architekta

Małymi kroczkami doszliśmy do naszego architekta. Osoby, która analizuje, projektuje i decyduje. Od której oczekuje się, że pokaże kierunek implementacji i przypilnuje, by był on utrzymywany. Aby jego działania były skuteczne, architekt powinien być elastyczny i komunikatywny. Do jego obowiązków należy weryfikowanie i ocenianie implementacji pod kątem realizacji architektury, a także rozwiązywanie pojawiających się w związku z nią problemów. Dodatkowo dochodzi tu kwestia planowania przyszłych kroków implementacji i zarządzania ryzykiem.

Aby wszystkie te działania miały miejsce, a przede wszystkim by zostały zaakceptowane przez zespół, na architekta wybiera się zazwyczaj osobę z dużym doświadczeniem i wiedzą. No i stąd ta kwestia władzy – jeśli mianujemy kogoś architektem, od razu stawiamy go na piedestale. Dając mu w ręce tyle odpowiedzialności, naturalnym odruchem jest myślenie, że wiąże się z tym decyzyjność.

Z premedytacją użyłam słowa rola, a nie stanowisko. Myśl/i rozwinę w przyszłych postach, w różnych ujęciach takich jak style podejmowania decyzji, dojrzałość zespołu, czy moje własne doświadczenia związane z architektami.