So räumen IT-Architekten die Applikationslandschaft auf

IT-Landschaften sind dynamische Konstrukte. Ein neugegründetes Unternehmen folgt typischerweise zunächst einem einfachen Geschäftsmodell, für dessen Unterstützung eine IT-Landschaft aufgebaut wird. Im Laufe der Zeit wird dann das Geschäftsmodell ausgeweitet, neue Geschäftsfähigkeiten kommen hinzu. Die bestehende IT-Landschaft wird dabei meist aus technischer Sicht erweitert, um den zusätzlichen Anforderungen gerecht zu werden. Dabei werden die Anforderungen an die gesamte Architektur tendenziell zu wenig beachtet.

So entstehen IT-Landschaften, die als Geschäftsarchitektur-Monolithen mehrere Geschäftsfelder und -fähigkeiten unterstützen. Die einzelnen Fähigkeiten und Geschäftsfelder sind alle miteinander verbunden und nicht mehr einzeln führbar. Das Ergebnis ist eine hohe Gesamtkomplexität verbunden mit Inflexibilität, begrenzter Skalierbarkeit, sowie hohen Betriebs- und Änderungskosten. Tiefgreifende Änderungen am Geschäftsmodell, die die Digitalisierung in der Regel erfordert, sind betriebswirtschaftlich nicht mehr sinnvoll umsetzbar. Die IT-Landschaft und das Applikationsportfolio müssen strukturell bereinigt werden.

Angelehnt an der TOGAF Architecture Development Method (ADM - siehe Abbildung 1) der Open Group wird im Folgenden am Beispiel einer Bank ein systematisches Vorgehen zur Bereinigung des Applikationsportfolios aus geschäftsstrategischer Sicht dargestellt. Die IT-Landschaft und das Applikationsportfolio werden dabei an den neuen Anforderungen der Digitalisierung ausgerichtet.

Architekturvision für die Digitalisierung: Die Geschäftsstrategie

Das Beispiel geht davon aus, dass die Bank den Kunden strategisch in den Mittelpunkt stellen möchte. Sie will sich vom Markt differenzieren, in dem sie die Kundenbedürfnisse im Kontext von Finanzdienstleistungen besonders gut befriedigen möchte. Dabei will sich die Bank auf bestimmte Kundenprozesse spezialisieren, die sie als Dienstleistungsintegrator besser abzudecken glaubt als ihre Mitbewerber.

Zur Illustration dient ein Kundenprozess "Auto besitzen". Der Kundenprozess erstreckt sich von der Informations- über die Angebots-, Kauf- und Betriebsphase bis schließlich zur Verkaufs- und Neukaufphase. Die Bank möchte dem Kunden alle Dienstleistungen möglichst kanalübergreifend anbieten, um den Prozess Auto besitzen so komfortabel wie möglich zu gestalten. Dazu gehören im wesentlichen Autotests und -erfahrungen, bedarfsgerechte Automodelle und -konfigurationen, Finanzierungsprodukte, Versicherungen sowie Wartungsangebote und Mobilitätsdienstleistungen. Dabei möchte die Bank ausschließlich Finanzierungsprodukte selbst anbieten und die anderen Dienstleistungen vermitteln.

In Zeiten der Digitalisierung soll der Autokauf über verschiedene Kanäle hinweg möglich sein. Also aus einer Hand im Web, komplett im Autohaus oder hybrid in einem sinnvollen Mix beider Kanäle. Der Abschluss soll direkt möglich sein. Der Kunde erhält Lieferdatum und die Finanzierungszusage innerhalb weniger Sekunden mit Versicherungszusage. Einen kanalübergreifenden Kauf erlauben die Systeme der Bank heute nicht. Genauso wenig ist ein 24/7-Betrieb für das Internet möglich. Kreditzusagen dauern mehrere Tage. Die heutigen Systeme lassen solch ein Strategieszenario also nicht zu - weder bezüglich Verfügbarkeit, noch in der Skalierbarkeit und auch nicht in der Abdeckung der Dienstleistungen für die einzelnen Phasen der Kundenprozesse.

