Wygrać z długiem technologicznym

Artur Król: Czym jest dług technologiczny i jakie konsekwencje niesie dla instytucji finansowych?

Grzegorz Laudy: Dług technologiczny możemy podzielić na trzy główne kategorie: funkcjonalny, aplikacyjny i techniczny. Ten pierwszy dotyczy funkcji, które nie są wykorzystywane, lub takich, które pokrywają się z funkcjonalnościami oferowanymi przez inne systemy. Może również obejmować funkcje, które są niekompletne lub nie pozwalają na dalszy rozwój.

Jakie jest znaczenie tego rodzaju długu technologicznego? Po pierwsze, obniża on użyteczność platformy lub oprogramowania, które nie jest w pełni wykorzystane. Po drugie, ogranicza możliwości rozwoju funkcji, które nie są w pełni udokumentowane lub nie mamy pełnych praw do ich modyfikacji.

Drugą kategorią długu technologicznego jest dług aplikacyjny, który narasta z czasem, głównie z powodu stosowanych narzędzi, architektury oraz podejścia przyjętego podczas tworzenia rozwiązania. Ponieważ technologia nieustannie się rozwija, pojawiają się nowe języki programowania, wzorce projektowe i sposoby dystrybucji software’u.

Rozwiązania, które nie są regularnie aktualizowane, szybko się starzeją, gromadząc tym samym technologiczny dług. Dla przykładu – system napisany w przestarzałym języku programowania, który nie jest dostępny w chmurze lub nie wykorzystuje nowoczesnych narzędzi, staje się przestarzały.

Konsekwencje technologiczne są tutaj znaczące. Po pierwsze, niewspierane rozwiązania mogą stać się podatne na luki w zabezpieczeniach, co czyni je ryzykownymi w kontekście ochrony danych. Dodatkowo, utrzymanie i rozwój narzędzi zapisanych w przestarzałych językach programowania może prowadzić do utraty kompetencji wśród pracowników oraz stwarzać trudności w modyfikacji i aktualizacji oprogramowania, o ile wiedza na temat tych systemów stopniowo zanika w organizacji.

Trzecią kategorią długu technologicznego jest dług techniczny, który jest stosunkowo łatwy do zdefiniowania. W przypadku pakietowych rozwiązań informatycznych często dotyczy to liczby wersji systemu, które pozostają z tyłu względem najnowszego wydania.

Przykładowo, może się zdarzyć, że posiadany przez nas system operacyjny jest o dwie lub trzy wersje starszy niż najnowsza wersja wydana przez producenta oprogramowania. Dodatkowo problemem jest też posiadanie rozwiązań, które nie są już wspierane przez zewnętrzne firmy, co stanowi znaczne ryzyko operacyjne dla banku.

Wpływ tego typu długu jest znaczący: posiadanie oprogramowania, które nie jest już wspierane przez stronę trzecią, czyli jego producenta, zwiększa ryzyko bezpieczeństwa oraz operacyjne. Nieaktualne oprogramowanie, oprócz przestarzałych funkcji, może narazić organizację na problemy związane z utrzymaniem ciągłości działania oraz z bezpieczeństwem danych.

Czytaj także: Prezes ZBP o AI Act i bezpieczeństwie polskich banków

Jak zatem przedstawia się sytuacja w sektorze finansowym, a w szczególności w bankowym, w kontekście długu technologicznego? Czy obecnie ów dług się powiększa, czy też można mówić o pewnej stałości? Oczywiście pozostaje możliwość, że się zmniejsza, ale wtedy nie dyskutowalibyśmy o nim jako o postępującym problemie…

– Jak już wspomniałem, dług technologiczny ma to do siebie, że wystarczy nic nie robić, aby narastał. Jeśli organizacja skoncentruje się wyłącznie na wybranych aspektach, np. interakcjach z klientami, dług technologiczny w obszarach backoffice’owych czy produktowych będzie nadal narastał.

Zasadniczo dług technologiczny rośnie nieustannie, chyba że wprowadzone zostaną specjalne mechanizmy do zarządzania nim, o czym wypowiem się szerzej w dalszej części rozmowy.

