Modernisierung von Banken-IT: Notwendige Operation am offenen Herzen

“If it ain’t broken, don’t fix it!” – an dieses goldene Motto halten sich Banken bei ihren IT-Systemen gerne. Es gibt dabei nur ein Problem: Der „Technical Debt“ nimmt zu, die IT-Landschaft veraltet und es ist nicht einfach, sie zu reparieren – von der Integration neuer Produkte und Services einmal abgesehen. Was können Banken jetzt tun, um ihre IT-Landschaft rechtzeitig zu modernisieren?

von Toby Dixon, Endava

Bei etablierten Banken spricht immer noch einiges für den Einsatz von Mainframes: Vor allem verarbeiten die Großrechner seit Jahrzehnten zuverlässig und stabil jeden Tag Milliarden von Backend-Transaktionen – und das ist entscheidend für die Positionierung als wichtiger Player im Finanzsystem. Sie sind damit ein entscheidender Bestandteil der IT-Infrastruktur von Banken, die im Laufe der Zeit organisch gewachsen ist. Man kann sie fast schon als Herzstück der Banken-IT bezeichnen.

Auch darüber hinaus verlassen sich Banken auf Technologien, Architekturen und Programmiersprachen, die seit Jahrzehnten dafür sorgen, dass sie ihren Kerngeschäften erfolgreich nachgehen können.”

Doch mit jedem Jahr, das diese Legacy-Systeme älter werden, entstehen immer mehr Probleme:

• Die Wartung der Hardware ist kostspielig: Auch wenn sich beispielsweise die Mainframes über die letzten 30 oder 40 Jahre in diesen speziellen Rollen noch behauptet haben, kommen sie langsam ans Ende ihrer physischen Lebenszeit. Ob sich die Wartung und Reparatur lohnt und überhaupt möglich ist – das ist mehr als fraglich.
• Fachwissen geht verloren: IT-Fachkräfte sind grundsätzlich schon Mangelware und es werden immer weniger, die sich mit alten Programmiersprachen wie COBOL auskennen, die heute kaum noch gelehrt werden. Das heißt, im Falle notwendiger Anpassungen oder Fehlerbehebungen sind diese Experten rar.
• Wenig Agilität und Flexibilität: Verbraucher erwarten heute wesentlich mehr und schnellere Dienstleistungen von Banken als in der Vergangenheit. Doch die Integration neuer Anwendungen in monolithische IT-Architekturen ist aufwendig und gelingt nicht immer zu hundert Prozent.

Damit muss die veraltete IT-Landschaft von Banken inzwischen als ernsthaftes Geschäftsrisiko betrachtet werden.”

Solange der Betrieb aber noch weitgehend läuft, wird diese Realität teilweise ausgeblendet und die Modernisierung oft auf einen unbestimmten Zeitpunkt in der Zukunft verschoben.

Das ist allerdings die falsche Herangehensweise, denn Banken müssen jetzt dringend einen Plan für die Modernisierung ihrer IT entwickeln. Nur so können sie ihre Prozesse optimieren, den Anforderungen und Wünschen ihrer Kunden gerecht werden und sich langfristig gegen die Konkurrenz durch Neobanken und FinTechs behaupten.

Der Schlüssel hierbei ist eine Microservice-Architektur.”

Viele kleine, unabhängig voneinander agierende Services, die über Schnittstellen miteinander kommunizieren. Dieser Ansatz hat vor allem den Vorteil, dass die einzelnen Microservices individuell gewartet und skaliert werden können. Zudem lassen sich neue Microservices für neue Anwendungen einfacher hinzufügen, da im Gegensatz zu einem Monolithen dafür nicht das gesamte System angefasst werden muss. Dabei können einzelne Microservices gleichzeitig für unterschiedliche Produkte und Dienstleistungen genutzt werden, sodass die gleichen Funktionalitäten nicht mehrfach entwickelt werden müssen. Die Granularität der Microservices erleichtert die Wartung, ermöglicht es, schneller auf Marktveränderungen zu reagieren, und verbessert dadurch die Business-Agilität.

Allerdings müssen Banken aufpassen, da der Wechsel von einem System zu einem neuen auch riskant sein kann.”

So gab es in den letzten Jahren verschiedene Beispiele, bei denen Banken verschiedene Kundendaten auf einer einzigen IT-Plattform zusammenführen oder ihr gesamtes Kernbankensystem migrieren wollten und es zu teilweise massiven und wiederholten Störungen kam. Die Kunden bekamen dies etwa beim Onlinebanking oder bei Barabhebungen an Automaten zu spüren.

