Modernizacja systemu legacy – od czego zacząć?

Mateusz Jerzyk | Rozwój oprogramowania | 16.03.2023

Zdarza się, że oprogramowanie lub technologia, która jest rozwijana przez bardzo długi czas, nie może – z różnych powodów – zostać zmieniona. Określa się ją wówczas jako „legacy system”. Niektóre organizacje latami używają takich systemów, inne w którymś momencie podejmują decyzję o modernizacji. Z tego artykułu dowiesz się, czym jest legacy system, jak może wpływać na twój biznes oraz w jaki sposób CIO powinien zaplanować jego modernizację, aby przyniosła realne korzyści.

● system legacy („system zastany”) to taki, którego dział IT nie jest w stanie szybko naprawić lub w miarę potrzeby rozbudować

● utrzymywanie systemu legacy może negatywnie wpływać na zespół programistyczny, relacje biznesowe oraz samą jakość rozwijanego produktu

Legacy system, czyli system zastany

We wstępie wspomniałem, że takie systemy pozostają niezmienione latami. Przyczyny mogą być różne: problemy projektowe, operacyjne, biznesowe lub też dotyczące samej kompatybilności projektu czy kwestii integracyjnych.

Legacy system, tzw. „system zastany”, często ma bardzo duży i długotrwały wpływ na sposób działania wielu komponentów w organizacji. Jest to spowodowane bardzo dużą ilością zależności, które potrafią blokować rozwój na wielu płaszczyznach. Organizacje mogą utrzymywać takie aplikacje, ponieważ działają „wystarczająco dobrze”, lub nie mają większego powodu, aby je zmienić. Często też zwyczajnie brakuje środków, aby taki system zastąpić nowoczesnym rozwiązaniem.

Decyzja o modernizacji i zastąpieniu systemu legacy nowszym rozwiązaniem powinna być podjęta z pełną świadomością potencjalnych zagrożeń i ze z góry założonym planem.

Typowe cechy systemów legacy

Po czym poznać, że mamy do czynienia z systemem legacy? Jest kilka czynników, które trzeba wziąć pod uwagę:

  • Wiek systemu – zwykle liczony w latach. Im starszy system, tym bardziej rośnie dług technologiczny, a wraz z nim mogą powstawać problemy na wielu płaszczyznach projektu.
  • Ograniczenie w rozwoju – gdy długość projektu jest liczona w latach to z każdym rokiem rozwój systemu legacy staje się coraz trudniejszy. W dodatku, jeśli organizacja nie prowadzi odpowiedniego spisu funkcjonalności projektu i dokumentacji, jest wysoce prawdopodobne, że wraz z rosnącą ilością kodu dany projekt będzie się stawał coraz trudniejszy do zrozumienia, a tym samym wzrośnie prawdopodobieństwo pojawienia się błędów.
  • Rotacja w zespole – rozwijanie systemu latami niesie ze sobą ryzyko rotacji w zespole. Zespół, który w niezmienionej formie przetrwał ze sobą lata pracy, jest naprawdę rzadkością, szczególnie na rynku IT. Dlatego, nawet jeśli zespół jest relatywnie mały, to prawdopodobnie na przestrzeni lat nad produktem pracowała spora liczba programistów. Taka rotacja stawia przed programistami konkretne wyzwania związane z rozwijaniem oprogramowania. Każdy programista ma przecież swój pomysł na wykonanie danej implementacji. Dlatego – zaznaczając, że istnieją oczywiście w projekcie i w każdej technologii odpowiednie szablony i wytyczne, do których programiści powinni się stosować – mimo wszystko na przestrzeni lat bardzo ciężko mieć pewność, że nowy kod dodany przez programistę będzie trzymał się zawsze takiego samego stylu jak u poprzednika.
  • Dług technologiczny i starsza technologia – świat IT nie czeka i codziennie się rozwija. Wraz z nim technologie. Legacy system, który ma swoje lata, z dnia na dzień staje się coraz bardziej odległy od aktualnych technologii, przez co jego komponenty mogą być przestarzałe, gorzej działać lub powodować braki w ważnych obszarach bezpieczeństwa.
  • Zniechęcająca technologia – starsza technologia jest mniej atrakcyjna dla programistów. Po części hamuje rozwój w zawodzie, dlatego może powodować problemy ze znalezieniem dodatkowej pary rąk do pracy w projekcie.

