Trzeba robić architekturę inaczej

Data: 2021-10-20
Autor: Sebastian Konkol
Trzeba robić architekturę inaczej

W czasach, kiedy miałem coś wspólnego z zarządzaniem, w świecie projektów było takie powiedzenie: „szybko, tanio, dobrze – wybierz dwa”. Choć traktowane było jak anegdotka, w rzeczywistości było to (i jest nadal) bardzo, ale to bardzo prawdziwe. W świecie architektury są bardzo podobne dylematy, choć nie da się ich opisać aż tak prostym stwierdzeniem. Sposób kształtowania architektury musi nadążać za zmianami w otoczeniu, przyspieszeniem, złożonością, wykładniczym wzrostem ilości danych oraz rosnącymi oczekiwaniami „czynienia magii”, czyli dokonywania cyfrowych transformacji z użyciem BigData (już niemodne), blockchain (moda już przemija), AI/ML (na pewno pozostanie) i czego tam jeszcze trzeba użyć. Poniżej propozycje zmian w sposobie i otoczeniu kształtowania architektury pozwalających na radzenie sobie ze znaczącymi dylematami.

Target Architecture does not exist

Planowanie w sferze architektury przebiega niemalże zawsze według wzorca: (1) ustal, gdzie chce dojść, (2) ustal, gdzie jesteś, (3) określ ścieżkę z miejsca wyjścia do miejsca dojścia oraz (4) dopilnuj realizacji tej ścieżki. Ten wzorzec jest bardzo dobry i opiera się na … transferze odpowiedzialności na „strategię biznesową”. Zakłada bowiem, że ten stan docelowy daje się określić na bazie tejże strategii, a później już z górki. Jeśli jednak spojrzeć współodpowiedzialnie za wartość biznesową, bardzo szybko dojdziemy do wniosku, że (a) nikt we współczesnym biznesie nie powie, jak będzie za 5 lat oraz (b) wszystko to, co wymyślimy dzisiaj z prawdopodobieństwem graniczącym z pewnością za rok będzie już nieaktualne. Nie ma sensu, a raczej realistycznej możliwości, aby oprzeć rozwój architektury na nieuchwytnym celu. Coraz częściej przekonuję się, że skuteczniej jest przygotować się na zmiany, niż udawać, że realizacja 5-letniego planu ma jakieś logiczne podstawy.

Architektura powinna pozwalać na reakcję na zmiany – im szybsze i dalej idące (pozostając nadal „pod kontrolą”), tym architektura lepsza. Naturalnie oznacza to dobrą znajomość tego, czym się dysponuje na moment startu … więc, ponownie, nieco odmiennie od dzisiejszych praktyk nastawionych na „architekturę docelową”. W naturze nie ma sytuacji „zerojedynkowych”, więc w praktyce część działań jest zwykle osadzona w myśleniu o architekturze docelowej, a druga część tego miksu – w bieżącej adaptacji. Jeśli więc uważasz, że wdrażanie architektury docelowej jest trudne, a agile bałagani, to niestety, taka to już rzeczywistość, a to, co można zrobić, to niedokładanie swoich kilku okruchów do istniejącego już bałaganu.

IT Strategy is not a plan any more

Kiedy mówimy o budowaniu długoterminowego planu działania dla IT jako funkcji wsparcia pada termin strategii IT (w firmach technologicznych IT nie jest funkcją wsparcia, tylko generatorem biznesu, więc tu sprawa ma się „nieco” inaczej). Od zarania dziejów było tak, że na podstawie strategii biznesowej robiło się strategię IT – wymyślało, w jaki sposób IT ma wspierać biznes i tak dalej. I choć dokładnie wiadomo, jak destrukcyjne to jest (IT zaczyna mieć jakieś własne cele, pojawiają się wymagania synchronizacja różnych „strategii cząstkowych”) nadal takie myślenie pokutuje w większości organizacji. IT – podobnie jak finanse czy HR – nie ma własnej strategii, a jedynym powodem istnienia IT wsparcie dla biznesu. IT może (a raczej musi) mieć architekturę (wizję, pryncypia, mapy, APM, data governance, TRM), imperatyw doskonalenia i usuwania istniejących ograniczeń oraz cel, aby nie podejmować decyzji, jakie ograniczałyby biznes w przyszłości. Nadrzędnym zadaniem IT (i odpowiedzialnością szefostwa IT) powinna być ciągła dbałość o najlepsze zarządzanie aktywami informacji firmy, podobnie jak finanse odpowiadają za aktywa finansowe. I tak, napisałem o informacji, a nie informatyce, bo IT powinno odpowiadać za kondycję aktywów (informacji), a nie wyłącznie za narzędzia do organizacji informacji (systemów informatycznych).

Na dziś miejsce strategii (tradycyjnego planu, portfela przedsięwzięć) powinny zająć reguły osadzone w IT Governance (budowanie resilience i usuwanie ograniczeń, model Demand-Supply, zapewnienie zarówno funkcjonowania Business Pull jak i Technology Push). Własne działania IT powinny się sprowadzać do osiągnięcia zdolności zapewniania biznesowi gotowości do zmiany kierunku lub doskonalenia tej zdolności oraz zapewniania partnerskiego udziału w przedsięwzięciach rozwojowych. Modus operandi IT to rozumienie ograniczeń (technicznych, organizacyjnych, procesowych, zasobowych) i ich ciągłe usuwanie. Grube optymalizacje dla kontroli kosztów już zostały zrobione (chyba, że jakieś IT kompletnie partoli swoją robotę). Taniej już nie będzie, teraz trzeba się skupić na współudziale w generowaniu biznesowej wartości.

Architectural Superpowers

Są dwie takie supermoce architektury: Agility (the power to embrace a change) and Resilience (the power of embracing failure). Wiedząc i pamiętając, jak bardzo wykrzywiona została cecha zwinności i do jakich absurdów została sprowadzona, dostrzegam pewne symbole powracającej karmy w takich wydarzeniach jak COVID, bo stanowią one rzeczywiste „sprawdzam” dla wszystkich przeświadczeń i wierzeń. Dzięki takim wydarzeniom do świadomości menedżerów może przebić się choć trochę prawdy. A prawda jest taka, że zwinność tak dzisiaj gloryfikowana jest nie tyle bezwartościowa, co tragicznie szkodliwa. Jest ona bowiem aplikowana nie tam, gdzie jest potrzebna (w architekturze), lecz tam, gdzie jest łatwiej ją zaaplikować (w procesach wytwórczych). Co nam po tym, że możemy „w zerowym czasie” zmienić priorytety działań (proces wytwórczy), jeśli te działania i tak zajmą pół roku w konkretnym systemie (architektura)?

Takie wydarzenia, jak COVID pozwalają także na refleksję dalszą: osiągnięcie nawet najlepszej zdolności do zmiany nic mi nie pomoże, jeśli nie będę miał możliwości wykonać ruchu. Jak bowiem wie każdy żeglarz, aby manewrować trzeba się poruszać, a podstawa dla zdolności do poruszania się to odporność na trudności, błędy, porażki. Architektura musi więc dawać podstawę dla działania, nawet w sytuacjach bardzo trudnych.

Supermoce architektury – zwinność (zdolność do adaptacji) i żywotność (odporność na problemy, blędy, porażki) – są czymś zupełnie odrębnym od tego, co w powszechnej świadomości mieści się w tych terminach. Jeśli firma ma uzyskiwać rzeczywistą wartość z działań w sferze IT, podstawą jej działań muszą być zwinność i żywotność, ale właśnie w sferze architektury, a nie procesów wytwórczych.

No space and time for “temporary solution”

Gdybym musiał wskazać jeden problem, będący największą zmorą architekta, wskazałbym tzw. „tymczasowe rozwiązanie”. Taki właśnie twór jest w sferze architektury ekwiwalentem „zrównoleglenia prac” na wielu frontach w sferze zarządzania projektami. Ostatnio wręcz obserwuję inwazję tymczasowych rozwiązań, na które w kolejnych krokach nakładane są jeszcze bardziej tymczasowe łatki, a jak trzeba coś zrobić naprawdę szybko i sprawnie, to z każdej szafy wypada nie jeden trup, ale od razu całe prosektorium. Rozwiązania „tymczasowe” czy „przejściowe” są takimi, bo dla jakiegoś celu (typowo  zyskania na czasie, obniżenia kosztów) do ich konstrukcji świadomie wprowadzono pewne ograniczenia, które zostały wyrażone w uproszczony sposób (np. „będzie działać przez kwartał”). Mają więc określony termin przydatności lub inne ograniczenia, po czym takie rozwiązanie musi być po prostu usunięte, bo (i to absolutnie bez wątpienia) nie jest ono skonstruowane dla bycia podstawą dla czegoś następnego.

