Digitalisierung und Innovation / 28.01.2021 / Klaus Kudjakov

Fünf Modernisierungsstrategien für Kernbankensysteme

Im Kernbankensystem (Core Banking System – CBS) spielt sich die digitale Bearbeitung der fachlichen Kernprozesse einer Bank ab. Die vorliegende Artikelserie beschäftigt sich mit der Frage, welche Modernisierungsschritte bei vorhandenen Kernbanksysteme notwendig sind, damit sie die Anforderungen aktueller Markt- und Technologie-Trends erfüllen. Teil 3 betrachtet fünf Strategien, mit denen Banken ihre Kernbanksysteme für die Zukunft ausrichten.

Halten wir fest: Open-Banking, Digitalisierung und Automatisierung von Prozessen, Banking-Plattformen sowie kundenzentriertes Banking stellen für die rein bankfachliche Leistungsfähigkeit eines ausgereiften, Echtzeit-fähigen Kernbankensystems meist keine besonderen Anforderungen.

Ausschlaggebend ist aber sehr wohl, inwieweit die Architektur eines Kernbankensystems die Offenheit bietet, die implementierten Services und Daten externen Dritten oder auch Applikationen über definierte Schnittstellen bereitzustellen. Ziel muss sein, die Funktionen und Daten schnell, sicher und konsistent an die möglichst standardisierten und automatisierten Prozesse anzubinden – ohne, dass dabei örtliche, zeitliche und gerätetechnischen Barrieren bestehen.

Ein neues oder erneuertes Kernbankensystem sollte in punkto Architektur über Microservices und standardisierte APIs verfügen. Damit kann die operierende Bank die benötigten bankfachlichen Funktionen modular entwickeln und einsetzen.

Neuentwicklung, Migration – oder Evolution?

Damit ein Kernbankensystem möglichst ohne Einschränkung in der Zukunft genutzt werden kann, braucht es also eine moderne und offene Architektur. Für diese stellt beispielsweise das Veralten von Programmiersprachen kein Hindernis mehr dar. Es gibt hierfür drei Optionen: Entweder eine Neuentwicklung auf der sprichwörtlichen „grünen Wiese“; oder die Migration auf ein zeitgemäßes Anbieter-System; oder eine evolutionäre Modernisierungsstrategie.

Neu entwickelten Kernbankenlösungen finden sich in Deutschland fast nur bei neu gegründeten Banken, die mit einer überschaubaren Produktpalette in den Markt eintreten. Ihr Differenzierungsmerkmal zu anderen Banken liegt primär in einem innovativen Geschäftsmodell mit überschaubaren bankfachlichen Funktionen und einer optimierten User Experience (UX) an der Kundenschnittstelle. Somit muss ihr neu entwickeltes Kernbankensystem nur eine überschaubare Bandbreite an fachlichen Funktionen abbilden.

Mit aktuellen „Anbietersystemen“ bestehen indes – zumindest im deutschen Markt – noch Defizite, da notwendige Funktionalitäten in den neu konzipierten Kernbankensystemen noch nicht ausreichend zu finden sind. Für einen Umstieg einer Bank mit einer breiten Produktpalette im Kontensegment müssten diese Funktionen im Rahmen eines Migrationsprojektes wiederum aufwändig realisiert werden. Maßgebliche Eingriffe in die bestehende Architektur, egal ob direkt im Kern oder über einen Layer, sind sehr komplex und nur in zeitraubenden Projekten zu implementieren. Oftmals gefährden sie sogar die Stabilität der Gesamtlösung.

Die Alternative zu einer Neuentwicklung und aufwändigen Migration auf eine andere Lösung, ist daher ein evolutionärer Ansatz. Dabei wird die bestehende Lösung durch einen sukzessiven Austausch der Technologie vorangetrieben. Eine wichtige Voraussetzung dafür ist, dass die bestehende Architektur eine Modularisierung sowie eine zeitweilige Koexistenz zwischen „alter“ und „neuer“ Technologie ermöglicht. Dies muss sowohl technisch abbildbar als auch wirtschaftlich tragfähig sein.

