Strategie zur Modernisierung von IBM i in der BFSI-Technologielandschaft (Noel Prince Moses V)

Abstrakt

Es gibt starke Empfehlungen für die Modernisierung oder Migration von IBM i-Anwendungen auf eine zukunftsweisende Plattform, und es gibt auch starke Zurückhaltung, die die Anti-Migrations-Stimmung fördert. Dies führt uns zu der Frage; Müssen wir in die Fähigkeiten investieren?
der bestehenden Plattform oder nicht?

Überblick

Da es sich bei IBM i um das Altsystem handelt, wird es aus verschiedenen Gründen von vielen Unternehmen für die Migration angestrebt. Hier in diesem Blog werden wir die verfügbaren Optionen für die Migration im heutigen Szenario, die Wahrscheinlichkeit ihrer Einführung und den Grund für die Nicht-Schnellverfolgung untersuchen
die Migration oder der Austritt und die Notwendigkeit, die Entwicklungsarbeitskräfte zu stärken.

IBM i (allgemein bekannt als AS/400) ist für viele mittlere bis große Unternehmen, darunter Banken, Finanzdienstleistungen und Versicherungen (BFSI), eines der strategisch wichtigsten Systeme. Bei all diesen Unternehmen ist es seit mehr als 25 bis 30 Jahren im Einsatz. Es beherbergt den Kern
Anwendungen für Banken und Versicherungen, einschließlich Core Banking, Kartenmanagement, Policenverwaltung usw. IBM i ist, wie wir hier besprechen, das gesamte Ökosystem, das mit IBM i einhergeht, der Hardware, dem Betriebssystem, den Programmiersprachen wie RPG,
COBOL und CL, Datenbank DB2 für i, IBM MQ für Messaging, Auftragsverwaltung, Benutzerzugriff, Sicherheit usw. Legacy-Modernisierung wird seit vielen Jahren in Banken diskutiert und IBM i steht aufgrund der neuen Technologien auch auf dem Radar der Ersetzung durch neue Technologien Herausforderungen
im Zusammenhang mit den spezifischen Fähigkeiten der IBM i-Plattform (RPG, COBOL), monolithischer Architektur von Anwendungen, die zu Agilitätsproblemen führt, Interoperabilität mit anderen Plattformen und DevOps-Tools, nicht auf strategische Investitionen ausgerichtet, fehlende Vorteile der Cloud (z. B.
On-Demand-Kapazität) usw. Gleichzeitig gibt es eine Reihe von Gründen, warum die Migration verschoben wird. Einige davon sind neue Hardware-Releases, Betriebssystem-Releases, erweiterte Supportfenster, die aktuellen Investitionen in umfangreiche Infrastruktur, Migrationsrisiken und -kosten.
Hier versuchen wir, die frühen Möglichkeiten eines Ausstiegs einzuschätzen, um die Abhängigkeit von seinen KMU vorherzusagen.

Unsere Perspektive

Im Laufe der Zeit ist das Unternehmen gewachsen, die Geschäftsanforderungen sind gewachsen, verschiedene Risiken sind gewachsen, Compliance- und behördliche Anforderungen sind gewachsen und schließlich wurden all diese Anforderungen in einer einzigen monolithischen Anwendung erfasst und verwaltet
Unternehmen. Und daher die hohe Komplexität mit der Konzentration des gesamten Wissens, der Geschäftsregeln, der Geschäftsprozesse. Hinzu kommen alle technischen Implementierungen wie Multithreading, Messaging, Job Scheduling, Job Control etc.,
sind ebenfalls Teil der Monolith-Implementierung.

Mit dem Aufkommen von Cloud-, DevOps- und Agile-Praktiken suchen Branchen und Unternehmen, darunter Banken und Versicherungen, auch nach einer Transformation von IBM i-Anwendungen, um von den neuesten Funktionen und Vorteilen zu profitieren. Unternehmen haben mehrere Möglichkeiten
vor ihnen. Diese Plattform kann agilen Praktiken folgen und mit ARCAD-Lösungen Teil der DevOps-Welt sein. Eine der großen britischen Banken hat DevOps auf IBM i erfolgreich eingeführt. Die kürzlich eingeführte IBM i Merlin Platform (Modernization Engine for Lifecycle
Integration) hilft dabei mit integrierten IDE-, CI/CD-Merlin-Tools für DevOps-Erlebnisse zusammen mit der Bereitstellung virtueller IBM i-Maschinen, der Verwaltung von REST-APIs usw. und lässt auf ein vollständiges DevOps-Ökosystem in der Zukunft hoffen. Aktuelle Entwicklungen helfen bei der Agilität
von IBM i-Umgebungen und Re-Hosting seiner Anwendungen. Die Systemverwaltung dieser Plattform wird durch die Migration der Infrastruktur direkt zur IBM Cloud oder zu Skytap auf Azure und IBM Cloud oder zu Connectria auf AWS ausgelagert. Infinite i ist in Rettung, um erneut zu hosten
die Anwendungen auf Azure oder AWS oder Google Cloud. Alle diese Optionen werden entweder als In-Place-Modernisierung oder Pseudo-Modernisierung kategorisiert und hängen von den IBM i-Fähigkeiten ab.