Dlaczego firmy nadal korzystają z systemów legacy?

Może zastanawiać, dlaczego pomimo powyższych minusów wiele firm nadal korzysta z systemów legacy. Najczęściej są to:

  • Ciągłość działania – przede wszystkim legacy system zapewnia ciągłość działania. Wykorzystanie starszej technologii, która nadal działa, często przysłania nam potrzebę stworzenia czegoś nowego.
  • Złożoność przedsięwzięcia – zastąpienie przestarzałej technologii w długo rozwijanym projekcie jest często ogromnym przedsięwzięciem, zarówno jeśli chodzi o kwestie biznesowe, projektowe, jak również finanse i zasoby ludzkie. Cytując popularne w świecie IT powiedzenie: „jeśli coś działa, lepiej nie ruszać”.
  • Koszty operacyjne – ważnym aspektem przemawiającym za dalszym wykorzystywaniem systemu legacy są też koszty operacyjne. Przejście z jednego rodzaju technologii na drugi może generować bardzo duże wydatki. Często kalkulacja finansowa pokazuje, że firmie bardziej opłaca się utrzymywać nadal starszą wersję aplikacji, aniżeli inwestować duże pieniądze w jej przepisywanie, migracje danych i w nową infrastrukturę całego projektu. Dlatego firmy bardziej skłonne są do inwestowania w zupełnie nowe projekty, niż do decydowania się na przepisywanie istniejących.

Wyzwania związane z modernizacją systemu legacy

Firma, która podejmie decyzję o modernizacji, z pewnością będzie się mierzyć z takimi wyzwaniami jak:

  • Kompleksowość – systemy pisane latami są bardzo rozbudowane oraz często występuje w nich wiele zależności. Wszystko to powoduje trudności w zrozumieniu takiego systemu, jak i zarządzaniu nim. Długość kodu to niejedyny czynnik przesądzający o skomplikowaniu produktu. Legacy system zwykle składa się z wielu biznesowych części, które trudno zrozumieć bez poświęcania im sporej ilości czasu.
  • Integracja i kompatybilność, tzn. „Integration Hell” – jednym z głównych problemów w otoczeniu programistycznym są integracje środowisk, systemów, aplikacji czy też ich komponentów. Rzadko kiedy proces integracji jest łatwy i bezproblemowy. Zamiast poświęcać relatywnie niewiele czasu, programiści są zmuszeni spędzać wiele godzin lub dni na poprawie tych rzeczy.
  • Migracja danych – istnieje duże prawdopodobieństwo, że podczas migracji danych ze starego systemu na nowy coś pójdzie nie tak. Migracja taka może być bardzo czasochłonna i należy się przygotować, planując wszystko jak najlepiej. W ten sposób można wyeliminować potencjalne ryzyko utraty danych.
  • Kwestie bezpieczeństwa – nieodpowiednie zabezpieczenie oprogramowania może być jedną z głównych przeszkód w modernizacji. Stare protokoły, sposoby autoryzacji i autentykacji mogą się znacząco różnić od nowszych standardów zabezpieczeń systemów i aplikacji.
  • Budżet – koszt modernizacji systemu legacy może być ogromny i należy mieć to na uwadze. Poza samymi wyzwaniami programistycznymi, gdzie początkiem wydatków jest zainwestowanie w dodatkowe osoby w zespole, a końcem zmiana środowiska programistycznego, może okazać się, że będą potrzebne dodatkowe fundusze. Na przykład na odpowiednie wyszkolenie pracowników z wykorzystaniem nowego systemu, wymianę sprzętu na nowy czy zmiany w kulturze pracy całej firmy (np. jeśli planujemy wdrożyć zwinne metody pracy czy kulturę DevOps).
  • Brak odpowiednich zasobów i wiedzy – zespoły decydujące się na zastąpienie swojego systemu legacy nowszym mogą mierzyć się z problemem braku zasobów, doświadczenia lub wiedzy w zespole. Inicjatywa modernizacji systemów czy też aplikacji musi być prowadzona przez odpowiednie osoby, z dużą wiedzą w krytycznych dla projektu obszarach biznesowych i kompetencjami, które pozwolą z sukcesem doprowadzić do zastąpienia aplikacji legacy nowszą technologią.