Die Bank hatte bisher keine kundenzentrierte, sondern eine länder- und produktorientierte Strategie, die historisch bedingt war. Sie begann mit Finanzierungen im Inland. Dann kamen Leasing und Versicherungsangebote hinzu. Parallel wurde begonnen autarke Filialen im europäischen Ausland aufzubauen.

Um das bestehende Applikationsportfolio aufzuräumen und auf die neue Strategie anzupassen, wird die Bank für Analyse und Planungszwecke verschiedene Bebauungspläne erstellen. Diese werden denselben Kartengrund mit einer y-Achse für strategische Geschäftsfelder und einer x-Achse für Geschäftsfähigkeiten haben. Um die Architekturvision zu erstellen, sind strategische Analysen der Geschäftsfelder, Geschäftsfähigkeiten und der Wertschöpfungsarchitektur Voraussetzung.

Strategische Geschäftsfelder

Für die Architekturvision sind im ersten Schritt die strategischen Geschäftsfelder klar abzugrenzen. Dabei werden Marktdimensionen in eine Reihenfolge gebracht, mit der man sich mit abnehmender Bedeutung differenzieren möchte:

Kunde > Produkt > Land > Kanal.

Durch die Fokussierung auf Kundenprozesse ist die erste Differenzierung die Dimension Kunde. Danach erfolgt eine Differenzierung über das passende Produktportfolio. Land und Kanal sollen möglichst standardisiert werden, mit Varianten in lokalen Compliance-Anforderungen. Diese Reihenfolge ist von hoher Bedeutung, da die Geschäftsfelder über die erste Dimension getrennt und über die nachfolgenden charakterisiert werden. Durch die Historie hatte die Bank bisher die strategische Reihenfolge:

Land > Produkt > Kunde > Kanal

Die Folge war, das IT-Systeme primär an Länder- und Produktbedürfnissen ausgerichtet wurden und mit geringer Priorität an Kundenbedürfnissen. Auf Basis der neu definierten Reihenfolge bildet die Bank zwei strategische Geschäftsfelder: Privatkunden und Geschäftskunden. Den Geschäftsfeldern ordnet sie die jeweiligen spezifischen Produktgruppen zu.

Die Geschäftsfelder definieren die y-Achse für mehrere Bebauungspläne, die die Bank im Folgenden erstellt. Abbildung 2 zeigt einen Kartengrund mit einer vereinfachten Darstellung von Geschäftsfeldern auf der y-Achse. Die Länder werden nur für Analysezwecke mit aufgenommen. Zukünftig soll darüber nicht mehr differenziert werden. Für die Sicht auf die Informationssysteme wird die Dimension aber wichtig sein, da sie bisher führend war. Da nach Kanälen nicht unterschieden werden soll (Omni-Channel-Strategie), erscheinen sie auch nicht auf dem Kartengrund.

Geschäftsfähigkeiten

Auf der x-Achse definiert die Bank die wesentlichen Geschäftsfähigkeiten, die notwendig sind, um die Kundenprozesse zu unterstützen. Die Geschäftsfähigkeiten bilden die Leistungsgrundlage des gesamten Geschäftsmodells. Als Referenzgrundlage für ein eigenes Geschäftsfähigkeitenmodell verwendet die Bank den Banking-Framework BIAN Service Landscape 4.0 (Banking Industry Architecture Network - bian.org). Abbildung 2 zeigt auf der x-Achse ein vereinfachtes Geschäftsfähigkeitenmodell auf Basis des BIAN Standards.

Wertschöpfungsarchitektur

