RegułyChaosu

Elastyczność, to jedno z najczęściej spotykanych wymagań stawianych przed rozwiązaniami informatycznymi, wynikające z braku wiedzy o przyszłych potrzebach. Pomijając powody, dla których miejsce otwartej dyskusji o unknowns zajmuje amorficzne i efemeryczne wymaganie elastyczności, jakoś trzeba się z nim zmierzyć i pomóc – szczególnie tym wstydliwym lub zobowiązanym do „wszystkowiedzenia” – dać sobie z nim radę.

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?

Czytając wpisy z serii Hybrid Multicloud można byłoby dojść do wniosku, że za chwilę całe ogólnocywilizacyjne IT będzie w rękach i pod pełną kontrolą kilku firm. Czyżby świat IT uzyskał ostateczną postać poukładania, w której wszystko jest już jasne i wszystko wreszcie wiadomo?

Po wcześniejszych wpisach, szczególnie dotyczących bezpieczeństwa w chmurze, prowadziłem kilka interesujących dyskusji na temat docelowej (o ile coś takiego istnieje) wizji chmury. Choć znacząca część tej dyskusji toczyła się wokół tematów uzależnienia od dostawcy, podniesionej czujności w kontroli kosztów i bezpieczeństwa wartości firmy (danych), skupię się na innym, ciekawym aspekcie typowego środowiska działania informatyki firmy.

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.