Microservices: Wie Versicherern der Weg in die Cloud gelingen kann

Fast alle Versicherer investieren derzeit dreistellige Millionenbeträge in den Umbau ihrer Anwendungslandschaft. Der Grund hierfür ist, dass vorhandene selbst entwickelte Bestandsführungs- und Schadensysteme in die Jahre gekommen sind und aktuelle Anforderungen an Flexibilität, laufende Kosten oder Innovationsfähigkeit nicht erfüllen können. Meistens werden die Legacy-Systeme durch Standardsoftware vom Markt ersetzt, die dabei oftmals umfangreich an die Bedürfnisse des Versicherers angepasst wird. Am Ende des Migrationsprojekts werden die teilweise noch in COBOL programmierten Altanwendungen durch Software, die in einer zukunftsfähigen Programmiersprache entwickelt wurde, abgelöst. Ein Gastbeitrag.

Parallel zur Ablösung der Legacy-Systeme treiben die meisten Versicherer auch ihre Cloud-Strategie voran und wollen ihre Systeme in die Cloud migrieren oder Funktionalitäten gleich „as a Service“ von Dritten (SaaS) aus der Cloud beziehen. Damit sollen u.a. Kosten eingespart und die Skalierungsfähigkeit verbessert werden.

Die Architektur der Anwendungs- und Infrastrukturlandschaft bedarf der Anpassung

Bei näherer Betrachtung erfüllen sich die hoch gesteckten Erwartungen mit diesem Vorgehen allerdings nicht. Zwar werden mit der Einführung von Standardsoftware die weitgehend BiPRO-konformen Geschäftsprozess-Standards des Herstellers übernommen, aber die grundlegende Architektur der Anwendungs- und Infrastrukturlandschaft wird nicht verändert. Letztendlich werden nur alte Anwendungen durch neue ausgetauscht und die eine oder andere Anwendung nicht mehr im eigenen Rechenzentrum, sondern in der Cloud betrieben.

So bleibt die klassische Architektur aus Frontend, Middleware und Backend bestehen, aber damit lassen sich die gewünschten Verbesserungen hinsichtlich Skalierbarkeit und Flexibilität nicht realisieren. Die erhofften Kosteneinsparungen werden in der Regel auch nicht erzielt, weil zum einen die gekaufte Standardsoftware umfangreich angepasst wird, was zu erhöhten Kosten in Weiterentwicklung und Betrieb führt, zum anderen treiben umfangreiche Batch-Läufe und komplizierte Job-Netze die Kosten für die Cloud in die Höhe.

Entwicklung einer State-of-the-Art-Architektur und Implementierung von Microservices

Ein alternatives Vorgehen ist die Entwicklung einer State-of-the-art-Architektur, die einen dezentralen service-orientierten Ansatz verfolgt und verstärkt auf die Festlegung und Implementierung von Microservices setzt. Hierzu sind zunächst die erforderlichen fachlichen Funktionalitäten wie Tarifierung, Provision oder Schadenmanagement zu identifizieren und beschreiben, zum Beispiel mit Hilfe einer fachlichen Architekturlandkarte (Capability Map) oder entlang der Customer Journey.

Im nächsten Schritt muss überlegt werden, wie die entsprechenden Services bereitgestellt werden. Eine Möglichkeit ist die Eigenentwicklung, wobei entweder vorhandene Software angepasst oder die Funktionalitäten neu programmiert werden. Die zweite Variante ist der Einsatz von Standardsoftware. Drittens können fachliche Dienste als Software as a Service (SaaS) vom Markt bezogen werden. Welche der drei Optionen für welchen Service am besten geeignet ist, muss im Einzelfall entschieden werden. So bietet es sich an, die individuelle Gestaltung von Frontends für Vermittler und Kunden auf Basis von schnell veränderbaren Microservices selbst zu entwickeln, während klassische, stabile und automatisierbare Backend-Prozesse durch angepasste Standard-Software abgebildet werden können. Hochstandardisierte Services wie Auskünfte zur Bonität eines potenziellen Versicherungsnehmers oder innovative Dienste wie KI-Lösungen im Schadenmanagement, für die das Know-how im eigenen Haus fehlt, können wiederum von Dienstleistern oder Insurtechs eingekauft werden.

Im Fall von eigenentwickelter oder Standardsoftware muss das Versicherungsunternehmen klären, wo die Anwendungen betrieben werden. Hierfür steht vorerst weiterhin das eigene Rechenzentrum zur Verfügung, zudem kann eine Private oder Public Cloud genutzt werden. Bei einer Entscheidung für einen Cloud-Dienstleister müssen mögliche Risiken, wie zum Beispiel die Sicherstellung von Datenschutz, ein möglicher Vendor Lock-In sowie aufsichtsrechtliche Vorgaben geprüft und bewertet werden. Zur Risikominimierung ist eine Multi-Vendor-Strategie sinnvoll, um größtmögliche Flexibilität beim Wechsel des Providers oder Auslagerungsmodells sicherzustellen, zum Beispiel, um verschärften regulatorischen Richtlinien nachzukommen.

Eine Herausforderung bei diesem Vorgehen ist, die verschiedenen dezentralen (Micro-)Services zwischen eigenem Rechenzentrum, den verschiedenen Clouds und den SaaS-Dienstleistern zu orchestrieren. Hierfür werden die Services über ein Integration Layer und entsprechende API Gateways miteinander verbunden und mit Hilfe einer Cloud-Management-Plattform gesteuert und kontrolliert. Dabei wird auch festgelegt, wo welche Daten gehalten und z.B. für Analytics ausgewertet werden, da die Daten ggf. über verschiedene Cloud-Anbieter und das eigene Rechenzentrum verteilt sind.

Für die meisten Versicherer sind sowohl entsprechende Sourcing-Modelle als auch konsequente Orientierung in Richtung (Micro-)Services Neuland, aber letztendlich sind die Anforderungen der Digitalisierung nur mit einer modernen Architektur umsetzbar.

Autor: Matthias Gröbner, Managing Partner Detecon International