1 godzina temu
Dług technologiczny nie pojawia się w bilansie, choć regularnie obciąża wynik: zwiększa koszt utrzymania systemów, wydłuża projekty i sprawia, iż każda kolejna zmiana technologiczna zaczyna kosztować więcej niż poprzednia.
Samo pojęcie bywa jednak nadużywane. Do jednego worka trafiają przestarzały kod, stare aplikacje, nadmiarowe integracje, manualne procesy, skomplikowana architektura czy platformy, których nikt nie chce już rozwijać. Ekonomicznie łączy je coś innego: zwiększają koszt przyszłej zmiany.
To właśnie ten koszt jest istotniejszy niż wiek technologii.
Deloitte w Global Technology Leadership Study 2026 szacuje, iż dług technologiczny może odpowiadać za 21–40 proc. wydatków IT. Badanie objęło ponad 660 liderów technologii na świecie, ale sama liczba wymaga ostrożności: nie pochodzi z audytu budżetów przedsiębiorstw i nie powinna być traktowana jako uniwersalny benchmark. Pokazuje raczej skalę problemu, który w wielu organizacjach przestał być marginalnym kosztem utrzymania.
Nie istnieje jedna wartość długu
Największą pokusą jest sprowadzenie problemu do jednej liczby. Literatura naukowa nie daje jednak podstaw do takiej precyzji.
Systematyczny przegląd badań opublikowany w „Journal of Systems and Software” wskazuje na brak wystarczających dowodów empirycznych pozwalających wiarygodnie mierzyć zarówno „kapitał” długu technologicznego, jak i płacone od niego „odsetki”. Nie ma również jednego, zwalidowanego zestawu narzędzi pozwalających porównywać jego wartość między organizacjami.
Nie jest to argument przeciwko mierzeniu długu. Przeciwnie. Zamiast próbować wycenić abstrakcyjny stan całej architektury, bardziej użyteczne jest mierzenie kosztów, które można przypisać konkretnym ograniczeniom.
Pierwszym jest nadmiarowy koszt utrzymania. o ile środowisko wymaga dodatkowych licencji, infrastruktury, manualnej obsługi, specjalistycznych kompetencji czy równoległego podtrzymywania kilku generacji systemów, różnica między stanem obecnym a docelowym staje się mierzalna.
Drugim jest rework: praca, która nie tworzy nowej wartości, ale wynika ze złożoności istniejącego środowiska. Software Engineering Institute od lat wskazuje właśnie rework i propagację zmian przez zależne elementy architektury jako użyteczne przybliżenia kosztu długu. Im więcej komponentów trzeba zmienić, aby bezpiecznie zmodyfikować jeden z nich, tym droższa staje się kolejna decyzja produktowa.
Trzecim składnikiem jest ryzyko operacyjne: awarie, podatności, niedostępność kompetencji, utrata wsparcia producenta czy ograniczenia zgodności. Tutaj nie trzeba tworzyć nowej ekonomii. Wystarczy prawdopodobieństwo zdarzenia zestawić z potencjalnym kosztem jego materializacji.
Najdroższy może być czas
Najmniej widocznym składnikiem długu pozostaje koszt opóźnienia.
Jeżeli wdrożenie nowej funkcji trwa sześć miesięcy zamiast trzech, rachunek nie kończy się na dodatkowych godzinach programistów. Obejmuje również późniejsze uruchomienie przychodów, późniejszą redukcję kosztów, dłuższe utrzymywanie starego procesu oraz krótszy okres ekonomicznego wykorzystania nowego rozwiązania.
W takim ujęciu dług technologiczny przestaje być problemem jakości kodu. Staje się premią doliczaną do niemal każdej przyszłej inwestycji.
Załóżmy, iż utrzymanie systemu pochłania rocznie 5 mln zł, podczas gdy porównywalne środowisko docelowe kosztowałoby 3,5 mln zł. Kolejne 800 tys. zł pochłaniają prace związane z obejściami i poprawkami, a oczekiwana roczna wartość incydentów wynosi 400 tys. zł. Sam mierzalny ciężar istniejącej architektury sięga wówczas 2,7 mln zł rocznie, jeszcze przed uwzględnieniem opóźnień biznesowych.
Modernizacja za 8 mln zł wygląda wtedy inaczej niż „projekt IT za 8 mln zł”. Można zestawić koszt inwestycji z możliwą redukcją przyszłych wydatków, policzyć okres zwrotu, NPV i scenariusz pozostawienia systemu bez zmian.
AI podnosi znaczenie fundamentów
Obecna fala inwestycji w AI dodatkowo odsłania tę zależność. DORA przebadała w 2025 r. niemal 5 tys. specjalistów technologicznych i zebrała ponad 100 godzin danych jakościowych. Większa adopcja AI była związana z wyższą przepustowością dostarczania oprogramowania, ale przez cały czas korelowała z niższą stabilnością. Zespoły pracujące na luźniej powiązanych architekturach, z szybką informacją zwrotną i dojrzałym testowaniem, uzyskiwały wyraźnie lepsze efekty niż środowiska obciążone silnymi zależnościami.
Automatyzacja może więc przyspieszyć wytwarzanie kodu szybciej niż organizacja potrafi upraszczać system, do którego ten kod trafia.
Nie każdy dług warto przy tym spłacać. Stabilny system o niewielkim koszcie utrzymania i małej potrzebie zmian może być ekonomicznie racjonalny mimo wieku. Problem zaczyna się tam, gdzie architektura systematycznie zwiększa koszt każdej kolejnej decyzji.
Najbardziej użyteczną miarą długu technologicznego nie musi więc być jego całkowita wartość. Znacznie ciekawsze jest pytanie o cenę pozostawienia go na kolejny rok.