Korzyści wynikające z modernizacji systemu legacy

Firma może wiele zyskać dzięki modernizacji i zastąpieniu takiego długo rozwijanego systemu nowszą technologią. Korzyści, które mogą się pojawić:

  • Lepsza wydajność – jedną z głównych zauważalnych zalet powinna być zdecydowana poprawa wydajności. W porównaniu ze starszą wersją technologii zmodernizowane oprogramowanie może zarządzać zdecydowanie większym ruchem i procesami, dzięki czemu poprawia się User Experience i efektywność działania aplikacji.
  • Poprawiona skalowalność – rynek IT bardzo szybko się rozwija, dlatego zaspokojenie popytu na nowe funkcjonalności dla rozwijanych produktów jest bardzo ważną rzeczą i jednocześnie dużym wyzwaniem. Przedsięwzięcie zastąpienia systemu legacy nowszym rozwiązaniem, które jednocześnie będzie poprawnie zaprojektowane i oparte na dobrych praktykach rozwoju oprogramowania, powinno pomóc w zwinnym rozwijaniu produktu i zaspokajaniu pojawiających się potrzeb klienta.
  • Bezpieczeństwo – zauważalną zmianą będzie również poprawa bezpieczeństwa. Starsze systemy były projektowane przed wykryciem wielu obecnych zagrożeń z obszaru cybersecurity. Oznacza to, że są one bardziej podatne na tego typu zagrożenia. Nowsze aplikacje są rozwijane w taki sposób, że zagrożeniom przeciwdziała się już na etapie tworzenia aplikacji, np. z wykorzystaniem DevSecOps (takie podejście np. cechuje projekty cloud native). Migracja z systemu legacy na nowsze sprawdzone wcześniej technologie może dać gwarancję, że większość wykrytych wcześniej zagrożeń jest pokryta odpowiednimi poprawkami zwiększającymi bezpieczeństwo. Dodatkowe wydatki na bezpieczeństwo rozwijanego produktu również mogą zostać zniwelowane. Poprawnie zaimplementowane najnowsze technologie zmniejszają ryzyko kradzieży danych, zhakowania systemu i wyrządzenia większych szkód.

Zanim zdecydujesz się na modernizację

Modernizacja systemu legacy jest dużym wyzwaniem, ale jednocześnie może okazać się bardzo korzystna dla produktu. Przed rozpoczęciem modernizacji warto usiąść wspólnie z zespołem doświadczonych pracowników i omówić wszystkie istotne aspekty takiego przedsięwzięcia. Do konsultacji warto zaprosić:

  • architekta, który nakreśli nową wizję produktu,
  • analityka finansowego, który przedstawi konkretne liczby przemawiające za tym, że firmie jednak opłaci się zmodernizować system, którego wolałaby „nie ruszać, póki działa”,
  • konsultantów Business Intelligence, którzy podpowiedzą, jak „wyjść z Excela” i zacząć korzystać z nowoczesnych systemów bazodanowych i narzędzi analizy danych,
  • doświadczonych programistów, którzy doradzą w kontekście najnowszych technologii i kompetencji,
  • project managera, który będzie trzymał rękę na pulsie przez cały czas trwania modernizacji.

Kiedy zapadnie decyzja o zastąpieniu starszego systemu, należy się upewnić, że plan działania jest dla wszystkich jasny i czytelny, każdy zna swoje zadania, cele są wyznaczone i wiadomo, jakie potencjalne korzyści mogą wynikać z takiej modernizacji dla produktu i firmy.

Kiedy powinno się rozważyć modernizację?

IT jest jednym z najszybciej rozwijających się rynków na świecie. Według prognoz Gartnera w 2023 r. wydatki na IT w skali globalnej wyniosą 4,6 bilionów dolarów. To wzrost o 5% w porównaniu z poprzednim rokiem.

Pisanie jak najlepszego i najnowszego oprogramowania odgrywa zatem kluczową rolę, jeśli zależy nam na tworzeniu produktów jak najlepszej jakości. Wraz z szybkim rozwojem technologii rośnie prawdopodobieństwo, że rozwijane produkty wewnątrzfirmowe szybko mogą stać się definicją systemu legacy. Może to wpływać negatywnie na rozwój firmy, jak i całego biznesu.

