sobota, 4 marca 2017

Kryzys tożsamości



“There are three forms of visual art: painting is art to look at, sculpture is art you can walk around, and architecture is art you can walk through.” (Dan Rice).
Pewne kontrowersje wzbudza tekścik umieszczony na niniejszej stronie, po prawej stronie mojego wizerunku: „Analityk architektoniczny alias architekt analityczny”. Podobno nie ma takiej profesji. Czyżby? Pierwotnie miał to być tylko żart, ale po chwili zastanowienia doszedłem do wniosku, że w tej frazie może kryć się jakiś sens.Czy analityk architektoniczny analizuje architektury? Czy architekt analityczny projektuje (sic!) architektury analitycznie ? Może robi i jedno i drugie? Jak się to ma do roli tzw. architekta rozwiązań?

Zacznijmy od podstawowego dla tego postu pojęcia. Co to jest "architektura"? 


Na potrzeby niniejszego postu przyjmijmy najbardziej, na ile to możliwe, generyczną definicję architektury, która, mam nadzieję, wzbudzi znikome kontrowersje:

Architektura to uświadomione (czasami utrwalone) wyobrażenie zbioru powiązanych elementów, relacji zachodzących miedzy nimi oraz oddziaływań występujących w obrębie i w otoczeniu tegoż zbioru. Struktura to opis elementów i powiązań. Zachowanie to opis oddziaływań.
W myśl powyższej definicji można przyjąć, iż każdy byt - i duży, i mały - ma swą architekturę (nawet jeśli o tym nie wie), bo to kwestia sposobu postrzegania i rozumienia tego, co się postrzega.

Proszę zauważyć , że nie ma sensu rozpatrywanie Zachowania w oderwaniu od Struktury – zachowuje się zawsze "coś, jakaś Struktura, przynajmniej w analizie biznesowo-systemowej. Odwrotne stwierdzenie nie zawsze jest prawdziwe. Istnieją struktury tzw. elementów pasywnych, które żadnego Zachowania nie przejawiają, na przykład informacja (dane), bo same są tylko przedmiotem oddziaływania. Puryści twierdzą jednak, że informacja może i nie, ale jej nośniki już tak, a skoro informacja by „być”, musi zostać utrwalona i przekazywana via jakiś nośnik z określonym mechanizmem dostępu do zawartości (patrz np. wzorzec DAO i operacje CRUD), to i ona również jest elementem aktywnym. Można i tak.


Problem polega na tym, że wielu nie dostrzega istoty związku Struktury i Zachowania. Często w swych rozważaniach albo ograniczając się tylko do analizy/syntezy Struktury, albo odwrotnie, rozważają Zachowanie poza jego strukturalnym kontekstem.
Czyż nie spotkaliście się z sytuacją, kiedy to panaceum na kłopoty miała być tzw. zmiana struktury organizacyjnej, szumnie zwana „reorganizacją”? Czy potem coś się zdarzyło tak samo z siebie? Czy próbowaliście zmienić zachowanie organizacji bez zmiany jej struktury? Z jakim skutkiem?

Dlaczego myślenie "architektoniczne" ma sens i daje korzyści? Dostrzegając i budując architektury, za jednym zamachem widzimy wszystkie elementy we wzajemnym powiązaniu oraz rozumiemy "jak to działa", czyli lepiej rozumiemy związki przyczynowo-skutkowe pomiędzy zmianą Struktury a zmianą Zachowania, a w analizie biznesowo-systemowej o Zmianę właśnie chodzi.

Jak w dowcipie o naukowcach badających pchły. Grupa entomologów badała anatomię i fizjologię pcheł. W ramach krwawego i potępienia godnego eksperymentu, wyrywała pchle kolejną nóżkę, zadawała komendę "hop" i obserwowała reakcję. Pchła karnie wykonywała skok. Po wyrwaniu ostatniej nóżki stwierdzono, że pchła straciła słuch.

