geekyprimitives

Dekonstrukcję architektury czas zacząć.

Czas płynie nieubłaganie, nowy rok nabiera rozpędu i nastał czas najwyższy aby zebrać w sobie troche siły i samozaparcia na kolejną projekcję wniosków i przemyśleń.

Minęło już ponad pół roku od momentu gdy przekroczyłem próg nowego biura, zasiadłem na nowym krześle, zapuściłem “żurawia” w “nieprzebyty lazur oceanu kodu”.Czas więc na podsumowanie i słów gorzkich kilka w temacie architektury i jej, a także mej “niemocy”.

Śpieszę też, z wyjaśnieniem, iż poziom mojego cynizmu nie uległ zmianie, więc niechaj teraz wszyscy czytelnicy przekręcą pokrętło regulujące współczynnik akceptacji dla cynizmu do właściwego poziomu.

Od ponad pół roku zasiadam jako sprawiedliwy (i czasami despotyczny) król Artur przy Okrągłym Stole “Core Architecture”. Nie zaprzeczę ani też nie potwierdzę, że bawię się przednio, znalazłem w końcu swą przystań a w niej właściwych ludzi na właściwym miejscu.

W czy więc problem i co skłoniło mnie do naruszenia spokoju i zebrania myśli ponieukładanych?
Nikt tak naprawdę nie wie co robimy, nikt tak naprawdę nie jest w stanie ocenić naszej pracy, jej jakości i celowości. Architektura tak jak i w większości poprzednich “kombinatów” jest tajemnym zakątkiem w Mrocznej Puszczy, gdzie brzydkie wiedźmy, o aparycji ukraińskich “pracownic utrzymania dróg” na trasie Częstochowa-Warszawa,w kotle warzą tajemnicze mikstury, zatruwające życie programistów, chłopaków od “hostingu” i dziewcząt z “supportu”.

O ile dla wielu z was taka sytuacja może brzmieć jak opis “pracy marzeń”, po pewnym czasie każdy rozsądny człowiek, wczesniej czy później ujrzy bezcelowość swego wysiłku.Mimo więc całej radości, którą przynosi mi moja praca, dumy z tego robimy, oraz rosnącego szacunku na “dzielni”, zaczynam się zastanawiać czy, odkładając na bok naszą satysfakcje, odwalamy kawał porządnej architektonicznej roboty czy też wcześniej czy później, ktoś przeklnie dzień gdy wraz z drużyną zajęliśmy nasze biurka przy oknie z widokiem na miasto.

Gwoli wyjaśnienia, cele mamy. Duże, grube, tłuste cele. Cele która mają nas pchnąć na nowe nieznane wody. Jednak są to cele odległe, jak miraż na pustyni, cele wydumane, realizujące (lub też nie) odległe strategiczne cele firmy (czy też osób trzecich i postronnych). W codziennej pracy potrzebuję jednak celów na wyciągniecie ręki, które utwierdzą mnie w pewności, iż jestem na dobrej scieżce ku “oświeceniu”. Potrzebuje też sposobu na potwierdzenie, że odgórnie narzucone cele nie sprowadzą mnie na manowce i podczas swej wędrówki przez mroczną puszczę nie trafię przypadkiem na chatkę psychopatycznego mordercy, czy też Baby Jagi.

Jeśli więc dane mi zostało dostać w pieczę Excalibur, którym to przebijam się przez wrogie zastępy wraz z mym dzielnym oddziałem, niszcząc po drodze wszelkie przejawy niesubordynacji i herezji wobec Przenajświętszej Architektury, zacząłem się zastanawiać, co tak naprawdę stanowi o sensowności i jakości mojej pracy. Jaki jest w tym wszystkim cel.Czym jest architektura, w kontekście systemów IT?. Co mamy na myśli słysząc od kolegów epitety w rodzaju “gównianą architekturę mamy”, “gdybyśmy tylko mieli lepszą architekturę” czy też “czym nas Bóg pokarał, że taka architekturę mamy”?

