Zasady tworzenia zwinnej architektury

Data: 2018-01-15
Autor: Sebastian Konkol
Zasady tworzenia zwinnej architektury

Umysł architekta pracuje inaczej. Jest wrażliwy na schematy i wzorce. Praca architekta opiera się często na zasadach, tzw. pryncypiach (Architecture Principles). Jakimi pryncypiami powinien kierować się architekt tworząc zwinną architekturę (Agile Architecture)?

Praktycy IT zachłystują się podejściem zwinnym podejściem do tworzenia oprogramowania, prześcigając się w wizjach organizacji pracy i metodach działania. Jak już pisałem, zwinność w odniesieniu do architektury ma nie tylko stronę metodyczną, ale także (a może przede wszystkim) stronę efektu działania, inżynieryjną. To właśnie zwinność w tej drugiej sferze decyduje o uzyskaniu zwinnej architektury. Pracując jako architekci powinniśmy dysponować warsztatem dopasowanym do zwinności, ale osadzonym w praktyce pracy architekta. Jednym z elementów takiego warsztatu są właśnie zasady, pryncypia architektoniczne. Niestety, pryncypia dostały już łatkę – w wielu (wszystkich?) przypadkach prac nad architekturą korporacyjną pod tym hasłem pryncypiów tworzone są ogólne bzdury typu że używamy powtórnie, że związek ze strategią, że wspólnie zdefiniowane pojęcia biznesowe, że zarządzamy długiem technologiczny, że nie kopiujemy danych. Takie pryncypia nie mają kompletnie żadnego przełożenia na architekturę – to martwe, nic nie wnoszące zapisy, z resztą łamane nagminnie, bo zapomniane natychmiast po opublikowaniu. Między tymi zapisami a praktyką pracy architekta jest bowiem taka przepaść „granulacji” przedmiotu pracy, że przełożenie tych pryncypiów na wynik prac architektonicznych jest niemal zawsze działalnością z obszaru filozofii, a nie inżynierii.

Zasady architektoniczne muszą być ogólne, ale mieć cechę bezpośredniej aplikowalności do architektury. W podejściu zwinnym konieczność pragmatycznej strona określania zasad jest jeszcze mocniej eksponowana. Na bazie moich doświadczeń oraz wskazówek odnośnie tego, czym ma być zwinność w architekturze wskazałbym trzy obszary pryncypiów architektury zwinnej:

  • reużywalność, czyli wielokrotne użycie – tworząc architekturę (korporacyjną, rozwiązań, oprogramowania) trzeba myśleć o takim podziale problemu na komponenty, aby (a) identyfikować miejsce dla użycia już posiadanych komponentów, (b) wykorzystywać dostępne, choć nie posiadane komponenty oraz (c) definiować nowe komponenty z myślą o ich użyciu w przyszłości;
  • rekonfigurowalność, czyli użycie w innym kontekście – pracując na architekturze trzeba zadbać o uniezależnienie komponentów od kontekstu ich działania i zamykać kompleksowo logikę biznesową dotyczącą konkretnego zagadnienia w pojedynczym komponencie;
  • skalowalność, czyli użycie w większym zakresie / zasięgu – architektura musi zapewniać możliwość zwielokrotnienia działania komponentu, realizacji logiki biznesowej w szczególnych okolicznościach w innej implementacji, czy dławienie ruchu oferowanego komponentom.

Tworząc pryncypia zwinnej architektury chcę przyjąć pewne podstawy, z którymi nie trzeba chyba dyskutować. Dla przykładu, wiadomo, że stosujemy frameworki bo one ułatwiają realizację rozwiązań. Wiadomo, że skalowalność to zagadnienie opisywane w trzech wymiarach (zwielokrotnienie komponentów, dekompozycja względem funkcjonalności, dekompozycja względem danych).