W pierwszym odruchu przedstawicielom naszej profesji (analitykom) termin „architektura” kojarzy się z architekturą - biznesową, aplikacyjną lub technologiczną - jakiejś „dużej" całości, np. przedsiębiorstwa, instytucji lub systemu IT. Utrwaliło się więc przekonanie, że musi być „duża” i "skomplikowana" (cokolwiek to znaczy), adekwatnie do skali rozpatrywanego obiektu. Nawet gdy rozpatrujemy coś "małego", które jest częścią "dużego", konsekwentnie uważamy, że architektura "małego" jest częścią, wycinkiem tej "dużej" i "skomplikowanej" architektury "dużego", gdyż uważamy, że by zrozumieć "małe", najpierw musimy wyobrazić sobie "duże". "Duże" determinuje nasze wyobrażenie o "małym".

Takie rozumowanie, w pewnych okolicznościach jak najbardziej uprawnione, skutecznie zniechęca do myślenia architektonicznego i tworzenia architektur, jako czynności może i chwalebnej, ale żmudnej i długotrwałej - bo dotyczy "dużych" obiektów - na korzyści z której to przychodzi oczekiwać wiele miesięcy, a bywa, że i lat. Niestety potwierdza to praktyka i doświadczenia wyniesione z projektów budowy tzw. Enterprise Architecture. Wielu uważa, że koncept EA nie spełnił pokładanych w nim nadziei, gdyż na efekty jego wdrożenia trzeba czekać zbyt długo. Temat do dyskusji.

Gdyby tak spojrzeć na "małe", które jest częścią "dużego", jak na coś "oddzielnego", które znajduje się W ŚRODOWISKU tego "dużego". Czy wtedy architektura "małego" mogłaby być adekwatnie "mała" i "prosta" - i nie tak przerażająca.


Jak traktować obiekty o budowie fraktalnej? Mają "dużą" czy "małą" architekturę? "Prostą" czy "skomplikowaną"?
Mówiąc krótko, załóżmy, że podsystem ma swą własną, postrzeganą autonomicznie architekturę, która nie musi być traktowana jako wycinek architektury nadsystemu.

Drugą skrajnością jest kojarzenie terminu "architektura" z czymś w skali micro - z „architekturą oprogramowania”, niekiedy mylnie utożsamianą z architekturą kodu oprogramowania i wzorcami projektowymi np.GoF. 

Pomiędzy tymi skrajnościami można natknąć się na dziesiątki definicji „pośrednich”.

W praktyce nie zawsze chodzi o budowę Architektury Wszystkiego. Chodzi również o dostrzeganie architekturek rzeczy malutkich, nawet tak małych jak nanoroboty albo np. paramecium caudatum (pantofelek).

Paramecium caudatum i jej "architekturka"

Wróćmy jednak do „analizy architektonicznej alias architektury analitycznej”.

Pytanie: co robi analityk (ok, analizuje i, wbrew pozorom, czasem syntetyzuje – to już wiemy, ale nie o to teraz chodzi)?
Odpowiedź: diagnozuje Problem poszukując rzeczywistej jego Przyczyny, by następnie opracować Rozwiązanie i Metodę jego wdrożenia. Proste. Zobaczmy to na diagramie.