Als ersten Bebauungsplan erstellt die Bank die neue Wertschöpfungsarchitektur. Dabei werden auf dem Kartengrund die entscheidenden wertschöpfendenden Prozesse auf oberster Stufe eingezeichnet, die sogenannten Level-1-Prozesse. Die Level-1-Prozesse gruppieren Geschäftsfähigkeiten, die in einem engen Austausch stehen und im Wesentlichen qualitativ gleich ausgeprägt werden sollen. Die Bank trennt Marketing, Sales und Serviceprozesse funktional über die Geschäftsfelder hinweg, siehe Abbildung 3, da zum Beispiel ein Verkaufsprozess sich für Geschäftskunden grundlegend von dem für Privatkunden unterscheiden soll. Das klingt selbstverständlich, war es aber bisher in der dominierenden Länder-Produkt-Strategie nicht. Da die Dimension Kunde in der Reihenfolge bisher in der Länder-Produkt-Strategie zu wenig Gewicht hatte, wurden die Prozesse über die Kundengruppen hinweg nicht explizit unterschieden, sondern in ihren Ausprägungen vermischt.

In der Wertschöpfungsarchitektur stehen Geschäftsfähigkeiten innerhalb einer Domäne in enger Kommunikationsverbindung, wohingegen sie über die Domänengrenze hinweg weniger kommunizieren.

Die über Level-1-Prozesse gruppierten Geschäftsfähigkeiten sollen Kundenprozesse flexibel abbilden. Sie unterliegen einer hohen Änderungsdynamik, da die Geschäftsfähigkeiten kontinuierlich die Bedürfnisse der Kunden besser abbilden sollen. Da sie marktdifferenzierend sind, sind sie das Rückgrat der Strategie. Marktdifferenzierende Prozesse färbt die Bank orange ein.

Für die Geschäftsfähigkeit "Product Specific Fulfillment" in der Domäne Product Operation schafft die Bank vier produktspezifische Prozesse für Kredit, Leasing, Flottenleasing und Versicherung. Die Produkte Kredit und Versicherung sollen sich für die Geschäftsfelder nicht unterschieden. Sie werden übergreifend identisch angeboten. Lediglich die Produkte Leasing und Flotten-Leasing benötigen geschäftsfeldspezifische Ausprägungen der Geschäftsfähigkeit. Prozesse der Domäne Product Operation färbt die Bank blau ein. Sie sollen hochgradig standardisiert und automatisiert ausgeprägt werden. Hier entscheiden hohe Verarbeitungsgeschwindigkeit, sowie geringe Prozess- und Betriebskosten. Die Produkte sind aus Sicht der Bank auf dem Markt homogen, das heißt sie unterscheiden sich nur durch Verfügbarkeit und Preis.

Die Wertschöpfungsarchitektur definiert den strategischen Rahmen für die Zielbebauung der Informationssysteme. Sie definiert die Systemgrenzen und gibt die wesentlichen strategischen Qualitätsanforderungen vor wie Veränderbarkeit, Automatisierbarkeit und Kosten.

Informationssystemarchitektur: Bestehende Informationssysteme

Um einen Überblick über die Leistungsfähigkeit des bestehenden Applikationsportfolios zu bekommen, zeichnet die Bank die bestehenden Informationssysteme in den Kartengrund ein. So bekommt sie ein Bild von der Ist-Applikationslandschaft (siehe Abbildung 4).

Jede Applikation erhält eine eindeutige Identifikationsnummer, zum Beispiel "A001". Sie bekommt einen Karteneintrag für jede unterstützte Geschäftsfähigkeit je Land, Produkt und Kundengruppe. Dabei kann eine Applikation mehrfach erscheinen, wenn sie mehrere Produkte oder Kundengruppen unterstützt. Abbildung 4 ist eine vereinfachte Darstellung der Realität. Eine internationale Bank hat typischerweise mehrere hundert bis wenige tausend Applikationen im Einsatz.

An diesem Bild wird deutlich inwieweit die bisherige Länderstrategie die Systeme geformt hat. Die Applikationslandschaft ist horizontal nach Ländern ausgeprägt. Die Systeme beachten häufig nicht die Domänengrenzen und sind über alle Domänen hinweg häufig produktorientiert. Das Applikationsbeispiel A001 zeigt eine Kreditapplikation, die die Geschäftsfähigkeiten aus den Domänen Sales, Service und Product Operation unterstützt. Selbst Teile der Geschäftsfähigkeit "Payment" sind implementiert.

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.

