Die Rückkehr der IT-Architektur: BiPRO und die Digitalisierung fordern die Versicherer heraus

Fach- und IT-Architekturen von Versicherungen haben sich über Jahrzehnte kaum verändert. Doch der Bedarf an offenen Architekturen in digitalen Ökosystemen, veraltete IT-Systeme, Big Data und nicht zuletzt die BiPRO-Branchenstandards (Website) zwingen Versicherer jetzt, ihre Architekturlandschaft grundlegend anzupassen.

Dr. Matthias Gröbner, Managing Partner Detecon International

Versicherungen sind nach wie vor ein Hort der Stabilität und Kontinuität. Lange galt das auch für die Fach- und IT-Architekturen der Versicherer, denn Prozesse haben sich kaum verändert und die IT-Systeme waren zwar alt, erfüllten aber zuverlässig ihre Aufgabe. Das galt auch für die Vertriebsprozesse mit Maklern, Vertretern und Banken. Die Versicherer gaben den Vermittlern unternehmenseigene Prozess- und Schnittstellenstandards vor, an die sie mit ihren Systemen andocken mussten, wenn sie Produkte des Versicherers verkaufen wollten. Alternativ hatte der klassische Papierweg mit Fax und Post weiterhin eine große Bedeutung.

Grundsätzlich änderte daran zunächst auch die Ausweitung des Direktgeschäfts sowie die wachsende Bedeutung von Vergleichsportalen nichts. Letztendlich konnten die Versicherungen auch die neuen Schnittstellen mit den bestehenden Architekturen bedienen.

Eine erste ernsthafte Herausforderung für Versicherungsarchitekturen stellte die Herstellung einer spartenübergreifenden Kundensicht im Zuge der Einführung von neuen Betriebsmodellen und der damit einhergehenden Standardisierung und Automatisierung dar.”

Dies zwang die Versicherer, spartenübergreifende 1st-Level-Prozesse zu etablieren und ein unternehmensweites Partnerdatenmanagement aufzusetzen. Keine leichte Aufgabe, da die Spartensilos bis dahin kaum miteinander kommuniziert oder Daten ausgetauscht hatten. Den meisten Versicherern gelang dies allerdings, ohne die Architekturen mit ihren historisch gewachsenen Bestandsführungs-, Schadens- und Vertriebssystemen sowie Versicherungsprozessen grundlegend anzupassen.

Hemmschuh für eine Ablösung der Legacy-Welt waren dabei nicht nur die Technik und die hohen Investitionskosten, sondern auch die Hartnäckigkeit der Fachbereiche, ihre Produkte und Prozesse zu bewahren, weil sie hier ihren USP vermuteten.”

Architekturen im Fokus

Doch nun zwingen gleich mehrere Faktoren die Versicherungsunternehmen, sich ausführlicher mit ihren Architekturen zu beschäftigen: Die Einführung der BiPRO-Branchenstandards, der Trend zur Ablösung der in die Jahre gekommenen Anwendungen durch Standardsoftware sowie der steigende Bedarf, Daten mit Service- und Kooperationspartnern agil und flexibel über offene Schnittstellen auszutauschen und für Analytics aufbereitet zur Verfügung zu stellen. Zusätzlich wird seitens Regulatorik und Risikomanagement eine Sicherheitsarchitektur gefordert, die modernen Sicherheitsstandards entspricht.

Die größte Bewegung in bestehende Architekturen bringt aktuell die BiPRO-Umsetzung und die Ausrichtung der Schnittstellen und Prozesse am entsprechenden Standard.

Ein Problem ist, dass die Legacy-Systeme nicht die BiPRO-Sprache sprechen und auch nicht die Backend-Funktionalität in der Weise abbilden, dass sie der BiPRO-Norm folgt.”

Ein BiPRO-konformer Umbau der Anwendungen ist allerdings sehr aufwändig und kurz- bis mittelfristig nicht realisierbar. Unabhängig davon wäre eine substanzielle Anpassung vieler Systeme in vielen Fällen nicht mehr sinnvoll, weil sie sich am Ende ihres Lebenszyklus befinden.

Raus aus der Legacy – aber schrittweise und nicht sofort

