RegułyChaosu

Odkąd Nicholas Carr opublikował “IT Doesn’t matter”, pomimo ówczesnego świętego oburzenia całej branży, rzeczywistość dowodzi po kawałeczku chyba każdą z jego tez. Wartość IT stopniowo przenosi się w kierunku od infrastruktury do aplikacji. Wieszczone przez Nicholasa „IT jak elektryczność” na dziś jest faktem dla infrastruktury sprzętowej, platformy operacyjnej i aplikacyjnej. Tę wizję wypełniły usługi chmurowe. Im bliżej aplikacji, tym sprawa jest mniej oczywista, ale dla większości „tego poniżej” sprawa jest raczej jednoznaczna.

Temat zarządzania procesowego jest częstym tematem moich architektonicznych poszukiwań. Stąd i częstość powrotów tego tematu w formule mojego bloga. W dzisiejszych warunkach zarządzanie operacyjne (nie mylić z obrazem analityka biznesowego i nadzorczym, szczegóły rozróżniające we wcześniejszym wpisie) na bazie procesu end-to-end stało się już zbyt kosztowne, a zarządzać operacyjnie trzeba. Nawet zakładając, że są jeszcze jakieś firmy, które twierdzą, że funkcjonują w oparciu o procesy end-to-end, to bez hipokryzji – powszechna sytuacja wygląda tak, że istnieje „dział od procesów” żyjący w innym świecie, niż operacyjnie działająca firma.

„Cloud, czy on-premises” wchodzi już na stałe do kanonu procesów decyzyjnych o sposobie realizacji przedsięwzięć informatycznych. Na szczęście mamy już za sobą czasy naiwnego rachunku kosztów i dysponujemy doświadczeniem pozwalającym na znacznie głębsze zrozumienie mechanizmów związanych z ekonomiką rozwiązań chmurowych i skutkujących racjonalizacją kosztów posiadania informatyki.

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.

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…

Pracuję ostatnio dla firmy, która nie tyle potrzebuje cyfrowej transformacji, co błaga o nią. Firmy, choć mają osobowość prawną, nie mają jednak prawa głosu w podejmowaniu decyzji o jej losach – robią to ludzie pracujący dla takie firmy. Przyglądałem się nieco mechanizmom gaszenia potrzeb firm.

No dobrze, może trochę przesadziłem z tym odkrywaniem. Ale tylko trochę. Prowadziłem niedawno kilka wystąpień o tematyce nawiązującej do zwinności w architekturze. Poza innymi ciekawymi dyskusjami często wracaliśmy także do zagadnień SOA. Kilka myśli cieszyło się szczególnym powodzeniem.