Möglichkeiten und Lösungen: Bereinigung aus IT-Sicht

Selbst ohne strategische Analyse der Wertschöpfungsarchitektur ist eine Bereinigung des Applikationsportfolios auf Basis der Ist-Applikationslandschaft möglich. Basis für die Bereinigung sind die Zielsetzungen der IT-Strategie.

Option 1: Betriebskosten senken - Bereinigung der Technologien auf Basis des Lebenszyklus'

IT-Systeme unterliegen einem Lebenszyklus. Technologien und Softwarearchitekturen haben eine aufsteigende und reifende Phase in der sie ihre Leistungsfähigkeit entwickeln und eine absteigende Phase in der sie mit entsprechendem Wartungsaufwand stabil genutzt werden können. Am Ende des Zyklus sind die Technologien nicht mehr betriebswirtschaftlich sinnvoll nutzbar.

Am Beispiel von A001 in Abbildung 4 signalisiert die "rote" Farbe das Ende des Produktlebenszyklus'. Andere Applikation mit aufsteigenden, reifenden Technologien sind grün eingefärbt, die mit absteigenden Technologien gelb. Die Farben sind somit als Technologie-Heatmap interpretierbar.

Da "rote" Applikationen nicht mehr sinnvoll betriebswirtschaftlich betrieben werden können, sind sie Kandidaten für eine Bereinigung. In Abhängigkeit von Zielen der IT-Strategie, sollten sie auf neue Technologien gebracht werden. Die technischen Optionen sollen hier nur im Überklick kurz dargestellt werden, da der Fokus des Artikels auf der strategischen Bereinigung auf Basis des Geschäftsmodells liegt.

IT-Strategien bei Banken haben in der Regel zum Ziel IT-Betriebskosten zu senken. Die Wege dahin unterscheiden sich jedoch. Manche wählen eine Plattformstrategie auf Basis von Standardsoftware andere gehen den Weg der Virtualisierung auf Basis von Cloud-Technologien. Die beiden Wege stehen nicht im Widerspruch zueinander und lassen sich auch kombinieren. In beiden Fällen jedoch werden neue Technologien eingeführt, die geringere Betriebskosten ermöglichen. Die geringeren Betriebskosten werden in beiden Fällen durch Skaleneffekte auf Basis von Standardisierungen erzielt.

Option 2: Veränderbarkeit erhöhen - Bereinigung der Grenzen von Geschäftsfähigkeiten

Abbildung 5 zeigt, dass die Applikation A004 fachlich nicht ausreichend dimensioniert ist, um die Geschäftsfähigkeit Zahlungsverkehr (Payments) in Deutschland auszufüllen. Das führte dazu, das Kredit- und Leasingapplikationen (A001 und A002) ebenfalls einige Geschäftsfunktionen der Geschäftsfähigkeit Payments implementieren mussten.

Damit sind einige Geschäftsfunktionen der Geschäftsfähigkeit Payments mehrfach implementiert. Das hat zur Folge, dass die IT-Landschaft als Ganzes an Veränderbarkeit verliert. Jede Änderung an einer Geschäftsfunktion im Zahlungsverkehr, die nicht in der Applikation A004 enthalten ist, muss an mindestens zwei Applikationen von zwei Teams in unterschiedlichen Technologien durchgeführt werden. Das erhöht Abhängigkeiten, Implementierungszeiten, Fehlerwahrscheinlichkeiten und auf jeden Fall die Kosten.

Die IT kann die Veränderungsfähigkeit der IT-Landschaft dadurch erhöhen, dass sie Applikation A004 um die fehlenden Geschäftsfunktionen aus der Geschäftsfähigkeit Payments erweitert. Parallel dazu muss sie natürlich die Applikationen A001 und A002 entsprechend zurückbauen.