Dlatego warto się dowiedzieć, kiedy tak naprawdę powinniśmy myśleć nad stworzeniem czegoś nowego, systemu czy aplikacji, a co za tym idzie – zająć się migracją danych i zastąpieniem starszego oprogramowania nowym. Oto kilka kluczowych aspektów, na które warto zwrócić uwagę:

  1. Produkt ma ponad 5 lat
    Jednym z najczęstszych sygnałów potrzeby modernizacji jest przestarzałe oprogramowanie. Przyjęło się, że jeśli produkt ma za sobą ponad 5 lat pracy, to prawdopodobnie zawiera w sobie już przestarzały kod. Prowadzi to na przykład do braku wsparcia różnych wtyczek czy zależności, gdzie komponenty dla starszych wersji nie są już wspierane i rozwijane. W następstwie pojawiają się kolejne problemy z wydajnością oprogramowania, bezpieczeństwem i integracjami.
  2. Brak skalowalności
    Warto rozważyć modernizację systemu, jeśli zmieniające się wymagania klienta przekładają się na coraz większą liczbę problemów z oprogramowaniem. Stare oprogramowanie, rozwijane latami, prawdopodobnie nie ma już odpowiedniej liczby atrybutów, aby udźwignąć rosnące potrzeby użytkowników i pozwolić na szybki, a przede wszystkim odpowiedni rozwój produktu.
  3. Rosnące koszty
    Jeśli okaże się, że utrzymywanie starszej technologii staje się coraz bardziej kosztowne, prawdopodobnie nadszedł czas, aby rozważyć jej modernizację. Starsze oprogramowanie może wymagać bardziej kosztownego sprzętu niż nowoczesne rozwiązania. W dodatku poprawne działanie starszych systemów często wymaga interwencji specjalistów, a to może generować dodatkowe koszty i być bardzo czasochłonne.
  4. Brak wsparcia
    Jak już wcześniej wspomniałem, przestarzały produkt oznacza ryzyko braku wsparcia różnych wykorzystywanych elementów oprogramowania. Autorzy rozwijają swoje wtyczki do pewnego momentu, zapewniając wsparcie dla określonej wersji oprogramowania. Brak takiego wsparcia prowadzi między innymi do luk bezpieczeństwa. Znacznie wydłuża się także czas tworzenia nowych funkcjonalności przez programistów.
  5. Blokada rozwoju
    Każdy stara się maksymalnie wykorzystać potencjał posiadanego produktu. Kiedy jednak dotychczasowe oprogramowanie uniemożliwia firmie osiągnięcie założonych celów, jest to kolejny sygnał, aby rozważyć temat modernizacji. Dostosowanie się do zmieniających się wymogów klienta i warunków biznesowych może być bardzo utrudnione przez to, że produkt jest definiowany jako legacy system. Może to prowadzić do blokady rozwoju nie tylko produktu, lecz nawet firmy.

Strategie modernizacji systemów legacy

Istnieją sprawdzone praktyki, które pozwalają zachować przydatność i funkcjonalność systemów legacy. Najbardziej popularne z nich to:

Replatforming i rehosting

Proces przenoszenia systemów legacy na nowsze środowisko. Obejmuje przebudowę aplikacji lub umieszczenie jej na nowym serwerze. Zmiana taka może poprawić wydajność produktu i obniżyć koszt konserwacji.

Refactoring

Refactoring polega na zagłębieniu się w architekturę produktu i próbie zastąpienia pewnych jego komponentów innym, zazwyczaj lepszym rozwiązaniem ze strony programistycznej i biznesowej. Obejmuje to na przykład restrukturyzację bazy danych, optymalizację wydajności na wielu płaszczyznach aplikacji i poprawę bezpieczeństwa. Dobry refactoring wykonany w miejscach, które wymagały przepisania, jest prawdziwą ulgą dla developerów, ponieważ w przyszłości poprawianie błędów lub dodawanie nowych funkcjonalności dla poszczególnych części produktu, które zostały poddane takiej refaktoryzacji, może być zdecydowanie prostsze i mniej czasochłonne.

Reengineering

