Neue Welt – Dank Microservices sprechen Fachbereiche und IT eine Sprache
Versicherer verstehen ihre eigene IT nicht mehr. Neun von zehn Managern wünschen sich, dass sich die IT-Systeme wieder besser durchschauen lassen. Die „Blackbox IT“ sorgt für Frust. Wer seine IT-Systeme modernisieren will, sollte deshalb künftig lernen, selbst zu programmieren, sich von Standard-Software verabschieden und Microservices als Kernbaustein einer neuen IT-Architektur ernsthaft prüfen.
Wie sehr die Anbieter derzeit mit ihrer IT hadern, zeigt eine Umfrage von Camunda, an der sich mehr als 100 Führungskräfte und Projektleiter aus der Branche beteiligt haben. Die Versicherer wünschen sich neben einer leichter zu verstehenden IT vor allem Anwendungen, die sich einfach anpassen lassen und dabei unterstützen, neue Produkte zu entwickeln (vgl. Abb. 1). Als schwierig gilt zudem, dass immer noch viele Anbieter an wenige Releasezyklen pro Jahr gebunden sind und selbst Teilprogramme nur schwer anpassen können. Vielmehr gelten selbst für kleinste Änderungen feste Termine, an denen die IT aktualisiert werden kann.
Abb. 1: Versicherer kämpfen mit der eigenen IT, vor allem was die Verständlichkeit angeht.
Großsysteme aufbrechen
Monolithen in der IT stellen die Versicherer einerseits vor technische Probleme. Sie können sich gerade bei Standard-Software kaum selbst darum kümmern, wenn sie etwas anders machen wollen – und zumindest die Fachbereiche sind stets dazu gezwungen, für jede Kleinigkeit einen Change Request an die IT zu stellen. Andererseits bringt die veraltete IT auch organisatorische Probleme mit sich, weil häufig eine gemeinsame Sprache fehlt. IT‘ler denken in Datenbanken, Code und wie Informationen von A nach B gelangen. Fachabteilungen wie Underwriting, Schaden, Controlling oder Marketing dagegen denken in ganz eigenen Termini. Sie verstehen nicht, dass eine auf den ersten Blick simple Anpassung IT-technisch enorme Aufwände nach sich ziehen kann. Umgekehrt wissen die IT-Spezialisten nicht immer sofort, warum bestimmte Änderungen unumgänglich sind.
Der Monolith steht zwischen der fachlichen und der technischen Welt. Darum gehen immer mehr Versicherer dazu über, die in großen System-Suiten eingebaute Logik aufzuteilen und in einzelne Dienste zu verlagern, die jeweils für eine spezielle Aufgabe konstruiert werden. Beispielsweise legt ein Dienst neue Anfragen an, ein weiterer berechnet die Prämien, der nächste nimmt Schäden an und wieder ein anderer löst Zahlungen aus. Ein Workflow-System kümmert sich darum, dass diese Microservices miteinander harmonieren. So lassen sich nahezu alle Vorgänge im Unternehmen automatisieren. Selbst komplizierte Abläufe können abgebildet werden, weil Workflow-Systeme Regeln einhalten können, die etwa gesetzlich vorgegeben oder fachlich erforderlich sind.
Technisch bietet eine solche IT-Architektur allerlei Vorteile. Doch auch organisatorisch machen Microservices und ein Workflow-System vieles einfacher. Der Grund: Workflow-System stellen Prozesse grafisch dar und nutzen dafür die leicht zu verstehende Sprache BPMN. BPMN steht für Business Process Model and Notation. Der aktuelle Standard BPMN 2.0 ist weit verbreitet und erlaubt den Fachbereichen, die gewünschten Abläufe wie an einem Reißbrett zu modellieren. Eine Schadenmeldung (Ereignis) soll beispielsweise dazu führen, dass der Schaden (Auslöser) geprüft wird (Aufgabe), und wenn alles in Ordnung ist (Entscheidung), soll die Zahlung als freigegeben markiert (Ereignis) und ausgeführt (Aufgabe) werden (vgl. Abb. 2).
Abb. 2: Vereinfachtes BPMN-Schema für eine Schadenmeldung in der Versicherung.
Gemeinsame Sprache BPMN
Werden Ereignisse, Aufgaben und Entscheidungen in BPMN notiert, lässt sich auf den ersten Blick erkennen, was genau in einem Vorgang geschehen soll – ohne technische Vorkenntnisse. Workflow-Systeme führen die so modellierten Prozesse zudem tatsächlich aus. Fachabteilungen sind so in der Lage, auch komplexe Vorgänge abzubilden, ohne die IT-Kollegen über alle fachlichen Details aufklären zu müssen. Es reicht, über die einzelnen Aufgaben zu sprechen, die dann von der IT als individueller Microservice programmiert werden. Diese Modelle erleichtern auch, Fehler zu finden und schneller zu beheben. Weil die Fachbereiche im Workflow-System sehen können, wo es hakt, können sie der IT genauere Angaben machen. Das Workflow-System Camunda BPM stellt dafür beispielsweise sogenannte Heatmaps bereit (vgl. Abb. 3).
Abb. 3: Heatmap-Diagramme zeigen, wie stark einzelne Ablaufschritte beansprucht werden.
Auf der Heatmap ist selbst im produktiven Betrieb sofort zu erkennen, wie häufig bestimmte Aufgaben und Ereignisse aufgerufen werden. Das gilt auch für unterschiedliche Abzweigungen, denen das Workflow-System folgen soll. Entsteht beispielsweise kein neuer Traffic über das frisch angebundene Vergleichsportal, liegt auf der Hand, dass die Schnittstelle überprüft werden muss oder etwas beim Geschäftspartner und seiner IT nicht stimmt. Zudem lassen sich Lastspitzen leichter erkennen und Ressourcen besser steuern – und das ganz ohne Code lesen zu müssen oder Logfiles auf dem Server manuell auszuwerten. BPMN stellt die grafischen Werkzeuge bereit, um sich auch fachbereichsübergreifend effizient auszutauschen.
Weil die gesamte IT-Architektur zudem auf Microservices basiert und nicht mehr auf einem komplizierten Großsystem, lassen sich auch kleinere Eingriffe leichter vornehmen. Weil jeder Dienst bestimmte Aufgaben kapselt, brauchen sich nur die damit beschäftigten Experten finden, wenn sie etwas am System verändern möchten. Das fördert agile Teams und erlaubt zudem, auch während des laufenden Betriebs an einzelnen Microservices zu arbeiten, ohne ein umfangreiches Release zu planen und die IT über mehrere Stunden lahmzulegen. Sich für Microservices zu entscheiden und ein Workflow-System einführen, ist deshalb nicht allein eine IT-Entscheidung, sondern auch eine organisatorische, die sich auf die Kultur eines Unternehmens auswirkt und darauf, wie verschiedene Abteilungen künftig zusammenarbeiten.
26./27. November in Leipzig – Seien Sie dabei!
