Migracja jest złożonym, często wieloetapowym przedsięwzięciem, mającym na celu przeniesienie obsługi wybranych procesów biznesowych przedsiębiorstwa z jednego systemu informatycznego do drugiego. Nie dotyczy ona jedynie systemów legacy, a jest również uzasadnionym działaniem w ramach takich projektów biznesowych, jak fuzja czy przejęcie przedsiębiorstwa, gdzie jednym z oczekiwanych w dłuższej perspektywie wyników jest ujednolicona architektura rozwiązań IT.
Podstawowe strategie migracji
Migracja całkowita
Strategia migracji całkowitej zakłada jednorazowe przeniesienie wszystkich procesów, obsługiwanych przez system źródłowy, do docelowego. Jej zastosowanie jest oczywiste w przypadku małych aplikacji, ale także wtedy, gdy ze względu na dużą ilość zależności trudno jest wyodrębnić mniejsze, logicznie spójne części funkcjonalności. Zaletą migracji całkowitej jest niemal natychmiastowa deklasyfikacja systemu źródłowego z rangi krytycznego do archiwalnego, co – w przypadku problemów z jego utrzymaniem – może być czynnikiem kluczowym. Do najistotniejszych wad tego rozwiązania należy natomiast zaliczyć wysokie ryzyko biznesowe (szczególnie w przypadku dużych systemów) oraz duży koszt jednostkowy.
Migracja stopniowa
Strategia migracji stopniowej polega na sukcesywnym i rozłożonym w czasie procesie przenoszenia wyodrębnionych funkcjonalności systemu źródłowego do jednego lub wielu systemów docelowych. Choć jej bezpośrednie zalety i wady to głównie przeciwieństwa wad i zalet migracji całkowitej, to warto zwrócić uwagę, że do migracji etapowej dochodzi często niepostrzeżenie – np. w ramach rozszerzeń systemów legacy – gdzie część funkcjonalności bywa już nieformalnie zastąpiona lub zduplikowana. Sprawia to, że wybór migracji stopniowej jest naturalny, a czynniki niskiego ryzyka i ograniczonych kosztów jednostkowych – jeszcze bardziej odczuwalne.
Konwersja danych
Jednym z podstawowych elementów procesu migracji – szczególnie z technicznego punktu widzenia – jest przeniesienie danych systemu źródłowego do systemu docelowego. Aby to było możliwe, źródłowe dane muszą zostać poddane procesowi konwersji do formatu i logiki docelowego modelu danych.
Konwersja to obszar, w którym nasz zespół zyskał szczególne doświadczenie – również w zakresie budowy silników konwersji w ramach migracji dużych systemów bilingowych.
Reguły konwersji
Podstawą powodzenia migracji, a w szczególności konwersji, jest ścisła – poprzedzona wnikliwymi analizami – definicja reguł, które pozwolą na przeniesienie danych bez utraty ich merytorycznej zawartości i spójności. W tym celu definiowane są m.in. mapowania poszczególnych tabel (lub ich zespołów), pól danych i wartości danych słownikowych, a także – w razie konieczności – bardziej złożone algorytmy łączenia, rozbijania, ekstrakcji lub generowania danych.
Wskaźniki jakości
Najczęściej w procesie konwersji mamy do czynienia ze zbiorami danych, gromadzonych przez lata lub nawet dziesiątki lat. Długa historia, obfitująca czasami w awarie lub ręczną manipulację, powoduje, że ich fragmenty mogą stać się niespójne lub w jakiś sposób odstające od reguł biznesowych, co uniemożliwi ich automatyczną konwersję zgodną ze zdefiniowanymi regułami. Wyznaczane są więc wskaźniki jakości, jak odsetek liczby wyjątków (obsługiwanych później manualnie) lub wartości zbiorcze (np. sumy transakcji), których wartości są oceniane po konwersji, a ich akceptowalność jest podstawą ostatecznej decyzji o powodzeniu procesu.
Silnik konwersji
Integralnym elementem konwersji jest tzw. silnik (Conversion Engine), czyli oprogramowanie, które – zgodnie ze zdefiniowanymi regułami – przetwarza dane źródłowe do postaci, która zostanie ostatecznie zaimportowana do systemu docelowego. Sposób tworzenia silnika konwersji musi brać pod uwagę szereg wymagań, których jednoczesne spełnienie warunkuje jego skuteczne tworzenie i wykorzystanie.
- Identyfikacja wyjątków – wszystkie elementy algorytmu odpowiedzialnego za przetwarzanie poszczególnych obszarów logicznych muszą w ścisły sposób kontrolować jakość danych oraz jednoznacznie raportować niekonwertowalne wyjątki wraz z czytelną informacją o ich istocie. Jest to materiał do analizy po każdym testowym uruchomieniu silnika, skutkującej decyzją, czy klasa wyjątku zostanie obsłużona ręcznie po finalnej konwersji, czy też wymaga rozszerzenia silnika o implementację dodatkowych reguł.
- Łatwa rozszerzalność – oprogramowanie silnika konwersji powinno uwzględniać możliwość łatwego jego rozszerzenia o kolejne reguły konwersji, pojawiające się podczas kolejnych uruchomień testowych, będących jednocześnie głęboką analizą danych wejściowych. Uzyskuje się to poprzez dynamicznie dołączane fragmenty kodu lub dane konfiguracyjne.
- Wydajność – konwersje dużych wolumenów danych, a szczególnie te wymagające stosowania złożonych reguł, mogą stanowić wyzwanie wydajnościowe dla dostępnej infrastruktury, na której uruchamiany jest silnik konwersji. Oznacza to, że tworząc jego kod, należy zwrócić szczególną uwagę na dobór optymalnych technik przetwarzania. Czas niezbędny do przeprowadzenia konwersji jest kluczowym czynnikiem determinującym planowanie „dnia konwersji”, a zbyt długi może być wręcz nieakceptowalny biznesowo.
- Kontrolowalność – w procesie tworzenia silnika konwersji konieczne jest jego wielokrotne uruchamianie w celu przetestowania poprawek lub implementacji nowych reguł konwersji. Kompletny proces konwersji może jednak trwać wiele godzin (czasem dni), byłoby więc wysoce nieefektywne każdorazowe oczekiwanie na jego zakończenie w celu weryfikacji efektów wprowadzonych zmian. Aby uniknąć tego typu problemów, silnik wyposażony jest w mechanizm monitorowania stanu przetwarzania w czasie rzeczywistym. Dostarcza on informacji o dotychczasowych błędach, wyjątkach, aktualnych wartościach wskaźników jakości oraz postępie procesu. Implementowana jest również funkcjonalność umożliwiająca szybkie zatrzymanie przetwarzania, jego wznowienie oraz restart.
„Dzień konwersji”
Zwieńczeniem wielotygodniowych prac przygotowawczych jest tzw. „dzień konwersji” – określenie to ujęto w cudzysłów, ponieważ w rzeczywistości może on obejmować dłuższy okres (najczęściej weekend), podczas którego przeprowadzana jest finalna konwersja. Składa się na nią szereg działań, których szczegóły mogą się różnić w konkretnych przypadkach, jednak najistotniejsze etapy są na ogół podobne:
- Zapewnienie niemodyfikowalności danych systemu źródłowego (np. wyłączenie, blokada dostępu, tryb tylko do odczytu).
- Eksport danych z systemu źródłowego, wraz z weryfikacja jego kompletności.
- Udostępnienie lub transfer danych do silnika konwersji.
- Uruchomienie i monitorowanie działania silnika konwersji do czasu zakończenia procesu.
- Ostateczne weryfikacja wskaźników jakości.
- Udostępnieni lub transfer danych do środowiska systemu docelowego.
- Przygotowanie systemu docelowego do importu, czyli blokada dostępu oraz wykonanie kopii zapasowej danych. Krok ten warto rozpocząć wcześniej – jeszcze podczas trwania kroków poprzednich – aby jak najszybciej rozpocząć działania po udostępnieniu danych do importu.
- Import danych do systemu docelowego.
- Weryfikacja zaimportowanych danych poprzez sporządzenie, przygotowanych wcześniej, raportów sumarycznych.
- Udostępnienie systemu docelowego lub rollback, czyli przywrócenie z kopii zapasowej do stanu przed importem w przypadku negatywnego wyniku weryfikacji.
Harmonogram konwersji powinien być dokładnie zaplanowany, tak aby zmieścić się w dostępnym oknie czasowym. Musi również brać pod uwagę możliwość niepowodzenia na każdym z etapów oraz określać kryteria podejmowania decyzji o możliwości powtórzenia kroku lub wycofaniu/zaniechaniu bieżącego procesu konwersji.