Sposoby na systemy Legacy: replatforming, migracja czy może transformacja

W świecie IT słowo „legacy” niestety kojarzy się mocno negatywnie – przestarzały, trudny w utrzymaniu, a przecież w języku angielskim to dumnie brzmiące “dziedzictwo”. Jak to tak naprawdę jest?

Definicji Systemu “dziedzictwa” można znaleźć wiele. Dla mnie system Legacy jest przede wszystkim ofiarą swojego sukcesu. Znakomity system, który świetnie spełnia swoją rolę, jest mocno zżyty z organizacją, często z nowatorskimi rozwiązaniami pod spodem, ale niestety takimi które: nie wytrzymały próby czasu, technologia zestarzała się, brakuje dla niego wsparcia “żywych” firm na rynku, albo nie dały one po prostu rady skalowaniu, wzrostowi, ciągłej rozbudowie, którą jako ludzie lubimy aplikować wszędzie, gdzie tylko coś się udaje.

Jest to dosyć popularny problem naszych czasów. Najlepszym przykładem jest tu podejście Agile, z całym swoim arsenałem dobrych zasad. Zostało ono zdruzgotane wdrożeniami w dużych organizacjach. Albo startupy z ich pięknymi pomysłami, nowatorskimi rozwiązaniami rozbijające się o próby zbudowania czegoś wielkiego. Świat dużych organizacji zna dwa proste rozwiązania dla naszego problemu.

UPGRADE

Jedno z nich to aktualizacja do wyższej wersji. W dużej mierze rozwiązanie opierające się o nadzieję, że dostawca zatroszczy się kiedyś o problem i pozbawi nas kłopotu … o ile dostawca jeszcze istnieje. Jeśli nawet takie podejście jest aplikowalne, pozostaje jeszcze kwestia kosztów i ryzyka. Niestety dosyć częstym procederem jest przesunięcie odpowiedzialności za proces aktualizacji z dostawcy na klienta, organizację. Długotrwały proces testowania, weryfikowania jest tym bardziej kłopotliwy, iż te znakomite z punktu widzenia biznesowego systemy często nie były wystarczająco rozwinięte z perspektywy rozwoju i procesów SDLC. To może jest inne wyjście?

NOWY MODEL

Drugie rozwiązanie to wymiana na nowszy model. Jeśli już zaczynamy rozważać kosztowne operacje, to może należy wymienić nasz system na coś innego, lepszego, bardziej nowoczesnego. Dla działających instytucji oznacza to tak naprawdę dwa projekty – wdrożenie nowego systemu i migracja istniejących danych.

I tu pojawia się jeszcze jeden, do tej pory nieopisany aspekt systemów Legacy. Mało kto wie, jak one powinny działać, jakie wymagania powinniśmy spełniać, nie mówiąc już o tym jak przeprowadzić migrację z jednego modelu produktów do drugiego z całą konsekwencją działań z tym związanych, a są to:

• działania prawne,
• renegocjacja umów z klientami,
• jakość, a wszystko zazwyczaj w trakcie burzliwych projektów regulatory-must.

Ten długi wstęp opisuje sytuację, którą napotkałem 4 lata temu w mBanku. System centralny idealnie dopasowany do nas, stanowiący o naszej przewadze konkurencyjnej, ale taki którego upgrade do nowej wersji jest już niemożliwy, a przejście na inny system – jeśli w ogóle istnieje taki o zbliżonej funkcjonalności – to olbrzymi wysiłek w każdym wymiarze: czasu (Man-days), kosztów i wiedzy.

MARZENIE

mBank to de facto olbrzymi software-house. Mamy bogate i często oryginalne doświadczenia, pozwoliliśmy więc sobie marzyć. A gdyby tak móc przenieść nasz system do nowoczesnych technologii, takich które tak dobrze znamy, które posiadają nowoczesny warsztat deweloperski, wsparcie dostawcy, wsparcie społeczności. Zrobić to bez zmian funkcjonalnych, bez ryzyka i konieczności ciężkiej przebudowy biznesowej, czy ryzyka utraty klientów. Tak rozpoczyna się nasza przygoda z replatformingiem, który dalej przerodził się w migrację, a na końcu przeistoczył się w transformację systemu centralnego. A gdyby jeszcze, móc korzystać ze zmiany nie czekając na koniec projektu? Projekt rozpoczął się serią inicjatyw, z których każda zasługuje na osobny rozdział.

REPLATFORMING

Prędzej czy później każde podejście oznacza jakąś formę testów akceptacyjnych, ale jak zorganizować takie wydarzenie, skoro zmienia się w zasadzie wszystko? Czy zaufać testom manualnym? Od początku projektu inwestowaliśmy w testy automatyczne – zbudowaliśmy platformę SQUEEZER, której zadaniem było umożliwienie użytkownikom biznesowym i analitykom projektowanie testów automatycznych. Udało się! Należy dodać, że testy te jesteśmy w stanie bez zmian uruchamiać w nowej platformie w celu weryfikacji jakości finalnego rozwiązania.

