RegułyChaosu

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.

Termin zwinności (agile, agility) robi karierę. Zachwycamy się podejściem zwinnym, w coraz to nowych obszarach. Wręcz zaczynamy to traktować jak nowe lekarstwo na „całe zło”. Jestem absolutnym fanem włączania cech zwinności w każdy z obszarów moich zawodowych zainteresowań. Agile jednak ponosi klęskę za klęską i wcale nie wynika to z tych cech, lecz z praktyki ich wykorzystania. No więc jak to jest w praktyce?

W kilku ostatnich projektach – w firmie z branży bankowości, branży bardzo świadomej zagadnień bezpieczeństwa – w których całość rozwiązania działała w oparciu o chmurę, miałem przyjemność pełnić rolę doradcy w zakresie architektury bezpieczeństwa. W tych projektach powtarzała się ewolucja myślenia o bezpieczeństwie w kontekście rozwiązań chmurowych – od robienia tradycyjnie (rozwiązania on-premises) do nowocześnie (chmura). Może być ciekawie?

Motywem, jaki często przewija się w dyskusjach o przyszłości IT jest temat wzrastającej trudności realizacji zadań inżynierii systemowej. Z jednej strony bowiem coraz trudniej o doświadczonych inżynierów. Z drugiej strony rosnąca złożoność, wielość możliwości i zależności między nimi stanowi coraz większy koszt realizacji rozwoju IT. A pomyłka w tej sferze potrafi się latami odbijać czkawką. Najczęstszą konkluzją z takich dyskusji jest „przejdźmy do chmury”, tylko co zrobić z dotychczasowym bagażem?

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.