Wśród elementów, które decydują o przetrwaniu kryzysu, a których nie widać na diagramach architektury, dwa pierwsze idą w parze: realna kontrola nad środowiskiem i wiedza o zależnościach systemów. Piszemy o nich razem, bo jedna bez drugiej pozostaje niepełna. Kontrola bez wiedzy o zależnościach jest ślepa. Wiedza bez kontroli jest bezradna.

Zacznijmy od kontroli. Formalnie deklaruje ją każda organizacja: są właściciele systemów, są uprawnienia, są dokumenty. Realna kontrola oznacza coś więcej. Firma rzeczywiście panuje nad tym, co działa w jej środowisku, kto ma do niego dostęp i co się w nim zmienia. Między deklaracją a rzeczywistością bywa przepaść, która w spokojnych czasach nikomu nie przeszkadza.

Tę przepaść mierzy się prostymi pytaniami. Kto ma dziś dostęp do środowiska, łącznie z dostawcami i podmiotami zewnętrznymi? Co w nim działa, również z elementów uruchomionych dawno temu i przez nikogo nieopisanych? Kto wie o ostatnich zmianach i kto je zatwierdził? Organizacja z realną kontrolą odpowiada od ręki i z pewnością. Organizacja z kontrolą formalną obiecuje, że sprawdzi. W kryzysie ta różnica przekłada się wprost na czas reakcji.

Drugim elementem jest wiedza o zależnościach systemów. Środowisko IT to nie lista elementów, tylko sieć powiązań. Proces sprzedaży zależy od aplikacji, aplikacja od bazy, baza od infrastruktury, a spora część tych ogniw od zewnętrznych dostawców. Diagram pokazuje klocki. Zależności pokazują, jak te klocki trzymają się nawzajem i co pociągną za sobą, upadając.

W kryzysie to właśnie nieznane zależności kosztują najwięcej. Każdą odkrywa się w najgorszym momencie, czyli wtedy, gdy przestaje działać. Zamiast odtwarzać środowisko według znanej kolejności, zespół prowadzi śledztwo: dlaczego system, który powinien już działać, nadal nie działa i czego jeszcze mu brakuje. Pisaliśmy o tym w tekście dotyczącym pytania zarządu o największy pojedynczy punkt awarii. Bez mapy zależności nikt w firmie nie potrafi na to pytanie uczciwie odpowiedzieć.

Obie zdolności buduje się podobnie i bez spektakularnych inwestycji. Punktem wyjścia jest spis stanu faktycznego: kto ma dostępy, co działa, co od czego zależy i które procesy biznesowe wiszą na których elementach. Ważne, żeby mapa powstawała od strony procesów, a nie od strony sprzętu. Zarząd nie musi wiedzieć, jak nazywa się serwer. Musi wiedzieć, co zatrzyma sprzedaż. Dobrym rytmem startowym jest jedna mapa dla jednego, najważniejszego procesu. Reszta może dochodzić stopniowo.

Taka mapa ma jedną niewygodną cechę: starzeje się. Środowiska zmieniają się szybciej niż dokumentacja, więc jednorazowa inwentaryzacja opisuje firmę sprzed roku. Realna kontrola to nie projekt, tylko nawyk. Przegląd dostępów, aktualizacja zależności i uzgadnianie zmian muszą mieć swój stały rytm.

Na koniec warto wrócić do punktu wyjścia. Ani kontroli, ani wiedzy o zależnościach nie widać na diagramie architektury i nie da się ich kupić razem ze sprzętem. To cicha, mało efektowna praca. Ale to od niej zależy, czy w kryzysie firma działa według mapy, czy prowadzi śledztwo we własnym środowisku.