Strategia modernizacji IBM i w środowisku technologii BFSI (Noel Prince Moses V)

Abstrakcyjny

Istnieją silne zalecenia dotyczące modernizacji aplikacji systemu IBM i lub migracji na futurystyczną platformę, a także silne wahania, które napędzają nastroje antymigracyjne. To prowadzi nas do pytania; czy musimy inwestować w zestaw umiejętności
istniejącej platformy, czy nie?

Przegląd

IBM i jako starszy system jest przeznaczony dla wielu przedsiębiorstw z różnych powodów do migracji. W tym blogu omówimy dostępne opcje migracji w dzisiejszym scenariuszu, prawdopodobieństwo ich przyjęcia, powód braku szybkiego śledzenia
migracji lub wyjazdu oraz potrzebę podniesienia poziomu siły roboczej zajmującej się rozwojem.

IBM i (szeroko znany jako AS/400) to jeden z najbardziej strategicznych systemów dla wielu średnich i dużych przedsiębiorstw, w tym z sektora bankowości, usług finansowych i ubezpieczeń (BFSI). Jest używany przez wszystkie te przedsiębiorstwa od ponad 25 do 30 lat. Obsługuje rdzeń
aplikacje dla banków i ubezpieczycieli, obejmujące podstawową bankowość, zarządzanie kartami, administrowanie polisami itp. IBM i, jak tu omawiamy, to cały ekosystem towarzyszący systemowi IBM i, sprzęt, system operacyjny, języki programowania, takie jak RPG,
COBOL i CL, baza danych DB2 for i, IBM MQ do przesyłania wiadomości, zarządzania zadaniami, dostępu użytkowników, bezpieczeństwa itp. Modernizacja starszej wersji jest przedmiotem dyskusji w bankach od wielu lat, a system IBM i również rozważa zastąpienie nowymi technologiami ze względu na wyzwania
związane z zestawem umiejętności specyficznych dla platformy IBM i (RPG, COBOL), monolityczną architekturą aplikacji prowadzącą do problemów z elastycznością, interoperacyjnością z innymi platformami i narzędziami DevOps, niedostosowane do inwestycji strategicznych, pozbawione większości korzyści związanych z chmurą (np.
przepustowość na żądanie) itp. Jednocześnie istnieje wiele powodów odkładania migracji. Niektóre z nich to nowe wydania sprzętu, wydania systemu operacyjnego, rozszerzone okno wsparcia, bieżące inwestycje w ciężką infrastrukturę, ryzyko i koszty migracji.
W tym miejscu staramy się ocenić wczesne możliwości jego wyjścia, aby przewidzieć zależność od MŚP.

Nasza perspektywa

Z biegiem czasu firma się rozwinęła, wzrosły wymagania biznesowe, wzrosły różne zagrożenia, wzrosły wymagania dotyczące zgodności i przepisów, aż w końcu wszystkie te kwestie zostały ujęte i obsługiwane w ramach jednej monolitycznej aplikacji dla każdego
przedsiębiorstwo. Stąd wysoki poziom złożoności, skupiający całą wiedzę, zasady biznesowe, procesy biznesowe. Dodając do tego wszystkie wdrożenia techniczne, takie jak wielowątkowość, przesyłanie wiadomości, planowanie zadań, kontrola zadań itp.,
są również częścią implementacji monolitu.

Wraz z pojawieniem się praktyk Cloud, DevOps i Agile, branże i przedsiębiorstwa, w tym bankierzy i ubezpieczyciele, szukają transformacji aplikacji IBM i, a także czerpania korzyści z najnowszych funkcji i korzyści. Przedsiębiorstwa mają wiele możliwości
przed nimi. Platforma ta może stosować zwinne praktyki i być częścią świata DevOps dzięki rozwiązaniom ARCAD. Jeden z dużych brytyjskich banków pomyślnie wdrożył DevOps na IBM i. Niedawno uruchomiona platforma IBM i Merlin (silnik modernizacji dla cyklu życia
Integracja) pomaga w tym dzięki zintegrowanym narzędziom IDE, CI/CD Merlin do obsługi DevOps wraz z udostępnianiem maszyn wirtualnych IBM i, zarządzaniem API REST itp. i daje nadzieję na kompletny ekosystem DevOps w przyszłości. Najnowsze osiągnięcia pomagają w zwinności
środowisk IBM i i ponownego hostowania jego aplikacji. Administrowanie systemem tej platformy zostanie odciążone poprzez migrację infrastruktury bezpośrednio do IBM Cloud lub do Skytap na platformie Azure i IBM Cloud lub do Connectria na AWS. Infinite i jest na ratunek, aby ponownie gościć
aplikacje na platformie Azure, AWS lub Google Cloud. Wszystkie te opcje należy sklasyfikować jako modernizację na miejscu lub pseudomodernizację i są one zależne od zestawu umiejętności systemu IBM i.

