Banken-IT: per Aufspaltung der System-Komplexität zu neuen Services

Manche Systeme sind so komplex, dass man sich kaum traut, daran etwas zu ändern. Monolithische Bankensysteme gehören dazu. Aber wenn die Institute neue Technologien nutzen und moderne Services anbieten wollen, müssen sie ihre Software modernisieren. Mit der richtigen Strategie und einer Aufspaltung der Komplexität gelingt der Umstieg.

von Jörg Ramser und Valentino Pola, Cofinpro 

Die Migration von zentralen IT-Systemen wird in der Regel als „Big Bang“ umgesetzt. Dabei stellt die enorme Komplexität eines solchen Projekts alle beteiligten Akteure vor große Herausforderungen. Sollte etwas schiefgehen, drohen Imageverluste und hohe Folgekosten. 2018 zum Beispiel konnten in Großbritannien nach einer missglückten Migration 1,9 Millionen Kunden einer schottischen Bank mit über 500 Filialen nicht mehr auf ihre Konten zugreifen.

Es dauerte Wochen, bis das neue System reibungslos lief. Unterm Strich stiegen die Kosten auf über 330 Millionen Pfund, 80.000 enttäuschte Kunden wechselten ihren Kontoanbieter und der damalige CEO musste seinen Platz räumen.

Aber es sind nicht allein die großen Projekte, selbst kleinere Anpassungen im Online-Banking-Portal oder der Stammdatenverwaltung können unvorhergesehene Komplikationen nach sich ziehen. Die Folge: genervte Kunden und gestresste Banker. Kern des Problems ist die Komplexität der Banken-IT. Diese ist begründet in den strengen Auflagen des Regulierers, einem umfangreichen Produktangebot der Bank, unterschiedlichsten Anforderungen auf Kundenseite – und einer undurchsichtigen Software-Architektur.

Denn die Banksysteme sind über die Jahre hinweg oftmals zu einem Monolithen herangewachsen mit einer Vielzahl an internen Strukturen und Abhängigkeiten sowie Schnittstellen zu weiteren Systemen.”

Ein schwerer Brocken

Ein typischer Bank-Monolith wurde früher oft auf Basis eines Lastenhefts, einer Spezifikation des Anforderungskatalogs, erstellt. Darauf folgte das Pflichtenheft, sozusagen die Roadmap für die Projektteilnehmer. Und genau wie beim Fabrikbau auf der grünen Wiese ging es anfangs schnell voran: Module, Schnittstellen und Anforderungen waren bekannt. Das gesamte System konnte als eigenständige Einheit entwickelt und programmiert werden. Die Lauf- oder Lebenszeit wurde dabei meist auf zehn bis 20 Jahre gerechnet.

Aber direkt nachdem ein solches System live geschaltet wird, gibt es häufig kleinere und größere Umbauarbeiten: Regulatorische Anforderungen müssen umgesetzt werden, neue Kundenbedürfnisse abgedeckt oder weitere Systeme und Funktionalitäten angebunden werden. Und genau da fangen die Probleme an: Aufgrund der vielen Abhängigkeiten innerhalb des Systems sind Änderungen nur schwer zu planen und umzusetzen. Die Folge: Projektmitarbeiter suchen aufgrund enger Zeitpläne und Projektdruck dann gerne eine Abkürzung. Zum Schluss ist es wie beim Mikado: Jedes Stäbchen liegt an einer Vielzahl anderer Stäbchen an. Und wird ein Stäbchen bewegt, kann dies eine Kettenreaktion durch den gesamten Stapel nach sich ziehen. Schätzungen zufolge liegt das Verhältnis zwischen Betriebs- und Weiterentwicklungskosten eines in die Jahre gekommenen Banking-Systems am Anfang seiner Einführung bei rund 30 zu 70. In wenigen Jahren aber ist die Software undurchdringlich und hat das Verhältnis umgekehrt: Die Betriebskosten verschlingen aufgrund der immer komplizierteren Wartung 80 Prozent des Budgets, 20 Prozent verbleiben für die Weiterentwicklung. Unterm Strich sind die Systeme irgendwann nicht mehr beherrsch- oder modifizierbar.

