Właściwie zaplanowana modernizacja systemów legacy przyspiesza osiągnięcie korzyści biznesowych

Z Grzegorzem Popielnickim, kierującym Business Unit Bankowość i Marcinem Kirilenko, odpowiedzialnym za Business Unit Ubezpieczenia i Flowee Product Ownerem w Finture rozmawiam o: problematyce długu technologicznego, wyzwaniach towarzyszących modernizacji systemów legacy, doświadczeniach Finture w realizacji takich projektów, dobrych praktykach i sposobach na sprawną eliminację długu technologicznego.

Jakie są dziś główne wyzwania związane z utrzymaniem środowisk aplikacyjnych i jakie znaczenie ma tu kwestia długu technologicznego?

Grzegorz Popielnicki (G.P.): Pierwszym problemem jest złożoność ekosystemów technologicznych. Widać to szczególnie w instytucjach finansowych, gdzie systemy budowane lata temu były obudowywane kolejnymi rozwiązaniami satelitarnymi. W efekcie powstały środowiska przypominające technologiczne spaghetti – zmiana jednego elementu takiego układu bywa ryzykowna, bo często brakuje dokumentacji, albo system był tworzony przez zespół, którego w organizacji już nie ma.

Do tego dochodzą przestarzała architektura i technologie, które nie odpowiadają obecnym standardom. W jednym z systemów, z którymi pracujemy, ponad 80% logiki biznesowej zostało ukryte w procedurach składowanych na poziomie bazy danych. Taki system można utrzymywać, ale każda zmiana jest czasochłonna i obarczona wysokim ryzykiem.

Marcin Kirilenko (M.K.): Z mojego punktu widzenia kluczowe są 3 cechy rozwiązań legacy. Po pierwsze, jest to niska elastyczność w dostosowaniu do zmian regulacyjnych. W sektorach regulowanych bardzo szybko staje się to blokadą dla rozwoju. Po drugie, rosnące koszty utrzymania starych technologii, które choć nie gwarantują możliwości rozwoju, to zapewnienie ich sprawności wymaga ciągłych nakładów pracy. Trzecia kwestia to bezpieczeństwo. Wraz ze starzeniem się technologii rośnie liczba podatności. Już samo to powinno być silnym impulsem do podjęcia decyzji o modernizacji rozwiązań legacy.

Z czego wynika doświadczenie zespołu Finture w projektach modernizacji środowisk typu legacy?

M.K.: To konsekwencja naszego zaangażowania w realizację projektów aplikacyjnych dla sektora finansowego, gdzie wykorzystanie systemów obarczonych istotnym długiem technologicznym jest niemal powszechne. Działamy z klientami w trybie ciągłym. Poznajemy ich środowiska. Zdobywamy zaufanie. Często stajemy się dla nich naturalnym partnerem do rozmowy o modernizacji. Choć później oczywiście bierzemy udział w normalnych procesach zakupowych i przetargach.

Na przestrzeni lat braliśmy udział w wielu projektach tego typu, spotkaliśmy się z różnymi rozwiązaniami oraz wyzwaniami i teraz korzystamy z tych doświadczeń, wspierając klientów również w branżach innych niż sektor finansowy.

W jakich branżach problem legacy jest dziś najbardziej widoczny?

M.K.: Wyzwania związane z bagażem technologicznym są w naturalny sposób dostrzegalne przede wszystkim w tych sektorach, które od wielu lat intensywnie korzysta ją z IT. To spółki państwowe, energetyka, telekomunikacja, wspomniany sektor finansowy, a także administracja publiczna. Są to, w pewnym sensie, najbardziej naturalne obszary występowania systemów legacy. W tych właśnie branżach działają systemy budowane dawno temu i wielokrotnie rozbudowywane.

Z kolei z perspektywy naszej oferty naturalnym kierunkiem pozostaje rynek finansowy. Mamy też doświadczenia w innych branżach, zwłaszcza w telekomunikacji. Nie zmienia to jednak faktu, że podejście do modernizacji systemów legacy, a także nasza oferta, muszą pozostać uniwersalne. Ścieżka modernizacji nie jest przywiązana do specyficznych wymogów danej branży, tylko potrzeb i wyzwań działów IT mierzących się z koniecznością utrzymywania i rozwoju złożonych systemów biznesowych.

G.P.: Warto dodać, że problem systemów legacy nie dotyczy wyłącznie branż z długą historią użytkowania rozwiązań IT. Zdarza się, że nawet stosunkowo młode organizacje wdrożyły aplikacje, które już w chwili wyboru były blisko technologicznej granicy opłacalności. Innym scenariuszem jest sytuacja, w której liczyło się szybkie dostarczenie rozwiązania, a nie wybranie najlepszej metody. Skutkowało to zbudowaniem długu technologicznego już na etapie projektu wdrożeniowego. Nawet młody system może więc mieć cechy legacy, np. problemy wydajnościowe.

W jaki sposób należy zdefiniować podejście „legacy”?

G.P.: Postrzeganie danego rozwiązania jako przestarzałego zależy głównie od kontekstu organizacji. W praktyce jednak system legacy to rozwiązanie, które w różny sposób zaczyna daną firmę uwierać. Jeżeli system działa w starej architekturze, ale spełnia potrzeby biznesu i mieści się w ramach wyznaczonych przez wymagania regulacyjne, to nie musi być postrzegany jako balast operacyjny i bariera dla rozwoju.

System staje się jednak legacy, jeśli ogranicza szybkość reagowania organizacji na potrzeby rynku, wydłuża Time to Market, utrudnia rozwój, integrację z nowymi rozwiązaniami, uniemożliwia sprawne wdrożenie lub kompleksowe przetestowanie zmian w środowisku aplikacyjnym, albo brakuje dokumentacji potrzebnej do realizacji któregokolwiek z powyższych działań.

M.K.: Kwestię braków w dokumentacji technicznej dobrze opisuje pojęcie „wiedzy plemiennej”. System legacy często jest uzależniony od wiedzy ludzi, którzy go kiedyś budowali albo utrzymywali. W momencie, gdy odchodzą, często znika też wiedza o systemie. Wówczas trudno myśleć nie tylko o jego rozwoju, lecz także o bezpiecznym testowaniu zmian.

Jakie technologie są dziś najczęściej zaliczane do kategorii legacy?

G.P.: Myślę, że jest to również kwestia zależna od konkretnej organizacji, jej środowiska aplikacyjnego oraz posiadanych w zespole kompetencji. Wiadomo jednak, że im starsza technologia, tym większe ryzyko. Przy kładowo, dla jednej z firm realizowaliśmy projekt zmiany systemu opartego na bazie Adabas i zbudowanego w języku Natural. Dziś jest to technologia trudna do rozwijania, a dostępność specjalistów na rynku jest niezwykle ograniczona. Oczywiście do tego dochodzą także stare wersje Javy czy innych technologii, które formalnie jeszcze działają, ale mają małe możliwości rozwoju i integracji.

Jakiego rodzaju problemy związane z istniejącymi rozwiązaniami legacy są najbardziej dotkliwe?

G.P.: Największym problemem jest brak zdolności do sprawnego monetyzowania zmian biznesowych. Sam brak specjalistów od starszych technologii to tylko część obrazu. Dużo ważniejsze jest to, że organizacja z czasem dochodzi do punktu, w którym nie potrafi już sensownie rozwijać systemu, bo kompetencje są niszowe, ryzyko zmian rośnie, a każde działanie wymaga ogromnego zaplecza i ostrożności.

M.K.: System staje się legacy również wtedy, gdy każda zmiana z nim związana trwa zbyt długo, a więc dłużej niż jest to akceptowalne dla użytkowników biznesowych. Powodów może być wiele. Jednym z nich są niewątpliwie długie i kosztowne, ale przecież niezbędne testy, które angażują duże zespoły po stronie IT oraz biznesu.

Poza tym, w przypadku systemów obarczonych długiem technologicznym wyzwaniem staje się już samo zaplanowanie okna serwisowego. Jest to szczególnie widoczne w przypadku systemów zbudowanych w architekturze monolitycznej, gdzie każda zmiana może przynieść nie oczekiwane skutki. W takiej sytuacji firma nie tylko ponosi koszt utrzymania systemu, ale też traci szanse rynkowe, bo nie jest w stanie odpowiednio szybko reagować na zmiany. Nagle okazuje się, że koszt legacy to zarówno koszt utrzymania systemu liczony jako ten element środowiska IT, jak i utracone przychody.

Jeżeli zatem inwestycję mającą na celu neutralizację długu technologicznego można rozłożyć na lata, to ostatecznie jej wpływ na wynik w danym roku może być stosunkowo mniejszy, niż koszt dalszego trwania przy starym rozwiązaniu. To doskonałe uzasadnienie finansowe dla projektów modernizacji środowisk legacy.

Na czym polega specyfika takich projektów?

