Problem legacy systems, czyli ABC długu technologicznego
Po polsku mówi się o nich “systemy zastane” lub po prostu “systemy legacy” i nazwa ta doskonale odzwierciedla zarówno ich nieaktualność, jak i problematyczność. “Zastały się”, czyli zesztywniały w skutek bezruchu - braku aktualizacji, poprawek i zmian. Co gorsza, im więcej czasu mija, tym więcej z nimi problemów. Zaciągnięty dług technologiczny rośnie.
Legacy systems = dziedzictwo, którego nikt nie chce
Ponoć prawie każda firma, która działa na rynku co najmniej 4–5 lat, posiada jakiś legacy system, czyli kluczowy dla swojej działalności system, który działa w oparciu o przestarzałe już technologie.
Kiedy pojawił się w przedsiębiorstwie, wydawał się być najlepszym możliwym rozwiązaniem — firma dopiero startowała, a dostawca oprogramowania zalecał stabilny, centralny system monolityczny, w którym nie trzeba specjalnie przejmować się wydzielaniem poszczególnych funkcji czy usług. Nikt nawet nie wiedział jeszcze, czym firma będzie zajmować się w perspektywie dekady i jakie będą jej potrzeby.
Czas jednak mijał. Firma się rozwijała. Jej otoczenie się zmieniało. Standardy technologii również. I tak, w pewnym momencie, system, który dawniej był dobry do wszystkiego, stał się do wszystkiego zły.
Co gorsza, im więcej czasu mijało, tym więcej problemów on rodził. Każdy kolejny problem “łatało się” zazwyczaj ad hoc, bo gruntowne zmiany pożarłyby morze czasu i pieniędzy. Tak właśnie wygląda opowieść o systemach legacy w praktyce — opowieść, która dzieje się w zaskakującej liczbie firm w Polsce.
Najczęstsze problemy, jakie generują systemy legacy, z jakimi borykają się obecnie firmy, to:
- utrudnione, długotrwałe wprowadzanie zmian w systemie, które i tak tylko zwiększają technologiczny dług, zamiast pomagać — legacy systems są ze swej natury bardzo mało elastyczne, co sprawia, że nawet taka błahostka, jak np. wymuszona przez nowe przepisy zmiana formatu danego dokumentu księgowego urasta do wielkiego rangą (i wielce kosztownego) przedsięwzięcia. Raz zbudowany zastany monolit trwa w swej niezmienionej formie latami, a wszystko wokół się zmienia. Przepisy, wymogi prawne, dodatkowe aplikacje itd. Wszystko to rodzi gigantyczny, wewnętrzny ból — zamiast walczyć o nowe, lepsze tereny, nieustannie walczymy o utrzymanie się na powierzchni,
- niedostępność danych z systemu legacy do integracji z innymi, nowszymi systemami, które podniosłyby konkurencyjność firmy na rynku. Dane przechowywane w przestarzałych systemach cechuje brak standaryzacji — nie można ich tak po prostu “przesłać” do innej aplikacji czy oprogramowania. Najpierw trzeba je wyciągnąć, obrobić i oczyścić, a tego raczej nie zrobi dostawca naszego systemu, ani nasz wewnętrzny dział IT z jednego, prostego powodu: często brakuje im do tego koniecznego doświadczenia i umiejętności pracy z danymi. Firma posiada zatem ważne dane, ale praktycznie z nich nie korzysta lub korzysta z nich w utrudniony, manualny sposób, wywołujący gorączkę u każdego pracownika. Szansa na rozwój kolejnych produktów w oparciu o te dane jest bliska zeru,
- wysoka awaryjność systemu, a co za tym idzie wysokie, stałe koszty jego utrzymania — jako, że system ma już swoje lata, to co chwilę coś się w nim psuje. Z uwagi na to, że większość systemów zastanych ma postać systemów monolitycznych, składających się z milionów linijek kodu, każda najmniejsza nawet awaria, wiąże się z wielogodzinnym poszukiwaniem źródła problemu. W efekcie, spora część budżetu IT firmy idzie nie na inwestycje w modernizację, a na łatanie pojawiających się regularnie dziur w obecnym systemie. Stwierdzenie “system znowu padł” staje się ponurą codziennością firmy i przestaje kogokolwiek dziwić,
- wisząca jak cień nad głową, obawa, że przyjdzie dzień, kiedy system ulegnie tak ogromnej awarii, że straty firmy będą liczone w milionach — wyciek danych użytkowników czy zatrzymanie linii produkcyjnych na nie wiadomo jak długo, to chaos i paraliż pracy przedsiębiorstwa. Ile kosztuje taki zastój, doskonale wie każdy właściciel firmy czy członek zarządu. Oni wtedy nie cieszą się z przymusowego wolnego i nie robią sobie spokojnie kawy, jak liniowi pracownicy,
- uzależnienie się od dostawcy rozwiązania — z uwagi na to, że system pisany był w archaicznych technologiach i zazwyczaj brakuje mu aktualnej dokumentacji technicznej, która obejmowałaby również “dorabiane” w późniejszym czasie aplikacje i interfejsy, wymiana dostawcy na nowego graniczy z cudem. A gdy ktoś ma swoisty “monopol” na system, to może dyktować takie ceny napraw i zmian, jakie tylko chce. W efekcie, wiele firm decyduje się w pewnym momencie w ogóle przestać aktualizować zastany system, co z czasem rodzi kolejne problemy,
- brak pracowników, którzy “pamiętają, jak to było robione” — dopóki w firmie pracuje jeszcze ktoś, kto był przy tym, jak dany monolit powstawał, zna system od lat i potrafi z pamięci znaleźć dany wers kodu, utrzymanie legacy system jeszcze jako tako funkcjonuje. Gdy jednak ta osoba odchodzi — a teraz przecież nie żyjemy w czasach, gdy pracownicy całe życie spędzają w jednej firmie — wszystko zaczyna się nieodwracalnie sypać,
- częste luki bezpieczeństwa, które są trudne do usunięcia — aby sprostać najnowszym zagrożeniom, wszystkie systemy powinny być aktualizowane w trybie ciągłym. A jak już wspomnieliśmy wyżej, legacy systems są oporne na zmiany. Przez wzgląd na zastosowane w nich przestarzałe technologie, frameworki i rozwiązania, usunięcie niektórych luk bezpieczeństwa okazuje się zazwyczaj nie lada wyzwaniem i zajmuje sporo czasu, tworząc potencjalne zagrożenie dla firmy.
Problem legacy, a problem długu technologicznego
To właśnie z powyższych powodów, gdy mówi się o systemach zastanych, bardzo często zaczyna się też mówić o zaciągniętym przez firmę długu technologicznym.
Określenie “dług technologiczny” to pojęcie pochodzące ściśle z branży IT i oznacza “brak projektu”. Innymi słowy, firma świadomie (lub nie, bo tak też się zdarza) decyduje się pominąć jakąś aktualizację, analizę czy etap projektowania, pójść na skróty i po kosztach, zaciągając w ten sposób swoistą technologiczną pożyczkę.
W rozumieniu architektury oprogramowania, taki dług, to np. załatanie jakiejś usterki na szybko albo dorobienie czegoś do systemu, czego nie przewidziano pierwotnie w architekturze całości. Nie jest to więc wykonane rzeczywiście tak, jak powinno.
W teorii, pożyczkę taką zaciąga się chwilowo po to, żeby np. więcej środków z budżetu przeznaczyć na inny obszar lub dlatego, że w danej chwili firma rzeczywiście nie może sobie pozwolić na taki wydatek albo nie ma czasu na wdrożenie najlepszego możliwego rozwiązania. Rozwiązanie “takie se” jakoś wystarcza.
W praktyce, jak od każdej pożyczki, tak i w przypadku pożyczki technologicznej, odsetki rosną i tworzy się wspomniany już dług. Byle jak wykonane poprawki i funkcje systemu (lub ich brak) się kumulują, doprowadzając do momentu, gdy system naprawdę ledwo oddycha. Finalnie więc, wszystkie te nieprzeprowadzone aktualizacje czy wybór gorszego rozwiązania i tak będzie trzeba kiedyś spłacić. Najpewniej skokowo, żeby dogonić innych na rynku — grubą sumą konieczną na wielką inwestycję. Sumą, o której większość menedżerów wolałoby nigdy nie słyszeć, bo przecież wszyscy nieustannie czują presję obniżania kosztów, a nie ich generowania.
Dobrze problem legacy i ciągłej pogoni za byciem aktualnym, przedstawia obecna sytuacja sektora finansowego: w Polsce wcześniej niż na Zachodzie pojawiły się szybkie transfery i płatności zbliżeniowe, bo nie mieliśmy takich ogromnych legacy systems, jak pozostałe kraje. Nie mieliśmy ani czeków, ani tak rozwiniętej technologicznie bankowości. Nie trzeba było tego nagle skokowo dostosować pod nowe wymagania rzeczywistości. Teraz jednak, non stop gonimy Afrykę, która stała się liderem bankowości mobilnej. Kontynent ten przeskoczył Europę, tak jak kiedyś Polska, bo z kolei na moment popularyzacji smartfonów, to oni nie mieli tak kolosalnie wielkiego trupa w szafie, jak reszta graczy.
Dlaczego firmy “po prostu” nie wymieniają przestarzałych systemów legacy na nowe?
W kontekście tego, o czym pisaliśmy wyżej, jedynym słusznym rozwiązaniem wydaje się być aktywne wyjście naprzeciw problemom: refaktoring kodu lub całościowa wymiana systemu na nowy poprzez stopniowe wydzielanie z niego kawałek po kawałku mniejszych fragmentów, które będą działać niezależnie i które można ze sobą później połączyć ( i z zewnętrznymi aplikacjami, do których obecnie firma nie ma dostępu) jako sieć mikroserwisów.
Gdy tak o tym piszemy, wydaje się to proste. W rzeczywistości jednak takie nie jest.
Przypomnijmy, system legacy, to często główny rdzeń firmy — centralny ERP, z którego nadal aktualnie korzysta dział finansowy, zakupów, sprzedaży i na przykład logistyki. Nie można go po prostu wyciąć i w jeden dzień zastąpić nowym. Wiele osób tak wielkie przedsięwzięcie zwyczajnie przerasta i wolą skupić się na łataniu mniejszych dziur.
Absolutnie każdy wie, że obecny system legacy generuje mnóstwo problemów, jest niewydolny, niedostosowany do obecnych realiów i w końcu sam z siebie padnie, robiąc niezły bajzel.
Mało kto jednak ma ochotę wyjść przed szereg i zaryzykować własną karierę, mówiąc “Mam taki pomysł na zmianę…”.
Dlaczego? Bo proces zmiany z pewnością będzie:
- kosztowny (jak pisaliśmy wyżej, obecnie trwa moda na ucinanie kosztów, a nie ich generowanie, nawet jeśli w tabelkach Excela da się łatwo wykazać, że większa inwestycja zwróci się już w 2 lata i długodystansowo będzie korzystniejsza),
- długi (pół roku, rok, dwa lata — wszystko zależy od strategii zmiany, wielkości zastanego systemu i stopnia jego skomplikowania),
- niełatwy w rozumieniu wymagający dodatkowej pracy od managera i jego zespołu. Oczywiście wyspecjalizowana firma software, która podejmie się wyzwania, weźmie na siebie wszystkie technologiczne problemy i będzie doradzać, w jaki sposób uefektywnić przepływ procesów taką a taką architekturą, ale na początku będzie też potrzebowała zmapować te wewnętrzne procesy z klientem. Jak, co i komu służy w firmie, to wiedza know-how, której nikt z zewnątrz nie posiada.
A co najważniejsze, jeśli planowane prace nie pójdą tak gładko, jak zakładano, to istnieje możliwość, że poleci nie ten, co “chowa trupa w szafie”, a ten, co postanowił tego trupa z szafy wyciągnąć! Niesłusznie, ale zdziwilibyście się, ile firm nadal nie jest na tyle dojrzała i mądra, żeby nagradzać innowatorów, a nie wygodnych leniów! Dopiero wykształcenie kultury organizacyjnej, stawiającej na perspektywiczne myślenie, pozwala przedsiębiorstwu na rzeczywisty rozwój.
Problem legacy nie jest więc problemem samej technologii, braku pieniędzy na cyfrową transformację czy tego, że firma będzie musiała dostosować się do zmiany. Te rzeczy naprawdę są “do zrobienia”, jeśli tylko przedsiębiorstwo tego chce. Problem legacy to w głównej mierze problem odpowiedzialności i zamiatania niewygodnych tematów pod dywan. “Ja nie będę tym, co ryzykuje, skoro tylu przede mną też tego nie zrobiło…” — tak właśnie myśli sporo menedżerów.
Efekt? Władza się zmienia, ale problem pozostaje.
Chcesz wyjść z problemu legacy?
Napisz do nas. Kontakt do nas znajdziesz na: https://transparentdata.pl/
Mogą Cię zainteresować również:
