Czy taki dług technologiczny straszny, jak go malują?

Dług technologiczny nie jest pojęciem nowym, choć według ekspertów MyCompany Polska specjalistów IT oraz tych z pogranicza IT i biznesu wciąż czeka sporo pracy, by go spopularyzować. Już w początkach lat 90. ubiegłego stulecia Howard G. „Ward” Cunningham opisał go jako zjawisko przypominające dług finansowy. 

Gdy wydając oprogramowanie, idziemy na skróty w celu przyspieszenia procesu wytwórczego, zaciągamy pożyczkę od samych siebie z przyszłości. Póki pamiętamy o tym, aby tę pożyczkę spłacać na bieżąco poprzez wprowadzanie niewielkich zmian, poprawiając obarczony długiem kod, mamy jeszcze pewien margines bezpieczeństwa. 

Sprawy mają się zgoła gorzej, jeśli nieustannie odkładamy spłatę. Zadłużenie rośnie, w skrajnych przypadkach doprowadzając do przestojów w procesie wytwórczym na czas gruntownego przemodelowania architektury aplikacji lub poprawy krytycznych błędów w kodzie.

Dług niejedno ma źródło…

Wspomnieliśmy już o długu technologicznym, który powstaje w wyniku konkretnych decyzji programistycznych, jednak nieoptymalna jakość kodu nie jest jego jedynym źródłem. Może się on przejawiać w dowolnym z obszarów: infrastruktury, technologii czy aplikacji.

W organizacjach z kilkunasto- czy nawet kilkudziesięcioletnią historią wdrożeń IT, można zaobserwować szczególnie jaskrawe przykłady źródeł długu. Zarówno w warstwie hardware, jak i software.

Aplikacje wspierające tzw. podstawową działalność (ang. core business), obsługujące produkty organizacji w formie niezmienionej od lat (ze względu choćby na umowy z dużymi klientami czy brak wypracowanego biznesowo planu migracji produktów do aplikacji wytworzonych w bardziej aktualnych technologiach), stają się rozwiązaniami przestarzałymi. Nie dość, że możemy stanąć przed widmem kończącego się utrzymania przez dostawcę aplikacji lub technologii, w której aplikacja powstała, to jeszcze może nam się zmniejszać grono specjalistów w utrzymaniu i rozwoju aplikacji. 

Przestarzałe rozwiązania często wymuszają kompatybilność wsteczną sprzętu. Przestarzały sprzęt z kolei jest mniej energooszczędny i w mniejszym stopniu poddaje się optymalizacji wydajności, a to przekłada się w efekcie na wzrost kosztu środowiskowego technologii. I tak oto z długu w warstwie aplikacji i technologii wyłania się dług w warstwie sprzętowej oraz dług ekologiczny.

Podobne konsekwencje w zakresie utrzymania i rozwoju będzie miało zastosowanie w dowolnej z warstw rozwiązań niszowych. W przypadku rozwiązań oferowanych przez pojedynczych dostawców możemy mierzyć się z ryzykiem tzw. vendor lock-in. 

W przypadku rozwiązań open-source przeszkodą będzie społeczność, czyli niewystarczająco liczna lub prężnie działająca na rzecz tworzenia nowych funkcji i poprawy istniejących, modernizacji technologicznych, czy też łatania luk bezpieczeństwa.

Niemałe znaczenie dla powstawania i pogłębiania się długu w warstwie software będą miały też decyzje w zakresie:

• braku reużycia standardowych komponentów aplikacyjnych, czyli odkrywanie koła na nowo,
• zastosowania języków programowania i serwerów aplikacyjnych nieoptymalnie wykorzystujących zasoby sprzętowe,
• tworzenia funkcji nadmiarowych lub spełniających wymagania niszowej grupy użytkowników,
• wdrażania rozwiązania bez wystarczającego rozpoznania potrzeb odbiorców końcowych,
• analizy i retencji gromadzonych danych, czyli potencjalnie zbierania nadmiarowych danych oraz przechowywania ich przez okres dłuższy niż to wymagane operacyjnie czy prawnie.

W warstwie hardware możemy mieć dodatkowo do czynienia z powstawaniem długu w efekcie braku ustalenia polityk dla czasu życia i migracji sprzętów. Zbyt rzadkie wymiany sprzętów skazują nas na utrzymywanie „muzeum techniki” i obniżającą się efektywność energetyczną. 

