Co zrobić z legacy systems? Strategie wyjścia z technologicznego długu
Budowa nowego systemu od zera, refaktoryzacja kodu i rewrite — oto trzy strategie wyjścia z technologicznego długu, jaki tworzą legacy systems. W niniejszym artykule opowiadamy nieco o każdym z podejść.
Ostatnio sporo pisaliśmy o legacy systems — czym są, jakie problemy generują, w jaki sposób pogłębiają w firmach dług technologiczny i dlaczego problem legacy to w głównej mierze problem odpowiedzialności i zamiatania niewygodnych tematów pod dywan, a nie braku nowoczesnej technologii [LINK DO ARTYKUŁU].
Niniejszy artykuł dedykujemy tym z Was, którzy mentalnie podjęli już słuszną decyzję “zrobienia czegoś” z legacy system i zastanawiają się, w jaki sposób należy ugryźć temat.
Strategie rozwiązania problemu legacy systems
Istnieją w zasadzie trzy możliwe sposoby na wyzerowanie nieustannie powiększającego się w firmie technologicznego długu:
1) całościowa wymiana legacy system na nowy,
2) jego przebudowa/unowocześnienie poprzez refaktoryzację kodu,
3) stopniowy rewrite systemu.
O tym, które z rozwiązań jest korzystniejsze w danym przypadku, decyduje wykonany wcześniej przez odpowiednią firmę technologiczną, audyt.
Strategia Nr 1: Wymiana legacy system na nowy
Budujemy wszystko od zera
Strategia ta jest bardziej kosztowna niż refaktoryzacja kodu i w praktyce stosuje się ją tylko wtedy, gdy ze starego systemu legacy “naprawdę nie ma już co uratować”.
Jeżeli podczas audytu obecnego serwisu wyjdzie na jaw, że archaiczny kod zawiera błąd na błędzie, wydajność i bezpieczeństwo totalnie leżą, a do tego obecna architektura serwisu nie spełnia swych funkcji i zdecydowanie efektywniej będzie całkowicie inaczej zaplanować architekturę systemu, wówczas nie ma sensu “naprawiać” fragment po fragmencie obecnego kodu — zajęłoby to tysiące godzin pracy, a efekt finalny i tak nie spełniłby biznesowych oczekiwań przedsiębiorstwa.
Warto tu przy tym zaznaczyć, że taka kompleksowa wymiana całości legacy system, to też (często niedoceniana) szansa na poprawienie nie tylko samej wydajności technicznej, ale i gruntowne zmapowanie występujących w firmie procesów i ułożenie ich od nowa dużo efektywniej, z uwzględnieniem prawdopodobnych zmian w przyszłości.
Case study wymiany legacy system na nowy z naszego portfolio:
Przykład: jeżeli obecny legacy system jest systemem monolitycznym, w którym całościowa baza danych Klientów jest współdzielona w ten sam sposób przez wszystkie działy firmy, a wiemy, że część działów w ogóle z niej nie korzysta albo potrzebuje tylko części danych, to lepiej już w momencie projektowania architektury systemu, postawić na architekturę mikroserwisów, które zostaną tj. stworzone wokół bazy legacy system. Pobierać one będą dane z bazy legacy, ale nie bezpośrednio lecz przez specjalnie stworzone do tego API. W ten sposób, uniezależnimy inne mikroserwisy od jednego źródła danych.
Każdy dział będzie otrzymywał i tj. “przesyłał” dalej, tylko te dane, które powinien. Dodatkowo, bez problemu, w przyszłości będziemy mogli zintegrować kolejne dane z systemem czy zwiększyć lub zmniejszyć dane uprawnienia.
Co ważne, w przyszłości, mikroserwis opakowujący bazę legacy będzie można rozbić na mniejsze mikroserwisy.
To, kiedy i która architektura systemu jest lepsza dla danego biznesu, pisaliśmy w osobnym artykule Monolity vs. mikroserwisy — zalety i wady.
Strategia Nr 2: Refaktoryzacja kodu
Małymi kroczkami poprawiamy jakość kodu, ulepszając finalnie cały system
Refaktoryzacja (z ang. refactoring) to proces zmiany wewnętrznej struktury kodu bez ingerowania w jego zewnętrzne zachowanie. Dla przykładu, jeśli jakiś fragment kodu odpowiedzialny był za dodanie do siebie pewnych liczb, ale był źle napisany, to w efekcie refaktoryzacji, niektóre linijki kodu się zmienią (zostaną lepiej napisane), ale fragment ten nadal będzie odpowiedzialny za dodawanie do siebie liczb.
To udoskonalenie kodu, odbywa się poprzez małe, ale systematyczne i częste działania, które brane pojedynczo w zasadzie nie byłyby zauważalne. Tym niemniej, gdy je wszystkie razem zsumować, naprawdę “robią różnicę”.
W ten sposób, dany legacy system możemy refaktoryzować do modularnego monolitu lub do mikroserwisów albo przygotować go na nowe funkcje biznesowe.
To, co jest najbardziej charakterystyczne dla refaktoryzacji i odróżnia ją od standardowego rewrite (całościowego przepisania) aplikacji, to robienie tego małymi fragmentami poprzez wprowadzanie mikroskopijnych, łatwych w kontroli i testowaniu zmian, które następnie można bardzo szybko zintegrować ze starym kodem. Te świeżo napisane fragmenty kodu, których z czasem jest coraz więcej i więcej, stopniowo zastępują stary, archaiczny kod, ale, że dzieje się to właśnie malutkimi fragmentami, system nadal działa, jak gdyby nigdy nic. W porównaniu z przeszczepem serca, refaktoring jest zatem bardziej milionem operacji na żywym ciele, które normalnie sobie funkcjonuje, chodzi do pracy, bierze kąpiel itd.
Innymi słowy, efektem refaktoringu jest lepszy jakościowo, czysty kod, którego wdrożenie w żaden negatywny sposób nie wpływa na obecne funkcjonowanie systemu — nie wymaga długich technicznych przerw itp. Jest to niezwykle bezpieczna, a przy tym skuteczna metoda.
De facto, refaktoring może stanowić nie tylko jednorazową inwestycję, ale całoroczną strategię przedsiębiorstwa — być ciągłym, codziennym procesem, którego celem jest, jak mówi Zasada Skauta, zostawienie kodu lepszym niż go zastałeś. Stosowanie systematycznego refaktoringu zasłużyło sobie właśnie na ten oddzielny skrót w żargonie IT — BSR (z ang. Boy Scout Rule) — i w ostatnich czasach przyrasta tej praktyce wielu zwolenników.
Strategia Nr 3: Stopniowy rewrite systemu
Przepisanie systemu na nowo
Rewrite systemu, czyli przepisanie kodu na nową technologię, zakłada (w przeciwieństwie do refactoringu), że nie zaglądamy w obecny kod i jego działanie, tylko bierzemy jakiś jego wycinek i przepisujemy go na nowo. Do tego można wykorzystać na przykład strangler pattern tak, aby po kawałku przepisać newralgiczne części systemu.
Co istotne, nie ma sensu rzucać się na głęboką wodę i zakładać, że przepisze się cały system od razu. W praktyce to nigdy się nie wydarza i jest tzw. “sztuką dla sztuki”. Rewrite ma sens tylko wtedy, gdy legacy system jest naprawdę mały. W przypadku dużych systemów monolitycznych nie ma sensu rewritować od razu całości — jedynie wspomniane wyżej newralgiczne miejsca (czyli te miejsca, które są często rozwijane pod nowe cele biznesowe albo miejsca, które często wyrzucają błędy).
Ważne! Każdy system w końcu się zestarzeje, jeśli nie będziemy o niego dbać
To, że zaczniemy tworzyć nowego zastępcę legacy system czy go unowocześniać, wcale nie gwarantuje, że nie doprowadzimy go w pewnym momencie do takiego samego stanu, jak przed rozpoczęciem prac! O każdy system trzeba regularnie dbać. Do utrzymania dobrej jakości kodu należy stosować narzędzia do analizy statycznej kodu, pisać testy jednostkowe, funkcyjne i integracyjne. Dodatkowo, pieczę nad architekturą systemu powinien mieć architekt firmowy lub technical leader.
Metody przekonywania zarządu, że inwestycja ma sens
W dobie tendencji do nieustannego cięcia kosztów, wielu managerów zastanawia się jak przekonać zarząd, że większa inwestycja w przebudowę legacy systems ma sens. Najczęstszymi praktykami stosowanymi w tym celu są:
- wykazanie w Excelu, że inwestycja się zwróci, a w dłuższej perspektywie czasu, doprowadzi do eliminacji kosztów — wystarczy dobrze policzyć obecne koszta związane z utrzymaniem legacy system (godziny poświęcone na dbanie o system przez własny dział IT i godziny pracy zewnętrznej firmy), a także dodać do tego koszty przestojów w działaniu serwisu (np. system magazynowy nie działał w sumie 70 godzin, co doprowadziło do utraty X zamówień o wartości Y; w wyniku zastojów ERP obsłużyliśmy w sumie 15 tys. Klientów, gdzie standardowo byłoby to 16 tys., tracąc przy tym kontrakty na kwotę Y itd.). Wiedząc, że nowy system będzie nas kosztował XYZ, a jego roczne utrzymanie ewentualnie CYZ, możemy łatwo porównać oba warianty (zachowanie obecnego systemu i koszty z tym związane, a inwestycję w nowy) i wykazać po jakim czasie nowoczesny system się zwróci,
- przedstawienie argumentów i symulacji finansowych, pokazujących, że nowy system zwiększy zyski firmy — bezawaryjny system, to szybsza obsługa klientów i ich wyższa satysfakcja, zwiększona sprzedaż, większa produkcja, szybsze zmiany tu i teraz, możliwość szybkiej odpowiedzi na działania konkurencji, szansa na pozostawienie konkurencji w tyle. Przynajmniej część tych korzyści biznesowych również można ładnie zaprezentować w Excel’u,
- wpisanie części inwestycji w inny projekt — dla przykładu, w firmie planowane jest stworzenie nowego narzędzia dla działu sprzedaży, którego kalkulacja ROI jest taka a taka. Żeby to narzędzie rzeczywiście sprawnie działało, należy jednocześnie przebudować moduł Sale w naszym obecnym legacy system. Innymi słowy, tak jakby chowamy wydatki na inwestycję w legacy system w ROI innego projektu.
Dodatkowo, warto też od razu ustalić w firmie, że pewien określony % budżetu projektu, będzie szedł na aktualizacje, nowe licencje i drobną refaktoryzację kodu na bieżąco w przyszłości. Ten tzw. odpis na dług technologiczny oscyluje w różnych firmach od 5 do 12% i sprawia, że nie doprowadzimy znów do sytuacji, gdy za kilka lat będzie trzeba wymieniać całość systemu.
Chcesz wyjść z technologicznego długu? Potrzebujesz pomocy z legacy system?
Jesteśmy ekspertami w dziedzinie technologii i danych. Napisz do nas https://transparentdata.pl/
Mogą Cię zainteresować również:
