Ist die Versicherungs-IT bereit für Microservices?

Das Thema Microservices ist aktuell in aller Munde und erreicht nun auch die Versicherungsbranche. In vielen Diskussionen werden Architekturen auf Microservice-Basis als die Lösung für alle Probleme identifiziert. Dies gilt auch für Artikel, die sich mit Architekturen der Versicherungsbranche beschäftigen. In vielen Punkten ist dies sicherlich korrekt und der Einsatz beziehungsweise die Teilung großer Applikationen in viele kleine Module mit definierten Verantwortlichkeiten bringt Vorteile bei der Entwicklung und im Betrieb, jedoch sind die bestehenden Systemlandschaften einer Versicherung häufig nicht auf eine Microservice-Architektur ausgelegt. In diesem Artikel werden nicht wie üblich die Vorteile einer Microservice-Architektur heruntergebetet, sondern explizit auf die Herausforderungen eines solchen Aufbaus, insbesondere in einer Versicherung, eingegangen.

von Stefan Rogge, Software-Architekt & Entwickler bei adesso

Wie bereits eingangs angesprochen, tritt der Technologieansatz der Microservices schon seit einiger Zeit immer stärker in den Fokus der Softwareentwicklung und macht nun auch in eher konservativen Branchen wie bei Banken und Versicherungen auf sich aufmerksam.

Der Hype scheint allerdings an einigen Punkten den reellen Einsatzzweck beziehungsweise den Business-Value außer Acht zu lassen und häufig eher aus technischer oder „Entwickler“-Sicht auf die Möglichkeiten von Microservices zu blicken.”

So ist es zum Beispiel nicht sinnvoll, einen Monolithen im Sinne eines Service-Mesh zu zerschlagen, wenn das System nur im Ganzen weiterentwickelt werden kann.

Herausforderungen von Microservices in der Versicherung

Zunächst werden die Herausforderungen betrachtet, welchen sich insbesondere Versicherungen zu stellen haben, die Microservices einsetzen möchten. Die Herausforderungen lassen sich gut in die Kategorien technisch und organisatorisch unterteilen.

Technische Herausforderungen

Als erstes sollten die technischen Herausforderungen beleuchtet werden, da es häufig die Techniker sind, die die Umstellung der Architektur anstreben und die Vorteile verteidigen. In einer Versicherung gruppieren sich die meisten Systeme um zentrale Bestandsführungssysteme, welche die Daten zu Kunden und deren Verträgen verwalten. Dieses Herz der Versicherung ist über Schnittstellen meist eng mit den Umsystemen verzahnt, was eine Trennung erschwert. Hinzu kommt. das es sich häufig um Systeme handelt, welche aktuelle Webservice-Schnittstellen nicht bereitstellen können.

Eine enge Verzahnung von Systemen geht mit einer fehlenden Trennung von Verantwortlichkeiten einher. Diese ist jedoch eine der Grundvoraussetzungen für den Schnitt geeigneter Services nach dem Muster des Domain-Driven-Design.”

Ist die Trennung des Systems in Domänen möglich ist, so birgt die Verwaltung und der Betrieb vieler Einzelsysteme neue Herausforderungen, welche nach monolitischem Aufbau so nicht existieren. Wurden bisher Applikationsserver mit mehreren großen Anwendungen bestückt, so muss nun eine Vielzahl von kleinen Anwendungen zusammengefügt werden, um ein erfolgreiches Gesamtsystem zu schaffen. Diese Orchestrierung von Services erfordert neben Know-How der Domänen auch den Einsatz neuer Komponenten, um den Überblick über den Status und das Zusammenspiel der kleinen Einzelsysteme zu behalten. Zu nennen sind hier beispielsweise Circuit Breaker und Service-Registrierungen, aber auch neue oder andere Authentifizierungsverfahren spielen eine Rolle, um der Kommunikation über REST-Services gerecht zu werden. Zusätzlich basiert der DevOps-Ansatz auf einer hohen Automatisierung, sowohl bei der Bereitstellung, als auch beim Test einzelner Softwarekomponenten. Die Umsetzung von Webservice-Kommunikation erfordert, dass Kompensationsstrategien notwendig werden, da Transaktionen über eine Microservice-Architektur nicht umsetzbar sind. Bei dieser Aufzählung handelt es sich lediglich um eine Auswahl, die zeigen soll, dass eine einfache Aufsplittung monolithischer Strukturen nicht ohne weiteres möglich ist. Sind dazu noch Host-Systeme im Einsatz, verstärkt sich die Kopplung zusätzlich.

Organisatorische Herausforderungen

Neben den technischen Herausforderungen sind auch die Anforderungen, welche an die Organisation gestellt werden, bei der Einführung von Microservices nicht zu unterschätzen.

Die Umsetzung und Entwicklung von Microservices in eigenen Domänen setzt ein agiles Vorgehen in der Entwicklung und damit eine gewisse Agilität in der gesamten Versicherungs-IT voraus.”

