Klassische Kernbankensysteme im Anwendungssystem Konglomerat

Kurzer Rückblick in die historische Entwicklung von Standardsoftware in Bankensystemen

Im Gegensatz zu Industrie und Handel hat sich der Einsatz von Standardsoftware gegenüber Individualentwicklungen erst sehr spät in der Bankenwelt durchgesetzt. Die verschiedenen Geschäftsmodelle und Größendifferenzen der Banken und der Anspruch auf „Individualität“ erschwerten den frühzeitigen Einsatz von Standard-Anwendungssystemen. In diesem Spannungsfeld sind in den letzten 20 bis 30 Jahren mehrere Core-Banking-Systeme entstanden, die sich vor allem auf Wertpapiere und klassische Bankkernfunktionen konzentrieren. Dabei gab es ganz grob zwei Richtungen. Zum einen den Sparkassenverband und die Genossenschaftsbanken mit geschlossenen eigenentwickelten Systemwelten und die Privatbanken mit zum größten Teil gekauften Standard-Anwendungssystemen.

Das Streben nach Verringerung der Fertigungstiefe und nach Erfüllung der technischen, regulatorischen und marktgetriebenen Anforderungen an Bankensysteme in einem vertretbaren Zeit- und Kostenaufwand hat dazu geführt, dass Dritt-Standard-Core-Banking-Systeme vor allem bei den Privatbanken sowohl im Retail-Bereich als auch im Wealth Management Einzug hielten.

Damit dieses Vorgehen aber langfristig zielführend ist, müssen ausgewählte Standard-Core-Banking-Systeme eine wohldefinierte Architektur, eine Serviceorientierung und vor allem ausreichende Serviceschnittstellen (API´s) nach außen besitzen. Diese sind wichtige Voraussetzungen für eine erfolgreiche Integration an ein Standard-Core-Banking-System und die Integration anderer Systeme in die komplexe und heterogene Gesamtanwendungs- und Prozesslandschaft einer Bank.

Vor dem Hintergrund der fortschreitenden Digitalisierung und von Big Data kommen vor allem den Serviceschnittstellen besondere Bedeutungen zu.

Serviceschnittstellen

Offen gelegte Schnittstellen eines Standard-Core-Banking-Systems, die bereits in einem großen deutschen Standardsoftwaresystem auch so hinterlegt sind, kann man dabei grob in die folgenden Kategorien unterteilen:

• Die Serviceschnittstelle ist wichtig für die Bereitstellung der Geschäftsvorfälle des Bankenbusiness. Hier ist die Herausforderung der fachliche Schnitt der bankfachlichen Services. Dieser entscheidet, ob die Anforderungen, die z.B. die Digitalisierung an Kernbankensystem stellen, erfüllt werden können.
• Dateischnittstellen sind standardisierte, meist extern vorgegebene Schnittstellen, wie z.B. SCHUFA oder SWIFT, Output-Management-Systeme oder Meldungswesensysteme.
• User-Exits sind wohl definierte Stellen im Sourcecode des Standardsystems mit definierten Schnittstellen, in denen Veränderungen durch den Anwender zulässig sind. Sie bieten z.B. die Möglichkeit für zusätzliche Validierungen, algorithmische Erweiterungen, Differenzierungen in Prüfvorgängen oder ähnliches durch den Anwender.

Problematik „Borderline“

Eine eindeutige Schnittstelle zwischen einem Standardsystem und den Kundensystemen ist oft fließend. Große Anbieter wie SAP haben dabei den Vorteil, aufgrund ihrer Marktdominanz den Kunden eindeutige Adapterschnittstellen „aufzuzwingen“. Eingriffe in die Systemwelt von SAP erfolgen auf eigenes Risiko des Anwenders.

Diese „Borderline“ ist aber gerade in anderen Standardsystemen oft so nicht gegeben oder nur unscharf definiert. Obwohl die Unveränderbarkeit der Interna ein Definitionsmerkmal von Standardsoftware ist, muss beachtet werden, dass der Unterscheid zwischen Tailoring (Anpassung) und der Veränderung der Interna oft fließend ist.

Des Weiteren werden auch oft private interne Schnittstellen benutzt, wie z.B.

• interne, temporäre Dateien,
• Datenbank-Tabellen,
• Druckaufbereitete Kundenmitteilung (statt Nettodaten) oder
• interne fachliche und technische Services aus verschieden Eben der eingesetzten Frameworks.

Diese internen Schnittstellen erfüllen nicht die Eigenschaften der offengelegten Serviceschnittstellen (abgeschlossen, wohldefiniert, versioniert, qualitätsgesichert und dokumentiert) und gefährden mit jedem neuen Release die Stabilität des Gesamtsystems.

Im Allgemeinen ist der Grad der kundenspezifischen Anpassungen (Abweichung vom Standard, Tailoring) auch ein gutes Maß für den Aufwand, der bei jedem neuen Release zur Stabilisierung und Qualitätssicherung zu leisten ist.

Fazit

Der Aufwand zur Qualitätssicherung von ausgewählter Standardsoftware durch Regressionstests, Aufbau diverser Testumgebungen beim Anbieter und Kunden, Simulation vom Echtzeitbetrieb, Performancetest und ähnliches sind bereits heute eine signifikante Größe bei den Banken.

Auf Grund der Korrelation vom Grad der Abweichung vom Standard der eingesetzten Standard-Core-Banking-Systeme und den Kosten zur Qualitätssicherung setzen die Banken vermehrt auf Individualisierung durch kundenspezifische Apps mit dem Ziel, komplexe Änderungen an den Backendsystemen zu vermeiden.

Dieser Beitrag ist auch im „Der Bank Blog“ erschienen.