Lista pryncypiów nigdy nie jest zamknięta – w miarę ewolucji środowiska różne elementy mogą mieć znaczenie. Na początek proponowałbym przyjąć podstawowe zasady odnoszące się do powyższych obszarów pryncypiów architektury zwinnej:

  • Hermetyczna modularność. Komponenty są oddzielnymi, rozróżnialnymi, samowystarczalnymi modułami współpracującymi dla osiągnięcia wspólnego, współdzielonego celu. Ma zapewnić między innymi zdolność do podmiany lub zrównoleglenia implementacji komponentu. Wspiera reużywalność.
  • Kompatybilność wtyczek. Komponenty współdzielą i implementują zdefiniowane standardy interfejsu i interakcji, dając się łatwo dodawać i usuwać. Standardy mogą obowiązywać w różnych warstwach, od medium komunikacji (np. TCP), przez syntaktykę (np. XML) po semantykę (np. nazwy i znaczenie metod i atrybutów). Wspiera reużywalność.
  • Ułatwione, „wspomagane” reużycie. Komponenty są gotowe do ponownego użycia i replikowania, a gotowość do ponownego użycia i replikowania, a także zarządzania nimi, ich utrzymania i upgrade’ów są świadomie projektowane i realizowane. Wspiera reużywalność.
  • Płaskie inteakcje, choreografia. Komponenty komunikują się bezpośrednio między sobą, a preferowaną taktyką komunikacji jest równoległość, a nie sekwencja komunikacji. Ma eliminować sytuacje, w których realizacja jakiejś funkcji wymaga „łańcuszka” wywołań komponentów i nie uda się, jeśli któryś z komponentów nie zadziała. Wspiera rekonfigurowalność.
  • Odroczone kontrakty. Związki między komponentami są krótkotrwałe, gdzie to jest tylko możliwe. Ustalenie powiązań jest odraczane do momentu, w którym ustanowienie takiego powiązania jest niezwłocznie konieczne, a związki takie są harmonogramowane lub nawiązywane w czasie działania komponentu. Wspierają rekonfigurowalność.
  • Rozproszenie kontroli i informacji. Logika komponentów nakierowana jest na osiągnięcie celu, a nie wyznaczana przez metodę działania. Decyzje podejmowane są wtedy, kiedy zgromadzona została maksymalna dostępna wiedza. Informacja jest kojarzona lokalnie, dostępna globalnie i dowolnie rozpowszechniana. Wspiera rekonfigurowalność.
  • Samoorganizacja. Związki między komponentami nie są narzucane (określają się na podstawie zapotrzebowania na współpracę), a mechanizmy interakcji między komponentami mają zdolność do dopasowania lub negocjacji parametrów. Oznacza tworzenie komponentów „świadomych” wersji protokołów komunikacyjnych, które implementuje. Wspiera rekonfigurowalność.
  • Ewoluujące standardy. Frameworki standaryzują komunikację i interakcje między komponentami, definiują reguły kompatybilności komponentów i mają wbudowaną odpowiedzialność wdrażanie ewolucji frameworków i kompatybilności. Wspierają skalowalność.
  • Redundancja i różnorodność. Zduplikowane, różne implementacje komponentów są wykorzystywane dla zapewnienia wydajności i skalowania, tolerancji błędów, a różnorodność implementacji różnych metod realizacji tego samego celu działania komponentu jest badana i wykorzystywana. Wspierają skalowalność.
  • Elastyczna pojemność. Zwielokrotnienie instancji uruchomionego komponentu może być zwiększane lub zmniejszane w szerokim zakresie w ramach użytkowanych frameworków. Wspiera skalowalność.

Związek podejścia zwinnego z architekturą nie jest rzeczą nową. Wiele wiedzy w tym obszarze wytworzył kolega z Cutter Consorcium, Scott Ambler. Tym niemniej, niewiele jest publikacji doświadczeń z przedsięwzięć realizowanych w zgodzie z zasadami zwinnej architektury – szczególnie w sferze inżynierskiej. Tym bardziej nie ma skąd czerpać mądrości o zasadach, jakie powinny kierować pracą architektów realizujących zwinną architekturę. Nawet jeśli nieudolnie, chcę wypełnić tę lukę. Może coś dodacie?

Pozostaw komentarz