Wird im Unternehmen der agile Entwicklungsansatz nicht gelebt, so verlieren Microservices schnell ihre positiven Aspekte. Insbesondere ist es notwendig, sich von sturen Entwicklungszyklen, wie zum Beispiel vier Releases im Jahr, zu verabschieden, um einen nennenswerten Vorteil durch Geschwindigkeit (Time to Market) und damit einen Business Value für die Versicherung zu schaffen. Die agile Transformation einer Versicherungs-IT ist nicht innerhalb weniger Wochen zu bestreiten und bedarf einer guten Vorbereitung sowie dem Rückhalt der Unternehmensführung. Nicht zuletzt ist vor allem die Ausbildung der Mitarbeiter in den neuen Technologien und Vorgehensmustern sowie dem agilen Ansatz notwendig, um Know-how in der Breite aufzubauen. Die Verantwortung für das in der Domäne entwickelte Artefakt liegt nach der Umsetzung im Team und sollte sich von der Entwicklung über das Release bis in den Betrieb (Stichwort Dev-Ops) erstrecken.

Wie entsteht eine Microservice-Strategie?

Nachdem im vorhergehenden Abschnitt einige der technischen und organisatorischen Herausforderungen angeschnitten wurden, stellt sich nun die Frage, wie eine Versicherung zu einer tragfähigen und erfolgreichen Microservice-Strategie kommen kann. Wenn eine Versicherung sich diese Frage gestellt hat, hat sie aber meistens einen entscheidenden Schritt übersprungen. Zu Beginn ist nämlich die Frage „Ist das Unternehmen bereit für Microservices?“ zu beantworten. Erst wenn diese Frage vollständig und positiv beantwortet werden kann, sollte mit der Erarbeitung einer Strategie für den Aufbau einer Webservice-Architektur begonnen werden.

Ist das Unternehmen bereit für Microservices?

Bevor eine Versicherung sich für eine Microservice-Strategie entscheidet, sollten zuerst folgende Fragen geklärt werden. Erst dann kann entschieden werden, ob der Einsatz von Microservice sinnvoll ist beziehungsweise erfolgreich sein kann.”

1. Was erhoffen sich Versicherer von einer Architekturumstellung und welche Ziele sollen damit erreicht werden? Wichtig ist die Frage nach dem „Warum“. Microservices bieten eine Reihe von Vorteilen, fordern aber auch sehr viel Agilität in einem Unternehmen ein. Eine Versicherung sollte sich ebenfalls die Frage stellen, ob sie wichtige Vorteile einer Microservice-Architektur (Agilität, Time-to-Market, verbesserte Reaktionsfähigkeit) erreichen will oder muss.

2. Wie agil ist ein Unternehmen aufgestellt oder soll es in der Zukunft agil sein?

Will sich die Versicherungs-IT in Zukunft agil organisieren und ist sie bereit, eine neue Struktur im Unternehmen zu etablieren, so ist eine Aufteilung der Verantwortlichkeiten auf Domänen sinnvoll. Diese Aufteilung ist des Weiteren für die Umsetzung einer Microservice-Architektur essentiell und die Systeme sollten nach dem Muster des Domain-Driven-Design aufgeteilt werden.

3. Kennt ein Versicherer seine Anwendungslandschaft?

Um eine Entscheidung für oder gegen Microservices in der Versicherung treffen zu können, muss die Anwendungslandschaft genau bekannt und beschrieben sein. Dazu gehören neben den großen Systemen zur Bestandsführung auch alle weiteren Subsysteme inklusive ihrer Schnittstellen. Nur über diesen Weg kann eine Einschätzung erfolgen, ob sich monolithische Strukturen auf Domänen auftrennen lassen. Systeme, die von vielen Services genutzt werden und mögliche Engpässe in einer Unternehmensarchitektur darstellen können, sollten genauer betrachtet werden. Dazu zählen beispielsweise das Partnersystem oder der Dokumentendruck genauso wie ein mögliches Archivsystem.

4. Welche Technologien passen in bestehende Anwendungslandschaften?

Nachdem die Anwendungslandschaft analysiert und die Möglichkeit der Trennung in Domänen bestätigt wurde, sollte in die Analyse möglicher Technologien eingestiegen werden. Dabei muss neben bekannten Parametern, welche die technische Umsetzung betreffen, auch die Fragen nach dem Umgang in der Versicherung gestellt werden. Fragen wie „Haben unsere Mitarbeiter das notwendige Know-how oder wie schnell kann Wissen zu Microservices aufgebaut werden?“ oder „Wo bestehen Rahmenverträge?“ sollten ebenfalls gestellt werden.

Wie geht es weiter?

Der Artikel greift das Thema Microservices von einer anderen Seite auf und stellt die Frage nach der Ausrichtung einer Versicherungs-IT und der bestehenden Anwendungslandschaft in den Fokus.

Eine Auftrennung der IT-Landschaft in kleine Service-Einheiten beziehungsweise Self-Contained-Systems kann einen enormen Vorteil bei der Weiterentwicklung oder Neuentwicklung von Softwaresystemen darstellen, jedoch ist der Weg in eine agile IT nicht mit der Einführung neuer Technologien und Tools beschritten, sondern beginnt mit der Fragestellung nach den Zielen und den Chancen für die bestehende Versicherungs-IT.”

Können diese Fragen positiv beantwortet werden, steht der weiteren Erarbeitung einer Umsetzungsstrategie nichts im Wege.Stefan Rogge, adesso