Zbyt częste natomiast generują niepotrzebne koszty ekonomiczne i ekologiczne (szczególnie poprzez generowanie odpadów technologicznych w przypadku braku polityk przekazywania sprzętów do dalszego użycia poza organizacją). 

Długi czas przełączania/migracji z wyłączanych urządzeń na nowo instalowane z kolei będzie się wiązał z niepotrzebnym dublowaniem zasobów sprzętowych.

… i nie zawsze zaciągany jest z pełną świadomością konsekwencji

Sam Holcman, Dyrektor Zarządzający EACOE i BACOE, w swoim niedawnym webinarze zastosował bardzo praktyczną i wymowną kategoryzację długu.

Tam, gdzie najbardziej liczy się czas realizacji zadań z backlogu biznesowego, zespoły wytwórcze często zmuszane są do daleko idących kompromisów. Nie mają wystarczającej przestrzeni na tworzenie dobrze przemyślanych i bezpiecznych rozwiązań ani na zadbanie o spłacanie długu na bieżąco. 

Naprawianie błędów wynikających z takiego podejścia stanowi zagrożenie ze względu na kumulację długu i może kosztować organizację nawet 20% budżetu przeznaczanego na technologie i innowacje, jak wynika z ankiety przeprowadzonej przez firmę doradczą McKinsey w 2021 r. wśród menedżerów IT.

Podejmując decyzje dotyczące technologii, możemy w wyniku rozpoznania i porównania dostępnych na rynku rozwiązań wybrać technologię, która spełnia oczekiwania zarówno biznesowe, IT, jak i bezpieczeństwa. Z czasem, przykładowo w obliczu konieczności przeskalowania rozwiązania w celu dostosowywania go do potrzeb zmieniających się bardziej dynamicznie niż to założono, może się okazać, że wybrana technologia przestaje być adekwatna. Wówczas mamy do czynienia z długiem zaciągniętym przypadkowo i nieświadomie. Ten jednak będzie wymagał spłacenia w jak najkrótszej perspektywie, aby nie pogarszać efektywności działania organizacji.

Z długiem zaciąganym przypadkowo, powodującym największe reperkusje, będziemy mieli do czynienia w wyniku decyzji podejmowanej pochopnie. Wdrażanie rozwiązań stosowanych z powodzeniem przez konkurencję, ale bez odpowiedniego zbadania alternatyw, rozpoznania przystawalności tegoż rozwiązania do faktycznych potrzeb organizacji, czy testów bezpieczeństwa, może doprowadzić nas do niepożądanej sytuacji. Konieczny będzie spory nakład pracy i środków, żeby uszczelnić luki bezpieczeństwa czy pokryć większość potrzeb biznesowych, gdy okaże się, że wdrożone rozwiązanie odbiega od wyobrażeń co do jego przydatności.

Dług zaciągany z pełną świadomością konsekwencji, dobrze opisany, zakomunikowany i z uwzględnionymi w planach rozwojowych propozycjami jego spłaty, będzie natomiast efektem zdrowego kompromisu. Pogodzone zostaną potrzeby biznesowe dotyczące skrócenia czasu dostarczania kolejnych przyrostów rozwiązania z potrzebami IT i bezpieczeństwa dotyczącymi ograniczania nakładu pracy na poprawki, przebudowy i przyszłe aktualizacje technologii.

Dlaczego trzymanie długu technologicznego w ryzach jest takie ważne?

Według raportu Polcomu i Intela aż 65% przedsiębiorców wskazało dług technologiczny jako przeszkodę w rozwoju organizacji. Decyduje o tym kilka względów, dla których postaramy się przedstawić sugestie zmniejszania ich wpływu na organizację.

Długiem nierozpoznanym i niemierzonym nie daje się zarządzać

Pomocne w zarządzaniu długiem technologicznym będzie (kolejność nieprzypadkowa):