Informationssystem- und Technologiearchitektur: Applikationsportfolio strategisch aufräumen

Alle Vorarbeiten sind getan. Die IT hat nun alle Vorgaben, um das Applikationsportfolio strategisch nach den Vorgaben der Geschäftsarchitektur und der IT-Strategie aufzuräumen und strategisch auszurichten. Dazu legt sie die Karte Geschäftsarchitektur (Abbildung 6) über die Karte Ist-Applikationslandschaft (Abbildung 4). Es entsteht die strategische Planungsgrundlage für die Soll-Applikationslandschaft (Abbildung 8).

Die Grenzen der Level-1-Prozesse aus der Geschäftsarchitektur geben die Grenzen der Applikationen vor. Als Planungsprinzip gilt dabei, dass es eine Applikation pro Level-1-Prozess geben soll. Applikationen sollen über die Prozessgrenzen hinweg lose gekoppelt und unabhängig führbar sein. Innerhalb eines Level-1-Prozesses soll die Applikation eine logische Einheit sein, die aber durchaus weiter in Geschäftsfunktionen modularisiert werden kann. Wichtig zu unterscheiden an dieser Stelle ist Applikation und Technologieplattform. Eine Applikation ist in sich geschlossen, sowie unabhängig entwickel- und installierbar. Mehrere Applikationen können auf einer Technologieplattform betrieben werden.

Die IT der Bank entwickelt auf Basis der strategischen Planungsgrundlage eine Soll-Applikationslandschaft (Abbildung 9), die die Grenzen der Geschäftsarchitektur einhält und die Prinzipien umsetzt.

Die Bank beschließt, nur Applikationen mit aufsteigender Technologie ("grüne Applikationskästchen") für die Soll-Planung zu verwenden. Rote und gelbe werden abgeschaltet oder ersetzt. Für die Geschäftsfähigkeit Payments verwendet die Landesgesellschaft Großbritannien heute schon eine Standardsoftware mit aktueller Technologie (A008). Diese Applikation soll ausgebaut werden zur zentralen internationalen Zahlungsplattform A008. Für den Kredit wird die Applikation A010 international standardisiert ausgebaut. Für das Privatkundenleasing entscheidet sich die Bank für den Ausbau von A015 in zwei Varianten. Eine für das Privatkundengeschäft A015-PK und eine für die Geschäftskunden A015-GK.

Für das Produkt Versicherungen hat die Bank keinerlei aktuelle Technologie im Portfolio. Sie entscheidet sich dafür eine neue Standardsoftware anzuschaffen. Da zum Planungszeitpunkt noch nicht entschieden werden kann, welche Standardsoftware angeschafft werden soll, zeichnet sie auf der Soll-Applikationslandschaft einen blauen Platzhalter Versicherung (PH Versicherung) ein. Die blaue Farbe markiert die strategischen Eigenschaften, die die Applikation haben soll: stabil, standardisiert, produktorientiert, automatisiert und kosteneffizient. Im Laufe der anschließenden Transformation wird ein entsprechendes Softwareauswahl-Projekt eingeplant, dass eine passende Standardsoftware auswählen soll.

Ähnlich geht die Bank beim Bebauungsplan für die Domänen Marketing, Sales und Service vor. Sie besitzt zwar moderne "grüne" Applikationen in den Domänen, aber keine davon eignet sich als Basis für Microservices in der Cloud. Die Bank entscheidet sich dafür, die kundenfokussierten Geschäftsfähigkeiten auf Basis einer Platform as a Service (PaaS) in der Cloud neu zu entwickeln. Da zum Planungszeitpunkt noch nicht klar ist, wie das im Detail geschehen soll, zeichnet die IT der Bank für jede Geschäftsfähigkeit, die über Microservices implementiert werden soll, einen orangenen Platzhalter. Wie die blauen Platzhalter, markiert die orangene Farbe die strategischen Eigenschaften, die die zukünftigen Microservices haben sollen: veränderbar, spezifisch, kundenorientiert, flexibel und agil.