Wygląda na to, że w Polsce mamy do czynienia z sytuacją, w której źródłem długu technologicznego jest wiele kluczowych systemów. Problem może również wynikać ze sposobu ich integracji. Często zdarza się, że rozwiązania typu Enterprise, jak obsługa faktur czy systemy HR-owe, nie otrzymują wystarczającej uwagi ze strony biznesu. To sprawia, że w obszarach mniej eksponowanych na zewnątrz dług technologiczny narasta szybciej z powodu niższego priorytetu biznesowego.

Czy istnieją jakieś szacunki określające wartość długu technologicznego, i czy da się ją jakoś obliczyć? Rozumiem, że jest to także wartość finansowa, wynikająca z różnic technologicznych. Czy można ją wyrazić w konkretnej, wymiernej kwocie?

– Oczywiście, daje się to zmierzyć w wymierny sposób. Szacujemy, że między 23% a 41% czasu poświęconego na rozwój oprogramowania jest w rzeczywistości marnowane na walkę z długiem technologicznym.

Te dwie granice, które przytaczam, mają swoje źródła w badaniach. Wartość 23% to wynik badań skandynawskich odnośnie czasu traconego przez deweloperów na radzenie sobie z długiem technologicznym[1]. Natomiast liczba 41% pochodzi z badania opublikowanego przez Stripe[2], z którego wynika, że deweloperzy średnio tygodniowo tracą 13,5 godziny na radzenie sobie z długiem technologicznym, a 3,5 godziny ze względu na oprogramowanie złej jakości.

Czytaj także: Raport Specjalny | Technologie Bankowe | O tych rozwiązaniach niedługo usłyszymy

Co zatem powinny robić instytucje finansowe, aby zminimalizować dług technologiczny?

– Przed przejściem do omówienia strategii zarządzania długiem technologicznym, warto jeszcze wspomnieć o kosztach z nim związanych. Koszty te możemy podzielić na bezpośrednie i pośrednie. Bezpośrednie są związane z utrzymaniem platform typu legacy, czyli starych systemów, które mogą być obciążone przestarzałą infrastrukturą sprzętową oraz problemami operacyjnymi. Koszty pośrednie wynikają z niestabilności systemów, obciążonych długiem technologicznym. Takie systemy mogą być często niedostępne, co zakłóca nieprzerwane świadczenie operacji, w tym również sprzedaży.

Spłatę długu technologicznego można porównać do spłaty kredytu – możemy spłacać zarówno kapitał, jak i odsetki. Odsetki to koszty wynikające z tolerowania długu.

Przykładowo, nasza architektura integracji, będąca de facto architekturą typu „spaghetti”, utrudnia oddzielenie i odseparowanie systemów. To z kolei wydłuża czas wdrożeń i testowania zmian, co również generuje dodatkowe koszty. Zarządzanie długiem technologicznym obejmuje dwa aspekty: repayment, czyli radzenie sobie z problemem, który dług generuje na bieżąco oraz spłatę samego kapitału, co oznacza bezpośrednie usuwanie źródła długu. To ostatnie może przybierać formę korygowania błędnych architektur, refaktoringu kodu, migracji do nowszej wersji systemu, czy też przejścia na nowsze języki programowania.

Przechodząc do działań, które organizacje mogą podjąć, aby proaktywnie zarządzać długiem technologicznym, proponujemy podejście, które składa się z trzech głównych kroków: pomiar długu technologicznego – istotne jest, aby mierzyć wielkość długu i monitorować jego wpływ na organizację.

Następnie ocena i priorytetyzacja działań – należy ocenić dług, by zdecydować, gdzie najlepiej zainwestować czas i zasoby, oraz ustalić priorytety działań.

Trzeci krok to akcja, czyli usuwanie długu – konkretna realizacja wyznaczonych działań w celu redukcji lub eliminacji długu technologicznego.

