Kiedy nadchodzi czas na modernizację? Sygnały, że system legacy zaczyna kosztować

Systemy legacy rzadko upadają w sposób, który wymusza decyzję. Zwykle działają. Obsługują klientów, generują przychód i przez lata są dowodem, że firma zbudowała coś wartościowego. Właśnie dlatego moment, w którym taki system przestaje być aktywem, a zaczyna być obciążeniem, tak łatwo przeoczyć. Nie ma awarii, która zmusza do reakcji, jest tylko powolne narastanie kosztu, rozłożone na tyle miesięcy, że nikt nie widzi krzywej.

Pytanie „czy już czas na modernizację" pada więc zwykle o rok za późno, po serii sygnałów, które w danym momencie wyglądały na pojedyncze problemy. Poniżej zestaw tych sygnałów: co konkretnie obserwować, jak odróżnić naturalne starzenie się systemu od realnego blokera wzrostu i jak podjąć decyzję na podstawie dowodów, a nie przeczucia. Osobno kilka słów o tym, dlaczego odpowiedzią prawie nigdy nie jest przepisanie wszystkiego od nowa.

Sygnał pierwszy: koszt dostarczenia funkcji rośnie, choć zespół nie maleje

To najbardziej wiarygodny pojedynczy wskaźnik. Jeśli funkcja, która trzy lata temu zajmowała dwa tygodnie, dziś zajmuje sześć, a zespół jest tej samej wielkości albo większy, system pobiera podatek od każdej zmiany. W jednym z modernizowanych przez Altimi systemów, platformie do zarządzania jakością opartej na stosie z 2016 roku, koszt dostarczenia funkcji wzrósł pięciokrotnie względem stanu wyjściowego.

Ten sygnał jest szczególnie podstępny, bo organizacja zwykle go racjonalizuje. Mówi się, że produkt jest już dojrzalszy, że wymagania są bardziej złożone, że trzeba uważać na regresje. Wszystko to bywa prawdą, ale nie tłumaczy różnicy pięciokrotnej. Warto mierzyć to wprost: średni czas od podjęcia decyzji o funkcji do jej wdrożenia na produkcję, porównany rok do roku. Jeśli krzywa idzie w górę mimo stabilnego zespołu, to nie jest kwestia dojrzałości produktu, tylko architektury.

Sygnał drugi: zespół omija pewne obszary kodu

Każdy zespół inżynierski, który pracuje na starszym systemie, ma listę miejsc, których się nie rusza. Czasem jest spisana, częściej funkcjonuje w formie ustnej tradycji: tego modułu lepiej nie dotykać, tam trzeba zawołać jedną konkretną osobę, ta integracja działa i nikt nie wie dokładnie dlaczego.

Dopóki takie obszary są nieliczne i peryferyjne, to normalne. Problem zaczyna się, gdy zaczynają obejmować funkcje istotne dla rozwoju produktu. Wtedy roadmapa produktowa przestaje być kształtowana przez potrzeby klientów, a zaczyna przez to, co technicznie da się bezpiecznie ruszyć. To jeden z najkosztowniejszych mechanizmów w firmach produktowych, bo działa cicho: nikt nie zgłasza, że czegoś nie da się zrobić, po prostu te pomysły przestają trafiać do backlogu.

Sygnał trzeci: wiedza o systemie jest skoncentrowana w jednej lub dwóch osobach

Gdy odpowiedź na pytanie o działanie kluczowego modułu zawsze prowadzi do tej samej osoby, firma ma ryzyko ciągłości, którego nie zrekompensuje żadna jakość kodu. To ryzyko rzadko materializuje się stopniowo. Materializuje się w dniu, w którym ta osoba składa wypowiedzenie albo idzie na dłuższe zwolnienie.

Warto zwrócić uwagę na wersję pośrednią tego sygnału: wdrożenie nowego programisty trwa miesiące zamiast tygodni. Jeśli osoba z odpowiednim doświadczeniem potrzebuje kwartału, żeby samodzielnie wprowadzać zmiany, to nie jest kwestia jej kompetencji, tylko tego, że system nie daje się zrozumieć bez przewodnika. Przy planach rekrutacyjnych oznacza to, że każdy kolejny etat przynosi wartość znacznie później, niż zakłada model.

Sygnał czwarty: technologia zbliża się do końca wsparcia

Ten sygnał jest jedyny w swoim rodzaju, bo ma konkretną datę. Baza danych, framework albo system operacyjny, który przestaje być wspierany, zamienia niepewny problem architektoniczny w twardy termin. We wspomnianej platformie do zarządzania jakością jednym z czynników uruchamiających decyzję było wygaszenie wspieranej wersji bazy danych zaplanowane na 2027 rok, co przy skali migracji klientów wymagało rozpoczęcia prac z dużym wyprzedzeniem.

Koniec wsparcia oznacza brak poprawek bezpieczeństwa, rosnące trudności z rekrutacją, problemy z integracjami i, coraz częściej, kłopoty w rozmowach z klientami korporacyjnymi, których działy bezpieczeństwa pytają wprost o wersje komponentów. Warto potraktować taką datę jako punkt odniesienia do zaplanowania prac wstecz, a nie jako odległy termin, do którego jeszcze sporo czasu.