• stworzenie rejestru posiadanych: infrastruktury, technologii, aplikacji,
• stworzenie katalogu technologii wraz z pryncypiami zarządzania nim i wskazaniem z imienia i nazwiska opiekunów każdej z technologii (już występującej w katalogu oraz dodawanych w przyszłości),
• wyznaczenie miar długu zrozumiałych dla każdego,
• cykliczne pomiary aktualnego poziomu długu i dzielenie się ich wynikami również poza IT.

Każda ze skatalogowanych technologii wymaga dodatkowo określenia jej czasu życia z datą graniczną jej zastąpienia nową wersją lub wycofania. Pozwoli to uniknąć zaskoczenia w przypadku informacji od dostawcy technologii o planowanym zakończeniu jej utrzymania.

Długu budowanego latami nie da się usunąć od razu

Redukcja skumulowanego długu potrafi być projektem samym w sobie. Zarządzanie nim wymaga:

• ustalenia optymalnego dla organizacji poziomu długu i granic jego tolerancji,
• powołania dedykowanego budżetu,
• zasobów, zespołów IT wspierających proces redukcji i czasu.

Warto jednak nie dopuszczać do nadmiernej kumulacji długu, a więc należy zadbać o jego spłacanie na bieżąco (co będziemy powtarzać do znudzenia) lub ustalić plan spłaty w perspektywie kilkuletniej, uwzględniając zmieniające się otoczenie zewnętrzne i planowanie zasobów w obszarze infrastruktury.

Im większy dług, tym większa zależność od pojedynczych dostawców lub osób

Wybór rozwiązań niszowych może skazać nas na wspomniany już vendor lock-in i w efekcie utrudnić lub uniemożliwić wydawanie aktualizacji, poprawek bezpieczeństwa czy wprowadzanie nowych funkcji w odpowiednim dla organizacji rytmie. Podejmując decyzje o wyborze technologii i rozwiązań warto szukać tych bardziej popularnych, wykorzystywanych szerzej rynkowo.

Starzejące się lub przestarzałe technologie i rozwiązania będą stanowiły coraz większe wyzwanie w utrzymaniu. Z dużą dozą prawdopodobieństwa będą uniemożliwiały dalszy rozwój. Warto zaplanować zawczasu ich wymianę i migrację wspieranych przez nie procesów, aby uniknąć frustracji partnerów biznesowych, którym nie będziemy mogli zaoferować dostosowań do zmieniających się realiów, jak również uniknąć zmniejszania się liczby specjalistów IT posiadających kompetencje niezbędne do utrzymania danej technologii czy rozwiązania.

Dług zmniejsza poziom bezpieczeństwa

Zagrożenie dla bezpieczeństwa stanowią zarówno starzejące się rozwiązania i technologie, w których z czasem wykrywane są niezidentyfikowane dotychczas podatności, jak i wdrażane w pośpiechu, a nieprzetestowane pod kątem bezpieczeństwa komponenty technologiczne.

Remedium jest więc dbałość o aktualizacje technologii do najnowszych i przetestowanych pod kątem bezpieczeństwa wersji, jeśli na etapie projektowania zabraknie czasu na ich uważny dobór.

Dług przeszkadza w codziennej pracy

Według badań Stepsize dla ponad 50% programistów dług technologiczny jest podstawą do rozważania zmiany pracodawcy. Ponad 80% programistów wskazuje brak odpowiedniego rozwoju i wdrażania nowych narzędzi jako jeden z najpoważniejszych czynników obniżenia satysfakcji z pracy. Choć dług technologiczny rzadko bezpośrednio wpływa na decyzję o zatrudnieniu, to jednak warto o nim pamiętać, by nie tracić najbardziej kompetentnych specjalistów oraz przyciągać nowe talenty.

Podsumowanie

Czy zatem dług technologiczny jest straszny? "To zależy". Nie, jeśli zaciągamy go w pełni świadomie, robiąc przestrzeń na jego spłacanie w backlogu projektów biznesowych lub technologicznych. Jeśli na bieżąco monitorujemy jego stan i komunikujemy go, nie tylko wewnątrz IT. Jesteśmy wtedy na najlepszej drodze do utrzymania go na bezpiecznym poziomie. Takie działanie przekłada się na sprawniejsze działanie organizacji i jej rozwój, jak również na coraz bardziej zrównoważone rozwiązania IT w organizacji.

Zespół Architektury Domenowej w Biurze Projektowania i Efektywności IT w PZU