Teraz, aby lepiej to zrozumieć, rozwińmy przedstawione założenia. Przybliżając proces mierzenia długu technologicznego, należy go formalizować, uwzględniając pełny koszt posiadania platformy. Ważne jest, aby określić, jaki dodatkowy koszt generuje dług technologiczny – zarówno w kontekście utrzymania, jak i rozwoju. Należy również uwzględnić dodatkowe koszty licencyjne. Następnym krokiem jest stworzenie tzw. backlogu, czyli listy zagadnień związanych z długiem z uwzględnieniem ich wpływu na organizację. Powinniśmy również wybrać i wdrożyć narzędzia do kwantyfikacji i ilościowej oceny długu.

W drugim kroku, który dotyczy oceny długu technologicznego, powinniśmy zgromadzić informacje o nim ze wszystkich platform i dokonać ich segregacji. Celujemy w identyfikację i adresowanie tych aspektów długu, które mają największy potencjalny wpływ, ale jednocześnie są najłatwiejsze do usunięcia.

Trzeci podpunkt dotyczy ustalenia z działem biznesowym, jaką część zdolności produkcyjnych IT przeznaczyć na walkę z długiem technologicznym. Najczęściej mowa tu o 10% do 40% mocy przerobowych, które powinny być wykorzystane na redukcję długu, refaktoring oraz aktualizacje wersji oprogramowania, a także na ogólne usprawnienia rozwiązań.

Ostatni krok to implementacja wyznaczonych działań naprawczych. Obejmuje on aktualizację całkowitego kosztu posiadania (Total Cost of Ownership, TCO) dla całego portfolio aplikacji i zaktualizowanie wskaźników długu technologicznego.

Jak polska bankowość prezentuje się na tle innych krajów Unii Europejskiej w walce z problemem długu technologicznego? Czy jesteśmy w tym zaawansowani, a może pozostajemy z tyłu? Wydaje się, że sytuacja się poprawia i zaczynamy nadążać za innymi.

– Polski sektor bankowy zawsze był uznawany za jeden z najbardziej innowacyjnych na świecie, szczególnie w obszarze rozwiązań kanałowych, takich jak aplikacje mobilne i bankowość internetowa. Wydaje mi się, że naprawdę nie mamy sobie niczego do zarzucenia, również w obszarze rozwiązań CRM-u, gdzie wykorzystanie sztucznej inteligencji i interakcje z klientem są na bardzo wysokim poziomie.

Polska bankowość jest w dalszym ciągu jednym z liderów światowych w zakresie nowoczesnych technologii. Banki coraz chętniej korzystają z najnowocześniejszych rozwiązań dostępnych w chmurze. To, co sprawiło, że nieco spadliśmy z czołowych pozycji, to bardziej restrykcyjne podejście do wykorzystania rozwiązań chmurowych oraz duże skupienie na interakcjach z klientem.

Wydaje się, że obszary, które miały mniejszą ekspozycję na klienta, traktowano z mniejszą uwagą, co skutkowało większym narastaniem długu technologicznego, zwłaszcza w obszarze systemów core’owych.

Na koniec zapytam o przyszłość problemów z długiem technologicznym. Czy będzie się powiększał, czy raczej będą podejmowane kroki mające na celu jego redukcję?

– Trudno jednoznacznie określić sytuację całego sektora, jednak zauważam różnice w podejściach banków do redukcji długu technologicznego. Niektóre podejmują proaktywne kroki i regularnie przeznaczają część swojej zdolności operacyjnej IT na jego redukcję.

Inne podchodzą do tego zagadnienia bardziej reaktywnie, tolerując dług dopóty, dopóki nie zaczyna on wpływać na ryzyko operacyjne. Jeśli dług nie opóźnia znacząco wprowadzania na rynek nowych funkcjonalności, niektóre firmy uznają za priorytetowe zachowanie bieżącej zwinności operacyjnej nad długofalowym planowaniem.

Na polskim rynku widoczni są zarówno gracze, którzy systematycznie i regularnie podchodzą do redukcji długu technologicznego, przeznaczając regularnie część budżetu na ten cel, jak i ci, którzy stosują bardziej reaktywne, taktyczne podejście.

Czytaj także: Jak FTB łączy prawo bankowe i technologie cyfrowe?

***

[1] Besker, T., Martini, A., Bosch, J. (2019) „Software Developer Productivity Loss Due to Technical Debt”.

[2] The Developer Coefficient: Software engineering efficiency and its $3 trillion impact on global GD.