Strategi för modernisering av IBM i i BFSI-tekniklandskap (Noel Prince Moses V)

Abstrakt

Det finns starka rekommendationer för att IBM i-applikationer ska moderniseras eller migreras till en futuristisk plattform och det finns också en stark tvekan som driver anti-migrationskänslan. Detta leder oss till frågan; behöver vi investera i kompetensen
av den befintliga plattformen eller inte?

Översikt

Eftersom IBM i är det äldre systemet, är det inriktat på migrering av många företag på grund av olika anledningar. Här i den här bloggen kommer vi att utforska tillgängliga alternativ för migrering i dagens scenario, sannolikheten för att de antas, anledningen till att inte snabbspårning
migrationen eller exit och behovet av att lyfta utvecklingsarbetskraften.

IBM i (känd som AS/400) har varit ett av de mest strategiska systemen för många mellanstora och stora företag, inklusive bank, finansiella tjänster och försäkringar (BFSI). Den har använts av alla dessa företag i mer än 25 till 30 år. Den är värd för kärnan
applikationer för banker och försäkringsbolag inklusive Core Banking, Card Management, Policy Administration etc. IBM i, som vi diskuterar här, är hela ekosystemet som följer med IBM i, hårdvaran, operativsystemet, programmeringsspråken som RPG,
COBOL och CL, databas DB2 för i, IBM MQ för meddelandehantering, jobbhantering, användaråtkomst, säkerhet etc. Legacy Modernisering har diskuterats inom banker i många år nu och IBM i är också i radarn för att ersättas med ny teknologi på grund av utmaningar
relaterat till IBM i-plattformsspecifika färdigheter (RPG, COBOL), monolitarkitektur för applikationer som leder till smidighetsproblem, interoperabilitet med andra plattformar och DevOps-verktyg, inte anpassade till strategiska investeringar, missar de flesta molnfördelarna (t.ex.
on-demand-kapacitet) etc. Samtidigt finns det flera anledningar till att migrationen skjuts upp. Några av dem är nya hårdvaruversioner, OS-släpp, utökat supportfönster, nuvarande investeringar i tung infrastruktur, migreringsrisk och kostnad.
Här försöker vi bedöma de tidiga möjligheterna för dess exit så att beroendet av dess små och medelstora företag ska förutsägas.

Vårt perspektiv

Under perioden har verksamheten vuxit, affärskraven har vuxit, olika risker har vuxit, efterlevnads- och regulatoriska krav har vuxit och så småningom har alla dessa fångats och tagits om hand inom en enda monolitapplikation för varje
företag. Och därav den höga nivån av komplexitet med koncentrationen av all kunskap, affärsreglerna, affärsprocesserna. Till detta kommer alla tekniska implementeringar som multi-threading, meddelandehantering, jobbschemaläggning, jobbkontroll etc.,
är också en del av monolitimplementeringen.

Med intåget av moln, DevOps och Agile praxis letar industrier och företag, inklusive banker och försäkringsbolag, efter transformation av IBM i-applikationer också för att skörda de senaste funktionerna och fördelarna. Företag har flera alternativ
framför dem. Denna plattform kan följa agila praxis och vara en del av DevOps-världen med ARCAD-lösningar. En av de stora brittiska bankerna har antagit DevOps på IBM i framgångsrikt. Den nyligen lanserade IBM i Merlin Platform (Modernization Engine for Lifecycle
Integration) hjälper detta med integrerade IDE, CI/CD Merlin-verktyg för DevOps-upplevelse tillsammans med IBM i-virtual machine provisioning, REST API-hantering etc., och ger hopp om ett komplett DevOps ekosystem i framtiden. Den senaste utvecklingen hjälper till med agility
av IBM i-miljöer och återhosta dess applikationer. Systemadministrationen av denna plattform ska laddas ur genom att migrera infrastruktur direkt till IBM Cloud eller till Skytap på Azure och IBM Cloud eller till Connectria på AWS. Infinite i är i räddning för att återställa värd
applikationerna på Azure eller AWS eller Google Cloud. Alla dessa alternativ ska kategoriseras som antingen modernisering på plats eller pseudomodernisering och är beroende av IBM i-kompetens.

Verktygsset från Fresche, Google (G4) tillhandahåller en till en konvertering (refaktor) av IBMs inbyggda källkoder och öppnar porten för distribution av applikationen på öppna system och moln. Men preferensen för detta alternativ bleknar med tanke på underhållbarheten
och futuristisk syn för stora företag som banker. Banker och mer specifikt försäkringsbolag har mycket dynamiska affärsbehov som ständigt ökande krav på regelverk och efterlevnad och därmed behovet av mycket underhållbar kodbas.

Om man lämnar in-place modernisering (sista utväg) och refactor, kan de andra alternativen till stor del grupperas i ett av de två alternativen, nämligen COTS-ersättning eller omskrivning av hela applikationen. Dessa alternativ har sina egna för- och nackdelar. För de flesta av
medelstora och stora banker och banker med verksamhet i flera länder eller flera geografiska områden, är kärnapplikationerna deras skatt, deras styrka och möjliggöraren för vad de är. Så COTS-användningsfrekvensen kommer att vara begränsad på grund av den exakta anpassningen av COTS-applikationen
för bankens rika möjligheter som korthantering, lojalitet och belöningshantering.

Nu har bankerna det andra alternativet som är omskrivning. Som alla vet är att skriva om den befintliga applikationen (funktionellt likvärdig men arkitektoniskt aktuell) till ett mållandskap nästan som att bygga en ny applikation. Reverse engineering
verktyg från Fresche och ARCAD hjälper till att påskynda regelextraktionen. Det nya utvecklingssättet som drivs med Agile, DevOps, Test Automation etc., omskrivningen kanske inte tar för lång tid men den blir inte heller kort. Några av de stora bankerna försökte skriva om
och experimenterar. Många banker visar intresse för att skriva om men letar efter en kostnadseffektiv, robust och riskfri eller minskad risk migration som fortfarande är långt borta.

Förutom den förväntade tidslinjen för omskrivning, faktorer som strategiska beslut om mållandskap, målteknologier, målarkitektur, regelverks- och efterlevnadsutmaningar, organisatoriska förändringar för att anta transformationsaktiviteterna,
nuvarande investeringar i tung infrastruktur etc. kommer att påverka den övergripande IBM i-migreringstidslinjen för de flesta av bankerna.

IBM investerar och uppgraderar också kontinuerligt Power-servrarna (Power10-baserade servrar lanserades 2021) och IBM i (7.5 släpptes i maj 2022) på regelbunden basis tillsammans med stöd för öppen teknik också för att hålla farten på att behålla denna plattform.
Supportfönstret (i allmänhet 7+3 år – Normal + Extended) och återanvändbarheten av Power-servrar för andra miljöer (AIX) är några av de viktiga faktorerna som ger ytterligare utrymme för beslutsfattande (ingen brådska att lämna plattformen).

Slutsats

Med alla dessa faktorer fortsätter behovet av att köra IBM i-applikationerna att vara stort i många år till. Det betyder att dessa applikationer bör stödjas, underhållas och förbättras tills företagen hittar en effektiv livskraftig alternativ. Men vid
Samtidigt blir det svårare och svårare att engagera personalen på IBM i-kompetensen. Det är dags att lyfta utvecklingspersonalen genom att utnyttja de förbättrade IDE:erna och verktygen för denna plattform.