Najbardziej czasochłonna i kosztowna procedura. Oznacza rozpoczęcie wszystkiego od zera z wykorzystaniem współczesnych technologii w celu odtworzenia systemu i jego zastąpienia. Celem decyzji o reengineeringu powinna być między innymi poprawa architektury produktu, wydajności, bezpieczeństwa, jak i zmniejszenie kosztów utrzymania aplikacji.

Service Oriented Architecture (SOA)

Tworzenie oprogramowania przy użyciu podejścia SOA obejmuje segmentację dużych części produktu na mniejsze, niezależne usługi, do których można uzyskać dostęp za pośrednictwem sieci. Dzięki dzieleniu kodu na mniejsze komponenty i usługi łatwiej go rozwijać i rozwiązywać ewentualne błędy.

Application Program Interface (API)

Częściowym oraz pomocnym rozwiązaniem jest zintegrowanie systemu legacy z API wystawionymi przez inne aplikacje. Taka integracja może przyczynić się do polepszenia skalowalności i wydajności oprogramowania.

Chmura

Rozwiązanie chmurowe może okazać się pozytywnym impulsem i zwiększyć możliwości integracyjne, testowe, jak również poprawić jakość obsługi produktu na wielu płaszczyznach. Chmura poprawia też skalowalność i obniża koszty eksploatacji. Pamiętajmy, że wbrew obecnym mitom koszty rozwiązania chmurowego wcale nie muszą być wysokie, a kluczem jest poprawna implementacja (np. dzięki wykorzystaniu procesów DevOps). Jeżeli zależy ci na nowoczesnym i niezawodnym rozwiązaniu, przeniesienie oprogramowania do chmury może okazać się jednym z lepszych pomysłów.

Podsumowanie

Modernizacja systemu legacy jest z pewnością bardzo trudnym przedsięwzięciem. Niełatwo zrezygnować z czegoś, co było rozwijane latami i linijki programu można liczyć w tysiącach. Oprócz suchych liczb pojawia się też kwestia skomplikowania biznesowego, a zatem wszystkich procesów i kosztów, jakie trzeba wziąć pod uwagę.

Należy pamiętać, że decyzja o zastąpieniu systemu legacy lub nawet częściowej modernizacji może okazać się bardzo dobrą decyzją, ale jednocześnie nieść ze sobą wiele ukrytych zagrożeń. Jeżeli masz jakiekolwiek wątpliwości, warto skorzystać ze wsparcia doświadczonych specjalistów – poprawna kalkulacja na wielu płaszczyznach projektu jest kluczowa, aby zawczasu wyeliminować wszelkie problemy i zagrożenia.

FAQ

Przykłady systemów legacy w organizacjach

● Oprogramowanie Oracle, IBM i Microsoft świadczących usługi w zakresie IT były na topie rankingu wykonanego przez firmę Flexera w zakresie posiadania produktów, które definiuje się jako legacy system
● Infrastruktura chmury i przestarzałe oprogramowanie w Walmart
● Projekt NASA Orion Spacecraft

Jakie są rodzaje systemów legacy?

Systemy Mainframe – duże scentralizowane komputery zwane „Mainframe” były używane w latach 60. i 70. XX wieku. Wiele dużych organizacji i jednostek rządowych nadal z nich korzysta
Client-Server system – w porównaniu do systemów Mainframe są one bardziej skalowalne i elastyczne. Składają się z programu działającego na serwerze oraz aplikacji klienckiej działającej na urządzeniu użytkownika
Aplikacje desktopowe – tradycyjne aplikacje działające na komputerze użytkownika. Często są budowane na bazie starszych języków programowania, takich jak C++ lub Visual Basic
Aplikacje webowe – działają za pomocą przeglądarki internetowej. ASP i JSP są przykładami technologii które są wykorzystywane do dziś w takich aplikacjach

Jakie są przykłady platform legacy?

IBM mainframes – najbardziej popularna platforma typu legacy
Sun Solaris – na topie w użytkowaniu w latach 90. dla serwerów WWW i innych aplikacji sieciowych
Windows XP – niewspierany już system firmy Microsoft, jeden z najbardziej popularnych systemów komputerowych w historii, jakie powstały
AS/400 – używana w sektorach IT takich jak finanse, służba zdrowia i produkcja, bardzo ceniona platforma w latach 90.