Die Herausforderungen sind nicht neu – aufgrund des wachsenden Spannungsfelds am Markt aus neuen Marktteilnehmern, der Digitalisierung und schwachen Kundenbeziehungen – jedoch aktueller denn je: Die IT-Architekturen der meisten Banken sind geprägt von komplexen Verflechtungen großer, monolithischer und zahlreicher angrenzender Systeme, die meist von Eigenentwicklungen geprägt sind. Die Probleme, die mit solchen heterogenen Architekturen einhergehen, sind vielfältig. Neben hohen Kosten für den Betrieb und die Weiterentwicklung solcher Systemlandschaften, ist der Aufwand für dessen Wartung groß. Das hemmt die Fähigkeit Innovationen, neue Produkte, Services oder Prozesse zu integrieren. Ferner entstehen bei eigenentwickelten Systemen häufig Risiken durch Wissensmonopole, die insbesondere durch natürliche Fluktuationen, Krankheit oder Renteneintritt der zuständigen Mitarbeiter hervorgerufen werden.

Neobanken als Inspirationsquelle

Neben den systeminhärenten Herausforderungen stehen Banken einem veränderten Kundenverhalten gegenüber. Kunden fordern nicht nur eine 24/7-Verfügbarkeit, sondern auch eine Omnikanalfähigkeit von Bankservices. Die darüber hinaus durch die Entstehung von Vergleichsportalen hergestellte Markttransparenz fördert zudem die Kostensensitivität der Bankkunden. Dies führt zu einer abnehmenden Kundentreue. Dem gegenüber stehen neue Marktteilnehmer, die mit innovativen Produkten und Services in den Markt drängen und die veränderten Kundenbedürfnisse aufgreifen. Neobanken, Fin- und InsurTechs etablieren sich daher zunehmend als ernstzunehmende Marktteilnehmer, die insbesondere durch ihre nicht historisch bedingte heterogene IT-Architektur schneller auf neue Herausforderungen reagieren und innovative Produkte und Services integrieren können als traditionelle Häuser.

Neue Marktteilnehmer haben folglich das Potenzial, Banken als Inspirationsquelle zu dienen oder durch strategische Partnerschaften und Kooperationsmodelle bestehende Wettbewerbsnachteile zu kompensieren. Eine der zentralen Fragestellungen ist daher, wie es einer Bank gelingen kann ihre Architektur so zu modernisieren, dass sie die Erfolgsfaktoren von FinTechs – Schnelligkeit, Agilität, Innovationsfähigkeit – adaptieren  und gleichzeitig im Einklang mit den geltenden regulatorischen Anforderungen stehen kann.

Digitale Transformation ist ein ganzheitlicher Prozess

In der Praxis wird häufig das Ziel verfolgt, Architekturen konsequent günstiger zu gestalten. Um das Kostenziel zu erreichen, wird aus vermeintlichen Digitalisierungs- oder Modernisierungsinitiativen schnell ein reines Stilllegungs-Projekt: Systeme werden abgeschaltet oder lediglich durch günstigere ersetzt.

Diese Ansätze erzielen gelegentlich kurzfristige, positive Effekte auf der Kostenseite. Allzu häufig münden diese Projekte jedoch in kostenintensiven Nachfolgeprojekten zur Einführung neuer Systeme oder im sukzessiven Aufbau von Schattensystemen, die die Prozesse und Arbeitsschritte der Altsysteme ersetzen.

Möchten Banken die Potenziale der digitalen Transformation ausschöpfen und erfolgreiche Digitalisierungs- und Modernisierungsinitiativen einleiten, sollte die Konzeption der IT-Architektur nicht allein aus dem Blickwinkel der Kostenperspektive betrachtet werden. Ein Wechsel des Blickwinkels zur Produkt- bzw. Prozessperspektive (oder gar: Business-Capability-Perspektive) ermöglicht eine Vereinfachung der IT-Architektur und damit einhergehende digitale, innovative, kundenorientierte und günstige Produkte und Prozesse.

Wenn es gelingt, die Vereinfachung der IT-Architektur aus dem Blickwinkel des Kunden, seiner Bedürfnisse und der damit verbundenen der Produkte und Services zu betrachten, kann ein höherer Beitrag zur digitalen Transformation geleistet werden, Dabei haben sich Modelle zur Nutzung von so genannten Business Capabilities als Instrument zur Abstraktion von Prozessen und Produkten bewährt.  Das Kostenziel kann dabei gleichermaßen verfolgt werden.

Architecture Simplification als möglicher Lösungsansatz zur Komplexitätsreduktion von IT-Architekturen