Sygnał piąty: bezpieczeństwo i zgodność zaczynają ograniczać sprzedaż

Moment, w którym dział handlowy przegrywa transakcje na etapie ankiety bezpieczeństwa, jest jednoznacznym sygnałem, że dług techniczny przestał być kwestią wewnętrzną. Podobnie działa brak certyfikacji oczekiwanych przez klientów, luki w kontroli dostępu, brak śledzenia zmian albo trudności z wykazaniem zgodności z RODO.

Ten sygnał ma bezpośrednie przełożenie na wycenę firmy i na dostępny rynek. Jeśli architektura uniemożliwia spełnienie wymagań, które warunkują wejście do najbardziej wartościowego segmentu klientów, modernizacja przestaje być projektem technicznym, a staje się warunkiem realizacji planu sprzedażowego.

Sygnał szósty: koszty utrzymania rosną szybciej niż przychód

Jeśli rachunek za infrastrukturę rośnie proporcjonalnie do liczby klientów albo szybciej, model biznesowy nie skaluje się tak, jak zakłada plan. Typowe przyczyny to brak elastycznego skalowania, nadmiarowe zasoby rezerwowane na wszelki wypadek, architektura uniemożliwiająca współdzielenie zasobów między klientami oraz obejścia utrzymywane latami, bo ich usunięcie wymagało zbyt dużej zmiany.

Warto policzyć to wprost: udział kosztów utrzymania i infrastruktury w przychodzie, śledzony w czasie. Rosnący udział przy stabilnej marży produktowej oznacza, że każda kolejna złotówka przychodu jest droższa do obsłużenia niż poprzednia.

Sygnał siódmy: nowe możliwości technologiczne są poza zasięgiem

Ostatni sygnał jest najnowszy i najczęściej pomijany. Jeśli firma chce wykorzystać sztuczną inteligencję w produkcie, ale dane są rozproszone po kilku bazach bez spójnego modelu, brakuje potoków danych, a architektura nie pozwala na osadzenie nowych komponentów bez ingerencji w rdzeń, to nie jest problem AI, tylko problem fundamentów.

Ten sygnał różni się od pozostałych tym, że nie objawia się rosnącym kosztem, tylko brakiem opcji. System działa poprawnie i nic nie boli, ale firma nie może zrobić rzeczy, które robi konkurencja. W praktyce oznacza to, że modernizacja przestaje być kwestią redukcji kosztów, a staje się warunkiem utrzymania pozycji rynkowej.

Jak odróżnić naturalne starzenie się od realnego blokera

Nie każdy z tych sygnałów uzasadnia program modernizacyjny. Praktyczne kryterium brzmi: czy dany problem blokuje coś, co firma faktycznie planuje zrobić w ciągu najbliższych dwóch lat. System z niedoskonałą architekturą, który stabilnie obsługuje niezmieniający się proces, może spokojnie działać dalej. Ten sam system staje się problemem w dniu, w którym plan zakłada wejście na nowy rynek, integrację z partnerami albo obsługę klientów o wyższych wymaganiach bezpieczeństwa.

Pomocne jest też rozróżnienie między kosztem bieżącym a kosztem opcji. Rosnący koszt dostarczania i rosnące rachunki za infrastrukturę to koszt bieżący, widoczny w liczbach. Utracone możliwości, przegrane transakcje i pomysły, które nigdy nie trafiły do backlogu, to koszt opcji, którego nie widać w żadnym raporcie. Ten drugi bywa większy, ale wymaga świadomego szukania.

Wreszcie, warto policzyć koszt odroczenia decyzji. Modernizacja odłożona o rok zwykle nie kosztuje tyle samo za rok, bo w międzyczasie przybywa kodu opartego na starych założeniach, a okno przed końcem wsparcia komponentów się kurczy. To pytanie, które w decyzjach zarządczych pada najrzadziej, a często jest najważniejsze.

Dlaczego odpowiedzią prawie nigdy nie jest przepisanie wszystkiego

Kiedy sygnały się nakładają, naturalną reakcją jest myśl o napisaniu systemu od nowa. To zrozumiałe i w większości przypadków błędne. Przepisanie zakłada, że zespół rozumie istniejący system na tyle dobrze, żeby go odtworzyć, że wymagania nie zmienią się przez wiele kwartałów przebudowy i że w odrzucanym kodzie nie kryje się nic istotnego. W praktyce stary system koduje lata przypadków brzegowych, a przepisywanie odkrywa je ponownie, w bolesny sposób i bez dostarczania nowej wartości.

Podejście, które sprawdza się znacznie częściej, polega na modernizacji przyrostowej: zaczynając od modułów o najwyższym ryzyku, walidując założenia na realnym kodzie i dostarczając zmiany etapami, tak aby zespół przez cały czas mógł wypuszczać nowe funkcje. Sztuczna inteligencja przesunęła tu rachunek jeszcze wyraźniej, bo najmocniej skraca właśnie tę pracę, która czyniła modernizację przyrostową żmudną: rozumienie kodu, mapowanie zależności, generowanie testów i powtarzalne przekształcenia. Przy odpowiednio dobranych zadaniach narzędzia AI potrafią zredukować nakład inżynierski o 50 do 80 procent, przy czym część pracy nadal wymaga osądu doświadczonych inżynierów i to rozróżnienie trzeba ustalić dla konkretnej bazy kodu, a nie zakładać z góry.

