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

Abstrakt

Det er sterke anbefalinger for at IBM i-applikasjoner skal moderniseres eller migreres til en futuristisk plattform, og det er også sterk nøling som driver anti-migrasjonsstemningen. Dette leder oss til spørsmålet; trenger vi å investere i kompetansesettet
av den eksisterende plattformen eller ikke?

Oversikt

IBM i er det gamle systemet, og det er målrettet for migrering av mange bedrifter på grunn av forskjellige årsaker. Her i denne bloggen vil vi utforske tilgjengelige alternativer for migrering i dagens scenario, sannsynligheten for at de blir tatt i bruk, årsaken til ikke rask sporing
migrasjonen eller exit og behovet for å løfte utviklingsarbeidsstyrken.

IBM i (omtrent kjent som AS/400) har vært et av de mest strategiske systemene for mange mellomstore og store foretak, inkludert bank, finansielle tjenester og forsikring (BFSI). Den har vært i bruk av alle disse foretakene i mer enn 25 til 30 år. Det vert kjerne
applikasjoner for banker og forsikringsselskaper inkludert Core Banking, Card Management, Policy Administration etc. IBM i, som vi diskuterer her, er hele økosystemet som følger med IBM i, maskinvaren, operativsystemet, programmeringsspråkene som RPG,
COBOL og CL, database DB2 for i, IBM MQ for meldingsutveksling, jobbadministrasjon, brukertilgang, sikkerhet etc. Legacy Modernisering har vært i diskusjon i banker i mange år nå, og IBM i er også i radaren for erstatning med ny teknologi på grunn av utfordringer
relatert til IBM i-plattformspesifikke ferdigheter (RPG, COBOL), monolitt-arkitektur av applikasjoner som fører til smidighetsproblemer, interoperabilitet med andre plattformer og DevOps-verktøy, ikke tilpasset strategiske investeringer, mangler de fleste skyfordelene (f.eks.
on-demand-kapasitet) etc. Samtidig er det flere årsaker til at migreringen utsettes. Noen av dem er nye maskinvareutgivelser, OS-utgivelser, utvidet støttevindu, gjeldende investeringer i tung infrastruktur, migrasjonsrisiko og kostnader.
Her prøver vi å måle de tidlige mulighetene for exit slik at avhengigheten av SMB-er skal forutses.

Vårt perspektiv

I løpet av perioden har virksomheten vokst, forretningskravene har vokst, ulike risikoer har vokst, compliance og regulatoriske krav har vokst, og til slutt har alle disse blitt fanget opp og tatt hånd om i én enkelt monolittapplikasjon for hver
bedriften. Og derav det høye nivået av kompleksitet med konsentrasjonen av all kunnskap, forretningsreglene, forretningsprosessene. I tillegg til dette har alle de tekniske implementeringene som multi-threading, meldinger, jobbplanlegging, jobbkontroll etc.,
er også en del av monolittimplementeringen.

Med bruken av Cloud, DevOps og Agile-praksis, leter bransjer og bedrifter, inkludert banker og forsikringsselskaper, også etter transformasjon av IBM i-applikasjoner for å høste de nyeste funksjonene og fordelene. Bedrifter har flere alternativer
foran dem. Denne plattformen kan følge smidig praksis og være en del av DevOps-verdenen med ARCAD-løsninger. En av de store britiske bankene har tatt i bruk DevOps på IBM i. Den nylig lanserte IBM i Merlin Platform (Modernization Engine for Lifecycle
Integration) hjelper dette med integrerte IDE, CI/CD Merlin-verktøy for DevOps-erfaring sammen med IBM i-virtuell maskinforsyning, REST API-administrasjon osv., og gir håp om et komplett DevOps-økosystem i fremtiden. Nylig utvikling hjelper til med smidighet
av IBM i-miljøer og re-hosting av applikasjonene. Systemadministrasjonen for denne plattformen skal avlastes ved å 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 å re-vert
applikasjonene på Azure eller AWS eller Google Cloud. Alle disse alternativene skal kategoriseres som enten in-place modernisering eller pseudo-modernisering og være avhengig av IBM i-kompetanse.

Verktøysett fra Fresche, Google (G4) gir én til én konvertering (refaktor) av IBMs opprinnelige kildekoder og åpner porten for distribusjon av applikasjonen på åpne systemer og sky. Men preferansen for dette alternativet falmer med tanke på vedlikeholdbarheten
og futuristisk syn for store bedrifter som banker. Banker og mer spesifikt forsikringsselskaper har svært dynamiske forretningsbehov som stadig økende krav til regelverk og etterlevelse, og derav behovet for svært vedlikeholdbar kodebase.

Ved å forlate på plass modernisering (siste utvei) og refactor, kan de andre alternativene i stor grad grupperes i ett av de to alternativene, nemlig COTS-erstatning eller omskriving av hele applikasjonen. Disse alternativene har sine egne fordeler og ulemper. For det meste av
mellomstore og store banker og banker med operasjoner i flere land eller flere geografier, er kjerneapplikasjonene deres skatt, deres styrke og muliggjøreren for hva de er. Så, COTS-adopsjonsfrekvensen vil være begrenset på grunn av den nøyaktige tilpasningen av COTS-applikasjonen
for bankens rike muligheter som kortbehandling, lojalitet og belønningsadministrasjon.

Nå sitter bankene igjen med det andre alternativet som er omskriving. Som alle vet, er å omskrive den eksisterende applikasjonen (funksjonelt ekvivalent, men arkitektonisk aktuell) til et mållandskap nesten som å bygge en ny applikasjon. Omvendt engineering
verktøy fra Fresche og ARCAD bidrar til å øke hastigheten på regelutvinningen. Den nye utviklingsmåten drevet med Agile, DevOps, Test Automation etc., omskrivingen vil kanskje ikke ta for lang tid, men den vil heller ikke være kort. Noen av de store bankene prøvde å skrive om
og eksperimentere. Mange banker viser interesse for å omskrive, men ser etter en kostnadseffektiv, robust og risikofri eller redusert risikomigrasjon som fortsatt er langt unna.

Bortsett fra den forventede tidslinjen for omskriving, faktorene som strategisk beslutning om mållandskap, målteknologier, målarkitektur, regulatoriske og samsvarsutfordringer, organisatoriske endringer for å ta i bruk transformasjonsaktivitetene,
nåværende investeringer i tung infrastruktur osv., kommer til å påvirke den overordnede IBM i-migrasjonstidslinjen for de fleste av bankene.

IBM investerer og oppgraderer også kontinuerlig Power-serverne (Power10-baserte servere lansert i 2021) og IBM i (7.5 utgitt i mai 2022) med jevne mellomrom, sammen med støtte for åpne teknologier også for å opprettholde momentumet for å beholde denne plattformen.
Støttevinduet (generelt 7+3 år – Normal + Utvidet) og gjenbrukbarheten av Power-servere for andre miljøer (AIX) er noen av de viktige faktorene som gir ekstra plass for beslutningstaking (ingen hast med å forlate plattformen).

konklusjonen

Med alle disse faktorene fortsetter behovet for å kjøre IBM i-applikasjonene å være høyt i mange år til. Det betyr at disse applikasjonene bør støttes, vedlikeholdes og forbedres til bedriftene finner et effektivt levedyktig alternativ. Men på
Samtidig blir det vanskeligere og vanskeligere å engasjere arbeidsstyrken på IBM i-kompetansesettet. Det er på tide å løfte utviklingsarbeidsstyrken ved å utnytte de forbedrede IDE-ene og verktøyene for denne plattformen.