Möglichkeiten und Lösungen: Soll und Ist-Applikationslandschaft im Vergleich, sowie der Reifegrad der Unternehmensarchitektur

Die Soll-Applikationslandschaft unterscheidet sich quantitativ, qualitativ und strukturell elementar von der Ist-Applikationslandschaft, siehe direkten Vergleich in Abbildung 10.

Die Anzahl der Applikationen wird über die Strategie im Bereich Produkt Operations stark reduziert. Die strategisch kundenfokussierten Anforderungen in den Domänen Marketing, Sales und Service sind mit der bestehenden Technologie weder qualitativ noch strukturell erfüllbar. Diese Applikationen müssen in der Transformation strukturiert zurückgebaut und bis zur gänzlichen Abschaltung Schritt für Schritt durch Microservices ersetzt werden.

Der Landschaftsvergleich macht deutlich, welche unterschiedlichen IT-Bebauungen die jeweils unterschiedlichen Strategien aus Geschäftsfeld- und Geschäftsfähigkeitskombinationen hervorbringen. Die unterschiedliche Struktur wird primär getrieben durch die strategische Priorisierung von Kunde > Produkt > Land > Kanal im Soll oder Land > Produkt > Kunde > Kanal im Ist. Die ersten beiden Dimensionen entscheiden über die Struktur des Applikationsportfolios. Die Wertschöpfungsarchitektur entscheidet über die Qualität und Quantität.

Die strategische Bebauungsplanung setzt einen hohen Reifegrad der Unternehmensarchitektur und der strategischen Planungsfähigkeit- und -willigkeit voraus. Die Geschäftsstrategie muss analysierbar sein und strategische Geschäftsfelder abbildbar. Die Unternehmensarchitektur muss ein Geschäftsfähigkeitenmodell bereitstellen und die Geschäftsarchitekten müssen eine Prozessarchitektur für das Wertschöpfungsmodell erstellen. Erst dann bekommt die IT die Möglichkeit das Applikationsportfolio strategisch aufzuräumen. Kapitel "E - Möglichkeiten und Lösungen: Bereinigung aus IT-Sicht" hat gezeigt, dass ein Aufräumen des Applikationsportfolios auch ohne strategische Analysen möglich ist. Die jeweiligen Optionen zeigten aber auch die Beschränkungen auf. Die IT kann das Portfolio zwar aufräumen, bleibt aber strukturell immer im alten Geschäftsmodell verhaftet. Der Weg in ein digitales Geschäftsmodell erfordert eben auch eine digitale Geschäftsarchitektur an der sich die IT ausrichten kann.

Migrationsplanung: Transformationsplanung und -governance

Die Bank hat eine Soll-Applikationslandschaft entwickelt, die sich fundamental von der heutigen Ist-Applikationslandschaft unterscheidet. Die Erfahrung zeigt, dass jetzt der schwierigste Teil beginnt: die Transformation. Hierfür müssen Planungs- und Governance-Strukturen aufgesetzt, sowie organisatorische Änderungen eingeleitet werden. Die IT muss taktische Bebauungspläne entwickeln, um Zwischenstufen auf dem Weg zum Ziel aufzuzeigen. Das Management muss Rahmenbedingungen für Änderungsbewusstsein und -bereitschaft, Ressourcenumleitung und -neuaufbau schaffen und aktiv kontinuierlich managen. Insbesondere der Aufbau von Microservices revolutioniert die IT-Organisation.

Die Transformationsplanung und -Governance und ist so ein umfängliches und komplexes Thema, dass sie im Umfang dieses Artikels nur kurz angedeutet werden konnte.