In einem Interview mit The Financial Revolutionist erläutert Holland, weshalb die automatisierte Codegenerierung nur einen Teil komplexer Modernisierungsvorhaben abdecke.
Lizenzrechte können die Core-Banking-Migration ausbremsen
Ein häufig unterschätztes Hindernis seien die Lizenzbedingungen kommerzieller Kernbanksysteme. Holland nennt als Beispiele die Mainframe-basierten Systeme Hogan und Systematics. Viele Banken verfügten über Quellcode-Lizenzen und hätten die Anwendungen über Jahrzehnte umfangreich angepasst. Daraus ergebe sich jedoch nicht zwangsläufig das Recht, die Software auf eine andere Technologieplattform zu migrieren.
Dies beeinflusse auch die Modernisierungsstrategie. Nach Hollands Beobachtung setzen Banken deshalb häufig auf das sogenannte Strangler-Fig-Pattern beziehungsweise „Strangle the Core“. Dabei würden zunächst selbst entwickelte Module rund um das eigentliche Kernbanksystem modernisiert. So ließen sich Mainframe-Workloads schrittweise reduzieren, während das lizenzierte Core-Banking-System unverändert bestehen bleibe.
Holland erwartet, dass viele Institute in den kommenden fünf Jahren auch diese verbliebenen Kernsysteme angehen müssten. Für zahlreiche Banken könne dann nur die vollständige Ablösung durch eine Core-Banking-Plattform der dritten oder vierten Generation infrage kommen.
Datenmigration: Warum relationale Datenbanken im Vorteil sein können
Eine weitere Herausforderung sieht Holland in der Datenhaltung. Mainframe-Anwendungen nutzten neben relationalen Datenbanken wie Db2 weiterhin VSAM-Dateien sowie Datenbanksysteme wie IMS, IDMS, Adabas oder Datacom.
Bei der Migration müsse deshalb nicht nur der Anwendungscode transformiert werden. Ebenso wichtig seien geeignete ETL-Verfahren (Extract, Transform, Load), um die Daten in moderne relationale Datenbankmanagementsysteme (RDBMS) wie PostgreSQL oder SQL Server zu überführen.
Holland warnt dabei vor einem vorschnellen Wechsel zu NoSQL-Datenbanken. Mainframe-Anwendungen seien häufig auf die Verarbeitung hoher Transaktionsvolumina ausgelegt. Wenn funktionale Gleichwertigkeit, Performance und Durchsatz erhalten bleiben sollten, seien klassische relationale Datenbanken aus seiner Sicht die geeignetere Wahl.
COBOL-to-Java-Konvertierung reicht häufig nicht aus
Auch die Vielfalt der eingesetzten Programmiersprachen erschwere eine automatisierte Transformation. Neben COBOL enthielten Mainframe-Anwendungen häufig Assembler-Komponenten oder seien teilweise in PL/I beziehungsweise 4GL-Sprachen wie Natural, CA Gen oder Telon entwickelt worden. Hinzu kämen Batch-Skriptsprachen wie REXX oder CLIST.
Während die automatisierte COBOL-to-Java- beziehungsweise COBOL-to-C#-Konvertierung seit Langem etabliert sei, unterstützten viele Refactoring-Werkzeuge nicht sämtliche dieser Technologien. Unternehmen müssten deshalb unter Umständen mehrere Transformationslösungen einsetzen und deren Ergebnisse anschließend zusammenführen.
Diese Heterogenität stellt laut Holland auch die neue Generation KI-basierter Refactoring-Agenten vor Probleme. Viele der bisherigen Angebote könnten Anwendungen außerhalb der COBOL-Welt noch nicht ausreichend abdecken.
KI-gestütztes Refactoring erhöht die Anforderungen an Tests
Besonders großes Potenzial sieht Holland beim Einsatz agentischer KI für Application Discovery, die Dokumentation bestehender Geschäftsprozesse und die Testautomatisierung. Kritischer beurteilt er Ansätze, bei denen KI zunächst durch Reverse Engineering die bestehende Anwendung analysiert und anschließend durch Forward Engineering eine neue Anwendung erzeugt.
Gelingt es den Agenten nicht, die vorhandene Geschäftslogik vollständig zu rekonstruieren, mahnt der Experte, können Funktionen fehlen oder durch von der KI angenommene beziehungsweise erfundene Logik ersetzt werden.
Zusätzliche Schwierigkeiten entstünden, wenn die neue Anwendung nicht nur konvertiert, sondern grundlegend neu architektiert werde. Dann sei ein direkter Eins-zu-eins-Vergleich zwischen Alt- und Neusystem häufig nicht möglich. Entsprechend sorgfältig müsse die neue Anwendung getestet werden.
Bei Banken kämen weitere Anforderungen hinzu. KI-basierte Modernisierungslösungen müssten sich in bestehende Governance- und Sicherheitsvorgaben integrieren und bereits freigegebene Large Language Models (LLMs) nutzen können. Während KI-Agenten für Application Discovery und Testautomatisierung zunehmend akzeptiert würden, beobachtet Holland bei der automatisierten Transformation von Legacy-Code weiterhin Zurückhaltung.
Trotz der Fortschritte durch agentische KI bleibe die Mainframe-Modernisierung damit ein komplexes Transformationsvorhaben. Holland rechnet zwar mit sinkenden Kosten, geringerem Ressourcenbedarf und kürzeren Projektlaufzeiten. Umfassende Migrationen würden aber auch künftig Monate oder Jahre benötigen. (td)
Foto: LinkedIn/Paul Holland