Tool-Sets von Fresche, Google (G4) ermöglichen eine Eins-zu-eins-Konvertierung (Refaktorierung) von nativen IBM i-Quellcodes und öffnen das Tor für die Bereitstellung der Anwendung auf offenen Systemen und in der Cloud. Angesichts der Wartbarkeit schwindet jedoch die Bevorzugung dieser Option
und futuristische Sichtweise für große Unternehmen wie Banken. Banken und insbesondere Versicherer haben sehr dynamische Geschäftsanforderungen wie ständig steigende Regulierungs- und Compliance-Anforderungen und daher den Bedarf an einer gut wartbaren Codebasis.

Abgesehen von der direkten Modernisierung (letzter Ausweg) und der Umgestaltung können die anderen Optionen weitgehend in eine der beiden Optionen gruppiert werden, nämlich COTS-Ersatz oder Neuschreiben der gesamten Anwendung. Diese Optionen haben ihre eigenen Vor- und Nachteile. Für die meisten
Bei mittelgroßen und großen Banken und Banken mit Niederlassungen in mehreren Ländern oder Regionen sind die Kernanwendungen ihr Schatz, ihre Stärke und der Wegbereiter für das, was sie sind. Daher wird die COTS-Einführungsrate aufgrund der genauen Anpassung der COTS-Anwendung begrenzt sein
für die umfangreichen Funktionen der Bank wie Kartenverarbeitung, Treue- und Prämienmanagement.

Jetzt bleibt den Banken nur noch die andere Option: Umschreiben. Wie jeder weiß, ist das Umschreiben der vorhandenen Anwendung (funktional gleichwertig, aber architektonisch aktuell) in eine Ziellandschaft fast so, als würde man eine neue Anwendung erstellen. Reverse Engineering
Tools von Fresche und ARCAD helfen dabei, die Regelextraktion zu beschleunigen. Bei der neuen Art der Entwicklung, die auf Agile, DevOps, Testautomatisierung usw. basiert, wird das Umschreiben vielleicht nicht allzu lange dauern, aber auch nicht kurz. Einige der großen Banken versuchten es umzuschreiben
und experimentieren. Viele Banken zeigen Interesse an einer Umschreibung, suchen aber nach einer kostengünstigen, robusten und risikofreien oder risikoreduzierten Migration, die noch in weiter Ferne liegt.

Neben dem erwarteten Zeitplan für die Neufassung spielen Faktoren wie die strategische Entscheidung über die Ziellandschaft, die Zieltechnologien, die Zielarchitektur, die regulatorischen und Compliance-Herausforderungen, organisatorische Änderungen zur Übernahme der Transformationsaktivitäten usw. eine Rolle
Die derzeitigen Investitionen in umfangreiche Infrastrukturen usw. werden sich bei den meisten Banken auf den Gesamtzeitplan für die IBM i-Migration auswirken.

IBM investiert und aktualisiert außerdem regelmäßig die Power-Server (Power10-basierte Server, die im Jahr 2021 eingeführt wurden) und IBM i (7.5, veröffentlicht im Mai 2022) und unterstützt auch offene Technologien, um die Dynamik bei der Beibehaltung dieser Plattform aufrechtzuerhalten.
Das Supportfenster (im Allgemeinen 7+3 Jahre – Normal + Erweitert) und die Wiederverwendbarkeit von Power-Servern für andere Umgebungen (AIX) sind einige der wichtigen Faktoren, die zusätzlichen Raum für die Entscheidungsfindung bieten (keine Eile, die Plattform zu verlassen).

Zusammenfassung

Angesichts all dieser Faktoren bleibt der Bedarf an der Ausführung von IBM i-Anwendungen noch viele Jahre lang hoch. Das bedeutet, dass diese Anwendungen unterstützt, gewartet und verbessert werden sollten, bis die Unternehmen eine effektive, tragfähige Alternative finden. Aber am
Gleichzeitig wird es immer schwieriger, die Belegschaft für die IBM i-Kenntnisse zu begeistern. Es ist an der Zeit, die Entwicklungsarbeitskräfte durch die Nutzung der verbesserten IDEs und Tools für diese Plattform zu stärken.