Modernizacja oprogramowania – kiedy staje się koniecznością

W dobie rozwijającej się z niespotykaną prędkością technologii coraz częściej, mówiąc o usprawnieniu oprogramowania, używa się słowa ‘modernizacja’.  Często również, staje się ono synonimem dla takich pojęć jak ‘migracja’ czy ‘refaktoryzacja’, które opisują jednak zgoła inne procesy, co może prowadzić do nieporozumień w komunikacji z klientem, a nawet, między współpracownikami. 

Zatem co faktycznie znaczą te zwroty? Jak wygląda ich przebieg oraz kiedy oprogramowanie staje się przestarzałe i należy poważnie rozważyć jego renowację? Ten artykuł odpowie na powyższe pytania, wyjaśniając popularne strategie, prezentując dostępne rozwiązania, a także przedstawiając pełen przebieg procesu modernizacji oprogramowania. 

Migracja, refaktoryzacja i modernizacja 

To trzy różne rodzaje rozwiązań problemów systemów informatycznych, które najlepiej zrozumieć poprzez konkretne scenariusze: 

Firma X sprzedająca odzież sportową posiada sklep internetowy, gdzie klienci przeglądają produkty i składają zamówienia. Witryna jest estetyczna i nowoczesna, a architektura systemu skalowalna i spełniająca wymagania biznesowe. Firma utrzymuje aplikację na lokalnej infrastrukturze, która na co dzień generuje koszty nieproporcjonalnie większe do aktywności na stronie, natomiast w trakcie wzmożonego ruchu, na początku sezonu letniego lub zimowego, jej wydajność drastycznie spada. W tym wypadku problemu nie stanowi aplikacja, tylko ograniczenia sprzętowe oraz brak elastyczności infrastruktury. W takim wypadku, skutecznym i rekomendowanym rozwiązaniem jest MIGRACJA, czyli proces przeniesienia systemu do nowocześniejszego, bardziej skalowalnego środowiska lub infrastruktury – na przykład chmury. Brak konieczności aktualizacji samego oprogramowania pozwoli niskim kosztem poprawić elastyczność i dostępność systemu oraz zoptymalizować koszty jego utrzymania. 

Bank Y posiada system, który przez lata służył jego pracownikom do rejestrowania płatności oraz wykonywania i nadzorowania operacji finansowych. Oprogramowanie działa płynnie a infrastruktura wykazuje się stabilną wydajnością oraz przemyślanymi zabezpieczeniami, jednak od jakiegoś czasu wprowadzanie zmian i dodawanie nowych funkcjonalności powoduje wiele błędów i zajmuje dużo więcej czasu niż kiedyś. Dokładniejsza analiza wykazuje, że kod jest przestarzały, ma liczne duplikacje i niespójne zależności oraz jest trudny w testowaniu. Ten przypadek pokazuje potrzebę REFAKTORYZACJI, czyli uporządkowania, optymalizacji i ulepszenia kodu źródłowego aplikacji bez zmiany logiki biznesowej ani jego funkcji. Efektem takiego procesu, będzie skalowalne oprogramowanie, którego ekspansywność nie będzie hamowana przestarzałym lub niskiej jakości kodem. 

Firma logistyczna Z korzysta z wieloletniego systemu stworzonego w oparciu o monolityczną architekturę. Aplikacja początkowo służyła głównie do zarządzania magazynem, ale wraz z poszerzaniem funkcjonalności o zarządzanie flotą, obsługę zamówień i inne dziedziny działalności, wydajność aplikacji i łatwość jej utrzymania wyraźnie spadła. Obecnie, rozwijanie systemu i integrowanie go z zewnętrznymi serwisami jest bardzo ograniczone. Dodatkowo, aplikacja nadal korzysta z technologii, które nie są już oficjalnie wspierane i nie otrzymują regularnych aktualizacji. Jest to przypadek, w którym można zaobserwować kilka problemów różnej natury, na które nie ma jednego, prostego Panaceum. MODERNIZACJA, oznacza proces wdrażania różnych rozwiązań prowadzących do unowocześnienia, ulepszenia i rozbudowy systemu, a także zwiększenie jego wydajności, bezpieczeństwa i funkcjonalności bez konieczności tworzenia go od nowa. Modernizacja może obejmować migrację na inne środowisko, refaktoryzację kodu, zmianę technologii oraz dostosowanie architektury do potrzeb biznesu. 

Wszystkie te procesy prowadzą do zwiększenia wydajności i bezpieczeństwa systemu oraz eliminowania barier i przygotowywania oprogramowania na przyszłe modyfikacje, ale różni je zakres działania i poziom ingerencji w jego strukturę. Koszt takiego przedsięwzięcia również różni się od obranej strategii, której odpowiednie dobranie zależy przede wszystkim od potrzeb biznesu. 

Strategie modernizacji systemu 

Przed podjęciem działania, należy wykonać dokładną analizę obecnego systemu – tzw. ‘legacy’, czyli oprogramowania, które stanowi ważną rolę w funkcjonowaniu firmy, ale staje się coraz trudniejsze w utrzymaniu, rozwijaniu i integracji z innymi narzędziami. Precyzyjne zdefiniowane potrzeb pozwoli obrać strategię najbardziej skuteczną dla indywidualnego przypadku oprogramowania. 

Model ‘7R Strategies’ opisuje najpopularniejsze strategie działania w przypadku modernizacji systemu: 

1. Retain (zachowaj) 

Kiedy system, nie będąc krytycznym elementem dla zaplecza biznesowego firmy, mimo upływu lat jest wystarczający, lub też budżet aktualnie nie pozwala na obranie stosownej dla niego strategii modernizacji, często podejmuje się decyzję o zachowaniu systemu w niezmienionej formie. Należy pamiętać, że nie jest to rozsądne rozwiązanie długoterminowe, ponieważ wraz z upływem czasu wiąże się z nim spadek wydajności i bezpieczeństwa oprogramowania oraz jego narastający dług technologiczny. Te konsekwencje skutkują nie tylko starzeniem się systemu, ale również nieoptymalnymi kosztami, które po określonym czasie mogą przewyższyć koszt modernizacji. 

2. Rehost (zmień hosting) 

Strategia znana również jako ‘lift-and-shift’ (podnieś i przełóż), jest wygodna i mało inwazyjna dla samego oprogramowania. Polega na przeniesieniu systemu do zewnętrznej infrastruktury (np. Chmury), gdzie jest on hostowany, konfigurowany i utrzymywany. Jej efektem jest zmniejszenie kosztów działania i konserwacji aplikacji oraz wygodniejsze zarządzanie jej zasobami. Jest to podstawowy przykład migracji – zmiany środowiska działania bez dokonywania zmian w aplikacji. 

3. Replatform (przeplatformuj) 

To rozwiązanie także będące odmianą migracji systemu, zwane również ‘lift-and-tinker’ (podnieś i popraw). Oprócz zmiany środowiska dodatkowo obejmuje ono drobne zmiany funkcjonalności systemu, przede wszystkim dopasowując go pod platformę docelową. Zmiany nie dotykają logiki biznesowej, za to poprawiają możliwość współpracy oprogramowania z zewnętrznymi narzędziami, a czasem są niezbędne do korzystania z nich. 

4. Refactor (refaktoryzuj) 

Ten plan nie skupia się na infrastrukturze tylko samym oprogramowaniu i jego działaniu. Jego dokładne znaczenie i obszary działania są różnie interpretowane a implementacja obejmuje szerokie spektrum zmian, jednak oznacza on przede wszystkim optymalizację i poprawę jakości kodu. Na refaktoryzację może składać się modyfikacja aplikacji podzielona na małe, łatwo testowalne segmenty, ale też może obejmować przekształcenie całej architektury aplikacji, jej warstwy lub poszczególnego modułu. W ramach refaktoryzacji może także dojść do zmiany technologii lub poprawienia logiki biznesowej, w momencie, kiedy te stanowią przeszkodę dla dalszego rozwoju systemu. 

5. Rebuild (przebuduj) 

To pojęcie znaczy całkowitą przebudowę aplikacji od zera, odtwarzając charakter biznesowy i spełniając jej wymagania względem poprzedniego systemu. Stosuje się to podejście w przypadkach, kiedy planowana aktualizacja obejmuje większą część systemu i koszty oraz nakład czasowy wykonania przewyższają stworzenie całego projektu od nowa. Jest to szczególnie rekomendowane, kiedy kluczowa technologia jest przestarzała lub nieodpowiednio dobrana, a także kiedy system został źle zaprojektowany od podstaw. 

6. Replace (wymień) 

Jest to wymiana własnego systemu na gotowy system informatyczny służący do zarządzania obszarami działalności firmy, na przykład ERP (Enterprise Resource Planning). Wiąże się to z porzuceniem personalizowanej aplikacji na rzecz zewnętrznego, bardziej uniwersalnego oprogramowania odpowiadającego funkcjonalnością i zaspokajając jej główne potrzeby biznesowe. Takie rozwiązanie oznacza niski koszt wdrożenia i krótki przestój pracy, wynikający jedynie z przeprowadzenia migracji danych na nowy system oraz jego konfiguracji. Bezpieczeństwo, wydajność, funkcjonalność i skalowalność systemu są zapewniane przez producenta oprogramowania, co jednak uzależnia działanie biznesu od zewnętrznych czynników. 

