Banken brauchen neue Fähigkeiten, um die IT-Komplexität zu zähmen

Von Dr. Felix Buschor

Die IT-Landschaft der Banken hat sich den letzten Jahren stark verändert. Mehr oder weniger schleichend hat eine Entwicklung von kompakten und uniformen zu verteilten und diversen Systemlandschaften stattgefunden. Damit einher geht eine erhöhte Komplexität, deren Bewältigung mancherorts für Bauchschmerzen sorgt.

Gerade kleinere und mittlere Retailbanken, aber auch viele Privatbanken setzen seit Jahren Standardprodukte als Kernbankensysteme ein. Diese Kernbankensysteme sind in der Regel als Monolithen gebaut, was heisst, dass sämtliche Funktionalitäten in einer einzigen, umfangreichen Softwareanwendung zusammengefasst sind. Mit dem monolithischen Ansatz ist unter anderem die Idee verbunden, dass so viele Funktionalitäten wie möglich darin zusammengepackt sind. Für die Banken hatte dieser Ansatz über viele Jahre den Vorteil, dass sie alles aus einer Hand beziehen konnten. Die zugehörige IT-Strategie lautete, Funktionalitäten werden aus dem Kernbankensystem bezogen, und wenn diese dort nicht verfügbar sind, dann sind sie nicht nötig. Mit anderen Worten: Der Hersteller des Kernbankensystems wird schon wissen, was die Bank benötigt.

Die Systemlandschaften der Banken werden diverser und verteilter

Mancher CIO musste nun aber erfahren, dass diese auf das Kernbankensystem fokussierte Haltung je länger weniger aufrecht gehalten werden kann. Im Zuge der Digitalisierung haben nicht nur das Angebot an IT-Produkten, sondern auch die Bedürfnisse der Benutzerinnen und Benutzer und insbesondere der Kundinnen und Kunden zugenommen. Der CIO ist von seinen Kolleginnen und Kollegen aus dem Verkauf oder Vertrieb immer stärker unter Druck gesetzt worden, auch Software-Produkte von anderen Herstellern zuzulassen. Es hat ein Wandel von einem produkt-zentrierten zu einem kunden-zentrierten Software-Markt stattgefunden. Parallel hat eine ganze Reihe von technischen Entwicklungen stattgefunden, die dazu geführt haben, dass die Art und Weise wie Software gebaut, ausgeliefert und betrieben wird, sich komplett verändert hat. An dieser Stelle soll lediglich ein Beispiel herausgegriffen werden, nämlich das Architektur-Muster der Microservices, bzw. der Self-contained Services. Was sind Microservices? Vereinfacht gesagt wird durch das Architektur-Muster der Microservice eine große Anwendung in kleinere Anwendungen zerlegt, die voneinander unabhängig sind und je abgeschlossene Aufgaben zusammenfassen. Man sagt auch, dass die einzelnen Microservices untereinander lose gekoppelt sind. Der Ansatz der Microservices ist mit zahlreichen Vorteilen verbunden. So etwa bringen es voneinander unabhängige, eher schlanke Microservices mit sich, dass IT-Applikationslandschaften schneller entwickelt werden können und diese robuster sind, da im Falle einer Störung nicht das ganze System abstürzt, sondern nur ein Teilbereich. Mit dem Einsatz von Microservices oder Self-contained Services hat sich die IT-Landschaft der Banken zwar verändert, aber ganz auf den Kopf gestellt wurde sie trotzdem nicht. Die Kernbankensysteme sind immer noch im Einsatz, aber sie werden durch eine wachsende Zahl von Microservices, in der Praxis eher Self-contained Services[1] erweitert.

Insgesamt haben die Emanzipation der Benutzerinnen und Benutzer auf der einen Seite und neue technische Möglichkeiten auf der anderen Seite dazu geführt, dass sich die IT-Systemlandschaft der Banken von einer kompakten und uniformen zu einer verteilten und diversen Landschaft entwickelt hat (siehe Abb. 1).

Komplexitätsbewältigung durch Kompetenzen in Architektur, Integration & Orchestrierung

Wenn die Systemlandschaft verteilter und diverser wird, dann ist eine einleuchtende Konsequenz, dass die Komplexität deutlich zunimmt. Geht es darum, die zunehmende Komplexität unter Kontrolle zu halten, besteht eine Möglichkeit darin, geeignete Fähigkeiten aufzubauen. Welches könnten solche Fähigkeiten sein, die dabei helfen, die Komplexität der IT-Applikationslandschaft im Zaun zu halten? An dieser Stelle wird die Meinung vertreten, dass es deren drei sind: Architektur, Integration und Orchestrierung. Diese drei Kompetenzen können entlang des Lebenszyklus von Software angeordnet werden und zwar sowohl für den Fall der Entwicklung einer Individualsoftware als auch für den Fall der Einführung eines Standardprodukts (siehe Abb. 2)

