Dług technologiczny: chytry dwa razy traci

Przy systemach legacy często, jeśli nie zawsze, spotykamy się z pojęciem „dług technologiczny”. Najprościej mówiąc, oznacza on nagromadzenie wielu zróżnicowanych problemów technicznych, które powstają podczas praktycznie każdego projektu informatycznego. Ignorowanie ich wpływa na jakość i tempo realizacji przedsięwzięcia. To jak rata kredytu, która systematycznie niespłacana, z czasem generuje niebotyczne odsetki, które mogą doprowadzić nas do bankructwa.

Bezlitosny dług technologiczny

Naraża on nas na podatności bezpieczeństwa, ogranicza możliwości dalszego rozwoju oraz zwiększa koszty z tym związane. Oprogramowanie oparte o starsze technologie stwarza ryzyko pojawienia się luk bezpieczeństwa. Wszyscy wiemy, że lepiej zapobiegać niż leczyć. Profilaktyka związana z długiem technologicznym obniży koszty rozwoju, a może ułatwić również ewentualną migrację do chmury, która nabiera w obecnym czasie coraz większego znaczenia. Nie warto być mądrym po szkodzie.

Dług technologiczny może zacząć narastać już na etapie powstawania projektu. Każdy dodatkowy rozwój jest obarczony dodatkowym ryzykiem jego wygenerowania, zwłaszcza gdy idziemy „na skróty”: minimalizując jednostkowe koszty bądź zmiany realizowane są przez zespół niedoświadczony lub słabo znający rozwiązanie. Na dług technologiczny warto również spojrzeć z punktu widzenia starzenia się aplikacji. Zmienia się otoczenie, powstają nowe frameworki, użyte biblioteki stają się przestarzałe, powstają ich nowe wersje, a w poprzednich wykrywane są takie czy inne podatności. Z czasem również zastosowana architektura aplikacji zaczyna być ciężarem.

Od mono do mikro

Jeszcze niedawno budowaliśmy duże, monolityczne aplikacje. Dziś zmierzamy w stronę mikroserwisów i rozwiązań przystosowanych do uruchomiania w środowiskach kontenerowych czy chmurowych. Dzisiaj sytuacja zmusiła nas do ograniczenia kontaktów międzyludzkich. To z kolei wpływa na większe użycie kanałów zdalnych. Aplikacje legacy często nie są na to przygotowane.

Niezależnie od źródła stajemy przed nagłą koniecznością modyfikacji systemu. Jeżeli jesteśmy obarczeni dużym długiem technologicznym, ewentualne zmiany i rozwój mogą stanowić istotny problem. Należy zdawać sobie z tego sprawę, gdyż wtedy istnieje nadzieja, że będziemy mogli sobie z tym poradzić.

Spłacaj dług technologiczny i rozwijaj system

Bardzo często w biznesie, czy nawet zespołach IT, istnieje pogląd, że likwidacja długu nie wnosi w zasadzie większej korzyści biznesowej. Racja, jest to typowy zabieg technologiczny, czysta profilaktyka. W związku z tym organizacje mają bardzo duże opory, aby poświęcić czas czy wydatkować budżet na systematyczne pozbywanie się tych zaległości. Niestety, takie podejście powoduje, że z każdym rokiem przyszłe koszty likwidacji tego zadłużenia będą rosły. W tym wypadku nie warto mądrzeć dopiero po szkodzie.

Z naszych dotychczasowych obserwacji wynika, że mimo wszystko pozbywając się na bieżąco długu technologicznego, zapewniamy sobie możliwość dalszego rozwoju systemu, ale przede wszystkim możliwość znacznego ograniczenia kosztu, czy może bardziej ograniczenia ryzyka powstania znacznego kosztu w najmniej spodziewanym momencie. Każde oprogramowanie, jeśli przestanie być wspierane, będzie starzało się szybko. Systemy nierozwijane mają tendencję zarówno do narastania długu jak i do utraty wartości biznesowej. W takiej sytuacji prędzej czy później migracja do nowego systemu staje się przede wszystkim nieuchronna.