Kolejna inwestycja do wzmocnienie naszych możliwości diagnostycznych, zbudowaliśmy rozwiązanie pozwalające na śledzenie kodu wykonywanego na produkcji – bez upośledzenia wydajności. Dzięki temu rozwiązaniu w naszym starożytnym świecie jesteśmy w stanie:

• określić, które części rozwiązania są używane, a które już nie,
• możemy monitorować wydajność i wprowadzać optymalizację w oryginalnym, starym środowisku.

Zdobywając tę umiejętność byliśmy w stanie dalej rozbudować bibliotekę o szczegółową diagnostykę, która rozwinęła jeszcze mocnie możliwości SQUEEZERa.

Migracja logów, a właściwie tworzenie nowych dla narzędzia SPLUNK, dało nam możliwość szybkiego przeszukiwania zdarzeń, możliwość odnoszenia się do zachowania systemu w przeszłości. Ten punkt, i poprzedni pozwoliły nam też na skrócenie czasu niezbędnego do reakcji na zgłoszenia błędów.

Jednym z bardziej uciążliwych aspektów naszego starego systemu był brak serwera aplikacyjnego z prawdziwego zdarzenia. Całość komunikacji opierała się o znany, ale leciwy protokół telnet. W oparciu o .NET Udało się nam zaimplementować zupełnie nowy kanał:

• skalowalny,
• bez-stanowy,
• monitorowalny,
• udostępniający interfejs REST i otwierający nas na narzędzia z rynku i integrację z nowym światem.

Wymiana UI to dosyć typowy ruch, często jedyny, który spotykamy w różnych instytucjach. Ma on jednak wiele zalet:

• otwiera platformę na narzędzia z rynku (w tym np. automatyzację testów, robotyzację),
• zmniejsza dystans między użytkownikiem a rozwiązaniem, dając mu takie same doświadczenie, do którego przyzwyczajony jest jako użytkownik-cywil,
• pozwala na projektowanie UX dopasowanego do problemu, gwarantującego lepszą jakość i dokładność pracy.

W naszym przypadku rozwiązanie idealnie wpasowało się w trudny COVIDowy świat pracy zdalnej.

TRANSLACJA

To najtrudniejsze wyzwanie w całym projekcie. W pełni automatyczna translacja oryginalnego kodu (3m LoC) do .NET. Cały proces opierał się na inżynierskim, w pełni mierzalnym podejściu, a także ~20k testach automatycznych, które gwarantują jakość tej inicjatywy.

Jednocześnie zadbaliśmy o to, aby cały framework zawierał jak najwięcej .NET w .NET. Dotyczyło to koncentracji na wszystkich koncepcjach zawartych w SOLID. Udało się nam uzyskać jednoznaczność w działaniu kodu wynikowego i źródłowego, co dalej otworzyło możliwość tworzenia testów automatycznych w języku C#. To zupełnie zmieniło warsztat deweloperski i możliwości pracy. Cała mnogość narzędzi ze świata .NET stała się dostępna dla nas od ręki.

Baza danych

Oryginalny język programowania naszych rozwiązań był językiem 4. generacji, co w większości wypadków wiąże się z silnym powiązaniem z jakąś bazą danych. Analogicznie do translacji zbudowaliśmy model transformacji danych i migracji do uznanej platformy PostgreSQL, i co ważne bez zmiany paradygmatu stojącego za oryginalnym rozwiązaniem.

MIGRACJA

Po rozwiązaniu tak kluczowych problemów, rozpoczął się mozolny proces stopniowego migrowania kolejnych elementów systemu z zachowaniem wszelkiej staranności w postaci:

• masywnych testów porównawczych,
• automatyzacji testów,
• porządkowania i sprzątania napotkanego bałaganu.

FINISH, TRANSFORMACJA

Ale … to nie jest tylko wyzwanie technologiczne. W działaniu systemu Legacy bardzo istotni są ludzie. To dzięki nim, negatywne aspekty “dziedzictwa” sprowadzają się dla zewnętrza do drobnych niedociągnięć. W całej historii tego projektu to właśnie ludzie – kolejni konwertowani ze świata Legacy deweloperzy, eksperci czy też analitycy – prowokowali kolejne odkrycia, kierunki i nowe rozwiązania. Bez nich projekt ten zakończyłby się w pierwszych jego dniach.

W mBanku przez lata byliśmy projektowani tak, aby sprostać tego kalibru wyzwaniom. Zespoły są mieszanką programistów systemu centralnego i nowych technologii, kładliśmy nacisk na równomierny rozwój odpowiedzialności, a nie warstwowy/technologiczny podział obowiązków. Dzięki temu byliśmy w stanie połączyć tak różne dwa światy i stopniowo wciągać na pokład kolejnych uczestników.

Leszek Włodarski, IT Deputy Director, mBank