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.

Rolę, jaką w wymiarze długoterminowym pełnią strategia i architektura, w wymiarze operacyjnym realizują przywództwo i zarządzanie. Pracujemy w realiach kultu menedżerów, organizacji zrzeszających C-level. W warunkach codzienności merytoryczna strona podejmowanych wyzwań, zawsze jest „schowana” gdzieś za strukturami projektowymi lub hierarchicznymi, podporządkowana im. Dla części organizacji taka sytuacja staje się wręcz osią konfliktu wszędzie tam, gdzie – choćby ze względu na złożoność wyzwań – prawdziwa decyzyjność i sprawczość muszą być rozszerzone, włączając do procesów decyzyjnych silną reprezentację merytoryki.

Pracując z różnymi firmami mam okazje obserwować ich działania z różnych perspektyw. Daje to często możliwość porównania sposobu ich działania. Ostatnie okoliczności u jednego z moich klientów zainicjowały porównanie z innym moim klientem, z nieodległej przeszłości. Firmy z zupełnie różnych branży, podobne jednak w charakterze wsparcia technologicznego (automatyka przemysłowa, IT, sieć), a jednak realizujące odmienne podejście do zagadnienia „robić właściwie rzeczy właściwe”.

Naruszenia bezpieczeństwa dotyczą najczęściej nie tych, którzy są uzbrojeni po zęby lecz tych, którzy są bezbronni – często na własne życzenie. Pracując w projektach IT obserwuję często „drogi na skróty”, także w sferze bezpieczeństwa. Najczęstsze samousprawiedliwienie – „ten projekt ma zrobić <to, czy tamto>, a nie naprawiać cały świat w zakresie bezpieczeństwa” – działa doskonale. Wszak, skoro nikt wcześniej nie zrobił tego „zgodnie i od początku do końca”, to „ja też nic nie muszę z tym zrobić”. W efekcie każdy projekt pogarsza sytuację, choć wystarczyłoby zachować minimalną higienę działania. I to naprawdę kosztem niewielkiego wysiłku.

Do tego, że składową przekazu dotyczącego Cloud Computing  jest marketingowo wzmacniany hype nie trzeba chyba przekonywać. O krytycznym spojrzeniu na skalę hype w komunikacji zagadnień chmurowych, na przykład w odniesieniu do uzasadnień finansowych usług chmurowych, napisano już wiele. Rzecz jasna, nie tak wiele, jak marketingu w tej sprawie. Dodałem także kilka groszy od siebie do tej publicznie prowadzonej dyskusji. Jednym z warunków urzeczywistniania tak fantastycznych business case jest zdolność do prowadzenia skutecznych procesów zakupowych. Czy kontekst zakupów chmurowych coś tu namiesza?

O tym, że co innego kieruje architekturą systemu chmurowego już uprzejmie donosiłem. Siły ekonomiczne, choć najmocniej odczuwalne w praktyce działań z rozwiązaniami chmurowymi, nie są jednak jedynymi czynnikami wpływu. W kilku innych przypadkach trzeba się będzie najprawdopodobniej od nowa nauczyć obsługi codziennych zadań związanych z posiadaniem ICT.

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ń.