Jak zmierzyć architekturę, jak zmierzyć jej efektywność, czy realizuje postawione przed nią cele? Jaki jest cel architektury oprogramowania? Bo jeśli coś nie ma celu, jakie jest uzasadnienie dla jej istnienia? Czy moja “niemoc”, brak uchwytnego celu wynika z “niemierzalności” i “nieweryfikalności” tego co robię. Tego, że nie wiem kiedy mogę szczerze, bez korporacyjnego zadęcia, krzyknąć przez biurko do zespołu, sakramentalne “good job”?

Każdy w swej podróży przez kolejne krainy rządzone przez szalonych, despotycznych władców, zamieszkałych przez agresywane trolle, pomocne wróżki czy też pracowite krasnoludy spotyka Mędrca. Kogoś, kto w jednym zdaniu potrafi ująć piękno i złożoność otaczającego nas świata. Kogoś, kto używając wyważonych słów, jakby każde wypowiedziane słowo warte było fortunę, zadając pytanie tak naprawdę udziela Ci odpowiedzi. I gdy spotykasz taką osobę, często myślisz, że to szaleniec. I pobłażliwie usmiechając się, dalej podążasz obraną scieżką. Przychodzi jednak taki dzień, moment gdy słowa Mędrca nabierają sensu i każą Ci zawrócić i podziękować. Jego już tam jednak nie ma.
Mój Mędrzec opowiedział mi kiedyś o “myśleniu systemowym”. Opowiedział, to może w tym przypadku jest ewidentne nadużycie. Z całego zdania pamiętam tylko “myślenie systemowe” i “może Cię zainteresować”. W związku z tym, że jak na porządnego Mędrca przystało, gdy zrozumiałem sens tego zdania, on już w innej odległej krainie próbował przywrócić pokój i porządek, na własną rękę zacząłem szukać wiedzy.

Znalazłem ją w kultowej już dla mnie pozycji “Thinking in Systems: A Primer” autorstwa Donella H. Meadows.
Książka ta stanowi swojego rodzaju elementarz dla wszystkich tych, którzy próbuja zapoznać się z ideą myślenia systemowego. Wprowadza w świat przepływów, magazynów, pętli balansujacych i archetypów systemów. Aby nie przedłużać i jednocześnie ustanowić wspólną platformę wymiany myśli, przytoczę tylko definicję słowa “system” z tej ksiażki, abyśmy wszyscy mieli jasność o czym mowa. Systemem nazywamy zbiór połączonych ze soba elementów, które pełnią jakaś funkcje lub realizuja określony cel. Czyż nie brzmi to jak definicja systemów IT? To własnie ta definicja, dała mi nadzieje, że jestem blisko rozwiązania swoich “niemocy”.Zainspirowała mnie do rozpoczęcie indywidualnego toku studiów w czasie wolnym z teorii systemów. Książka opiera się w przykładach na obecnym systemie ekonomicznym, przepływie towarów i demografii. Jednak te same wzorce z zaskakującą lekkością przenoszą sie na teren naszych rozważań.

Według autorki wspomnianego dzieła, jedną z cech charakterystycznych dla wielu sprawnie działajacych systemów, i nie mam na myśli systemów IT (słowo “sprawnie” jakoś w tym kontekście tutaj nie pasuje), jest ich z angielska zwane “resilience”.Siegając jeszcze raz do słownika, odnajdziemy tam taka oto definicje:

“the ability of something to return to its original shape after it has been pulled, stretched, pressed, bent, etc.” – Merriam-Webster Dictonary

W wolnym tłumaczeniu, rozumiem to jako odporność systemu na stres. Na nieprzewidziane działanie sił spoza systemu, które wpływają na jego funkcjowanie, stabilność czy też wydajność. Rozumiem to jako zdolność systemu do powrotu do stanu sprzed pojawienia się tych sił.