(Uwaga #1. Bystry czytelnik zauważy, że proponowany proces wykazuje wiele podobieństw do znanych z literatury przedmiotu podejść. Nie powinno to dziwić - jest tak generyczny, że drogą jego rozbudowy i "doprecyzowania" łatwo można uzyskać całą rodzinę praktykowanych metodyk.

Uwaga #2. Niech nie zmyli Was linearny charakter diagramu. To nie jest waterfall, wręcz przeciwnie, jest to mocno "pokręcony" proces, choć prosty w swej logice.)





Ok. Chyba nie aż tak prosty, ale spoko, po kolei, od lewego do prawego.

Biznes zgłasza Problem.
Właśnie w tym momencie mamy do czynienia z pierwszym nieporozumieniem: najczęściej zgłasza nie Problem lecz jego znamiona - pewne efekty negatywne lub braki pozytywnych, przyczyny których jeszcze pozostają nieznane. Rusza śledztwo.


Rozpoznanie Architektury Problemu.

Stosując różne przemyślne techniki (np. RCA, Thinking Process, ale nie tylko) analityk dochodzi do właściwych przyczyn zaobserwowanych przez biznes zjawisk, a dokładnie, identyfikuje wszystkie elementy, które są i/lub mogą być ich bezpośrednim i/lub pośrednim źródłem. „Winnych” należy poszukiwać zarówno w sferze biznesowo-organizacyjnej (ludzie, reguły, procesy, strategie, taktyki, kompetencje, zasoby i inne), jak i technologicznej (algorytmy, dane, software, hardware itp.) „Podejrzane elementy” mogą działać pojedynczo lub w zorganizowanej grupie (oby nie przestępczej). Bywa, że solo są niegroźne, a ich destruktywny charakter przejawia się dopiero w towarzystwie innych.

Zidentyfikowane elementy oraz relacje między nimi to Struktura Przyczyny, czyli to, co powoduje Problem, i zmiana czego daje nadzieję na uzdrowienie sytuacji.

Ująwszy sprawców na gorącym uczynku, można przystąpić do poznania ich modus operandi , czyli do rozpoznania mechanizmu powstawania złych i niepożądanych objawów, złego Zachowania (się) Przyczyny.

Tym sposobem zbudowaliśmy pierwszą architekturę: Architekturę Problemu obejmującą Strukturę i Zachowanie Przyczyn Problemu. Uwaga. Nie należy jej utożsamiać z architekturą tzw. domeny biznesowej. Przyczyna może być tworem wykraczającym poza domenę biznesową.

Komunikacja Architektury Problemu.
Zanim przystąpimy do poszukiwania Rozwiązania, analityk powinien potwierdzić trafność swych dociekań i przekonać poszkodowanych (biznes) do stawianych „podejrzanym” zarzutów, co bywa sporym wyzwaniem, gdyż w trakcie analizy Przyczyn można natrafić na „pikantne” szczegóły lub skrzętnie ukrywane „trupy w szafie” organizacji. Zalecam daleko posunięty takt i wejście na wyżyny swych dyplomatycznych umiejętności. Należy liczyć się z sytuacją, że w świetle nowo ujawnionych okoliczności nastąpi nowa kwalifikacja objawów i analizę trzeba będzie powtórzyć lub dać biznesowi szansę zapomnieć o sprawie. Na szczęście i na tę okoliczność są wypróbowane techniki perswazyjne. Ja stosuję najprostszą – metodę pokonywania tzw. progów oporu. Praktyczna rada: nie próbujcie komunikacji oprzeć tylko na prezentacji diagramów UML, BPM czy ArchiMate. W większości przypadków na tym etapie to już nie działa (w procesie modelowania architektur – jak najbardziej). Dyskusja na temat formy może zdominować analizę treści. Setstronicowe opasłe epopeje również mogą wzbudzić niechęć. Choć uwielbiam różnej maści zaawansowane modele i diagramy (i automatycznie generowane z nich pedeefy), na tym etapie najczęściej sięgam po stary, dobry PP lub podobne. Biznes kocha „proste, szczere żołnierskie słowa” i na temat.

Opracowanie Architektury Rozwiązania.
Kiedy już pokonamy wszystkie progi oporu i osiągniemy jednomyślność z chlebodawcą (oby żył wiecznie) co do istoty Problemu, możemy przystąpić do syntezy, czyli opracowania Architektury Rozwiązania. Jest to proces równie iteracyjny co bolesny, gdyż mało prawdopodobnym jest, byśmy znaleźli je od razu i to optymalne. Po każdej iteracji należy sprawdzić, czy Rozwiązanie działa, czyli rozwiązuje jakiś problem (najlepiej niech to będzie „ten” Problem) oraz, czy jest realizowalne w naszej biznesowej rzeczywistości. Warto przy okazji zbudować parę prototypów i przeprowadzić proof of concept przed prezentacją konceptu ostatecznego.


Komunikacja Architektury Rozwiązania.
Kolejny raz stajemy wobec dylematu, jak przekonać biznes do naszego pomysłu. Tu już potrzebna jest niezachwiana wiara we własne siły, czasami tupet na pograniczu arogancji. Nie zawadzi mieć jakieś analizy, które „czarno na białym” wykażą oczywistą oczywistość Rozwiązania. Bądźmy przygotowani na powtórzenie tego etapu, gdy Rozwiązanie nie wzbudzi dostatecznego entuzjazmu u sponsora.


Analiza wpływu.
Nie ma nic za darmo. Dobre Rozwiązanie może być złego początkiem. Zawsze, poprawa w jednym miejscu burzy coś w innym. To jest fundamentalne prawo Natury:
„Jeśli wiesz, że coś może pójść źle i podejmiesz stosowne środki zapobiegawcze, to źle pójdzie coś innego.” (Murphy)

Nie dość, że próba naprawy w jednym miejscu rodzi konsekwencje w innym, to próba kompensaty tych konsekwencji rodzi kolejne skutki uboczne, których kompensata rodzi kolejne skutki ….Przy odrobinie szczęścia możemy dojść do ogólnie akceptowanego kompromisu i coś ustalić. Tak powstaje Architektura Docelowa rozważanej rzeczywistości, choć nie idealna, ale możliwa do implementacji, która ma coraz mniej wspólnego z pierwotną Architekturą Rozwiązania.



Komunikacja Architektury Docelowej.
Wchodzimy w krytyczny punkt procesu. Teraz warto się pomodlić, bo gdy biznes zorientuje się, jaki jest potencjalny zakres ingerencji w dotychczasowy stan, może podziękować nam za współpracę. Lepiej na spotkanie od razu przyjść spakowanym do odlotu. Jeśli będziemy dostatecznie konsekwentni (czytaj zdesperowani) i przekonywujący, jest nadzieja, że albo skutecznie zniechęcimy biznes do jakichkolwiek zmian, albo dostaniemy zielone światło z pełną świadomością skali przedsięwzięcia i ryzyk. Niestety, inaczej się nie da, trzeba iść na całość - albo rozwiązujemy Problem w całej jego krasie, albo lepiej nie otwierać tej puszki Pandory i kolejny raz dać biznesowi szanse z honorem wycofać się z pomysłu. Tak uratujemy nasze to, gdzie kończą się plecy.

Planowanie Zmiany.
Skoro już wiemy, jaki jest rzeczywisty zakres ingerencji w bieżący stan w związku z próbą rozwiązania Problemu, dobrze jest pomyśleć o sposobie jej przeprowadzenia, czyli zaplanować zakres koniecznych do wykonania prac, ich kolejność i terminy , oszacować pracochłonność i opracować plan alokacji wymaganych zasobów. Tworzymy tym sposobem ostatnią z architektur – Architekturę Zmiany, która nie dotyczy samego przedmiotu transformacji, ale procesu Zmiany. AZ odpowiada na klasyczne 3 pytania: (1) co zmienić, (2) na co zmienić i (3) jak tego dokonać, oraz kolejny raz dlaczego tak drogo i dlaczego tak długo (plan utylizacji zasobów i harmonogram).

Decyzja "co dalej".
Przyszedł Wielki Moment na Wielką Decyzję: „to change, or not to change?”. Jest to rzeczywiście trudny dylemat, ale na tym etapie na szczęście już nie nasz. Można decydentowi dodać nieco otuchy słowami wielkiego męża stanu, Sir Winstona:


“To improve is to change, to be perfect is to change often.” (W.S.Churchill)

Zawsze działa. Każdy chce być perfect.


Na tym analityk kończy swe dzieło ( i spokojnie zaczyna podążać w kierunku kasy), bo za skutki tego bałaganu odpowiada już kto inny.


Pozostaje jednak pewne uczucie niedosytu. O czymś zapomnieliśmy.
Gdzie są WYMAGANIA !?!?!?

Wasz,

M.

P.S.

Dla miłośników BPMN dołączam diagram równoważny (prawie) zamieszczonemu wyżej. Można go poddać symulacji i zobaczyć, czy i jak działa. U mnie (w mojej aplikacji) działa, jak mawia każdy deweloper.




Diagramy zamieszczone w niniejszym tekście zostały wykonane przy użyciu notacji ArchiMate® i BPMN®. ArchiMate® jest znakiem zastrzeżonym The Open Group. BPMN® jest znakiem zastrzeżonym Open Management Group.