G.P.: Projekty zmierzające do eliminacji długu techno logicznego często wiążą się także ze zmianą dostawcy. Zdarza się, że najpierw przejmujemy utrzymanie kluczowego procesu, zapewniamy mu ciągłość działania, a dopiero potem przechodzimy do nowej technologii i nowego workflow. Dużym wyzwaniem jest nie tylko technologia, ale też wydobycie realnych oczekiwań biznesu i ustalenie momentu, po którym wymagania nie mogą już być stale zmieniane, bo projekt nigdy nie wyjdzie z fazy analitycznej.

Bywa również tak, że przychodzimy do organizacji, która wie, że konkretne rozwiązanie legacy jest dla niej obciążeniem, ale nie rozumie skali złożoności wykrytego problemu. Z zewnątrz jakaś zmiana może wyglądać na prostą, a w systemie legacy ujawnia ukryte zależności, których nikt nie przewidział. Do realizacji projektów podchodzimy w otwarty sposób i staramy się te wyzwania precyzyjnie tłumaczyć. Dlatego tak istotne jest dobre przygotowanie prac i przeprowadzenie analizy przedwdrożeniowej. Błędy popełnione na tym etapie potrafią wrócić z dużą siłą podczas prac deweloperskich.

W jaki sposób można modernizować systemy legacy, nie wymieniając ich w całości?

M.K.: Jedną z bardziej sensownych strategii modernizacji systemów legacy jest ich dekompozycja, rozbicie monolitycznej struktury oprogramowania i stopniowe dodawanie nowych domen biznesowych odseparowanych od rdzenia, ale połączonych z nim przez API i opartych na architekturze mikroserwisowej, ułatwiającej wprowadzanie kolejnych zmian.

W wielu przypadkach to właśnie budowa warstwy integracyjnej oraz interfejsów API staje się pierwszym warunkiem sensownej modernizacji. Bez niej trudno obudowywać system legacy nowymi modułami i stopniowo przejmować jego funkcje.

G.P.: Często wykorzystujemy model refaktoryzacji oprogramowania w kierunku wspomnianych mikroserwisów albo z użyciem wzorca Strangler Fig Pattern. Zakłada on stopniowe obudowywanie starego systemu nowymi funkcjami aż do momentu, w którym centralna część pierwotnego rozwiązania przestaje być potrzebna.

Czy firmy częściej wybierają stopniową przebudowę systemów legacy?

G.P.: Tak. Powód jest prosty: większość systemów legacy została na przestrzeni wielu lat bardzo mocno dostosowana do potrzeb i specyfiki działania konkretnej organizacji. W rezultacie, na pierwszy rzut oka zakup nowego rozwiązania może wydawać się tańszy, ale później pojawiają się kwestie dotyczące migracji danych, dostosowania do wymagań regulacyjnych czy odtworzenia w nowym systemie obsługi niestandardowych procesów biznesowych, co nie jest trywialne i winduje koszty.

Co więcej, niektórych ścieżek procesowych zwyczajnie nie da się zaimplementować na etapie podmiany dotychczasowego oprogramowania nowym, gotowym systemem. Potrzebne staje się tworzenie dodatkowych rozwiązań, pozwalających na obejście takiego problemu. Czasem więc lepszą drogą jest przemyślana przebudowa działającego systemu.

Kluczowe znaczenie na etapie wyboru ścieżki modernizacji systemów legacy ma rzetelny audyt – analiza, która pozwoli zrozumieć, z jakim rozwiązaniem mamy naprawdę do czynienia. Taki audyt nierzadko pokazuje, że system, który pierwotnie był gotowym, standardowym produktem, został tak rozbudowywany, że wieloetapowe podejście do modernizacji staje się po prostu wyborem bezpieczniejszym i mniej ryzykownym, jeśli chodzi o ciągłość działania.

M.K.: Zanim jednak zejdziemy na poziom kodu i architektury, trzeba rozpoznać krytyczne biznesowo procesy obsługiwane w ramach modernizowanego systemu. Należy precyzyjnie zidentyfikować procesy krytyczne biznesowo: które funkcje i przepływy są naprawdę istotne, jak często są wykorzystywane, jakie wolumeny obsługują oraz jakie byłyby konsekwencje ich niedostępności. Dopiero takie spojrzenie pozwala ocenić, gdzie modernizacja lub mi gracja przyniesie największą wartość biznesową i gdzie ryzyko jest najwyższe. W praktyce to właśnie ta wczesna analiza pozwala właściwie ustawić priorytety techniczne, uniknąć nadmiarowych prac i skupić inwestycje tam, gdzie realnie wspierają strategię biznesową.

Czy tego typu informacji nie można uzyskać np. z dokumentacji systemu?

