Strategia IBM i -modernisoimiseksi BFSI-teknologiaympäristössä (Noel Prince Moses V)

Abstrakti

On olemassa vahvoja suosituksia IBM i -sovellusten modernisoimisesta tai siirtämisestä futuristiselle alustalle, ja myös epäröintiä on voimakasta, mikä ajaa siirtolaisuuden vastaista mieltä. Tämä johtaa meidät kysymykseen; tarvitseeko meidän panostaa osaamiseen
nykyisestä alustasta vai ei?

Yleiskatsaus

Koska IBM i on vanha järjestelmä, se on suunnattu monille yrityksille eri syistä johtuen siirtymiseen. Tässä blogissa tutkimme käytettävissä olevia siirtovaihtoehtoja tämän päivän skenaariossa, niiden käyttöönoton todennäköisyyttä ja syytä siihen, miksi ei nopeuta seurantaa.
maahanmuutto tai poistuminen ja tarve kohottaa kehitystyövoimaa.

IBM i (tunnetaan laajalti nimellä AS/400) on ollut yksi strategisimmista järjestelmistä monille keskisuurille ja suurille yrityksille, mukaan lukien pankki-, rahoitus- ja vakuutusala (BFSI). Se on ollut kaikkien näiden yritysten käytössä yli 25-30 vuoden ajan. Se isännöi ydintä
sovelluksia pankeille ja vakuutusyhtiöille, mukaan lukien ydinpankkitoiminta, korttien hallinta, vakuutusten hallinta jne. IBM i, kuten täällä keskustelemme, on koko ekosysteemi, joka tulee IBM i:n, laitteiston, käyttöjärjestelmän, ohjelmointikielten, kuten RPG:n, kanssa,
COBOL ja CL, tietokanta DB2 for i, IBM MQ viestintään, työnhallintaan, käyttäjien pääsyyn, tietoturvaan jne. Legacy Modernization on keskusteltu pankeissa jo monta vuotta, ja IBM i on myös tutkalla korvaamaan uusia teknologioita, koska haasteita
liittyy IBM i -alustakohtaiseen osaamiseen (RPG, COBOL), sovellusten monoliittinen arkkitehtuuri, joka johtaa ketteryysongelmiin, yhteentoimivuus muiden alustojen ja DevOps-työkalujen kanssa, ei sovitettu strategisiin investointeihin, puuttuu suurin osa pilvieduista (esim.
on-demand-kapasiteetti) jne. Samaan aikaan on monia syitä siihen, miksi siirtymistä lykätään. Jotkut niistä ovat uusia laitteistojulkaisuja, käyttöjärjestelmän julkaisuja, laajennettu tukiikkuna, nykyiset investoinnit raskaaseen infrastruktuuriin, siirtymisriski ja -kustannukset.
Tässä yritämme mitata sen varhaisia ​​mahdollisuuksia irtautua, jotta voidaan ennustaa riippuvuus sen pk-yrityksistä.

Meidän näkökulmamme

Ajan mittaan liiketoiminta on kasvanut, liiketoiminnan vaatimukset ovat kasvaneet, erilaiset riskit ovat kasvaneet, vaatimustenmukaisuus ja säännösten vaatimukset ovat kasvaneet ja lopulta kaikki nämä on kerätty ja hoidettu yhdellä monoliittisella sovelluksella jokaiselle
yritys. Ja tästä johtuu korkea monimutkaisuus, jossa on keskittynyt kaikki tieto, liiketoimintasäännöt ja liiketoimintaprosessit. Lisätty tähän kaikki tekniset toteutukset, kuten monisäie, viestintä, työn ajoitus, työnhallinta jne.,
ovat myös osa monoliittitoteutusta.

Pilvi-, DevOps- ja Agile-käytäntöjen myötä teollisuudenalat ja yritykset, mukaan lukien pankkiirit ja vakuutusyhtiöt, etsivät muutosta IBM i -sovelluksiin sekä hyödyntääkseen uusimpia ominaisuuksia ja etuja. Yrityksillä on useita vaihtoehtoja
heidän edessään. Tällä alustalla voi seurata ketteriä käytäntöjä ja olla osa DevOps-maailmaa ARCAD-ratkaisujen avulla. Yksi Iso-Britannian suurista pankeista on ottanut DevOpsin käyttöön IBM i:ssä onnistuneesti. Äskettäin lanseerattu IBM i Merlin Platform (Modernization Engine for Lifecycle
Integraatio) auttaa tässä integroiduilla IDE-, CI/CD Merlin -työkaluilla DevOps-kokemukseen sekä IBM i -virtuaalikoneen hallintaan, REST-sovellusliittymien hallintaan jne. ja tuo toivoa täydellisestä DevOps-ekojärjestelmästä tulevaisuudessa. Viimeaikainen kehitys auttaa agilityssä
IBM i -ympäristöistä ja sen sovellusten uudelleenisännöimisestä. Tämän alustan järjestelmänhallinta puretaan siirtämällä infrastruktuuri suoraan IBM Cloudiin tai Skytapiin Azuressa ja IBM Cloudissa tai Connectriaan AWS:ssä. Infinite i on pelastuksessa isännöimään uudelleen
Azure- tai AWS- tai Google Cloud -sovellukset. Kaikki nämä vaihtoehdot luokitellaan joko nykyaikaisiksi tai näennäismodernisoinneiksi, ja ne ovat riippuvaisia ​​IBM i -osaamista.

