Kernbanksysteme: Vom Monolithen zum Service-Mesh

Was ist eigentlich ein Kernbanksystem? Und vor allem, was ist es nicht?

Sucht ihr nach einer Definition für den Begriff „Kernbanksystem“, dann werdet ihr eine bemerkenswerte Vielfalt von Ergebnissen finden, die allerdings sehr stark voneinander abweichen. Ich verstehe unter einem Kernbanksystem ein zentrales IT-System, das den sogenannten „juristischen Bestand“ einer Bank abbildet. Hier geht es um die Forderungen und Verbindlichkeiten, die eine Bank gegenüber Dritten, also gegenüber ihren Kunden und Geschäftspartnern, hat sowie um die Verwaltung der Daten, die für eine Erfüllung eben jener Forderungen erforderlich sind. Diese Daten sind im Wesentlichen für alle Banken gleich aufgebaut. Um den Kern herum besitzt jede Bank aber noch weitere Geschäftsprozesse, die ihren eigentlichen Charakter ausmachen. Zusammen bilden diese Prozesse das Serviceportfolio eines Instituts ab und werden durch ein Gesamtbanksystem in der Informationsverarbeitung unterstützt.

Die Unterschiede zwischen einem Kern- und Gesamtbankensystem sind schnell erklärt: Von einem Kernbanksystem wird erwartet, dass bankfachliche Anforderungen einfach und schnell abgewickelt werden können. Das Gesamtbanksystem hingegen soll die Prozesse möglichst standardisiert und automatisiert unterstützen. Somit sorgt das Gesamtbanksystem für ein gewisses Kundenerlebnis, während das Kernbanksystem im Hintergrund „leise“ seine Arbeit erledigt.

Die Architektur eines Kernbanksystems

Die Hauptaufgaben eines Kernbanksystems finden sich selbstverständlich auch in seiner Architektur wieder. Die Lösungsarchitektur hat sich über die Jahre hinweg allerdings nicht wesentlich verändert. Neben dem Hauptbuch der Bank, das als Datensenke lediglich die Journaleinträge der Kontenverwaltung aufnimmt, gibt es zwei weitere große Bereiche:

• Der Geldfluss: Er wird durch die Kontenverwaltung sowie durch seine beiden Nebensysteme zur Zahlungsverkehrsabwicklung und Buchungssteuerung kontrolliert.
• Die Kundenbeziehungen der Bank: Sie finden sich in der Geschäftspartner- und Vertragsverwaltung wieder.

Trotz seiner Wichtigkeit ist das Kernbanksystem für alle Kunden und sogar für die meisten Mitarbeitenden einer Bank „unsichtbar“. Die Banksysteme, die uns im täglichen Leben begegnen, sind im Umfeld des Kernbanksystems angesiedelt. So gehören selbst wichtige Funktionen des Zahlungsverkehrs - etwa Betrugserkennung, Business Intelligence oder das Erstellen von Kontoauszügen - genauso wenig zu den Kernfunktionen des Systems, wie der Interbanken-Zahlungsverkehr.

Wie hat sich das Herz der Banken-IT entwickelt?

Kurz nachdem die ersten Großrechner kommerziell verfügbar waren, erkannten auch Banken den Vorteil der Digitalisierung von Prozessen. So fand die Entwicklung von Systemen zur Unterstützung von damaligen Kernfunktionen des Bankbetriebs bereits vor mehr als 50 Jahren statt: Die Geburtsstunde des Kernbanksystems. Die Datenverarbeitung geschah in der Regel im Batch-Betrieb und die Daten wurden zentral gehalten. Die Softwarearchitektur eines solchen Systems wurde mit Sicht auf die Datenhaltung entwickelt, da die Verwaltung der zentralen Datenbank die Hauptfunktion des Systems war. Verteilte Architekturen waren weder verfügbar noch erforderlich und die benötigte Software wurde mit den damals verfügbaren prozeduralen Programmiersprachen entwickelt. Auf Mainframe-Computern wurden Anwendungen in der Regel für das spezifische Einsatzziel entwickelt. Auf diese Weise entstanden dann proprietäre monolithische Anwendungen.