G.P.: Problem w tym, że organizacja często nie dysponuje taką dokumentacją, bądź jest ona mocno niekompletna. W praktyce jest to jeden z głównych problemów towarzyszących projektom modernizacji oprogramowania. W sytuacji, gdy nikt do końca nie wie jak działa system kluczowy z punktu widzenia biznesu, ryzyko niepowodzenia radykalnie rośnie.

Dlatego, podczas realizacji tego typu projektów korzystamy z autorskiego narzędzia, które analizuje kod modernizowanego oprogramowania z użyciem AI i pomaga odtworzyć dokumentację techniczną. System s*doc pozwala zrozumieć działanie oprogramowania legacy, ocenić jak obsługiwany jest dany proces i z jakich funkcji korzysta, wskazać punkty krytyczne, a dopiero potem skonfrontować kwestie techniczne z oczekiwaniami biznesowymi klienta.

Na podstawie takiej analizy technicznej często jesteśmy w stanie wskazać biznesowe skutki problemów w działaniu systemu. Następnie nasze obserwacje zderzamy z do świadczeniami użytkowników biznesowych podczas warsztatów. Często są one zbieżne i pomagają zbudować plan prac nad poszczególnymi obszarami działania systemu.

W jaki sposób prowadzone są prace deweloperskie podczas tego typu projektów?

G.P.: Podstawą prac deweloperskich jest uzgodniony z klientem harmonogram. Do każdego projektu staramy się podchodzić w sposób maksymalnie zwinny i efektywny. Nie ukrywamy zatem, że na etapie prac wdrożeniowych wykorzystujemy kolejne, autorskie, oparte na sztucznej inteligencji narzędzie.

AI pomaga nam w szybkim tworzeniu kodu. Nie jest jednak tak, że automatycznie wygenerowany kod jest wstrzykiwany do działającego produkcyjnie systemu klienta. To iteracyjny proces angażujący zespół naszych specjalistów. Na koniec to człowiek bierze odpowiedzialność za zbudowane rozwiązanie. W zespole deweloperskim mamy architektów i senior developerów, którzy nadzorują cały proces, na bieżąco poprawiają kod, ale też odpowiadają za przygotowanie budowanego rozwiązania do testów.

Jak długo mogą trwać projekty modernizacji systemów legacy?

G.P.: Wszystko zależy m.in. od charakteru modernizowanego oprogramowania, jego złożoności, wykorzystanej technologii, dostępności i jakości dokumentacji, ale też obranej ścieżki modernizacji czy zaangażowania kluczowych użytkowników. Taki projekt może trwać nawet 2 lata. Choć ta informacja niewiele znaczy bez kontekstu danej organizacji. Sam proces wyboru kierunku modernizacji, podpisania umów, zbudowania zespołów i rozpoczęcia iteracyjnej analizy zajmuje czas, nawet gdy projekt prowadzony jest zwinnie.

M.K.: Moim zdaniem kluczowe nie jest to, ile trwa projekt, ale czy strategia modernizacji została dobrze za projektowana. Dobrze, a więc w sposób ukierunkowany na jak najszybsze dostarczenie wartości biznesowej, np. wyeliminowanie najbardziej odczuwalnych opóźnień w obsłudze istotnych procesów.

Prace w modelu dekompozycji można prowadzić w sposób zakładający jednoczesne wykorzystanie nowych modułów dla uruchamianych linii produktowych równolegle z dotychczasowymi funkcjami na potrzeby istniejących wcześniej produktów. To wszystko jest kwestią strategii.

Jeżeli więc modernizacja jest właściwie zaplanowana i rozłożona na moduły, wówczas użytkownicy biznesowi szybciej odczuwają pozytywne skutki przebudowy oprogramowania, kolejne usprawnienia są wdrażane iteracyjnie, zatem czas przestaje być głównym problemem.

Tylko czy zwinne, modułowe podejście da się zastosować zawsze i w odniesieniu do każdego systemu legacy?

M.K.: Absolutnie najważniejsze jest to, żeby nie skupiać się na kwestiach technologicznych, tylko dobrze zrozumieć potrzebę biznesu. Jeżeli ten cel zostanie właściwie rozpoznany, można zaproponować podejście lepsze pod względem czasu wdrożenia, efektywności, kosztów i szybkości osiągania wartości. Może się też okazać, że na tej podstawie doradzimy przyjęcie innego rozwiązania, niż zakładały pierwotne plany klienta. Dobrze uzasadniona propozycja innego sposobu rozwiązania problemów wynikających z wykorzystania przestarzałych technologicznie systemów często skutkuje lepszymi efektami biznesowymi.