Freschen, Googlen (G4) työkalusarjat tarjoavat IBM i:n alkuperäisten lähdekoodien muuntamisen (refactor) yhdestä yhteen ja avaa portin sovelluksen käyttöönotolle avoimissa järjestelmissä ja pilvessä. Mutta tämän vaihtoehdon suosio on hiipumassa huollettavuuden vuoksi
ja futuristinen näkemys suurille yrityksille, kuten pankeille. Pankeilla ja erityisesti vakuutuksenantajilla on erittäin dynaamisia liiketoiminnan tarpeita, kuten jatkuvasti kasvavat sääntely- ja vaatimustenmukaisuusvaatimukset ja näin ollen tarve erittäin ylläpidettävälle koodipohjalle.

Jättäen nykyaikaistamisen (viimeinen keino) ja uudelleenjärjestelyn, muut vaihtoehdot voidaan suurelta osin ryhmitellä jompaankumpaan kahdesta vaihtoehdosta, nimittäin COTS-korvaukseen tai koko sovelluksen uudelleenkirjoittamiseen. Näillä vaihtoehdoilla on omat hyvät ja huonot puolensa. Suurimmalle osalle
Keskikokoiset ja suuret pankit ja pankit, jotka toimivat useissa maissa tai useilla maantieteellisillä alueilla, ydinsovellukset ovat niiden aarre, vahvuus ja mahdollistaja sille, mitä ne ovat. Joten COTS-käyttöaste on rajoitettu COTS-sovelluksen tarkan sovituksen vuoksi
pankin monipuolisille ominaisuuksille, kuten korttien käsittelylle, uskollisuudelle ja palkkioiden hallintalle.

Nyt pankeille jää toinen vaihtoehto, joka on uudelleenkirjoitus. Kuten kaikki tietävät, olemassa olevan sovelluksen (toiminnallisesti vastaava, mutta arkkitehtonisesti ajankohtainen) uudelleenkirjoittaminen kohdemaisemaan on melkein kuin uuden sovelluksen rakentamista. Käänteinen suunnittelu
Freschen ja ARCADin työkalut auttavat nopeuttamaan sääntöjen purkamista. Agile-, DevOps-, Test Automation- jne. -teknologian uusi kehitystapa, uudelleenkirjoitus ei välttämättä kestä liian kauan, mutta se ei myöskään ole lyhyt. Jotkut suuret pankit yrittivät kirjoittaa uudelleen
ja kokeilemalla. Monet pankit ovat kiinnostuneita uudelleenkirjoittamisesta, mutta etsivät kustannustehokasta, kestävää ja riskitöntä tai vähäriskistä siirtymistä, joka on vielä kaukana.

Odotetun uudelleenkirjoituksen aikajanan lisäksi tekijät, kuten strateginen päätös kohdemaisemasta, kohdeteknologiat, kohdearkkitehtuuri, sääntely- ja vaatimustenmukaisuushaasteet, organisaatiomuutokset muutostoimintojen käyttöönottamiseksi,
Nykyiset investoinnit raskaisiin infrastruktuureihin jne. vaikuttavat useimpien pankkien IBM i -siirtymisaikajanaan.

IBM myös investoi ja päivittää jatkuvasti Power-palvelimia (Power10-pohjaiset palvelimet lanseerattiin vuonna 2021) ja IBM i:tä (7.5 julkaistiin toukokuussa 2022) säännöllisin väliajoin sekä tukea avoimille teknologioille pitääkseen vauhtia tämän alustan säilyttämisessä.
Tukiikkuna (yleensä 7+3 vuotta – Normaali + Extended) ja Power-palvelimien uudelleenkäytettävyys muihin ympäristöihin (AIX) ovat tärkeitä tekijöitä, jotka antavat lisätilaa päätöksenteolle (ei kiirettä poistua alustasta).

Yhteenveto

Kaikista näistä tekijöistä johtuen IBM i -sovellusten käyttötarve pysyy korkeana vielä monta vuotta. Se tarkoittaa, että näitä sovelluksia tulee tukea, ylläpitää ja tehostaa, kunnes yritykset löytävät tehokkaan elinkelpoisen vaihtoehdon. Mutta klo
Samaan aikaan on yhä vaikeampaa saada työntekijöitä mukaan IBM i -taitosarjaan. On aika kohottaa kehitystyövoimaa hyödyntämällä tämän alustan parannettuja IDE:itä ja työkaluja.