Die Portfoliobereinigung auf Basis von Geschäftsfähigkeiten setzt einen höheren Reifegrad der Architektur-Governance in der IT voraus. Es muss ein Geschäftsfähigkeiten-Modell bestehen und eine entsprechende Zuordnung der Applikationen. Ein Geschäftsstrategie-Bezug ist allerdings nicht Voraussetzung. Die bisher geschilderten Bereinigungen sind aus Sicht der IT möglich.

Diese Bereinigungen aus IT-Sicht können die Veränderbarkeit und Skalierbarkeit deutlich erhöhen und auch die Betriebskosten senken. Wir werden aber sehen, dass das nicht im Ansatz ausreichen wird, um die Wertschöpfungsarchitektur und damit die Digitalisierungsstrategie der Bank zu unterstützen.

Ziel-Geschäftsarchitektur: Strukturvorgabe für die IT-Bereinigung

Während die IT das bestehende Applikationsportfolio analysiert und mit den ersten Bereinigungen begonnen hat, haben die Business-Architekten damit angefangen, die Architekturvision aus Kapitel "A - Architekturvision" verfeinern.

Die Bank möchte zukünftig Dienstleistungsintegrator für verschiedene Kundenbedürfnisse sein und den Kundenprozess mit passenden Leistungen unterstützen. Als Beispiel wurde der der Kundenprozess "Auto besitzen" skizziert. Die Bank möchte sich aber auf die konkreten Kundenprozesse nicht festlegen, da diese kontinuierlichen Veränderungen unterliegen. Sie möchte auch die Möglichkeit haben, nach Bedarf in neue Märkte, also neue Kundenbedürfnisse zu expandieren. Da Kundenprozesse bei einem Markteinstieg nur grob bekannt sind, müssen sie in einem unternehmerischen Entdeckungsverfahren mit Versuch und Irrtum erkundet werden. Als weitere Kundenprozesse sind Beispielsweise angedacht "Vermögen aufbauen", "Haus besitzen" oder "Start-up aufbauen". Da die Kundenprozesse sehr vielfältig sein können, müssen es auch die angebotenen Leistungen sein. Die Anforderungen verlangen eine sehr hohe Flexibilität und eine entsprechende fachliche, feingranulare Strukturierung der IT. Die Businessarchitekten kommen zu dem Schluss, dass eine klassische CRM-Plattform diesen Anforderungen nicht gerecht würde.

Sie entscheiden sich stattdessen für einen leistungsfähigeren Ansatz, einer fachlichen Microservice-Architektur in den Domänen Marketing, Sales und Service, siehe Abbildung 6.

Jede Geschäftsfähigkeit mit direktem Kundenkontakt soll je Geschäftsfeld eigenständig fachlich produkt- und länderübergreifend mit dem Kunden im Mittelpunkt ausgeprägt und geführt werden. Die unabhängigen Geschäftsfähigkeiten bilden die funktionale Basis für alle zukünftigen Kundenprozesse.

Alle anderen Geschäftsfähigkeiten ohne direkten Kundenkontakt werden nach Produkten in der Domäne "Product Operation" gebündelt. Wie in der Architekturvision festgelegt, werden die Produkte auf Plattformen standardisiert und hochgradig automatisiert.

Möglichkeiten und Lösungen: Bimodale IT

Die Geschäftsarchitektur aus Abbildung 6 teilt die Bank in zwei Bereiche: eine an den Kundenprozessen ausgerichtete Bank mit hohen Veränderungsanforderungen und eine an Produkten ausgerichtete mit hohen Standardisierungsanforderungen, siehe Abbildung 7 mit oberem Kunden und unterem Produkt Teil. Die Geschäftsarchitektur fordert somit direkt eine bi-modale IT, eine IT mit zwei Geschwindigkeiten und unterschiedlichen qualitativen Anforderungen.

Die Aufspaltung stellt neben den technischen, auch hohe organisatorische Anforderungen an die IT. Die Herausforderungen stellen sich insbesondere in der Transformationsphase, worauf im Abschluss des Artikels unter Kapitel "F - Migrationsplanung: Transformationsplanung und -governance" kurz eingegangen wird.