Jestem absolutnym fanem podejścia “Learning by Doing”. Nauka jest bardzo wskazana, agile w teorii brzmi świetnie: zróbmy coś, popełnijmy błędy, nauczmy się, wyrzućmy do kosza i zróbmy lepiej. W codziennej rzeczywistości ten cykl kończy się jednak na „nauczmy się”, a często wręcz na „popełnijmy błędy”. W najczęstszej praktyce nic z tego, czego się uczymy nie jest później wdrażane, a decydujący o tym lekceważą wszystkie ograniczenia („No przecież działa…”). W praktyce więc nie stać nas na popełnianie błędów, bo organizacja pozostaje nie tyle z czymś niedoskonałym, co z czymś ewidentnie złym. Prowizorki są wszędzie najtrwalsze – ale skoro to tak dobrze wiemy, nauczmy się choć tego i nie popełniajmy więcej tego jednego błędu, w mojej ocenie najkosztowniejszego, jaki można sobie wyobrazić.

W praktyce, gdzie przytłaczająca większość firm „edżajlowych” nie dojrzała do takich metod działania, wszelkie propozycje „tymczasowego rozwiązania” powinny być traktowane na poziomie „mowy nienawiści” i z miejsca odrzucane. Jeśli ktoś ma co do tego wątpliwości, proponuję wprowadzić „okres tymczasowy”, w którym takie współdzielone ryzyko można przyjąć, jeśli także inni (w slangu IT tzw. biznes, czy kadra zarządzająca) dowiodą swoją dojrzałość i przy „najbliższym sprwadzam” dotrzymają swojej strony umowy, finansując naprawienie lub wyłączenie „tymczasowego rozwiązania” zgodnie z jego warunkami przydatności. Krótko mówiąc, na rozwiązanie tymczasowe stać jedynie rzeczywiście, naprawdę dojrzałe firmy. Otoczenie zmienia się zbyt szybko, żeby mniej dojrzałym firmom udało się zapanować nad konsekwencjami tymczasowości – takie firmy muszą robić wszystko od razu dobrze.

Do experiments routinely in sandbox

Nieodłączną cechą adaptacyjności jest zdolność do eksperymentowania. Naturalnie, dobra architektura to taka, która daje możliwości „eksperymentowania na produkcji”, eksperymentów pozostających pod kontrolą (patrz: sandbox). Eksperymentuje się jednak nie po to, żeby sprawdzić systemy informatyczne lecz aby sprawdzić modele biznesowe, którym mają służyć. Jak wiemy, najlepiej jest potknąć się najszybciej, jak to możliwe, więc na pierwszy ogień powinny iść najbardziej ryzykowne elementy modeli, a nie najbardziej standardowe. Cóż nam bowiem po sprawdzeniu, że standardowy system realizuje standardowe funkcje w standardowy sposób?

Eksperymentowanie w sferze biznesowej nie oznacza jednak dodatkowo eksperymentowania w sferze technicznej, a wręcz przeciwnie. Jeśli eksperymentowanie w sferze biznesowej ma być (w co głęboko wierzę) taktyką rozpoznania rynku (zamiast niekończących się analiz biznesowych i badań rynku o wątpliwej wiarygodności), to informatyka „pod takie eksperymenty” musi być bardzo dobra, dojrzała, wiarygodna i zaawansowana, a nie eksperymentalna.

Bezpieczne eksperymentowanie musi zapewniać separację działań prowadzonych w trybie eksperymentów od działań rutynowych – począwszy od określenia, dla kogo to obowiązuje, przez zapewnienie braku wpływu na operacyjne i finansowe wyniki firmy, aż po wydzielenie eksperymentów ze standardowego raportowania. Eksperymenty nie są budowane po to, aby w pełni panować nad systemami informatycznymi. Eksperymentowanie wymaga od IT ponoszenia większego ryzyka, a największy błąd, jaki można popełnić, to uznanie, że to coś zrobione na potrzeby eksperymentu jest wystarczająco dobre, aby działało dłużej – więcej nikt nigdy nie weźmie już odpowiedzialności  za rozwiązanie „na potrzeby eksperymentu”. Jeśli zdolność do eksperymentowania staje się podstawą taktyczną współczesnego biznesu, to gotowość do eksperymentowania musi być fundamentalnym założeniem architektonicznym dla każdego systemu informatycznego wspierającego ten biznes.

