Core Modernization: Auswege aus dem Legacy-Lock-in bei einem Kernbankensystem

Die Banken stehen in punkto Kernbankensystem vor der komplexen Herausforderung namens „Legacy Lock In“: die Technik ist zu teuer, sie ist veraltet und komplex, die ehemaligen Entwickler sind längst in Rente oder kurz davor und die Systeme sind nicht schnell genug anpassbar für die kommenden Ansprüche in punkto Agilität. Denn es gibt kaum Möglichkeiten, CI/CD (Continuous Integration/Continuous Delivery) im Legacy- bzw. Host-Umfeld einzusetzen. Die Empfehlung von Boris Strucken.

von Boris Strucken, Leiter Innovationen Banken, FIS

LLegacy-Lock-in beim Kernbankensystem: Verstärkt wird das Problem durch die Tatsache, dass die Banken sich in der Kostenfalle befinden: zwei Drittel der Budgets werden für Run-the-Bank (RtB) benötigt, und nur ein Drittel kann für Innovationen, d.h. Change-the-Bank (CtB) genutzt werden. Hinzu kommen steigende Kosten für die Erfüllung der Ansprüche seitens der Regulierung, auch mit kurzen Umsetzungszeiträumen nach Veröffentlichungen ist zu kämpfen. Die Banken müssen hier das bisherige zwei Drittel/ein Drittel Verhältnis deutlich verbessern, um der digitalen Welt schneller und kosteneffizienter zu begegnen.

Was ist Core Modernization eigentlich bzw. wie kann sie funktionieren?

Die effizienteste Lösung ist aus unserer Sicht die Komponentisierung mit „lift-out and lift-up“ – heißt im Klartext: entzerren, entrümpeln und höher ansiedeln. Gezieltes Layering macht Systeme flexibler und agiler.

Die scheinbar aufwändigere Integration ist die Chance, Business Services als Restful APIs im Sinne einer Abstraktionsschicht einzuziehen und technische Schnittstellen zu entkoppeln, d.h. dahinterliegende Systeme austauschen zu können.”

Gefragt ist dabei ein ganzheitlicher Architekturansatz, der Front to Back ist, um aus dieser Falle des leichtgewichtigen Frontends mit dem schwerfälligen und teuren Backend über eine smarte Integrationsschicht hinauszugelangen. Es muss daher von Anfang an eine umfassende Architektur aufgesetzt werden, die einen Aufbau bedient, wie sie von allen Banken benötigt wird.

Am sinnvollsten erscheint dazu eine Vierteilung in Schichten mit folgendem Setup: Kunden Channels bzw. Frontends, dann Business Process Orchestration und technische Integration, sowie einzelne gekapselte Applikationen als Enterprise Components / Factories. Hinter sämtlichen Schichten liegt ein Data-Universe bzw. Data-Lake, der nicht nur batch, sondern auch real-time ist. Neben einer klaren funktionalen Trennung nach Separation-of-Concerns und Front-to-Back-Integration wird auch noch das Thema Datenmanagement dabei immer wichtiger. Dies ist für die Banken ein bislang noch unentdeckter, riesiger Schatz, den sie noch nicht angefangen haben, richtig umfassend zu nutzen.

Mit Hilfe von AI (Artificial Intelligence) können über Big Data interessante Erkenntnisse gewonnen werden. Und zwar insbesondere zu Fragen, die gar nicht gestellt wurden und trotzdem tiefgreifende Erkenntnisse bringen – vor allem, wenn sie graphisch spannend dargestellt werden können. Die Banken könnten an dieser Stelle wesentlich tiefer in das Verständnis und damit auch die Kenntnis ihrer Kunden einsteigen.”

Wie kann das Thema Komponentisierung bei einem Kernbankensystem gelingen?

Es gilt, den Monolith Kernbank funktional aufzuspalten. Die einzelnen Bereiche wie etwa Payments, übergreifende Kunden- und Preis-Stammdaten, sowie Prozesse zur Kreditabwicklung etc. finden in eigenen IT-Systemen als eigenständige Einheiten statt. D.h., man identifiziert übergreifende Business-Funktionalitäten, die man dort in jeweils eigenen monolithischen Applikationen mehrfach und nicht übergreifend verbaut hat – schließlich ist das Corebankingsystem in über 25 Jahren Stück für Stück zu dem gewachsen, was es heute ist.

„Historisch“ ge­se­hen wur­de in den meis­ten Kern­ban­ken­sys­te­men die­sel­be Funk­tio­na­li­tät mehr­fach ver­baut. So wur­den bei­spiels­wei­se Pay­ments-Funk­tio­nen im­mer und an ver­schie­de­nen Stel­len ein­ge­baut, ob­wohl man es nicht im­mer brauch­te, weil es über­grei­fen­de Pay­ment En­gi­nes für SE­PA gibt. Das reicht aber nicht mehr für die Zu­kunft: Denn künf­tig soll es so sein, dass die Ele­men­te mo­du­lar sind, auf die man über­grei­fend zu­grei­fen kann, wenn dies vom Ge­schäfts­pro­zess not­wen­dig ist. Man hat dann nur ei­ne En­gi­ne statt vie­ler ver­schie­de­ner – doch bis­lang hat je­der die Mo­du­le so ein- und um­ge­baut, wie er sie lo­kal brauch­te. Man hat­te zwar ei­nen SE­PA-Stan­dard als Spe­zi­fi­ka­ti­on, aber wie die­ser um­ge­setzt wur­de, war da­mals in­ter­pre­ta­ti­ons­ab­hän­gig von der Spe­zi­fi­ka­ti­on insb. län­der­über­grei­fend (z.B. deut­sche vs. fran­zö­si­sche vs. tsche­chi­sche Nie­der­las­sung). Heu­te hin­ge­gen hat die Ar­chi­tek­tur ei­ne star­ke Go­vern­ment-Funk­ti­on zu er­fül­len, weil die Um­set­zung durch­nor­mier­ter ist. Man will auf die­se Wei­se Kom­ple­xi­tät ver­rin­gern und da­mit Kos­ten spa­ren und Speed-to-Mar­ket zu er­hö­hen.

Das wesentliche Ziel ist heute der Versuch, ein großes Kernbankensystem in kleinere, eigenständige, funktionale Blöcke zu teilen. Man muss viele Schnittstellen zu Adaptern umbauen, damit man darauf standardisiert aufbauen kann. Die Integrationsschicht spielt dabei eine zentrale Rolle, was jedoch für API Management im Sinne von Open Banking sowieso benötigt wird.

Ins Zentrum der Betrachtung rückt heute immer stärker der Business Case der Gesamtfunktionalität. Die Transformation ist mehr denn je eine evolutionäre denn eine revolutionäre Story. So lässt sich das Big-Bang-Risiko vermeiden und getätigte Investitionen werden geschützt. Besonders wichtig dabei ist die Frage nach den Pain Points, die auch Investitionen rechtfertigen und nicht eine getätigte Abschreibung noch finanziell jahrelang „ausschlachten“.

Der Run um den Kunden von morgen

Die Herausforderungen angesichts der Digitalisierung sind riesig – die Banken müssen nicht nur den neuen Wettbewerbern begegnen, sondern sich auch fit für die Zukunft machen. Ein (Kosten-)effizienteres Kernbankensystem ist dafür die Voraussetzung, um auch eine einfachere Integrierbarkeit künftiger, bislang möglicherweise noch unbekannter neuer Funktionen zu gewährleisten.

Innovation und Geschwindigkeit werden in Zukunft die beiden entscheidenden Bausteine sein, um den digitalen Kunden von morgen für sich zu gewinnen.” aj