Strategi for IBM i-modernisering i BFSI-teknologilandskab (Noel Prince Moses V)

Abstrakt

Der er stærke anbefalinger til, at IBM i-applikationer skal moderniseres eller migreres til en futuristisk platform, og der er også stærk tøven, hvilket driver anti-migrationsstemningen. Dette leder os til spørgsmålet; skal vi investere i kompetencerne
af den eksisterende platform eller ej?

Oversigt

Da IBM i er det gamle system, er det målrettet mod migrering af mange virksomheder af forskellige årsager. Her i denne blog vil vi undersøge tilgængelige muligheder for migrering i dagens scenarie, sandsynligheden for deres vedtagelse, årsagen til ikke hurtig sporing
migrationen eller exit og behovet for at løfte udviklingsarbejdsstyrken.

IBM i (bredt kendt som AS/400) har været et af de mest strategiske systemer for mange mellemstore og store virksomheder, herunder Banking, Financial Services and Insurance (BFSI). Det er i brug af alle disse virksomheder i mere end 25 til 30 år. Det er vært for kerne
applikationer til banker og forsikringsselskaber, herunder Core Banking, Card Management, Policy Administration osv. IBM i, som vi diskuterer her, er hele økosystemet, der følger med IBM i, hardwaren, operativsystemet, programmeringssprogene som RPG,
COBOL og CL, database DB2 for i, IBM MQ til meddelelser, jobadministration, brugeradgang, sikkerhed osv. Legacy Modernisering har været til diskussion i banker i mange år nu, og IBM i er også i radaren for at blive erstattet af nye teknologier på grund af udfordringerne
relateret til IBM i-platformspecifikke færdigheder (RPG, COBOL), monolit-arkitektur af applikationer, der fører til agility-problemer, interoperabilitet med andre platforme og DevOps-værktøjer, ikke tilpasset strategiske investeringer, mangler de fleste af cloud-fordele (f.eks.
on-demand kapacitet) osv. Samtidig er der flere grunde til, at migreringen udskydes. Nogle af dem er nye hardwareudgivelser, OS-udgivelser, udvidet supportvindue, de nuværende investeringer i tung infrastruktur, migrationsrisiko og omkostninger.
Her forsøger vi at måle de tidlige muligheder for dets exit, så afhængigheden af ​​dets SMV'er kan forudsiges.

Vores perspektiv

I løbet af perioden er virksomheden vokset, forretningskravene er vokset, forskellige risici er vokset, compliance- og regulatoriske krav er vokset, og til sidst er alle disse blevet fanget og behandlet inden for en enkelt monolitapplikation for hver
virksomhed. Og deraf det høje niveau af kompleksitet med koncentrationen af ​​al viden, forretningsreglerne, forretningsprocesserne. Tilføjet til dette alle de tekniske implementeringer som multi-threading, messaging, jobplanlægning, jobkontrol osv.,
er også en del af monolitimplementeringen.

Med fremkomsten af ​​Cloud, DevOps og Agile-praksis leder industrier og virksomheder, herunder bankfolk og forsikringsselskaber, efter transformation af IBM i-applikationer også for at høste de nyeste funktioner og fordele. Virksomheder har flere muligheder
foran dem. Denne platform kan følge agile praksisser og være en del af DevOps-verdenen med ARCAD-løsninger. En af de store britiske banker har med succes vedtaget DevOps på IBM i. Den nyligt lancerede IBM i Merlin Platform (Modernization Engine for Lifecycle
Integration) hjælper dette med integrerede IDE, CI/CD Merlin-værktøjer til DevOps-erfaring sammen med IBM i-virtuel maskine-provisionering, REST APIs-administration osv., og giver håb om et komplet DevOps-økosystem i fremtiden. Den seneste udvikling hjælper med agility
af IBM i-miljøer og genhoste dets applikationer. Systemadministrationen af ​​denne platform skal aflastes ved at migrere infrastruktur direkte til IBM Cloud eller til Skytap på Azure og IBM Cloud eller til Connectria på AWS. Infinite i er i redning for at gen-værte
applikationerne på Azure eller AWS eller Google Cloud. Alle disse muligheder skal kategoriseres som enten in-place modernisering eller pseudo-modernisering og er afhængige af IBM i-færdighedssæt.

Værktøjssæt fra Fresche, Google (G4) leverer én til én konvertering (refaktor) af IBMs oprindelige kildekoder og åbner gatewayen for udrulning af applikationen på åbne systemer og cloud. Men præferencen for denne mulighed forsvinder i betragtning af vedligeholdelsesevnen
og futuristisk syn for store virksomheder som banker. Banker og mere specifikt forsikringsselskaber har meget dynamiske forretningsbehov som stadigt stigende regulerings- og overholdelseskrav og dermed behovet for en meget vedligeholdelsesbar kodebase.

Hvis man forlader moderniseringen på stedet (sidste udvej) og refactor, kan de andre muligheder stort set grupperes i en af ​​de to muligheder, nemlig COTS-erstatning eller omskrivning af hele applikationen. Disse muligheder har deres egne fordele og ulemper. For det meste af
mellemstore og store banker og banker med multi-country eller multi-geografi operationer, kerneapplikationerne er deres skat, deres styrke og muliggør, hvad de er. Så COTS-vedtagelseshastigheden vil være begrænset på grund af den nøjagtige tilpasning af COTS-applikationen
for bankens rige muligheder såsom kortbehandling, loyalitet og belønningsstyring.

Nu står bankerne tilbage med den anden mulighed, som er omskrivning. Som alle ved, er omskrivning af den eksisterende applikation (funktionelt ækvivalent, men arkitektonisk aktuel) til et mållandskab næsten som at bygge en ny applikation. Reverse engineering
værktøjer fra Fresche og ARCAD hjælper med at fremskynde regeludtrækningen. Den nye måde at udvikle på med Agile, DevOps, Test Automation osv., omskrivningen tager muligvis ikke for lang tid, men den vil heller ikke være kort. Nogle af de store banker forsøgte at omskrive
og eksperimentere. Mange banker viser interesse for omskrivning, men leder efter en omkostningseffektiv, robust og risikofri eller reduceret risiko-migrering, som stadig er langt væk.

Bortset fra den forventede tidslinje for omskrivning, faktorer som strategisk beslutning om mållandskab, målteknologier, målarkitektur, regulatoriske og compliance-udfordringer, organisatoriske ændringer for at vedtage transformationsaktiviteterne,
nuværende investeringer i tung infrastruktur osv. vil påvirke den overordnede IBM i-migreringstidslinje for de fleste af bankerne.

IBM investerer og opgraderer også løbende Power-serverne (Power10-baserede servere lanceret i 2021) og IBM i (7.5 udgivet i maj 2022) på regelmæssig basis sammen med understøttelse af åbne teknologier også for at holde momentum på at bevare denne platform.
Supportvinduet (generelt 7+3 år – Normal + Udvidet) og genbrugbarheden af ​​Power-servere til andre miljøer (AIX) er nogle af de vigtige faktorer, der giver ekstra plads til beslutningstagning (ingen hastværk med at forlade platformen).

Konklusion

Med alle disse faktorer fortsætter behovet for at køre IBM i-applikationerne med at forblive højt i mange år endnu. Det betyder, at disse applikationer skal understøttes, vedligeholdes og forbedres, indtil virksomhederne finder en effektiv levedygtig alternativ. Men ved
Samtidig bliver det sværere og sværere at engagere arbejdsstyrken på IBM i-kvalifikationssæt. Det er tid til at løfte udviklingsarbejdsstyrken ved at udnytte de forbedrede IDE'er og værktøjer til denne platform.