Leistungssteigerungen bei der Hardware und veränderte Anforderungen führten schließlich dazu, dass diesen Monolithen im Laufe der Jahre immer mehr Funktionen hinzugefügt wurden.

Die Weiterentwicklung des Software Engineerings - insbesondere der objektorientierten Modellierung nebst passender Programmiersprachen - ermöglichte es, die Monolithen in Komponenten aufzuteilen. Dieser Schritt erforderte kein radikales Neudenken der Architektur, denn auch bei komponentisierten Monolithen herrscht ein datenzentriertes Design vor. Die Abstimmung zwischen den Komponenten bedeutet zwar einen höheren Aufwand für das Design der Schnittstellen, jedoch sinken die Gesamtkosten. Das hat einfache Gründe:

• Die kleineren Einheiten können einfacher erstellt und gewartet werden.
• Anstelle der für Großrechner üblichen Programmiersprachen - COBOL und PL/I - können heute weiter verbreitete objektorientierte Sprachen, etwa Java, eingesetzt werden.

Eine logische Weiterentwicklung dieses Konzepts führt zu einem System, bei dem einige wenige Monolithen, die aus wiederverwendbaren Komponenten aufgebaut wurden, miteinander kommunizieren. Dabei übernimmt jeder Monolith einen Aufgabenbereich - beispielsweise indem er den Zahlungsverkehr einschließlich Buchungssteuerung und Kontenverwaltung kontrolliert.

Es wird euch sicherlich nicht überraschen: Den Schritt weg von der reinen Sicht auf die Daten wagen erst neue Entwurfsmuster, die auf serviceorientierten Architekturen basieren. Deren prominenteste Ausprägung sind Microservices. Bei diesem Systementwurf liegt der Schwerpunkt des Designs auf den Schnittstellen zwischen den Diensten, die wesentlich kleiner sind als komponentisierte Monolithen. Allerdings erfordert die Einführung einer Microservice-Architektur einen radikalen Umbau des Kernbanksystems. Während sich aufgeteilte Monolithen noch grob an der funktionalen Architektur orientieren können, müssen Microservices so geschnitten werden, dass eine hohe fachliche Kohäsion bei gleichzeitig maximaler Entkopplung geschaffen wird. Hierfür ist ein tiefes Verständnis der Fachdomäne erforderlich. Gleichzeitig tritt das Datenmodell der früheren Entwicklungsphasen als Implementierungsdetail in den Hintergrund. Ein Beispiel: Während früher die Auftragsverwaltung nur eine Funktion der Kontenverwaltung war, würde ein Microservice lediglich die Entgegennahme, die fachliche Prüfung und die Weiterleitung einer SEPA-Überweisung übernehmen.

Der fachliche Schnitt darf dabei grundsätzlich über die klassische Systemgrenze des Kernbanksystems hinausgehen, wenn dies zu einer besseren Abbildung der Domäne führt. Voraussetzung für den Aufbau dieser Form der Architektur ist eine netzwerkfähige Infrastruktur. Mit Java oder einer verwandten Sprache kann das bewerkstelligt werden. Den vergleichsweise hohen Kosten für die erstmalige Einführung dieser Architektur stehen erheblich niedrigere Kosten für Wartung und Betrieb gegenüber.

Microservices können, im Gegensatz zu den älteren Entwürfen, in kleinen, standardisierten Umgebungen betrieben werden. Außerdem werden sie mit standardisierten Frameworks entwickelt. Das senkt die Kosten für Hardware, für proprietäre Software und für den Betrieb. Aufgrund der Standardisierung sind Microservices einfacher zu skalieren und über eine Virtualisierung der Betriebsplattform lassen sich die Hardwarekosten ein weiteres Mal senken. Ab dieser Stufe bezeichnet man die Umgebung übrigens als Cloud.