Vielen Versicherern bleibt also nichts anderes übrig, als ihre bestehende Anwendungslandschaft zunächst weiter zu betreiben und eine Architekturlösung zu finden, mit der die BiPRO-Prozesse über Services und dazugehörige Mappings bedient werden können. Hierzu ist es üblich, die bestehenden Systeme durch ein API Gateway oder einen Enterprise Service Bus (ESB) zu kapseln. Kooperationspartner können mit ihren Anwendungen die über APIs angebotenen BiPRO-Webservices aufrufen und damit BiPRO-konform Daten austauschen sowie Geschäftsvorfälle abwickeln. In Abhängigkeit vom Prozesskontext reagiert der Service dabei unterschiedlich. So wird zum Beispiel bei einer Adressänderung eine andere Funktionalität bereitgestellt, je nachdem, ob ein Vertriebspartner von seiner Anwendung oder der Kunde vom Kundenportal aus den Service aufruft.

Die größere Herausforderung ist allerdings die Backend-Integration, also die Anbindung der alten Systeme an den ESB.”

Fach- und IT-Architekten müssen die bestehende Prozess- und Anwendungslandschaft genau analysieren, um festzustellen, welche Anpassungen erforderlich sind und wie diese am besten in welcher Reihenfolge realisiert und später als fachliche Services genutzt werden. Eine ESB-Lösung hat immer auch Auswirkungen auf die bestehende Datenarchitektur, da bisherige Datenmodelle in der Regel nicht vollständig mit den BiPRO-Modellen vereinbar sind. Zudem muss geklärt werden, ob die Daten zentral oder verteilt verwaltet und von welchen Services angesprochen werden.

Trotz allem ist die beschriebene ESB-Lösung zunächst nicht mehr als eine Vortäuschung falscher Tatsachen, da zwar nach Außen die Standards bedient werden, aber die Prozess- und IT-Landschaft im Backend nach wie vor nach alter Logik funktioniert. Die hohen Kosten für den Betrieb der Legacy-Systeme bleiben also bestehen, unter anderem weil Anpassungen oder Erweiterungen der BiPRO-Normen zwangsläufig auch zu mehr oder weniger umfangreichen Änderungen im Backend führen.

Um die Anwendungslandschaft nachhaltig so umzubauen, dass flexibel und kostengünstig neue Funktionen hinzugefügt oder bestehende verändert werden können, muss im Backend eine serviceorientierte Architektur (SOA) realisiert werden.”

Dazu werden die hinter der Entkopplungs-Schicht liegenden Anwendungen schrittweise in wiederverwendbare Komponenten – Services bzw. Micro-Services – aufgeteilt und mit dem Gateway sowie untereinander verbunden. Geeignete Architektur-Management-Tools helfen hier den Architekten, den richtigen fachlichen und technischen „Schnitt“ zu finden.

API-Konzept dient nicht nur der BiPRO-Unterstützung

Ein positiver Nebeneffekt einer serviceorientierten Architektur ist außerdem, dass mit den bereitgestellten APIs nicht nur BiPRO-Nutzer bedient werden können, sondern sich offene Architekturkonzepte generell umsetzen lassen. Eine steigende Anzahl von Kooperationspartnern kann so flexibel mit standardisierten Funktionalitäten versorgt werden, die über die klassischen und von BiPRO abgedeckten Geschäftsvorfälle hinausgehen. Andersherum können auch Services von externen Partnern leichter genutzt werden, z.B. der Abruf von IoT-Daten aus Smart Home und Telematik, Adressüberprüfungen, Scorings oder eVB-Verfahren. Im Zielbild besteht auch die Architektur im Backend nur noch aus Services, die miteinander kommunizieren, was eine flexiblere und effizientere Weiterentwicklung der Prozesse und Anwendungen ermöglicht.

Doch nicht in jedem Fall ist die Umsetzung eines serviceorientierten Modells auf Basis bestehender Anwendungen sinnvoll. Denn inzwischen ist eine ganze Reihe von Anbietern von Versicherungs-Standardsoftware am Markt und die Einführung eines Standardsystems kann schneller und kostengünstiger sein als umfangreiche Veränderungen an den Altsystemen, auch wenn noch nicht alle Anbieter von Standardsoftware vollständig BiPRO-konforme Lösungen bereitstellen.

Ein sinnvoller Schritt ist auch die von BiPRO angekündigte RNext-Releasegeneration, die nicht nur die fachlichen Normen vorgibt, sondern direkt nutzbare cloudfähige Softwarekomponenten bereitstellt. Interpretationsspielräume werden dadurch eingeschränkt, da die Normen in der Software bereits implementiert sind.

Aktuell werden die Weichen für die Versicherungsarchitektur der Zukunft gestellt.”

Architekturentscheidungen sollten daher wohlüberlegt sein und von fachlichen und IT-Architekturexperten begleitet werden. Denn nur mit der richtigen Architektur können Versicherer ausreichend schnell und agil auf die Herausforderungen der Digitalisierung reagieren.aj