Gelebte IT-Architektur deckt im Wesentlichen drei Themen ab: Erstens strukturiert sie die IT-Landschaft, indem sie beispielsweise festlegt, welche Funktionalitäten in eigenständigen Applikationen zusammengefasst werden. Zweitens verlangt sie zwingende Eigenschaften, die eine IT-Anwendung aufweisen muss. Dazu gehören etwa Vorgaben zur Betriebs- oder zur Informationssicherheit. Und drittens formuliert sie Design Prinzipien, die bei der Beschaffung oder dem Bau von Software zu berücksichtigen sind. Wird die IT-Architektur entlang dieser drei Aufgaben gelebt, dann vermag sie einen unverzichtbaren Beitrag zur Kontrolle der Komplexität zu leisten.

Immer wenn eine Bank ihre IT-Funktionalitäten nicht mehr ausschliesslich aus dem Kernbankensystem bezieht, sondern die bestehende IT-Landschaft mit gekauften oder selber entwickelten Anwendungen erweitert, stellt sich die Herausforderung der Integration. In aller Regel hat die Integration in vier verschiedene Richtungen zu erfolgen. (a) Ein neues Softwareprodukt ist mit dem Backend und dort vor allem mit dem Kernbankensystem zu verbinden. (b) Ein neues Softwareprodukt ist in die Welt der Sicherheitssysteme der Bank zu integrieren. (c) Neue Anwendungen sind in die Infrastruktur-Landschaft der Bank einzubauen. Und (d) Mit Blick auf ein gelingendes Benutzererlebnis ist die Anwendung – beispielsweise mit Hilfe eines Portalansatzes – in die Benutzeroberfläche einzubetten. Da es sich bei der Integration häufig um eine schwierige, aufwändige und deshalb teure Angelegenheit handelt, lohnt es sich, diese sowohl in Bezug auf Methodik als auch in Bezug auf Toolunterstützung zu standardisieren, ja zu industrialisieren. Wenn die Integration in alle drei Richtungen gemäss einem standardisierten Vorgehen erfolgt, wird damit mit Bestimmtheit ein wichtiger Beitrag zur Kontrolle der Komplexität geleistet.

Orchestrierung als Kompetenz hat ihr hauptsächliches Einsatzgebiet in der Phase der Nutzung. Die Orchestrierung als Fähigkeit findet ihre Rechtfertigung in der Feststellung, dass Störungen im Betrieb einer verteilten und diversen Systemlandschaft um ein Vielfaches schwieriger zu analysieren und zu beheben sind als in einer kompakten, uniformen Landschaft. Unter Orchestrierung als Kompetenz wird deshalb verstanden, dass für die gängigen Benutzerreisen bekannt und dokumentiert ist, welche Anwendungen und technischen Komponenten in deren Verlauf verwendet werden. Man könnte sagen, dass die technischen und applikatorischen Stücklisten der Benutzerreisen vertraut sind. Gibt es solche Stücklisten, dann ist die Grundlage geschaffen, um eine aussagekräftige Betriebsüberwachung aufzubauen und um im Störfall ein zielgerichtetes sowie schnelles Issuemanagement zu garantieren.

Fazit

Die IT-Landschaften der Banken werden nicht zuletzt aufgrund der Benutzeranforderungen immer vielfältiger und diverser. Der CIO ist gefordert, Mittel und Wege zu finden, um die steigende Komplexität seiner Systemlandschaft zu zähmen. In diesem Blog wird die Meinung vertreten, dass der Aufbau geeigneter Fähigkeiten dazu einen Beitrag leisten kann. Für die Komplexitätsbewältigung zentrale Kompetenzen sind demnach das Durchsetzen einer klaren IT-Architektur, die Industrialisierung der Integration und schliesslich die Orchestrierung der in einer Benutzerreise eingesetzten Komponenten.

Möchten Sie das Thema mit uns vertiefen? Dann nehmen Sie mit uns Kontakt auf (felix.buschor@hslu.ch). Sind Sie an vertiefenden Ausführungen zum Thema IT Skills interessiert? Dann melden Sie sich für das IFZ Bank-IT Forum «IT Skills-Management» vom 28. Oktober an (IFZ Bank-IT Forum: IT-Skills-Management (online) | Hochschule Luzern (hslu.ch))