Die Zukunft der Business-Plattform von Banken und Versicherungen: Teil 2

Die aktuelle Anwendungslandschaft der Business-Plattform ist über die vergangenen Jahre organisch gewachsen. Neben funktionalen Erweiterungen müssen regelmässig neue regulatorische Vorgaben integriert werden. Die Heterogenität und Komplexität, die Gesamtkosten und der «technische Schuldenberg» nehmen laufend zu. In den letzten Jahren führte diese Entwicklung (itopia, 2024) bei Banken zu einem Kostenanstieg von rund 14 Prozent pro Jahr. Für die Versicherungsindustrie liegen uns keine Daten vor, jedoch gehen wir von ähnlichen Werten aus. Neue Vorhaben sind zusehend schwierig in der Umsetzung und erfordern eine aufwändige Koordination. Die laufenden Kosten des IT-Betriebs sowie der unausweichliche Technologie-Refresh verdrängen zunehmend die Budgets für Digitalisierungsprojekte, die im Business oder bei Kunden Mehrwert erzeugen. 

Orchestrierung wird zunehmend komplexer 

Auch im Betrieb stellt die derzeitige Business-Plattform eine grosse Herausforderung dar. Die Orchestrierung von Wartungsvorhaben und die Steuerung der Abhängigkeiten innerhalb der Applikationslandschaft ist eine Herkulesaufgabe. Im Störungsfall gestaltet sich die Fehlersuche als zunehmend schwierig. Folglich ist die Einhaltung der Service Levels für Verfügbarkeit oder Wiederherstellung sehr anspruchsvoll, auch weil Single-Points of Failure existieren. Und eben: Nur weil Applikationen aktuell gewartet und fast ausnahmslos verfügbar sind, applaudieren weder Kunden noch die internen Fachbereiche!

Die heute betriebene Anwendungslandschaft der Business-Plattform hat jedoch auch Vorteile: Beim Grossteil der Applikationen können wir auf profundes Wissen von erfahrenen Mitarbeitenden zurückgreifen. Diese Anwendungen basieren auf etablierten Technologien, die von zahlreichen Unternehmen seit Jahren genutzt werden. Kommt hinzu, dass die Stabilität der Anwendungen (Solidität) nach all den Jahren grundsätzlich gegeben ist. Wären da nur nicht Wartung und Weiterentwicklung sowie die dynamischen Kundenbedürfnisse! 

Entkopplung ist zwingend erforderlich

Die technologische Transformation der Business-Plattform muss einerseits das Szenario abdecken, dass das monolithische Kernsystem durch den Softwarehersteller erfolgreich umgebaut wird. Andererseits muss sie aber auch die Flexibilität bieten, damit andere Lösungsansätze umsetzbar sind. Der Entkoppelung und Modularisierung kommt dabei eine absolut strategische Rolle zu (vgl. Decoupling Platform). Unsere Analyse der laufenden Vorhaben der Kernsystem-Hersteller zeigt folgende, konsolidierten Trends: 
 

• Der Monolith wird aufgebrochen und in eine (micro-)serviceorientierte Struktur überführt. 
• Die einzelnen Module werden unabhängig und können individuell entwickelt, betrieben und gewartet werden. 
• Die Module werden geöffnet und entsprechende APIs zur Verfügung gestellt. 
• Module werden containerisiert und sollen auf PaaS-Services betrieben werden. 
• Syrius (Adcubum) kann ohne Oracle (PostgreSQL) betrieben werden; ein wichtiger Lock-in wird aufgelöst. 
• Grundsätzlich wäre ein Betrieb unabhängig von der IT-Infrastruktur möglich. 
• Die effektive Maturität (vgl. 12-Factors) der neuen Software kann aber erst mit der Veröffentlichung beurteilt werden. 
   

Es bewegt sich etwas bei den Kernsystemen und es geht in eine positive Richtung. Wir stellen jedoch fest, dass die Infrastruktur-Plattform und damit die Wahl des Kunden eingeschränkt wird. Dies führt zu neuen resp. zusätzlichen Lock-ins (z. B. OpenShift statt Kubernetes). Diese Vorgabe ist aus Sicht Support & Wartung des SW-Herstellers zwar nachvollziehbar, aber bzgl. Skalierung und Betrieb der gesamten IT nachteilig. Ferner stellen wir fest, dass die Kernsystem-Hersteller durch funktionale Erweiterungen wachsen und einen proprietären Integration-Layer zur Verfügung stellen. Damit wird den Kunden die Integrationstechnologie der Kernapplikation vorgegeben, eine weitere, indirekte Abhängigkeit zum Kernsystem geschaffen und der Lock-in weiter verstärkt. Zudem kann dieser Integration-Layer nicht für die gesamte Anwendungslandschaft skaliert werden (vgl. Decoupling Layer), was die Komplexität und zukünftigen Kosten zusätzlich antreibt.

Auch bei den Umsystemen bewegt sich etwas. Bei den Herstellern von Standard-Produkten sehen wir nur zögerliche Efforts, die Applikationen zu modernisieren. Dies erklären wir uns primär mit knappen Software-Entwicklungsressourcen. Die meisten Anbieter sind tendenziell kleinere KMUs bzw. das Produkt ist nur eine Nische im Gesamtangebot. Eine ähnliche Maturität beobachten wir auch bei neuen Standard-Softwareprodukten. Bei Individualentwicklungen schätzen wir die Maturität grundsätzlich höher ein. 

All das bedeutet, dass die Umsystem-Landschaft in absehbarer Zeit keine drastische Vereinfachung und technische Harmonisierung erlaubt und folglich in drei Pattern strukturiert werden kann: 

1. Pattern / Legacy: Monolithische Applikationen (Scale-up, Legacy-Technologien, keine API, Fat-Client) 
2. Pattern / Cloud ready: Moderne 3-Tier-Anwendung (Scale-out, public adressiert, API, Web-GUI) 
3. Pattern / Cloud native: 12-Faktor-Anwendung (Container, public adressiert, API, Composable-Experience) 

Nach diesen technischen Ausführungen werden wir im Schlussteil die Entwicklungen des IT-Betriebskonzepts betrachten und Empfehlungen für die IT-Strategie als Fazit ableiten. 

Bei Fragen bis hierin geben wir jederzeit gerne Auskunft. 

Autoren: Urs Rhyner, Rino Decurtins, Philippe Müller