Viele kleine Häppchen

Ein Ausweg aus dem Komplexitäts-Dilemma: Statt alle Funktionen der Banken-IT in einem Monolithen zu koppeln und zentral zu implementieren, ist es auch möglich, fest definierte Aufgabenbereiche in eigenständige Services und Systeme (Self Contained Systems, SCS) abzuspalten. Die Innovationen im Bereich Cloud und Virtualisierung der letzten Jahre ermöglichen einen solchen Ansatz ohne hohe Kosten in der Bereitstellung (Cloud-Native Architektur, CNA). Ziel ist es, einzelne Anwendungen als überschaubare, in sich abgeschlossene Einheiten zu entwickeln.

Während ein Monolith als Ganzes bereitgestellt wird und meistens auf zentralem Code basiert, können einzelne SCS unabhängig voneinander entwickelt sowie gelauncht werden und je nach Anforderungsprofil eine eigene Code-Basis haben. Wichtig ist der fachliche saubere Schnitt zwischen den einzelnen SCS. Damit werden die Abhängigkeiten zwischen den einzelnen Systemen auf ein Minimum reduziert. Die wenigen verbleibenden Abhängigkeiten werden durch Schnittstellen (APIs) zwischen den einzelnen Microservices abgebildet. Die verschiedenen SCS fügen sich für den Nutzer zu einer nahtlosen Gesamtanwendung zusammen.

Im Gegensatz zum Monolithen bietet eine SCS-Architektur besondere Redundanzmechanismen und eine hohe Ausfallsicherheit. Auch ist das System besser in der Lage, unerwartete Lastspitzen aufzufangen bzw. abzuarbeiten, weil neue Ressourcen in der Cloud-Umgebung relativ schnell zugefügt werden können.

Speziell in einer Banken-Umgebung bietet eine CNA-Plattform folgende Vorteile:

Die Bank wird agil

Mit einer SCS-Architektur wird nicht nur die Software selbst grundlegend verändert. Das Modell wirkt sich auch auf die Prozesse und die Arbeitsorganisation innerhalb der Bank aus. Agile Arbeitsformen in kleinen Teams mit viel Eigenverantwortung und einem hohen Maß an Kreativität sind mit großen Projekten kaum umzusetzen, weil der Abstimmungsbedarf untereinander zu groß ist.

Ganz anders bei der Bereitstellung von Self Contained Systems: Aufgrund der kleineren Teamgröße steigen das Commitment und die Eigenverantwortung der einzelnen Mitglieder für eine erfolgreiche und termingerechte Softwareverteilung (Deployment).

Dieser Fokus auf moderne Arbeitsformen wird angesichts der „neuen Normalität“ im Zuge der Corona-Pandemie sogar noch wichtiger. Denn große, hierarchisch geprägte Teams sind zunehmend schwer zu koordinieren.”

Aber auch die Service-Prozesse in der Bank werden neu arrangiert und strukturiert. Die traditionellen Banken-Systeme sind historisch häufig noch in einer von vielen manuellen Arbeitsschritten geprägten Unternehmenslandschaft verwurzelt. Diese eng verzahnte Online-Offline-Welt ist charakteristisch für viele Legacy-Systeme und war in der Vergangenheit eine der größten Hürden bei den Digitalisierungsvorhaben der Banken.

Im Zuge einer Modernisierung der Software sollten die einzelnen Prozesse und bankinternen Arbeitsschritte neu gedacht und strukturiert werden, um eine harmonische Orchestrierung der einzelnen Anwendungspakete in einem Gesamtsystem zu gewährleisten. Zugleich führt der iterative Arbeitsansatz, bei dem einzelne Anwendungen immer wieder neu programmiert und optimiert werden, zu immer effizienteren Lösungen und innovativen Lösungsansätzen, die Banken wie Kunden Vorteile bieten.

Zweimal ist einmal zu viel?