Evolutionäre Modernisierungsstrategien für (Legacy-)Kernbankensysteme

Die nachfolgenden Strategien und Maßnahmen kommen in Betracht, je nachdem welche Gegebenheiten bei der bestehenden Lösung vorzufinden sind. Dazu gehören beispielsweise die Programmiersprache, die Datenbanktechnologie oder auch die vorhandene Layer-Architektur. Zudem haben Rahmenbedingungen wie die betroffenen Schnittstellen und Umsysteme, aber auch Budget und Zeit, Einfluss auf die mögliche Umsetzung. Dementsprechend sollten die Maßnahmen bewertet, sinnvoll kombiniert und in Form einer Zielarchitektur zusammengeführt werden, um eine Projektplanung zu ermöglichen.

1. Modularisierung

Es muss geprüft werden, inwieweit eine Modularisierung der Kernbankenlösung nach fachlichen und technischen Notwendigkeiten erforderlich ist. Ein monolithisch aufgebautes Kernbankensystem sollte eine Entkopplung von Front- und Backend-Funktionalitäten aufweisen und in kleine, flexible Komponenten umstrukturiert werden können. Somit können diese Services gezielt angesprochen und skaliert werden. Ferner lässt sich damit auch ein Deployment leichter automatisieren, um kürzere und variable Release-Zyklen zu erreichen. Zudem sinkt der Testaufwand bei neuen Releases, indem nur die gepatchten Module und ihre Schnittstellen in den Fokus rücken.

2. Microservices im Legacy-Umfeld

Klassische, auf Mainframes basierte Kernbankenlösungen, können durch Microservices und Container die bestehende Geschäftslogik darstellen. Ein Software Defined Mainframe (SDM) in einem Container ermöglicht es, Legacy-Systeme an eine modernere und agilere Umgebung anzubinden. Dies geschieht, indem monolithische Strukturen in eine Vielzahl unabhängiger Microservices verwandelt werden, ohne dass am Quellcode Änderungen notwendig wären.

Dieser Ansatz ermöglicht es, dass bestehende COBOL-Programme in kleinere Softwareeinheiten bis hin zu Microservices heruntergebrochen werden und zur Nutzung dieser Services definierte APIs bereitstellen. Die Notwendigkeit entfällt damit, sie in einer anderen Programmiersprache neu zu schreiben. Die Ausführung des Legacy Codes als kleine Softwareeinheiten ermöglicht zudem, sie für moderne digitale Geschäftslösungen weiter- und wiederzuverwenden.

3. Evolutionäre Neuentwicklung durch Aushöhlung des (Alt-)Kerns

Bei diesem pragmatischen, inkrementellen Ansatz werden die Funktionen des Kernbankensystems auf der alten Codebasis sukzessive durch neuen Code ersetzt. Damit das Zusammenspiel zwischen den verbliebenen alten Komponenten und den neu entwickelten Komponenten gut funktioniert, müssen diese über definierte Schnittstellen miteinander kommunizieren. Um auch Aspekte der Laufzeitumgebung für die unterschiedliche Technologische Basis zu berücksichtigen müssen die Systeme über ein voneinander technisch sehr unabhängiges Protokoll setzen, beispielsweise Webservices auf http-Basis. Unter Umständen muss das abzulösende System in eine Hülle eingebettet werden, damit sich solche Schnittstellen nach Außen realisieren lassen.

Hierbei wird es notwendig, in der Transformation durch domänengetriebenes Design verteilte und entkoppelte Architekturen zu schaffen. Insbesondere kann das domänengetriebene Design den Aspekt der verteilten Datenhaltung berücksichtigen. Mit neugeschaffenen Komponenten auf Basis einer Containertechnologie wie Docker kann der Grundstein für einen cloudbasierten Betrieb gelegt werden. Der Faktor Skalierbarkeit wird somit auch angegangen.

4. Austausch von einzelnen fachlichen Komponenten

Ist das Kernbankensystem modularisiert und wurde eine serviceorientierte Architektur gemäß den vorgenannten Maßnahmen geschaffen, lassen sich einzelne Komponenten beziehungsweise Funktionen durch neue, am Markt erhältliche Produkte oder Open-Source-Lösungen ersetzen.