Schritt für Schritt auf Microservices wechseln

Solche Probleme zu vermeiden – und die Kunden nicht nachhaltig zu verärgern – ist eine der wichtigsten Aufgaben bei der Erneuerung und Weiterentwicklung der IT-Landschaft. Dies ist möglich, dafür müssen Banken aber im Vorfeld einen klaren Plan für die schrittweise Umstellung auf das neue System erarbeiten und diesen nach und nach abarbeiten.

Wichtig ist im ersten Schritt, zu definieren, welche Produkte und Services künftig (weiterhin) benötigt werden.”

Banken haben dadurch die Möglichkeit, ihr Produktportfolio an die realen Gegebenheiten anzupassen und Angebote zu streichen, die sie oder ihre Kunden nicht mehr wünschen. Gleichzeitig können sie festlegen, welche Leistungen ihnen bisher fehlen und in der neuen IT-Landschaft eingerichtet werden sollen. So steht das, was die Kunden beim Onlinebanking im User Interface sehen, oft nicht im Einklang mit den Backend-Systemen. Zum Beispiel wird bei Überweisungen das Geld zwar direkt vom Konto des Kunden abgezogen, kommt jedoch in der Regel erst am nächsten Tag beim Empfänger an.

Im nächsten Schritt geht es dann darum, das Kernsystem mithilfe von Microservices neu aufzubauen.

Angesichts des hohen Aufwands und des Risikos, die damit verbunden sind, kann es sinnvoll sein, sich Unterstützung von externen Partnern zu holen.”

Diese sollten bereits Erfahrungen mit der Entwicklung von Microservices und dem Einrichten entsprechender Architekturen haben. Entscheidend ist dabei ein schrittweises Vorgehen: Anstatt erst alle Microservices zu bauen und praktisch über Nacht den Systemwechsel zu vollziehen, sollten Banken nach und nach einzelne Komponenten ihrer IT durch Microservices ersetzen. Dabei bietet es sich an, zunächst mit der Integration von Funktionalitäten mit geringerem Umfang zu beginnen und sich so langsam zu den entscheidenden IT-Bausteinen vorzuarbeiten.

Eine solche Übergangsphase, in der das alte System beibehalten wird, während zunehmend Microservices eingebunden werden, hat vor allem zwei Vorteile: Zum einen ist natürlich das Risiko bedeutend kleiner.

Selbst wenn ein Microservice nicht wie geplant funktioniert, kann das Komplettsystem weitgehend wie zuvor weiterlaufen und die Unannehmlichkeiten für die Kunden gestalten sich – wenn überhaupt – minimal.”

Auch können Microservices in einem solchen Fall vergleichsweise schnell angepasst werden. Zum anderen lassen sich die notwendigen Kosten über einen längeren Zeitraum verteilen, anstatt dass sofort zu Beginn des Prozesses ein hohes Investment notwendig ist. Und schließlich gewinnt die IT-Abteilung die notwendige Erfahrung im Management von Microservice-basierten Architekturen.

Mit jedem Tag steigt das Geschäftsrisiko von Legacy-Systemen

Gleichzeitig müssen sich die Verantwortlichen bewusst sein, dass dieser Prozess eine gewisse Zeit in Anspruch nehmen wird – eher fünf als drei Jahre. Doch am Ende werden sie ihre gesamte veraltete IT-Landschaft durch Microservices ersetzt haben und müssen nicht mehr fürchten, dass die Hardware plötzlich nicht mehr betriebsbereit ist oder ihnen das qualifizierte Personal für die Wartung und Weiterentwicklung der Software ausgeht.

Vor allem aber werden Banken durch eine solche Architektur flexibler und agiler.”

Sollen neue Produkte oder Services integriert werden, können dafür neue Microservices eingeführt werden. Treten neue Regularien in Kraft, können sie die entsprechenden Anforderungen im Kern der betroffenen Microservices einbauen. Was vorher systemweite Analysen und einen hohen Aufwand erforderte, lässt sich nun fokussiert und deutlich schneller umsetzen. So können Banken ihre IT tatsächlich zukunftsfähig aufstellen und nicht nur teure Pflaster auf immer größer werdende Wunden kleben, wie es beispielsweise die Verlagerung alter Mainframes ohne eine neue Architektur in die Cloud wäre. Auch wenn der Prozess nicht ohne Risiken ist und Zeit braucht, müssen Banken jetzt handeln.Toby Dixon, Endava