Im Laufe der Entwicklung eines Kernbanksystems, das auf Microservices basiert, wird die Anzahl der Dienste stark ansteigen. In jedem Service müssen daher Funktionen vorgesehen werden, die eine Kommunikation und Verwaltung der Dienste untereinander ermöglichen. In einem Service-Mesh werden diese Funktionen in eine Infrastrukturschicht, die direkt in die Services integriert ist und auf Standardbibliotheken basiert, ausgelagert. Eine automatisierte Verwaltung wird damit möglich. So eine Schicht wird übrigens als „Sidecar“ bezeichnet und übernimmt Steuerfunktionen, die zur Verbesserung von Effizienz und Zuverlässigkeit der Serviceanfragen sowie der Ausfallsicherheit des gesamten Systems beitragen.

Für ein Kernbanksystem sind diese Faktoren essentiell, da sie zu seinen Hauptanforderungen zählen. Mit einem Service-Mesh können Entwicklungskosten gesenkt und kleinere Komponenten als Standardanwendungen entwickelt werden. Die kundenspezifische Gesamtfunktionalität wird dann nur noch über die geeignete Auswahl und Konfiguration der Services hergestellt. Ein Service-Mesh ist also der nächste logische Schritt hin zu einem reifen Kernbanksystem aus Microservices.

Fazit und Ausblick

Wie geht es nun weiter mit der IT im Herzen der Bank? Zugegeben, der Aufbau eines Service-Mesh, anstatt eines klassischen monolithischen Kernbanksystems, ist aktuell eher etwas für Finanzdienstleister, die auf der grünen Wiese beginnen können. Schließlich haben Großbanken sehr strenge Anforderungen an die Zuverlässigkeit und vor allem an die Verfügbarkeit ihrer Systeme. Außerdem laufen außerhalb der Bankarbeitszeiten auf den Mainframes noch Batch-Anwendungen, die ebenfalls für den regelmäßigen Geschäftsbetrieb zwingend erforderlich sind. Das alte Kernbanksystem kann also nicht einfach abgeschaltet werden. Trotzdem sollten auch Großbanken Erfahrungen mit dieser Technologie sammeln, damit ihre Entscheider Sicherheit im Umgang mit diesen Technologien erlangen. Hier bietet sich beispielsweise die Middleware des Gesamtbanksystems an. Sie bietet mit ihrer Vielfalt von kleineren Systemen einen einfacheren Zugang zu neuen Technologien.

Wir ihr euch sicherlich denken könnt, werden künftig immer mehr Funktionen des Bankbetriebs in die Cloud ausgelagert. Bis alle aufsichtsrechtlichen und betrieblichen Fragen geklärt sind, kann dies auch eine selbstbetriebene, das heißt also private Cloud sein. Auch hier können Banken schon von den Vorteilen einer Cloud-Lösung - etwa der einfachen Wartung durch kleinere Systeme, der besseren Skalierbarkeit oder der leichteren Verfügbarkeit von Entwicklungskapazitäten - profitieren. Gleichzeitig fördern Banken ihre Öffnung zu anderen Anbietern und können ihr Serviceportfolio zukunftsorientiert aufstellen.

Wie ihr sicherlich bemerkt habt, beziehe ich mich in meinem Blog-Beitrag ausschließlich auf Software. Auch Anbieter von Großrechnern bieten mittlerweile Virtualisierungslösungen, mit denen tausende virtuelle Server als Cloud-Lösung auf einem Mainframe ausgeführt werden. So kann der Host überleben, auch wenn sein klassisches Softwaremodell ausgedient hat.

Bei komplexen Projekten – etwa beim Austausch eines Kernbanksystems - sind nicht nur die technischen Fähigkeiten zur Umsetzung relevant. Mindestens genauso wichtig ist ein tiefes Verständnis der Fachdomäne und eine adäquate Erfahrung bei der Umsetzung derartiger Großprojekte. adesso unterstützt Banken bei der Einführung von Microservices und Service-Meshs - auf der Ebene des Gesamtbanksystems sowie bei Kernbanksystemen. Dabei werden Industriestandards wie Red Hat OpenShift oder Istio Service-Mesh eingesetzt, die professionelle Unterstützung für etablierte Open-Source-Projekte wie Docker, Kubernetes oder Envoy Sidecar bieten.

Wenn ihr mehr zu unserem Portfolio erfahren möchtet, werft doch einen Blick auf unsere Website.