W banku migracja systemu nie jest wydarzeniem technicznym, tylko ryzykiem biznesowym. Za każdą tabelą stoją pieniądze klientów, a za każdym oknem serwisowym regulator i reputacja. Dlatego migracja systemów bankowych udaje się nie wtedy, gdy nowy system działa, tylko wtedy, gdy klient w ogóle nie zauważył zmiany - przelewy chodzą, salda się zgadzają, aplikacja mobilna odpowiada tak samo jak wczoraj.
Z naszego doświadczenia najtrudniejsza nie jest sama konwersja danych, tylko utrzymanie ciągłości działania w trakcie przenosin. Od 2015 roku realizujemy migrację systemów dla klientów biznesowych i programowanie backendu w bankowości, między innymi dla banku należącego do międzynarodowej grupy finansowej, dla którego zbudowaliśmy nową generację aplikacji mobilnej. To tam nauczyliśmy się pisać plan migracji od strony klienta i rollbacku, a nie od strony nowej architektury.
Dlaczego migracja systemów w banku jest tak ryzykowna?
Bank różni się od zwykłego przedsiębiorstwa trzema rzeczami naraz: ciągłością, zgodnością i nieodwracalnością operacji. Rdzeń pracuje praktycznie bez przerwy, bo klient oczekuje dostępu do pieniędzy o każdej porze. Dane finansowe muszą się zgadzać co do grosza, a nadzór wymaga udokumentowania, że się zgadzają. Operacji księgowej nie da się „cofnąć” jak zwykłego rekordu - trzeba ją wyksięgować, co samo jest zdarzeniem.
Do tego dochodzi warstwa łatwa do pominięcia: systemy w banku są ze sobą posplatane. Rdzeń rozmawia z systemem kartowym, antyfraudem, raportowaniem regulacyjnym, bankowością mobilną i dziesiątkami integracji narosłych przez lata, więc migracja jednego elementu pociąga pytania o wszystkie pozostałe. Dlatego traktujemy ją jak operację na żywym organizmie.
Jak planujemy migrację banku bez przestojów?
Zaczynamy od inwentaryzacji, nie od kodu. Zanim ktokolwiek dotknie danych, mapujemy, co z czym rozmawia, które przepływy są krytyczne dla klienta i gdzie leżą dane, których nie wolno zgubić ani zdublować. Dopiero ta mapa pokazuje, co można przenieść w tle, a co wymaga ścisłego okna.
W planowaniu trzymamy się kilku zasad, które nieraz uchroniły nas przed nocnym rollbackiem:
- projektujemy migrację etapami, zamiast przenosić wszystko jednym ruchem,
- ustalamy twarde kryteria sukcesu i wycofania jeszcze przed startem, nie w trakcie,
- próbujemy całość na kopii produkcji, a nie tylko na danych testowych,
- planujemy rollback jako pełnoprawny scenariusz, nie jako plan awaryjny na kartce.
Jakie strategie migracji stosujemy: etapami, równolegle, z rollbackiem?
Rzadko istnieje jedna słuszna strategia - dobieramy ją do tego, jak krytyczny jest dany system i jak bolesny byłby jego przestój. Najczęściej łączymy w jednym programie trzy podejścia.
Migracja etapami (fazowa) przenosi funkcje lub grupy klientów partiami: nowy i stary system działają obok siebie, a ruch przełączamy stopniowo, co ogranicza zasięg ewentualnego błędu do jednej fazy, a nie całego banku.
Praca równoległa (parallel run) oznacza, że przez pewien czas oba systemy przetwarzają te same operacje, a my porównujemy wyniki. Dopóki nie zgadzają się co do grosza, źródłem prawdy pozostaje stary system - to nasz ulubiony sposób budowania pewności przed przełączeniem.
Rollback projektujemy zawsze. Przełączenie bez przećwiczonej drogi powrotu jest w banku zakładem, a nie planem, więc każde okno migracyjne ma zdefiniowany punkt bez powrotu i jasną procedurę wycofania przed nim.
Jak zapewniamy integralność danych podczas migracji danych w banku?
Tu nie ma miejsca na „prawie się zgadza”. Migracja danych w banku musi być uzgadnialna liczbowo - sumy kontrolne, liczby rekordów i salda po obu stronach muszą się spiąć, zanim ktokolwiek ogłosi sukces. Dlatego budujemy proces, w którym każdą porcję danych weryfikujemy automatycznie, a rozbieżności wychwytujemy natychmiast, a nie po reklamacji klienta.
W praktyce dbamy o kilka warstw kontroli:
- profilowanie i czyszczenie danych przed migracją, żeby nie przenosić śmieci,
- mapowanie pól i reguł transformacji opisane i wersjonowane, nie trzymane w głowach,
- rekoncyliację po każdej partii - porównanie sum, liczności i kluczowych sald,
- ślad audytowy, który pokazuje, skąd wziął się każdy rekord w systemie docelowym.
Jak testujemy i walidujemy migrację, zanim zobaczy ją klient?
Testujemy migrację tak, jak się ją później uruchamia - na danych i wolumenach zbliżonych do produkcji. Jednorazowa próba niczego nie dowodzi, więc powtarzamy przejścia migracyjne wielokrotnie, aż przebieg staje się przewidywalny co do minuty i co do wyniku - a każda próba to zarazem test procedury wycofania.
Oprócz poprawności danych sprawdzamy wydajność i zachowanie integracji pod obciążeniem. Nie wystarczy, że dane się przeniosą - muszą się przenieść w oknie mieszczącym się między ostatnią a pierwszą operacją klienta, dlatego mierzymy i skracamy czas przebiegu tak, żeby to okno było jak najmniejsze, a najlepiej niewidoczne.
Jak pilnujemy bezpieczeństwa i zgodności przy modernizacji systemów banku?
Modernizacja systemów banku toczy się pod okiem regulatora i działów ryzyka, więc zgodność wplatamy w projekt od początku, a nie doklejamy na końcu. Dane wrażliwe chronimy na każdym etapie przenosin, dostępy ograniczamy do niezbędnych, a cały proces dokumentujemy tak, żeby dało się go odtworzyć i uzasadnić przed audytem; w środowiskach nieprodukcyjnych pracujemy na danych zabezpieczonych, nie na żywych numerach klientów.
Równie ważne jest to, co dzieje się po migracji: nowy system musi od pierwszego dnia zasilać raportowanie regulacyjne i mechanizmy kontrolne tak samo jak poprzedni. Dlatego zgodność jest dla nas wymaganiem funkcjonalnym migracji, a nie osobnym projektem po fakcie.
Jakie kompetencje dostarczamy do projektu migracji w banku?
Dobieramy skład pod konkretny etap i system, a nie „na zapas”. W projektach migracyjnych i backendowych dla bankowości obsadzamy zwykle role takie jak:
- inżynierowie danych i migracji odpowiedzialni za konwersję i rekoncyliację,
- programiści backendu rozwijający i integrujący systemy po stronie banku,
- architekci spinający nowy i stary świat w jeden, działający przepływ,
- specjaliści QA i automatyzacji testów pilnujący, że wynik się zgadza.
Taki zespół może przejąć pełną odpowiedzialność za migrację albo wzmocnić Wasze zespoły tam, gdzie brakuje rąk lub konkretnej wiedzy; który model wybrać, podpowiadamy w artykule o modelach współpracy IT.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski z realnym stażem w bankowości sięgającym 2015 roku - przenosimy systemy i dane tak, żeby klient banku tego nie odczuł, a zespół banku zachował kontrolę nad całym procesem.
Najdobitniejszym dowodem jest współpraca z bankiem należącym do międzynarodowej grupy finansowej, dla którego zbudowaliśmy też nową generację aplikacji mobilnej. Realizujemy tam migrację systemów dla klientów biznesowych i programowanie backendu, a to doświadczenie wnosimy do każdego kolejnego projektu. Najczęściej pracujemy w modelu dedykowanego oprogramowania budowanego przez nasz zespół, a tam, gdzie trzeba szybko uzupełnić kompetencje, we wzmocnieniu zespołu klienta.
Od czego zacząć migrację systemów banku?
Zacznij od jednego pytania: który przepływ klienta nie może paść ani na minutę? To on wyznacza strategię, długość okna i kształt rollbacku. Potem zinwentaryzuj dane i integracje, bo to one zwykle decydują o realnym ryzyku, a nie sam nowy system.
Planujesz migrację lub modernizację systemów banku? Porozmawiajmy - zaplanujemy przenosiny i dobierzemy zespół tak, żeby klient niczego nie zauważył.