Eine gewisse Redundanz in der Softwarearchitektur bei den SCS lässt sich nicht vollständig vermeiden – es geht vielmehr darum, diese bewusst zugunsten von Flexibilität und Geschwindigkeit einzugehen. Arbeitet zum Beispiel ein Team an der Anwendung Kontoeröffnung und ein anderes Team an der Anwendung Depoteröffnung, kann es sein, dass manche Masken doppelt entwickelt werden, obwohl nur eine gereicht hätte. Dieser „doppelte Code“ ist, sofern fachlich abgetrennte Bereiche autark arbeiten, in einem gewissen Rahmen unvermeidlich und in der traditionellen Entwicklung ausgeschlossen. Angesichts der vielfachen Vorteile sind die Redundanzen jedoch gerechtfertigt – auch weil auf lange Sicht der Arbeitsaufwand am System sonst exponentiell durch die zahlreichen Abhängigkeiten steigt.

Anders als bei der oben beschriebenen schottischen Bank muss für die Implementierung eines SCS-Modells auch nicht das Alt-System als Ganzes migriert werden. Stattdessen kann in kleinen, kontrollierten Schritten häppchenweise vorgegangen werden. So können zum Beispiel an ein altes System modulweise jeweils neue SCS angedockt werden. Ein möglicher Startpunkt wäre die Kontoeröffnung. Im nächsten Schritt könnten dann Zahlungseingang und -ausgang abgewickelt werden. Und weil das alte System immer noch parallel im Hintergrund läuft, bleibt auch eine Art „Risikoversicherung“, sollte die neue Anwendung im live-Betrieb nicht alle Use Cases abdecken.

Die eigentliche Migration von Alt nach Neu kann in zwei unterschiedliche Vorgehensweisen eingeteilt werden, die je nach Zielvorgabe und Systembeschaffenheit sinnvoll sind.

Bei der iterativen Backend- und vollständigen Frontend-Migration bekommt der Nutzer von Anfang an die neue Anwendung zu sehen, sobald diese live gestellt ist.”

Die alten Anwendungen werden sukzessive von neuen Anwendungen ersetzt. Dies hat zur Folge, dass der Nutzer in der Übergangsphase – die durchaus mehrere Quartale in Anspruch nehmen kann – zwischen dem alten und dem neuen System hin- und herspringt.

Bei der iterativen Migration von Front- und Backend „verstecken“ sich die neuen Anwendungen hinter dem alten Frontend.”

Der Nutzer bekommt von den neuen Systemen im Hintergrund also nichts mit. Erst wenn alle neuen Anwendungen laufen, wird auch das Frontend umgeschaltet. Die beiden vorgestellten Vorgehensweisen sind bezogen auf den Aufwand nicht die effizientesten: Es werden Komponenten entwickelt, die nur für die Übergangszeit genutzt und dann wieder ausgebaut werden. Allerdings reduziert man damit das deutlich höhere Risiko, dass bei einer Gesamtumstellung etwas schiefläuft.

Eine übersichtliche Darstellung liefert die folgende Grafik:

Fazit

Im Bankenumfeld sind gerade ältere Anwendungen zu monolithischen Softwaresystemen herangewachsen. Die damit automatisch verbundenen Komplexitätsprobleme wurden mangels lauffähiger Alternativen in Kauf genommen.

Mit dem Aufkommen von neuen Architekturansätzen und Technologien gibt es nun jedoch die Möglichkeit, einen sicheren und reibungslosen Wechsel von den Legacy-Systemen auf eine moderne und skalierbare Software-Architektur zu ermöglichen.

Dass dies auch im großen Maßstab möglich ist, haben die jeweiligen Branchenschwergewichte Amazon und Netflix bereits vorgemacht. Die beiden Internet-Konzerne gelten als Pioniere in der Entwicklung von Cloud-Architekturen und zeigen, dass auch komplexe Systeme in viele kleine Systeme und Services aufgespalten werden können, um die Geschwindigkeit und Flexibilität auch bei steigendem Funktionsumfang und höherer/steigender Komplexität aufrechtzuerhalten.Valentino Pola und Jörg Ramser, Cofinpro