Zestawy narzędzi firm Fresche, Google (G4) umożliwiają konwersję jeden do jednego (refaktoryzację) natywnych kodów źródłowych systemu IBM i i otwierają bramę do wdrażania aplikacji w systemach otwartych i chmurze. Jednak preferencja dla tej opcji maleje, biorąc pod uwagę łatwość konserwacji
i futurystyczny widok dla dużych przedsiębiorstw, takich jak banki. Banki, a dokładniej ubezpieczyciele, mają bardzo dynamiczne potrzeby biznesowe, takie jak stale rosnące wymagania regulacyjne i dotyczące zgodności, a co za tym idzie potrzeba łatwej w utrzymaniu bazy kodów.

Pozostawiając modernizację na miejscu (ostateczność) i refaktoryzację, pozostałe opcje można w dużej mierze pogrupować w jedną z dwóch opcji, a mianowicie wymianę COTS lub przepisanie całej aplikacji. Opcje te mają swoje zalety i wady. Dla większości
średnich i dużych banków oraz banków prowadzących działalność w wielu krajach lub w wielu lokalizacjach geograficznych, podstawowymi zastosowaniami są ich skarb, ich siła i czynnik umożliwiający to, czym są. Zatem stopień przyjęcia COTS będzie ograniczony ze względu na dokładne dopasowanie aplikacji COTS
za bogate możliwości banku, takie jak obsługa kart, zarządzanie lojalnością i nagrodami.

Teraz bankom pozostaje druga opcja, czyli przepisanie. Jak wszyscy wiedzą, przepisanie istniejącej aplikacji (funkcjonalnie równoważnej, ale aktualnej pod względem architektonicznym) na środowisko docelowe jest prawie jak budowanie nowej aplikacji. Inżynieria odwrotna
narzędzia Fresche i ARCAD pomagają przyspieszyć wyodrębnianie reguł. Nowy sposób programowania oparty na Agile, DevOps, Test Automation itp., przepisanie może nie zająć zbyt długo, ale też nie będzie krótkie. Niektóre duże banki próbowały napisać je na nowo
i eksperymentować. Wiele banków wykazuje zainteresowanie przepisaniem nowych przepisów, lecz poszukują opłacalnych, solidnych i pozbawionych ryzyka migracji o zmniejszonym ryzyku, do czego jest jeszcze daleko.

Oprócz oczekiwanego harmonogramu przepisania, czynniki takie jak strategiczna decyzja dotycząca docelowego krajobrazu, docelowe technologie, docelowa architektura, wyzwania regulacyjne i związane ze zgodnością, zmiany organizacyjne w celu przyjęcia działań transformacyjnych,
bieżące inwestycje w infrastrukturę ciężką itp. będą miały wpływ na ogólny harmonogram migracji do systemu IBM i w większości banków.

IBM stale inwestuje także w i regularnie modernizuje serwery Power (serwery oparte na Power10 wprowadzone na rynek w 2021 r.) oraz IBM i (7.5 wydany w maju 2022 r.), zapewniając wsparcie dla otwartych technologii, a także aby utrzymać dynamikę utrzymania tej platformy.
Okno wsparcia (ogólnie 7+3 lata – Normalne + Rozszerzone) i możliwość ponownego użycia serwerów Power w innych środowiskach (AIX) to tylko niektóre z ważnych czynników zapewniających dodatkową przestrzeń na podejmowanie decyzji (bez pośpiechu przy opuszczeniu platformy).

Wnioski

Biorąc pod uwagę wszystkie te czynniki, zapotrzebowanie na aplikacje systemu IBM i będzie nadal wysokie przez wiele lat. Oznacza to, że aplikacje te powinny być wspierane, utrzymywane i ulepszane do czasu, aż przedsiębiorstwa znajdą skuteczną, realną alternatywę. Ale na
jednocześnie coraz trudniej jest zaangażować pracowników posiadających umiejętności związane z systemem IBM i. Nadszedł czas, aby podnieść poziom personelu programistycznego, wykorzystując ulepszone środowiska IDE i narzędzia dla tej platformy.