Skoro już pojawiło sie słowo “stres”. Spróbujmy zastanowić się czym jest lub może być źródłem stresu w architekturze. Jakie czynniki mogą wpłynąć na wytrącenie architektury systemu (która sama w sobie jest systemem) ze stanu równowagi. Nie powiem, że wpadłem na te wszytkie przykłady sam, bo byłbym kłamcą.

Pamiętając o tym, że skupiamy sie raczej w całym tym monologu na architekturze aplikacji (nie poruszamy drażliwych tematów architektury systemów, integracji, rozwiązań czy też uber architektury zwanej też potocznie “enterprise architecture”), możemy spokojnie stwierdzić, że głównym źródłem stresu w architekturze jest szeroko pojęta zmiana:
– zmiany technologii
– zmiany infrastruktury
– zmiany procesu wytwarzania
– nowa funkcjonalność
– zmiany w zespołach pracujacych nad aplikacja
Każdy z powyższych, razem i z osobna stanowią źródło stresu, nie tylko dla organizacji, zespołów czy też ludzi. To także stres architektury. Architektury, która od lat trzeszczy w szwach, nie potrafiąc oprzeć się fali napływając nowych funkcjonalności.

Kiedy więc wiadomo, że macie do czyniania z porządną architekturą? Kiedy nową funkcjonalność wrzuca się lekko jak pączki do rozgrzanego tłuszczu. Kiedy zmiana “frajmłorka” budzi na uroczych buziach programistów szelmowski usmiech, bo wiedzą, że wszystko w ich systemie jest ładnie odseparowane, cyklu w zależnościach nie widziano od czasów dinozaurów, a nowi pracownicy łapią w lot tzw. “flow” i z lekkością nawijają kolejne rymy w rytm “tłustych bitów” płynących spod ich palców.

Co więc jest miarą dobrej jakościowo architektury? Niski koszt wprowadzenia zmian.

Czy jest to aż tak proste? Wystarczy, że będę mierzył, pilnował, doglądał by “technical debt” nie eksplodował w stratosferę, by wściekły pies “code complexity” nie wyrwał się z łańcucha i nie pogryzł każdego, kto położy ręke na klawiaturę.

Ponad wszelką wątpliwość, w pierwszej kolejności walczymy jednak o stabilność i wydajność. O SLA, uptime, zapytania na sekundę. Bo takie są oczekiwania klienta, bo to realne pieniądze dla firmy i wiele innych korzyści. To coś namacalnego, łatwego do policzenia.

Jedna z ciekawych obserwacji poczynionych przez autorkę w “Thinking in Systems”, jest tendencja organizacji do tworzenia wydajnych i stabilnych systemów kosztem ich odporności na stres, “elastyczności”.

Wydaje mi się, jestem o tym przekonany, kazdy dzień utwierdza mnie w tym przekonaniu, iż najwazniejsza kompetencja architektury jest praca na zapewnieniem systemowi odpowiedniej elastyczności. Utrzymanie odpowiedniego balansu, pomiedzy wydajnościa, stabilnoscia a elastycznoscia.

I tak dzięki “Thinking in Systems” powoli próbuję zdefiniować swój własny osobisty cel, że w tym szaleńczym wyścigu zbrojeń o SLA i tps, każda decyzja powinna być poprzedzona odpowiedzią na pytanie jak to wpływa na elastyczność systemu? Czy dołożenie połączeń do bazy danych, w sytuacji zmasowanego ataku użytkowników na nasze strony zwiększy, czy też zmniejszy elastyczność naszego systemu. Czy “małżeństwo” Spring Framework z JBoss 4.2.3, podniesie, czy powiększy koszt wprowadzania zmian. Czy obecna granulacja modułów projektu Maven’a, przyspieszy czy spowolni process budowania, co w efekcie wpłynie na koszt wprowadzania zmian.

Czy też wyrażone poglądy są jedyną słuszną drogą, prawdą objawioną? Gdyby tak było nie poddawałbym tego poglądu pod publiczną dyskusję.