RegułyChaosu

Co pewien czas nachodzi mnie defetystyczny nastrój. Przyglądam się zmaganiom inżynierów informatyki z materią ich działań i odnoszę wrażenie, że klęska jest nieuchronna. Chwilę później zwykle wpadam na pomysł, jak sobie poradzić z takim, czy innym problemem, więc nastrój mi przechodzi – pozostają doświadczenia. Ostatnio rzecz dotyczyła spojrzenia na środowisko informatyczne od strony sprawności i skuteczności komunikacji pomiędzy systemami informatycznymi w środowisku typowym dla współczesnych firm.

Od ponad dwóch dekad rozwiązuję zagadki ze świata informatyki praktycznej, sfery nazywanej w literaturze “Enterprise Information Systems”, posługując się warsztatem i narzędziami architekta. Wraz ze wzrostem doświadczenia rośnie we mnie przekonanie, że najważniejszą klasą narzędzi architekta są wzorce architektury, wszak po co za każdym razem na nowo wymyślać koło, skoro już wiemy, jak ma wyglądać? Z drugiej strony jednak stosowanie wzorców staje się coraz trudniejsze, wymaga coraz większego wysiłku, napotyka na coraz więcej przeszkód. Coś jest nie tak ze wzorcami? Problemy są tak specyficzne dla każdego przypadku? Myślę, że nie, a prawdziwa zagadka jest w nieco innym miejscu.

Wiele lat temu, kiedy miałem rozpocząć studia, uczestniczyłem w wykładzie inauguracyjnym w temacie paradoksów rozwoju technologii, szczególnie ujawniających się cyklicznością zachodzących zmian. Wykładowca utrzymywał, że proces rozwoju technologii nie jest procesem liniowym – meandruje, gdyż ludzie budują zrozumienie metodą prób i błędów. Wykładowca twierdził, że – jako ludzie – jesteśmy całkiem nieźli w próbkowaniu, jednak umyka nam systematycznie zrozumienie cechy tego procesu, która czyni go wrażliwym.

W ramach moich poszukiwań sfer stosowania technologii teleinformatycznych „przez chwilę” udzielałem się w środowisku Smart City. Dzieje się tam wiele bardzo, ale to bardzo ciekawych rzeczy. Jest to jednak obszar działań, który przeżywa „najazd” technologii.

Gdyby Straton z Sardes żył współcześnie, nie zaś prawe dwa tysiące lat temu, mógłby zmienić swój epigram. Rzecz o RPA (ang. Robotic Process Automation), najnowszym trzyliterowym skrócie, którym – jak chyba każdym nowym, trzyliterowym skrótem – zachwyca się część branży „informatycznej”, zachwytem napędzanym budżetami marketingowymi uznanych dostawców technologii. Fajna, nośna koncepcja, tylko to wykonanie…

W ramach marketingu terminu „cyfrowa transformacja” pierwsze skrzypce grają firmy technologiczne, opowiadając jak to wiele można zrobić takim, czy innym narzędziem. Zupełnie nie o narzędzia to chodzi. Bez wątpienia, w Digital Transformation jest dużo Digital, ale – nawet jeśli potężne – Digital to tylko narzędzie, a nie cel.

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.

Podstawą Agile Architecture jest zdolność do użycia rozwiązania lub komponentu na nowe sposoby, nie przewidziane podczas projektowania takiego rozwiązania czy komponentu. Brzmi prawie jak herezja inżynierska – wszak informatyka to nie magiczna różdżka zmieniająca coś bez zmieniania. Jak więc uzyskać zdolność dopasowania rozwiązań informatycznych? Jak sprawić, aby architektura była naprawdę zwinna?