Agile Architecture Defined

Data: 2017-08-17
Autor: Sebastian Konkol
Agile Architecture Defined

Termin „agile” zrobił zawrotną karierę. Już nie tylko proces wytwórczy oprogramowania jest zwinny – zwinne są także projekty, nawet bez komponentu informatycznego. W praktyce jednak znaczenie tego terminu jest wypaczone, wręcz wykoślawione aż do granic karykatury. Kiedy słyszę „nasz projekt robimy w trybie agile” to już wiem, że w projekcie nie do końca znany jest cel, a jego zakres jest mglisty nawet dla największych optymistów. Chciałbym, aby architekturę nie spotkał ten sam los „zwinności” karykaturalnej.

W każdej sferze, w której aplikowane są koncepcje zwinności, fundamentem stają się dwa kluczowe elementy: zdolność do adaptacji w warunkach zmienności oraz świadomy i odpowiedzialny udział ludzi. Zasięg Agile Manifesto, choć powstało ono z myślą o procesach wytwórczych, rozciąga się zarówno na sferę organizacji i prowadzenia projektów, jak i na działania w sferze architektury, także korporacyjnej. Współczesna informatyka, zarówno w sferze wytwarzania jak i eksploatacji systemów, musi działać na zasadach systemów złożonych – rządzonych prostymi regułami, z integralnym udziałem ludzi będących nie użytkownikami systemu lecz jego integralną częścią. Z lematu prostoty reguł wynika wprost wykorzystanie najlepszych praktyk (Best Practices), zamiast ciężkich i rozległych ram procesowych (Frameworks). Żaden proces nie zapewni skuteczności działań – to cecha ludzi.

Prawdziwie zwinna architektura musi być jednak „odporna” nie tylko na zmiany zachodzące w czasie trwania projektu rozwoju takiego, czy innego systemu lub rozwiązania. Zwinność w tej sferze to domena procesu wytwórczego (np. SCRUM) czy zarządzania projektem (np. APM). Największa wartość prawdziwie zwinnej architektury objawia się po zakończeniu projektu w postaci zdolności do wykorzystania tego samego rozwiązania w innych, zmieniających się uwarunkowaniach i ograniczeniach. Nie chodzi wszak o to, aby – w obliczu konieczności dostosowania – egzekwować zwinność w kolejnym projekcie. Chodzi o to, aby udawało się „obejść bez projektu”.

Na czym więc polega Agile Architecture? Na zbudowaniu takiego systemu, którego funkcje będą mogły być wykorzystywane w zakresie szerszym, niż pierwotnie zakładane. Esencją Agile Architecture nie jest jednak wcale doskonała, nieskończona elastyczność rozwiązania informatycznego. Taka elastyczność, czyli „zwinność świadomie wbudowana” w rozwiązanie, wymaga przewidzenia każdej sytuacji biznesowej, w jakiej system miałby być wykorzystany. Niejako z definicji takie podejście jest niezwykle kosztowne, zarówno w czasie wytworzenia jak i późniejszego wykorzystania, a ostatecznie okazuje się i tak ułudą. Zwinność musi opierać się na zdolności różnorakiego wykorzystania tego, co się ma w nowych warunkach. Systemy muszą być otwarte na takie działania, ale żaden system informatyczny nie będzie samodzielnie zwinny – fundamentem Agile Architecture jest połączenie człowieka z systemem informatycznym. To inteligentne i odpowiedzialne korzystanie z rozwiązań IT jest najważniejszym warunkiem osiągnięcia zwinności.

Te same pryncypia architektury mają zastosowanie zarówno w sferze architektury rozwiązań (Solution Architecture, SA) jak i architektury korporacyjnej (Enterprise Architecture, EA). Między tymi sferami działań architektów istnieje jednak zasadnicza różnica. O ile SA skupione jest na projektowaniu, a celem jest osiągnięcie jakiegoś stanu w przyszłości, o tyle EA musi być skupione na stanie bieżącym i problemach. W swej esencji EA służy całościowemu naprawianiu (sic!), a nie projektowaniu. Każdy, kto używa EA do „projektowania przyszłości” – prędzej czy później – stanie się metodykiem i odpłynie w siną dal zrozumiałą wyłącznie dla innych metodyków od EA i nikogo więcej – ani ludzi od biznesu, ani ludzi od IT. Przestrzegam. W realiach Agile Architecture rolą EA powinno być wykrywanie bieżących ograniczeń zwinności, a SA – usuwanie ich. Czy oznacza to zmiany w metodycznym podejściu do EA? Bez wątpienia! Zwinność i adaptacyjność nie idą w parze z pseudo-deterministycznym procesem przejścia od „wartości strategicznych” do bitów i bajtów. Dead on Arrival. EA powinna się skupić przede wszystkim na przedmiocie działań, a nie na metodach.

Agile Architecture „stawia na głowie” bardzo wiele koncepcji architektonicznych, a sięga znacznie dalej i głębiej. Zwinność architektury nie ma jednak szans bez adaptacyjności w umysłach architektów. Gotowi?

Pozostaw komentarz