IT Projects are systematically wrong

Architektura IT definiuje każdy projekt – określa jak zrobić to coś, co projekt ma zrobić. Projekty IT mają realizować cele biznesowe w zgodzie z architekturą – i o ile z dowożeniem celów biznesowych bywa różnie o tyle ze zgodnością z architekturą jest już kompletnie na bakier. Z wieloletnich moich obserwacji wynika wręcz, że ten twór nazywany „projektem IT” jest zwykle głównym źródłem problemów, z jakimi IT musi się borykać. Już na etapie konstrukcji projektu, kiedy do pracy zabierają się kierownicy projektów, cele zaczynają się odrywać od możliwości ich realizacji. Później, kiedy projekt jest już realizowany, objawiają się najbardziej wymyślne sposoby „załatwiania zależności” między projektami (czyt. dłubania przy dokładnie tym samym bez jakiejkolwiek współpracy merytorycznej). A najwięcej tego widać wtedy, kiedy projektu już nie ma i nie ma komu ponieść konsekwencji wytworzonych potworków. Co ciekawe, w wielu przypadkach scoringów projektów (każda organizacja wszak ocenia jakoś podejmowane inicjatywy) kategoria zgodności z architekturą występuje, tylko jakoś później, kiedy już trafia w ręce jakiegoś zarządzającego, wszystko się rozjeżdża…

Rzecz jest bowiem w autonomii decyzji podejmowanych w ramach projektu, a typową sytuacją jest to, że – w imię budżetu, deadline’u i najwyższej jakości – projekty mają uprawnienia do zmiany sposobu realizacji swoich celów. Tylko, że te wyniki projektów później stają się rzeczywistą architekturą przedsiębiorstwa, taką ujawniającą się z gąszcza projektów i ich nieuzasadnionej autonomii decyzyjnej. W istocie projekty nie są zgodne z architekturą lecz ją kreują, ale niewiele organizacji ma na tyle odwagi, żeby na szczycie projektu, na równi z Największym Kierownikiem Projektu, postawić architekta. W konsekwencji, bez względu na zakres i zasięg wysiłków architektonicznych poza projektem, każdy projekt spie…li sprawę po swojemu. Jeśli do tego dołożymy prosty fakt arbitralnego określania obszaru działania projektu (wszak projekt musi dotknąć tego wszystkiego, czego dotyczą rozbuchane cele, nie patrząc na to, jak ryzykowne jest grzebanie w tym wszystkim), rozumiemy, że powszechnie stosowana praktyka projektowa jest źródłem największych problemów każdej firmy.

Projekty IT są systemowo złe, filozofia ich konstrukcji i nadzoru jest u samych podstaw błędna. Wiara w to, że cokolwiek sensownego można zrobić patrząc na przedmiot działania z jednej tylko perspektywy (projektu) jest tragicznie naiwna. Projekt IT ma zawsze dwie płaszczyzny: chciejstwa i móctwa. Ta pierwsza określa cele i ograniczenia, i odpowiada tradycyjnej perspektywie projektu. Ta druga określa przedmiot działania i powiązania w materii działania projektu, i odpowiada właśnie perspektywie architektury. Nie ma innej możliwości określania i realizowania projektów IT, niż na każdym etapie wymaganie pójścia do porozumienia tych dwóch perspektyw – czasami to będzie konsensus, częściej kompromis, ale nigdy nie wymuszenie. Zakres projektu IT z taką samą siłą zależy od celów biznesowych jak i od architektury. Granice zmagań projektu muszą uwzględniać tak samo szanse i czynniki ryzyka biznesowego, jak uwarunkowania i potencjał, warianty czy wartość opcjonalną architektury. Bez tego definiowanie projektu jest myśleniem życzeniowym. I nie chodzi o to, że architekt dostaje do obrobienia „coś” z już potwierdzonym budżetem i harmonogramem, choć widzi to pierwszy raz. Chodzi o to, że bez tego definiowanie projektów jest po prostu okłamywaniem siebie i zarządów firm.