Eine besondere Herausforderung ist hierbei, fachliche Komponenten eindeutig zu entflechten. Denn fertige Standardlösungen treffen oftmals nicht genau den auszutauschenden Aspekt. Hier bieten sich meist eher Komponenten für Querschnittsfunktionalitäten, wie Berechtigungssysteme an.

5. Layer für Schnittstellen

Die notwendigen (Kommunikations-)Schnittstellen sind optimalerweise als eigene Schicht zum bestehenden Kernbankensystem in einem Layer einzubetten. Diese Middleware steuert die Zugriffe und kann Defizite einer Kernbankenlösung abfedern, beispielsweise fehlende Realtime-Fähigkeit.

Es gibt zahlreiche Optionen und technologische Standards, um Dritte mit dem eigenen Kernbankensystem zu verbinden. Dabei können synchrone Schnittstellen – also REST- oder SOAP-basierte Webservices – oder asynchrone Technologien zum Einsatz kommen. In diesem Feld können auch leistungsfähigere Technologien wie gRPC für bestimmte Konstellationen Vorteile bieten.

Ein gut aufgestelltes API-Management kann dabei helfen, den Zugriff von und nach außen zu regulieren. Dabei können Aspekte wie die Dokumentation der angebotenen Schnittstellen realisiert, die auftretende Last gesteuert, sowie die Monetarisierung der Schnittstelle geregelt werden.

Bei den dargelegten Maßnahmen ist es zwingend notwendig, dass bei allen Formen von „hybriden Lösungsansätzen“ die Interoperabilität und Betriebsfähigkeit des Gesamtsystems jederzeit gewährleistet ist. Neben dem Zeitraum der Erneuerungsstrategie im Kernbankensystem, müssen die betroffenen Front- und Backendfunktionalitäten und auch die beteiligten Umsysteme sowie die angebunden Drittdienstleister mit ihren Applikationen jederzeit stabil und verlässlich bleiben. Sie sollten nicht bei jeder Erweiterung an den Kundenschnittstelle oder an den funktionalen Schnittstellen in maßgeblicher Weise betroffen sein.

Zusammenfassung: Lösungsstrategien für aktuelle Herausforderungen an das Kernbankensystem

Die Banking-Trends Open-Banking, Digitalisierung, Plattformstrategien sowie Kundenzentrierung stellen in der Regel keine besonderen Anforderungen an die rein bankfachliche Leistungsfähigkeit eines typischen Kernbankensystems. Bei der Umsetzung der genannten Trends muss die Leistung aber auch über entsprechende Schnittstellen abrufbar sein, damit die vorgelagerten Systeme diese sicher und performant für ihre Services nutzen können.

Um dies zu erreichen, muss die Kernbankenlösung eine entsprechende „API-Architektur“ aufweisen.
Bestehende Banken erreichen diese Architektur entweder durch:

  • eine Neuentwicklung, in der alle fachlichen und architektonischen Anforderungen berücksichtigt werden, mit anschließender Migration auf diese Lösung;
  • oder eine Migration auf ein bestehendes, moderne(re)s Kernbankensystem, gegebenenfalls mit einer Implementierung von noch nicht vorhandener Funktionalität;
  • oder eine evolutionäre Modernisierungsstrategie auf Basis der vorhandenen Kernbankenlösung.

In der Praxis dürften Neuentwicklungen kaum zu finden sein, höchstens bei Lösungen, die bei neu gegründeten Banken entstehen. So bleiben bei Universalbanken nur die letzten beiden Szenarien, um die notwendige Offenheit einer zukunftsorientierte Kernbankenlösung zu erreichen. Welches der beiden Szenarien tatsächlich zielführend ist, muss im Einzelfall geprüft und bewertet werden, wobei sich das Szenario einer evolutionären Modernisierungsstrategie mehr und mehr als potenzieller Lösungsweg für viele Banken herauskristallisieren könnte.

 

Einblicke

Shaping the future with our clients