Um sich von der reinen Anwendungsperspektive zu lösen und die Verbindung zur Business-Seite einer Bank herzustellen, hat sich das Business-Capability-Modell bewährt. Business Capabilities stellen funktionale Fähigkeiten dar, die eine Organisation benötigt, um ihre Geschäftsziele zu erreichen. Dabei stehen sie als abstrakter Sammelbegriff für Personen, Ressourcen, Prozesse, Werte, Technologielösungen und anderen Assets, die zur Umsetzung der Strategie bzw. einzelner strategischer Ziele verwendet werden. Im Gegensatz zu der domänenorientierten Sichtweise auf Prozesse, Produkte oder Rollen fokussieren Business Capabilties die funktionale Sichtweise und somit das Ergebnis selbst statt des Wegs dorthin. Business Capabilities beschreiben daher „was“ getan werden muss, um beispielsweise den Service „Konsumentenkredit“ zu erbringen und nicht „wie“ das getan wird. Business Capabilites lassen sich beliebig granular definieren. Um den Einstieg zu erleichtern und alle Beteiligten Akteure initial nicht zu überfordern, hat sich eine geringe Detailtiefe von etwa zwei bis drei Gliederungsebenen als pragmatisch erwiesen. So könnte sich initial zum Beispiel ein Geschäftsbereich „Retail Banking“ in 5-7 Geschäftsdomänen und jeweils 3-5 Services unterteilen. Ein Service wäre etwa „Sicherheitenbearbeitung“ oder „Zahlungsverkehr“. Perspektivisch ist eine höhere Detailtiefe anzustreben. Diese sehr grobe Gliederung eignet sich jedoch für eine initiale Verknüpfung von Systemen und Businessfunktionen.

Eine Vereinfachung der IT-Architektur setzt neben der Wahl eines entsprechenden Ansatzes zunächst eine vollständige Transparenzschaffung über die aktuelle Anwendungslandschaft einer Bank voraus. Unsere Erfahrung zeigt, dass nur wenige Häuser eine klare und vollständige Sicht auf ihre Architektur haben.

Zur Unterstützung des Ansatzes zur Vereinfachung der IT-Architektur bietet der Markt zahlreiche Tools und Systeme für ein geeignetes Architekturmanagement an. Hier sollte das Ambitionsniveau nicht der Maximalansatz sein, da eine vollständige Inventarisierung schnell in einem umfangreichen Enterprise Architektur Management-Projekt mündet. Stattdessen ist eine gezielte Informationssammlung wie etwa zur Geschäftskritikalität, zur Datenhaltung, zu Kosten oder Providern sowie deren kontinuierliche Ergänzung sinnvoller. Ein Tool-gestütztes Architekturmanagement dient in erster Linie einer strategischen Weiterentwicklung der Systemlandschaft. Es unterstützt bei der Reduktion von Komplexität, der Homogenisierung unterschiedlicher Technologien, der Reduktion von Kosten oder der Transformation in die Cloud. Ein Architekturmanagement ist keine Configuration Management Database (CMDB), die sich eher zur Unterstützung operativer IT-Steuerungsprozesse wie beispielsweise Change-, Incident-, oder Problem-Managementprozessen eignet. Wenngleich eine Verknüpfung beider Systeme perspektivisch ein wertstiftender Ansatz ist.

Eine konsequente Verfolgung des Prozesses zur systematischen Datenerhebung im Rahmen der Transparenzschaffung wird innerhalb relativ kurzer Zeit eine belastbare Datengrundlage ergeben. Diese ist wiederum Ausgangslage für eine eingehende Analyse des Anwendungsportfolios, wobei der „Strategic Fit“ der Architektur- und Unternehmensziele von zentraler Bedeutung ist. Das Bewertungsschema sollte über variable Metriken verfügen und eine anpassungsfähige Gestaltung und Gewichtung der Metriken erlauben. Dies ermöglicht eine flexible Auswertung der Daten unter unterschiedlichen Gesichtspunkten. So wird beispielsweise ein Anwendungsportfolio im Rahmen einer Cloud-Transformation anders analysiert und bewertet als es etwa im Rahmen eines Programmes zur Kostenreduktion durchgeführt werden würde.

Mögliche Dimensionen für Metriken zur Evaluation der Anwendungen könnten sein:

• Strategie
• Wirtschaftlichkeit
• Integration
• Funktionalität und
• Hersteller bzw. interner Leistungserbringer

Den jeweiligen Dimensionen liegen umfangreiche und ggf. individuelle Kriterienkataloge zugrunde, anhand derer die Informationen über das Anwendungsportfolio bewertet werden können. In diesem Rahmen ist insbesondere die vorherige Festlegung einer Priorisierung und Gewichtung innerhalb der Kriterienkataloge wichtig. Auf Basis dieser Erkenntnisse ergibt sich schließlich ein Bild über den technischen und den geschäftlichen Fit.

Dies ist die Grundlage, auf der Entscheidungen zum Umgang mit Applikationen getroffen werden. Es haben sich unterschiedliche Modelle etabliert, die eine Kategorisierung und Entscheidungsfindung erlauben. Das KPMG-eigene Modell hat sich in der Praxis bewährt.