Starość (nie) radość

Musimy mieć świadomość, że każdy system się starzeje.  Jeśli tylko mamy wpływ na to, żeby reagować i minimalizować szkody, to po prostu róbmy – tak naprawdę nie ma jednego prostego podejścia do legacy. Nie ma żadnego antidotum – każdy system jest inny: będzie też różnił się architekturą, technologią i wiekiem. Należy wykonać dużą pracę związaną z analizą, ewentualnie zatrudnić firmę, która wykona prace za nas.

Co może sygnalizować problemy?

• w używanych wersjach komponentów stwierdzono luki bezpieczeństwa.
• audyty stwierdzają niezgodności ze standardem.
• pojawiają się odgórne regulacje, które wymuszają na nas szybkie zmiany
• używanych przez nas wersji nie zaktualizowano do najnowszych.
• zmieniły się warunki, w jakich system działa: na przykład ilość jednocześnie korzystających użytkowników
• pojawiły się wymagania biznesowe, które skutkują koniecznością wprowadzenia zmian

Chytry dwa razy traci

Przypadek z życia: jeden z podmiotów finansowych zarządził odgórne regulacje dla całej organizacji: wszystkie wersje oprogramowania muszą zostać podbite do aktualnych, bezpiecznych „na już”. Dostosowanie się to tej sytuacji stanowi naprawdę ogromne wyzwanie. Pojawiają się wymagania, które są trudne do spełnienia w przypadku starszych wersji.

W naszych ostatnich doświadczeniach często spotykaliśmy się z regulacjami i wymogami wynikającymi z wewnętrznych audytów. Pojawiają się różne wytyczne jak dyrektywa PSD2, która wdrażana jest instytucjach finansowych. Rekomendacje Komisji Nadzoru Finansowego stawiają przed bankami konkretne wymagania, które muszą spełniać także aplikacje legacy. Szybkie dostosowanie do takich wymogów może stanowić dość duży problem.

Ciągłe dbanie o jakość kodu aplikacji i aktualizacje wersji poszczególnych komponentów wydaje się kosztowne, a jednocześnie „nie wnosi” żadnej wartości biznesowej. Firmy często mają poważne opory przed ponoszeniem takich kosztów. Jeśli z różnych przyczyn dochodzi do zmian w tym zakresie, zazwyczaj są to zmiany punktowe i możliwie najtańsze. Taka oszczędność często jest tylko pozorna, bo przy wprowadzaniu kolejnych zmian w aplikacji zaoszczędzony koszt i tak trzeba ponieść i to zwykle „z odsetkami”.

Podsumowanie

Warto zastanowić się nad innym, proaktywnym podejściem i minimalizacją długu technologicznego na bieżąco. Wówczas koszty będą istotnie niższe, a rozwój z pewnością szybszy, prostszy i pozbawiony opóźnień. Pozbędziemy się też niepotrzebnych nerwów, czyli skutków naszych zaniechań. W obecnych czasach włamanie się do systemu z dość poważnymi podatnościami bezpieczeństwa to już nie kwestia dni, a pojedynczych godzin…

Jeśli nie mamy własnych doświadczeń w tej materii lub po prostu nie wiemy co z danym systemem Legacy zrobić, najlepiej jest zwrócić się do firm, które świadczą takie usługi: zarówno utrzymania jak i rozwoju. Ignorując tę kwestię, możemy wpaść w pułapkę niemocy. Albo po prostu przegapimy ten moment, że jeszcze coś da się zrobić. Wtedy zostaniemy w sytuacji, że zostanie nam tylko kosztowna migracja do nowego systemu. Czas szybko po prostu biegnie, jeśli chodzi o technologię. Bądźmy czujni.

Krzysztof Skowerski
Paweł Szutowicz
Tomasz Turmowicz