RegułyChaosu

Realia współczesnego „robienia biznesu” nie dają komfortu podejmowania decyzji posiadając wszystkie dane. Podejmując decyzje biznesowe menedżerowie kierują się heurystykami i wyczuciem. Coraz częściej bowiem nawet suboptymalna decyzja podjęta we właściwym tempie okazuje się lepsza, niż super optymalna decyzja podjęta „chwilkę później”. Wszak chodzi o to, żeby nie wypaść oraz żeby nie popełniać dużych błędów. A jak w tej sytuacji podejmowane są decyzje architektoniczne?

Kiedy słucham o złożoności budowy aplikacji działających w środowisku hybrydowym lub multi-cloud, odnoszę wrażenie, że aby cokolwiek zrobić w takim scenariuszy trzeba łączyć zdolność inżynieryjną Mr Spocka ze szczęściem Arsena Lupin. Większość takich opowieści wygląda jak film Alfreda Hitchcocka – zaczyna się od trzęsienia ziemi, a potem napięcie zaczyna narastać. Czy naprawdę tak musi być?

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.

Jak pisałem ostatnio, rozważając metody zarządzania procesowego trzeba stawiać na zdarzenia (w oparciu o architekturę EDA, Event-Driven Architecture) i regułową organizację działań (w oparciu o rozwiązania klasy BRM, Business Rules Management). Takie są bowiem na dziś uwarunkowania organizacji współczesnego biznesu. Na tym jednak nie kończą się możliwości oferowane przez koncepcję zdarzeń ani siła wyrazu zdarzeń.

W prostych skojarzeniach, zarządzanie procesowe = BPMS, wydawałoby się, temat znany i ograny. Wydawałoby się. Wpadłem ostatnio w środek dość już „nabrzmiałego wyzwaniami” projektu wyboru „platformy BPMS”. Projekt przeprowadził RFI, RFP i nadal nie było wiadomo, co wybrać. Pierwsza diagnoza polegała na tym, że pomylone zostały pakiety komercyjnych środowisk z BPMS w nazwie, z koncepcjami narzędzi zarządzania procesowego. To pomieszanie doprowadziło do serii nieporozumień, kilku awantur i braku decyzji. Ale udało się wyprostować, a przepis na to poniżej.

Skuteczne działanie musi cechować celowość. Sfera danych staje się coraz bardziej złożona, przez co zachowanie celowości i skuteczności w tych nowych warunkach staje się często poważnym wyzwaniem. Wszak operujemy na danych nie po to, żeby mieć raport. Zdecydowanie nie! Na danych operujemy po to, żeby rutynowo podejmować w codziennych działaniach operacyjnych trafniejsze decyzje i robić to szybciej. Wiedza i zrozumienie danych to krok do celu, a nie cel sam w sobie – tak samo, jak ze zrozumienia reguł rządzących giełdą nic nie wynika, a wynika dopiero z zastosowania tej wiedzy.

Rewolucja inteligencji obliczeniowej (Machine Learning, Deep Learning) trwa i w końcu zmieni wszystko. Zapewne potrwa to jeszcze kilka lat lub dekad, ale w końcu kod programu zostanie zastąpiony przez dane. Wartość z danych można jednak masowo wydobywać już teraz, bez uciekania się do tych najpotężniejszych narzędzi. Kluczowym terminem jest tu zwinność, której osiągnięcie zapewnia te możliwości. Wymaga to jednak wprowadzenia zmian w stanie posiadania i sposobie użytkowania parku maszynowego technologii informatycznych.

Zwinność (agile) i chudość (lean) to terminy, które na dobre już zintegrowały się z myśleniem o rozwoju systemów informatycznych. Wiemy już jak zwinnie realizować projekty informatyczne, a nawet z relatywnie dużym prawdopodobieństwem umiemy tę wiedzę wykorzystać w praktyce. Aplikujemy tę wiedzę jednak do sfery funkcjonalności rozwiązań informatycznych, nie zaś do sfery danych. Jak zbudować fundament dla zwinności w sferze danych? O tym właśnie poniżej.