7. Retire (wycofaj) 

W wyniku analizy efektywności systemu w zestawieniu z generowanymi kosztami może dojść decyzji o jego zamknięciu lub wyłączenia jego modułów, które nie są już przydatne w środowisku produkcyjnym. Często jest to etap przestojowy dla przebudowania lub wymienienia oprogramowania, zwłaszcza, jeśli system nie stanowi krytycznego elementu funkcjonowania firmy. 

Przebieg modernizacji 

Modernizacja to proces, na który składa się o wiele więcej niż sama jej implementacja. Do skutecznego jej przeprowadzenia wymagana jest rozległa wiedza oraz doświadczenie – szczególnie w przypadku realizowania bardziej zaawansowanych i inwazyjnych dla systemu strategii. 

Proces ten można rozbić na kilka kluczowych elementów: 

1. Analiza aktualnego systemu 

Kluczowym elementem procesu jest zrozumienie obecnego stanu systemu; rozpoznanie wad warstwy infrastruktury, przeanalizowanie jakości kodu, prześwietlenie zależności między komponentami oraz zbadanie aktualnego zakresu pełnionych funkcji. Na tym etapie identyfikuje się nie tylko problemy, takie jak niska wydajność oprogramowania czy trudności w jego utrzymaniu, ale także przyszłe ryzyka, na przykład wycofywane wsparcie dla obecnych technologii lub silne powiązania, które utrudniają wprowadzanie zmian.  

2. Określenie celów i kontekstu biznesowego 

Po postawieniu diagnozy należy określić planowany zakres funkcjonalności systemu na podstawie wymagań biznesowych oraz technicznych, ale też priorytety i cel jego modernizacji. Jeśli klientowi zależy wyłącznie na poprawieniu wydajności oprogramowania to obrana strategia będzie się diametralnie różnić niż kiedy aplikacja się poszerza o nowe moduły. 

Ważnym aspektem tego etapu jest ścisła komunikacja z klientem, która pozwala na obranie właściwego kierunku dalszych prac i wraz z analizą systemu, stanowi klucz dla obrania właściwej strategii. 

Uwaga! 

Pospieszna analiza systemu lub nieprecyzyjne wymagania biznesowe mogą w konsekwencji doprowadzić do obrania niewłaściwej strategii, co może skutkować wydłużeniem czasu i zwiększeniem kosztów realizacji projektu. 

3. Zbudowanie planu w oparciu o strategię 

Po nabyciu wiedzy o celach i aktualnym stanie systemu, dokonuje się obrania strategii działania, a następnie opracowuje się plan przebiegu modernizacji. Plan oparty na strategii ulepszania obecnego systemu może obejmować na przykład harmonogram prac, docelową architekturę aplikacji, wybór technologii i przebieg implementacji oraz wdrożenia. W przypadku średnich i większych systemów, plan często dzieli się na kilka różnych strategii dla poszczególnych części. 

Na tym etapie można najprecyzyjniej określić rzeczywisty koszt usługi i potrzebny do jej zaimplementowania czas, a także oszacować ewentualny przestój. 

4. Wdrożenie 

Implementacja polega na wprowadzaniu zaplanowanych zmian, które obejmują zarówno przenoszenie systemów do nowego środowiska, jak i ich przebudowę czy integrację z zewnętrznymi serwisami. To najbardziej techniczny etap, podczas którego przede wszystkim realizuje się określone wcześniej prace, a zakres podejmowanych decyzji powinien być minimalny. 

5. Wsparcie 

Po wdrożeniu systemu na środowisko produkcyjne, następuje etap określonego wsparcia, które obejmuje na przykład monitorowanie poprawności działania systemu, naprawę przyszłych usterek czy zapewnienie pełnej i aktualnej dokumentacji użytkowania systemu. 

Po czym poznać, że “to już”? 

Modernizacja przestaje być opcją, a staje się koniecznością, kiedy system zaczyna ograniczać rozwój firmy zamiast go wspierać. Toporne, przestarzałe i niedopasowane do potrzeb biznesu systemy są nie tylko mało funkcjonalne, ale przede wszystkim kosztowne. 

Kiedy więc warto jest przenieść aplikację na zewnętrzny hosting, przepisać oprogramowanie na bardziej skalowalne lub całkowicie wymienić wieloletni system? 

W coraz większej liczbie przypadków odpowiedź jest prosta: 

Najlepszy czas na modernizację był kilka lat temu, a drugi najlepszy jest teraz.