Jak podjąć decyzję na podstawie dowodów

Sygnały ostrzegawcze mówią, że warto się przyjrzeć. Nie mówią, co konkretnie modernizować, w jakiej kolejności ani ile to będzie kosztować. Odpowiedź na te pytania wymaga ustrukturyzowanej oceny na realnym kodzie, a nie warsztatu przy tablicy.

AI Refactoring Assessment prowadzony przez Altimi jest zaprojektowany dokładnie pod tę sytuację i trwa cztery tygodnie. Składa się z dwóch powiązanych strumieni. Pierwszy to ocena architektury i długu technologicznego: wskazanie, które części systemu blokują wzrost i skalowalność, ze skwantyfikowanym długiem, oceną gotowości do zastosowania AI i przeglądem ryzyk infrastrukturalnych. Drugi to technical spike, czyli praktyczna walidacja najbardziej ryzykownego fragmentu bazy kodu na rzeczywistym kodzie produkcyjnym, dająca twarde dane o ryzyku migracji i realnym wpływie narzędzi AI, zanim zwiąże się budżet.

Rezultatem jest pakiet decyzyjny przygotowany dla zarządu: streszczenie wykonawcze, mapa ryzyka, roadmapa modernizacji wykorzystująca AI, priorytetyzowany backlog długu technologicznego, wnioski ze spike'u oraz zasady nadzoru nad wykorzystaniem AI, przekazywane podczas warsztatu podsumowującego. Przebieg jest prosty: pierwszy tydzień to uruchomienie i zebranie danych wejściowych, drugi pogłębiona ocena architektury i zależności, trzeci technical spike na module najwyższego ryzyka, czwarty synteza, roadmapa i warsztat.

Obciążenie zespołu klienta jest przy tym niewielkie, bo prace prowadzone są w trybie tylko do odczytu na repozytoriach, z dwoma lub trzema ustrukturyzowanymi sesjami tygodniowo z architektami lub liderami technicznymi. Nie wymaga to zamrożenia roadmapy, co jest istotne, bo pierwszą obawą większości zespołów jest właśnie to, że ocena zatrzyma dostarczanie.

Wartość takiej oceny nie zależy od tego, czy decyzja o modernizacji już zapadła. Przeciwnie, to najczęstszy punkt wyjścia: organizacja widzi rosnący dług i próbuje ustalić, czy modernizować, kiedy i za ile. Wynik odpowiada również na pytanie, co się stanie, jeśli decyzja zostanie odłożona.

Kontekst europejski

Dla firm działających w Polsce, regionie CEE i na rynkach niemieckojęzycznych wymiar regulacyjny często przyspiesza moment decyzji. Zgodność z RODO, wymagania norm takich jak ISO 27001 oraz oczekiwania klientów korporacyjnych co do bezpieczeństwa i śledzenia zmian realnie warunkują dostęp do najbardziej wartościowych segmentów rynku. System, który tych wymagań nie jest w stanie spełnić bez głębokiej przebudowy, ogranicza sprzedaż niezależnie od jakości samego produktu.

Znaczenie ma również to, gdzie przetwarzany jest kod źródłowy w trakcie oceny wspomaganej sztuczną inteligencją. Współpraca z partnerem z siedzibą w Unii Europejskiej, posiadającym certyfikat ISO 27001, pozwala utrzymać wrażliwy kod w europejskim obszarze ochrony danych i udokumentować zasady wykorzystania AI, co przy audytach i rozmowach z klientami korporacyjnymi bywa równie istotne co sam efekt techniczny.

Kiedy nadchodzi czas na modernizację? Podsumowanie

System legacy rzadko wysyła jeden wyraźny sygnał. Wysyła kilka słabych naraz: rosnący koszt dostarczania funkcji, obszary kodu, których zespół unika, wiedzę skupioną w jednej osobie, zbliżający się koniec wsparcia komponentów, przegrywane ankiety bezpieczeństwa, koszty utrzymania rosnące szybciej niż przychód i brak możliwości sięgnięcia po nowe technologie. Każdy z osobna daje się racjonalizować. Razem oznaczają, że system przestał wspierać plan firmy i zaczął go ograniczać.

Właściwą reakcją nie jest ani ignorowanie tych sygnałów, ani natychmiastowe przepisywanie wszystkiego, tylko ustrukturyzowana ocena, która zamienia je w konkretną odpowiedź: co modernizować, w jakiej kolejności, jakim kosztem i co się stanie, jeśli decyzja poczeka.

Jeśli rozpoznajesz u siebie kilka z tych sygnałów i chcesz ustalić, co z nich wynika dla Twojego systemu, najprościej zacząć od krótkiej rozmowy o tym, co dziś blokuje dostarczanie.