Twój system działa świetnie. Dopóki pracuje osoba, która wie, dlaczego.
Wyobraź sobie firmę, która ma system działający od siedmiu lat. Powstawał etapami. Najpierw zrobił go jeden software house. Potem część przejął freelancer. Później kolejny zespół dopisał moduł B2B. Następna agencja podłączyła CRM. Ktoś jeszcze zintegrował płatności.
System działa.
Firma zarabia dzięki niemu pieniądze.
Pracownicy korzystają z niego codziennie.
Klienci nawet nie wiedzą, ile procesów dzieje się w tle.
Tylko jest jeden problem.
Nikt już dokładnie nie wie, jak to wszystko działa.
Dokumentacja jest częściowo w Confluence. Coś zostało na Google Drive. Kilka informacji znajduje się w ticketach. Jedna integracja została opisana w mailu sprzed czterech lat.
A najważniejszą rzecz "chyba pamiętał Łukasz".
Tylko Łukasz odszedł trzy lata temu.
I przez trzy lata nic się nie działo.
Aż do pewnego wtorkowego poranka.
System działa. Czyli wszystko jest w porządku?
To jeden z najbardziej zdradliwych stanów, w jakich może znaleźć się firmowy system.
Działa.
Nie ma awarii.
Użytkownicy są zadowoleni.
Sprzedaż korzysta z aplikacji.
Zamówienia przechodzą.
Dane trafiają do CRM.
Raporty się generują.
Więc naturalna reakcja brzmi: Nie ruszajmy. Po co grzebać w czymś, co działa?
I rzeczywiście - nie ma powodu zmieniać działającego systemu tylko dlatego, że można.
Problem polega na tym, że system może być stabilny technicznie, a jednocześnie bardzo niestabilny organizacyjnie.
Może działać dzisiaj, ale nikt nie wie, co się stanie, gdy trzeba będzie zmienić serwer, dostawcę API, domenę, bibliotekę, sposób uwierzytelniania albo fragment procesu biznesowego.
Może być sprawny, ale zależny od jednej osoby.
Może być bezpieczny, ale nikt nie wiedzieć, gdzie znajdują się wszystkie klucze dostępowe.
Może być rozwijany, ale tylko przez człowieka, który zna historię wszystkich decyzji.
I właśnie tutaj pojawia się pojęcie bus factor.
Ile osób może zniknąć, zanim projekt zacznie mieć problem?
Bus factor to bardzo prosta, choć brutalna koncepcja.
Pytamy: Ile osób musi przestać być dostępnych, żeby projekt przestał być możliwy do sprawnego utrzymania?
Jeżeli odpowiedź brzmi: "Jedna", mamy problem.
Jeżeli odpowiedź brzmi: "Dwie, ale obie pracują w innej firmie", mamy jeszcze większy problem.
Nie chodzi oczywiście o dosłowne "zniknięcie" ludzi.
Programista może odejść z firmy.
Freelancer może zakończyć współpracę.
Software house może przestać obsługiwać klienta.
Administrator może zmienić pracę.
Osoba odpowiedzialna za konkretną integrację może przejść do innego działu.
Właściciel wiedzy może po prostu zachorować albo być przez kilka tygodni niedostępny.
Jeżeli wraz z nim znika możliwość zrozumienia systemu, firma nie ma problemu kadrowego.
Ma problem biznesowy.
Kod nie zawsze mówi, dlaczego coś działa
Można powiedzieć: "Przecież mamy kod źródłowy. W razie czego nowy programista sobie przeczyta."
Teoretycznie tak.
W praktyce kod odpowiada przede wszystkim na pytanie: jak system coś robi.
Nie zawsze odpowiada na pytanie: dlaczego robi to właśnie w ten sposób.
A to ogromna różnica.
W kodzie może znajdować się warunek: "Jeżeli klient ma określony typ konta, wykonaj operację X."
Nowy developer może go znaleźć.
Ale skąd ma wiedzieć, dlaczego?
Może to być wymóg biznesowy.
Może pozostałość po starej integracji.
Może zabezpieczenie przed błędem zewnętrznego API.
Może obejście problemu, który występował pięć lat temu.
Może rozwiązanie nietypowego przypadku jednego z największych klientów.
Może być tam z bardzo dobrego powodu.
Albo z żadnego.
Bez kontekstu trudno to ocenić.
Dlatego dokumentacja systemu nie powinna ograniczać się do instrukcji:
"kliknij tutaj, następnie tutaj".
Najcenniejsza dokumentacja często opisuje decyzje i zależności, a nie tylko obsługę funkcji.
Najbardziej niebezpieczna wiedza to ta, która istnieje tylko w czyjejś głowie
Firmy bardzo często mają dokumentację. Tylko że dokumentacja nie zawsze jest tym samym co wiedza.
Możemy mieć opis API - ale nie mieć informacji, dlaczego korzystamy akurat z tego API.
Możemy mieć instrukcję wdrożenia - ale nie mieć listy wszystkich miejsc, w których trzeba zmienić konfigurację.
Możemy mieć opis integracji - ale nie wiedzieć, co stanie się, gdy zewnętrzny dostawca zmieni sposób autoryzacji.
Możemy mieć listę serwerów - ale nie wiedzieć, który z nich jest krytyczny dla konkretnego procesu.
Możemy mieć dostęp do repozytorium - ale nie mieć dostępu do konta, na którym znajduje się produkcyjna infrastruktura.
To są właśnie te elementy, które potrafią zamienić pozornie prostą zmianę w kilkudniowe śledztwo.
Integracja, która działa od pięciu lat, nadal jest zależnością
Jeden z najczęściej ignorowanych obszarów to zewnętrzne usługi;
- Płatności.
- SMS.
- E-mail.
- CRM.
- ERP.
- Mapy.
- Systemy kurierskie.
- Platformy marketingowe.
- Systemy księgowe.
- Usługi chmurowe.
- Zewnętrzne API.
- Biblioteki open source.
Każda taka rzecz jest częścią większego ekosystemu.
Jeżeli system korzysta z dziesięciu zewnętrznych usług, nie mamy jednego systemu. Mamy system plus dziesięć zależności. I każda z nich może się zmienić.
Dostawca może zmienić API.
Może zakończyć usługę.
Może zmienić model cenowy.
Może wycofać starą wersję.
Może wprowadzić nowe wymagania bezpieczeństwa.
Może zostać przejęty przez inną firmę.
Dlatego coraz większą rolę odgrywa również wiedza o pochodzeniu komponentów i zależnościach oprogramowania. NIST wskazuje między innymi na znaczenie SBOM, czyli Software Bill of Materials - formalnego zestawienia komponentów użytych do zbudowania oprogramowania. Taki spis pomaga zrozumieć, z czego system się składa i szybciej ocenić wpływ podatności lub zmian w łańcuchu dostaw.
Dla biznesu można to sprowadzić do bardzo prostego pytania:
Czy wiesz, od czego zależy Twój system?
A teraz wyobraź sobie zmianę software house'u
To jeden z momentów, kiedy wszystkie braki wychodzą na światło dzienne.
Firma przez lata współpracowała z jednym wykonawcą. Nagle współpraca się kończy. Powodów może być wiele; Zmiana strategii. Zmiana budżetu. Przejęcie agencji. Problemy organizacyjne. Brak kompetencji do dalszego rozwoju. Albo po prostu firma chce pracować z innym partnerem.
Nowy software house pyta:
"Gdzie jest repozytorium?" - Jest.
"Gdzie jest infrastruktura?" - Jest.
"Jak wdrażamy produkcję?" - "Nie wiemy, robił to poprzedni zespół."
"Jak działa integracja z ERP?" - "Chyba przez ten serwer."
"Jakie mamy klucze API?" - "Powinny być w mailu."
"Które API są produkcyjne?" - "Nie wiemy."
"Które procesy są krytyczne?" - "Trzeba zapytać Łukasza."
Łukasz już tam nie pracuje...
I właśnie dlatego przeniesienie projektu nie jest tylko przeniesieniem kodu. Trzeba przenieść również wiedzę.
Dokumentacja to nie koszt. To polisa
W wielu firmach dokumentacja jest traktowana jako coś, co robi się "jak będzie czas".
Czyli zwykle nigdy.
Albo na końcu projektu.
Albo kiedy ktoś zapyta.
To błąd.
Dokumentacja jest jednym z mechanizmów ograniczających ryzyko operacyjne. Nie generuje bezpośrednio sprzedaży. Nie poprawia konwersji. Nie wygląda efektownie na prezentacji.
Ale w sytuacji kryzysowej może być różnicą między: "naprawimy to dzisiaj"
a: "najpierw musimy znaleźć człowieka, który pamięta, jak to działało".
W nowych wytycznych NIST dotyczących planów bezpieczeństwa, prywatności i zarządzania ryzykiem łańcucha dostaw oprogramowania dokumentowanie celu systemu, jego stanu, kontroli oraz odpowiedzialności i zachowania osób, które nim zarządzają, jest traktowane jako element uporządkowanego zarządzania systemem.
To bardzo dobrze pokazuje zmianę myślenia.
Dokumentacja nie jest wyłącznie narzędziem dla developera.
Jest elementem ciągłości działania organizacji.
Co powinno być udokumentowane?
Nie chodzi o stworzenie dokumentacji na 800 stron, której nikt nigdy nie otworzy.
Dobra dokumentacja powinna odpowiadać przede wszystkim na pytania, które pojawią się wtedy, gdy coś się zmieni albo przestanie działać.
- Kto jest właścicielem systemu?
- Gdzie znajduje się kod?
- Gdzie znajduje się produkcja?
- Jak wygląda proces wdrożenia?
- Jakie są środowiska?
- Jakie są krytyczne integracje?
- Z jakich zewnętrznych usług korzystamy?
- Kto jest ich dostawcą?
- Jakie mamy umowy i konta?
- Gdzie są klucze i dane dostępowe?
- Kto ma uprawnienia?
- Jak wygląda backup?
- Jak wygląda odtworzenie systemu?
- Jakie komponenty open source są wykorzystywane?
- Które biblioteki są przestarzałe?
- Jakie są najważniejsze decyzje architektoniczne?
- Które elementy są krytyczne dla biznesu?
- Co stanie się, jeśli konkretna usługa zewnętrzna przestanie działać?
To nie jest dokumentacja "dla programistów".
To jest mapa zależności biznesu od technologii.
"Działa, więc nie ruszajmy" może być strategią. Ale trzeba znać jej cenę
Nie każda firma potrzebuje przebudowy starego systemu.
Nie każdy legacy system jest zły.
Nie każdy stary kod trzeba przepisywać.
Wręcz przeciwnie - czasami stabilny, starszy system jest znacznie lepszym rozwiązaniem niż kosztowna migracja wykonywana bez konkretnego powodu.
Problemem nie jest wiek systemu.
Problemem jest brak wiedzy o jego stanie.
Jeżeli wiemy, jak system działa, jakie ma zależności, gdzie znajdują się ryzyka i kto potrafi go utrzymać, możemy świadomie zdecydować:
- zostawiamy,
- modernizujemy,
- przepisujemy fragment,
- migrujemy,
- albo niczego nie ruszamy.
Jeżeli tego nie wiemy, decyzja "nie ruszamy" nie jest strategią.
Jest zakładem.
Jak wygląda audyt odziedziczonego systemu?
Kiedy do software house'u trafia istniejący system, pierwszym krokiem nie powinno być: "Przepiszmy go." - Najpierw trzeba go zrozumieć.
Dobry audyt powinien objąć między innymi architekturę aplikacji, kod źródłowy, bazę danych, infrastrukturę, proces wdrożenia, zależności, integracje, bezpieczeństwo, dostęp do usług i dokumentację.
Ale równie ważne jest zrozumienie biznesu;
- Które procesy są krytyczne?
- Które funkcje są używane codziennie?
- Które moduły odpowiadają za przychód?
- Które elementy mogą zostać wyłączone bez konsekwencji?
- Co dzieje się, gdy konkretna integracja przestanie działać?
- Które elementy są najbardziej ryzykowne?
Dopiero po połączeniu perspektywy technicznej i biznesowej można powiedzieć, co naprawdę wymaga zmiany.
Audyt nie musi kończyć się rewolucją
Czasami wynik audytu jest zaskakująco prosty.
System jest w porządku, trzeba tylko:
- Uzupełnić dokumentację.
- Uporządkować dostępy.
- Zaktualizować kilka bibliotek.
- Przenieść własność kont.
- Opisać proces wdrożenia.
- Dodać monitoring.
- Ustalić backup.
- Wprowadzić drugą osobę do obszarów, które znał tylko jeden developer.
I nagle bus factor zmienia się z 1 na 3.
Nie trzeba przepisywać całej aplikacji.
Nie trzeba wyrzucać siedmiu lat pracy.
Nie trzeba budować wszystkiego od nowa.
Czasami największym problemem nie jest technologia.
Jest nim brak mapy.
System powinien przeżyć ludzi, którzy go stworzyli
To chyba najważniejsza zasada: dobry system powinien być w stanie przetrwać odejście developera.
Powinien przetrwać zmianę administratora.
Powinien przetrwać zmianę software house'u.
Powinien przetrwać reorganizację firmy.
Powinien przetrwać kilka lat rozwoju.
Nie oznacza to, że każdy programista musi rozumieć każdą linię kodu. Oznacza to, że wiedza krytyczna dla działania biznesu nie może istnieć wyłącznie w głowie jednej osoby.
Bo pracownik może odejść.
Freelancer może zakończyć współpracę.
Agencja może zniknąć.
Dostawca może zmienić usługę.
A firma nadal musi działać.
Technologia powinna być własnością organizacji, nie pamięci pojedynczej osoby
To szczególnie ważne w przypadku systemów budowanych przez wiele lat.
Jeżeli firma płaci za oprogramowanie, powinna wiedzieć nie tylko, gdzie znajduje się kod.
Powinna wiedzieć:
- co posiada,
- od czego zależy,
- kto ma dostęp,
- kto może je zmienić,
- jak można je wdrożyć,
- jak można je odtworzyć,
- jak można je przekazać innemu zespołowi.
NIST w aktualnych materiałach dotyczących due diligence dostawców zwraca uwagę między innymi na pochodzenie, odporność, praktyki cyberbezpieczeństwa i zależności w łańcuchu dostaw. To pokazuje szerszy kierunek: organizacje coraz częściej powinny wiedzieć nie tylko, kto dostarczył system, ale również z czego system się składa i jakie ryzyka wiążą się z jego utrzymaniem.
To nie jest już wyłącznie temat dla działu IT.
To temat zarządzania ryzykiem biznesowym.
Najgorszy moment na poznanie swojego systemu to awaria
Można poświęcić kilka dni na audyt.
Można uporządkować dokumentację.
Można sprawdzić zależności.
Można opisać architekturę.
Można zweryfikować dostępy.
Można ustalić, kto naprawdę odpowiada za poszczególne obszary.
Można zmniejszyć bus factor.
Albo można poczekać.
Do momentu, kiedy system przestanie działać.
Wtedy pytania będą dokładnie te same.
Tylko presja będzie większa, użytkownicy będą czekać, sprzedaż może stanąć, a każda godzina będzie kosztować pieniądze.
Dlatego warto zadać sobie jedno pytanie, zanim pojawi się problem: Gdyby jutro zniknęła osoba, która najlepiej zna Twój system, czy nadal wiedzielibyśmy, jak go utrzymać?
Jeżeli odpowiedź brzmi "nie", nie oznacza to jeszcze, że system jest zły.
Oznacza, że firma ma ukryte ryzyko, którego do tej pory nie musiała uruchamiać.
W Web24 przejmujemy nie tylko kod
Przejęcie istniejącego projektu to zupełnie inna praca niż rozpoczęcie nowego systemu od zera.
Najpierw trzeba zrozumieć, co już istnieje.
Co działa.
Co jest krytyczne.
Co jest zależnością.
Co jest problemem.
Co jest tylko pozostałością po wcześniejszych decyzjach.
I przede wszystkim - gdzie znajduje się wiedza, bez której system nie może być bezpiecznie rozwijany.
Dopiero wtedy można planować dalsze działania.
Czasami będzie to modernizacja.
Czasami rozwój.
Czasami uporządkowanie infrastruktury.
Czasami przejęcie utrzymania.
A czasami po prostu stworzenie porządnej mapy systemu, której przez lata nikt nie miał czasu przygotować.
Bo odpowiedzialny software house nie powinien budować technologii, która działa tylko wtedy, gdy przy komputerze siedzi właściwy człowiek.
System powinien być większy niż pamięć jednej osoby.
A biznes powinien mieć pewność, że gdy ktoś odejdzie, technologia nie odejdzie razem z nim.