IT Justification – Evil TCO

Gdziekolwiek nie przyłożyć ucha, wszędzie słychać okrzyki, że zwinność, że platform economy, że elastyczność, że gotowość do przyszłych zmian – że to wszystko musi być podstawą dla myślenia i działania w informatyce. Intuicyjnie każdy mam nadzieję rozumie, że zwinność, platforma, elastyczność, gotowość do zmian wymagają budowania w odpowiedniej strukturze, która „wymusi” te właśnie cechy. Architektura w sferze IT właśnie temu służy – nakładaniu adekwatnej struktury na  budowanie rozwiązań. Budowanie „na tu i teraz” z pogwałceniem tej struktury stopniowo ogranicza te wszystkie ważne „elementy strategiczne”. Każdy także chyba rozumie, że to wszystko oznacza inwestycję. Tym niemniej, w kwestii twardej oceny wartości biznesowej, dostrzegany jest tylko koszt i optymalizacja realizacji bieżących wymagań. What you pay for is what you get i nie ma to nic wspólnego z materią informatyki lecz w całości wynika ze słabości praktyk zarządzania IT.

Mimo zmiany roli IT w sferze wyznaczania biznesowej wartości działań IT nadal obowiązuje TCO. Strategiczna i taktyczna wartość informatyki musi opierać się na trwałej zdolności dostarczaniu nowych możliwości, a nie na „innowacyjności” w sklejaniu na kolanie posiadanych kawałków dla realizacji potrzeb na tu i teraz – każde takie „posklejanie” dodatkowo ogranicza możliwość analogicznego „posklejania” w przyszłości, co jest działaniem absolutnie przeciwnym do koniecznego. W tym znaczeniu operacyjna wartość informatyki musi być bezwzględnie podporządkowana celom taktycznym i strategicznym. Jeśli jednak tak ma być, nie możemy ograniczyć mechanizmów wyceny tej wartości do tak prymitywnych modeli, jak TCO.

Na szczęście wszystko jest pod ręką, a rynki finansowe już dawno odnalazły się w tych nowych, znacznie bardziej złożonych warunkach. Wartość strategiczną, potencjalne przyszłe możliwości, różnorodność scenariuszy można wyrazić w kategoriach ekonomicznych, na dobry początek polecam zapoznanie się z metodami wyceny Real Options Valuation. Trudniejsze? Bez wątpienia tak, ale choć trochę bardziej przystające do realiów rzetelnej wyceny wartości informatyki i jej przedsięwzięć. W sumie chyba chodzi o podejmowanie decyzji trudnych acz prawdziwych, a nie łatwych acz zbędnych.

To jak trzeba tę architekturę robić? Trzeba skupiać się na zrozumieniu tego, na czym stoimy (punktu odbicia) i patrzeć znacznie szerzej, niż artykułowane wymagania (nie zamykać możliwości). Trzeba umożliwiać odwlekanie decyzji i ubezpieczać się otwieraniem możliwości w przyszłości. Eksperymentów albo nie ma w ogóle, albo zawsze musi być gotowość do skorygowania (pod groźbą bezdyskusyjnego wyrzucenia), bo nie ma co udawać, że do czegokolwiek „wrócimy, żeby poprawić”. Jeśli ktoś wierzy, że może działać sensownie bez „robienia architektury”, to owszem, cynicznie rzecz ujmując, można, zawsze było i będzie można. W taki sam sposób można pozwolić na rozrastanie się miast, w których nikt niczego nie planuje – tak powstają co najwyżej slumsy. Jeszcze dekadę temu można było tak działać, a konsekwencje „odczuwali następcy”. Współczesność pokazuje, że karma wraca znacznie szybciej, niż można się tego spodziewać, a jej mnożnik jest tak duży, że „może zabić”. Moje doświadczenia mówią jednak jasno, że w coraz mniejszym stopniu praktyki menedżerskie do tego przystają. Pokutuje przekonanie, że IT musi tyle kosztować, … bo musi. Niewiele widzę pokory kwestionującej przestarzałe praktyki zarządzania. Im dłużej w tym fachu, tym większe przekonanie, że każdy skuteczny architekt będzie miał za przyjaciela Miguela de Cervantesa. Ale, czyż nie warto mieć takich przyjaciół?

Pozostaw komentarz