BiPRO für Versicherer: Standardisierung mittels Open-Collaboration-Modellen

“Nicht digitalisiert” zu sein, bedeutet nicht mehr wettbewerbsfähig zu sein. Wenn beispielsweise ein Versicherer nicht in der Lage ist, sein KFZ-System an die Online-Preisvergleichsportale anzubinden, dann verzichtet er möglicherweise auf einen der wichtigsten Vertriebskanäle. Ein Preis­ver­gleich­spor­tal muss wie­der­um vie­le ver­schie­de­ne Ver­si­che­rungs­sys­te­me mit je ei­ner pro­prie­tä­ren Schnitt­stel­le an­bin­den. Dies be­deu­tet ei­nen mehr­fa­chen Im­ple­men­tie­rungs­auf­wand. Ei­ne stan­dar­di­sier­te und für al­le Ver­si­che­rer gül­ti­ge Schnitt­stel­le kann den Im­ple­men­tie­rungs­auf­wand, so­wohl auf der Sei­te des Ver­si­che­rers, als auch auf der Sei­te des Kon­su­men­ten (Mak­ler­soft­ware, Preis­ver­gleich­spor­ta­le etc.) deut­lich re­du­zie­ren. Am Beispiel BiPRO.

von Ilja Leybermann, Senior IT Consultant Brockhaus

Standardisierte Schnittstellen können die Interoperabilität verschiedener IT-Systeme innerhalb der gesamten Versicherungsbranche nachhaltig verbessern.

Standardisierung ist der Motor der Digitalisierung, nicht nur in der Versicherungswirtschaft.”

In der Versicherungsbranche gibt es bereits eine solche Standardisierung in Form der sogenannten BiPRO-Normen. Sie bilden den branchenspezifischen digitalen Kommunikationsstandard. Dieser Standard wird in einer intensiven Zusammenarbeit verschiedener Branchenvertreter stetig weiterentwickelt.

Formale Spezifikation

Ein Standard ist in der Regel die Schnittmenge aller Anforderungen des Marktes. Der Markt selbst besteht wiederum aus vielen verschiedenen Teilnehmern mit unterschiedlichen Interessen. Daher sollte ein Standard auch durch eine repräsentative Anzahl von Marktteilnehmern mit dem entsprechenden Wissen verabschiedet werden. Die Herausforderung in der Standardisierung liegt aber nicht nur im politischen Konsens, sondern auch in der Implementierung des jeweils verabschiedeten Standards.

Wenn der angestrebte Standard kein mechanisches Bauteil, sondern z.B. ein Kommunikationsprotokoll spezifizieren soll, dann verhält es sich so wie mit der Stadt New York. Sie wird nie fertig! Man muss sich darauf gefasst machen, dass das Standardisieren kein punktuelles Ereignis, sondern ein andauernder Prozess ist, der einem permanenten Anforderungsfluss unterliegt. Mit einfachen Worten gesprochen: Standardisieren bedeutet vor allem, sich an einen Tisch zusammenzusetzen, etwas miteinander zu beschließen, um es anschließend gemeinsam zu nutzen – und das in einer Dauerschleife.

Dieser Vorgang klingt so gängig, dass man meinen könnte, es gebe dafür eine standardisierte Vorgehensweise. Tatsächlich gibt es hier etwas.

Open Collaboration

Es existiert bereits ein organisatorischer Ansatz namens Open Collaboration. Im Vordergrund steht dabei die Ideologie einer offenen Welt, in der Innovationen und Technologien von einer dezentralen und selbstregulierenden Organisation entwickelt werden. Diese Technologien sollen wiederum der Allgemeinheit zur freien und auch kommerziellen Nutzung zur Verfügung stehen. Es ist ein globales Konstrukt des Gebens und Nehmens. Die technischen Errungenschaften von heute werden nicht mehr von zwei Wissenschaftlern in weißen Kitteln und in einem Labor tief unter der Erde sitzend entwickelt. Nein, diese Entwicklung wird von jedem, der über das nötige Know-how und Interesse verfügt, vorangetrieben.

Man mag nun einwerfen, dass der ideologische Ansatz von „Open“ durchaus seine Berechtigung habe, aber für das Wirtschaften eines Unternehmens nicht von Bedeutung sei. Doch dieser Ansatz ermöglicht durchaus den Aufbau eines standardisierten Fundamentes, auf dem anschließend konkrete kommerzielle Geschäftsmodelle entstehen können. Das ist keine bloße Theorie. Nach diesem Prinzip wird bereits seit 1969 das Internet kontinuierlich weiterentwickelt. Aber das Modell beeinflusst auch viele weitere Technologien wie Blockchain oder künstliche Intelligenz, die unsere Welt von morgen nachhaltig verändern werden.

Open Standard

Beim Standardisieren wird eine formale Beschreibung dessen erstellt, was nachträglich mehrfach entwickelt bzw. implementiert werden kann und untereinander kompatibel sein sollte. Ein gängiges und spezifikationsgetriebenes Kollaborationsmodell für diesen Zweck ist Open Standard. Das Ziel ist, möglichst viele Lösungsvorschläge einzureichen, diese zu evaluieren und am Ende zu einem Konsens zu kommen. Der Konsens wird in der Regel in einer formalen Schreibform notiert, sodass kaum Spielraum für eine Eigeninterpretation bleibt. Dies sorgt für eine maximale Kompatibilität der verschiedenen Implementierungen.

Die Vorteile des OpenStandard-Modells liegen in seinem Regelwerk, welches hilft, einen möglichst fairen Konsens zu finden. Ebenfalls vorteilhaft ist die formalisierte Schreibweise der Spezifikation. Von Nachteil sind hingegen die oft langsamen Umsetzungsgeschwindigkeiten, da der jeweilige Konsens häufig über die sogenannten Mailing Lists ermittelt wird. Die Größe der Spezifikation spielt dabei ebenfalls eine wesentliche Rolle. Um ein Beispiel zu nennen: Die Weiterentwicklung von HTML1.0 zu HTML5 dauerte ca. 18 Jahre.

Nach dem Open-Standard-Modell werden nach wie vor die RFC’s (Requests for Comments) entwickelt. Sie sind die Grundlage des heutigen Internets. Dort werden Protokolle, wie z.B. TCP, HTTP, SSL oder IMAP spezifiziert. Anschließend können Softwareentwickler und Ingenieure anhand der Spezifikation die entsprechenden Hard- und Software-Komponenten realisieren, die untereinander kompatibel sind.

Open Source

Ein weiteres bekanntes Kollaborationsmodell ist das Open-Source-Modell. Das Ziel dieses Vorgehensmodells ist nicht die Erstellung einer Spezifikation, sondern einer konkreten Implementierung. Es ist daher ein lösungsorientierter Ansatz. Alternative Implementierungen können durch die sogenannten Forks parallel entwickelt werden. Die Erweiterungen und Korrekturen werden am Fork vorgenommen und können über Pull Requests dem Core Team zur Verfügung gestellt werden. Das Core Team kann anschließend mit Hilfe etablierter Tools und Verfahren die Änderungen sehr schnell in die Hauptversion übernehmen. Des Weiteren kann die Open Source Community über den Sinn und Unsinn der Features und Bug-Fixes diskutieren. Entwickelt wurden sogar Feature Votings, mit deren Hilfe die Findung des Konsenses möglichst demokratisch durchgeführt werden soll.

Im Gegensatz zum Open Standard können mit dem Open-Source-Modell sehr schnell nutzbare Ergebnisse erzielt werden. Oft werden Open-Source-Projekte ebenfalls nach einer Spezifikation realisiert, die wiederum selbst ein Open-Standard-Projekt ist.

Open-Source-Projekte sind ein Nährboden für die Digitalisierung von heute und morgen. Selbst Konzerne wie Microsoft, Oracle oder Google nutzen diese Modelle.”

Das, was gestern Internet war, ist heute z.B. Blockchain-Technologie, entwickelt in vielen Open-Source-Projekten, die eines Tages nicht nur das gesamte Finanzsystem, sondern jegliche Art von Vertragsmanagement (Transaktionssicherheit, Identitäts- und Eigentumsnachweis) revolutionieren könnten.

Ein Branchenstandard

Für einen Branchenstandard ist es wichtig, dass möglichst viele relevante Stakeholder den jeweiligen Standard mitentwickeln.”

Hier entscheidet nicht die Anzahl der Mitwirkenden, sondern die Breite der vorhandenen Expertise und die Schnittmenge des tatsächlichen Bedarfs. Der Konsens muss dem eigentlichen Standard dienen, nicht den einzelnen Interessen der Vertreter.

Die beiden oben genannten Open-Ansätze bieten zahlreiche Möglichkeiten. Im Vordergrund steht der Aufbau einer Community. Eine gelebte Transparenz innerhalb der Community erleichtert enorm das Finden des wahren Konsenses. Man kann die Modelle aber auch auf etwas Konkretes anwenden, wie z.B. auf das „Fork & Pull“ Development Model aus dem Open-Source-Spektrum. Dies enthält die Aufteilung einer großen Spezifikation in kleinere Einheiten, wie es z.B. bei den RFC’s der Fall ist.

Nun stellt sich noch die Frage, was mit „Open“ genau gemeint ist. Open besagt unter anderem, dass jeder partizipieren kann und dass das Projekt möglichst dezentral und selbstorganisierend ablaufen sollte. Dennoch setzen auch Open-Projekte einen Organisator voraus. Bei den Internet RFCs beispielsweise übernimmt dies die IETF (Internet Engineering Task Force) oder die IAB (Internet Architecture Board). Bei den Open-Source-Projekten gibt es immer ein Core Team oder einen Initiator. Und selbst Wikipedia hat ihren Jimmy Wales. Es ist vor allem die operative Umsetzung, die möglichst selbstorganisiert sein sollte, damit die Realisierung skaliert und Entscheidungen demokratisiert werden können. Open-Projekte schließen also eine zentrale Organisationseinheit nicht aus, denn nur ein gut organisiertes Projekt ist in der Lage, möglichst effizient zu agieren.

BiPRO e.V.

Die BiPRO-Normen bilden in der Versicherungswirtschaft den branchenweiten Standard. Sie sind vergleichbar mit den Internet RFCs.”

Das Spezifizieren der Normen wird unter dem Dachverband BiPRO e.V. (Brancheninitiative Prozessoptimierung) organisiert. Die Mitglieder dieses Vereins oder der BiPRO Community sind in der Regel vertreten durch alle Stakeholder der Versicherungsbranche, wie z.B.: Makler, Dienstleister, Produkthersteller und nicht zu letzt durch die Versicherer selbst. Innerhalb der vielen Arbeitsgremien werden verschiedene Normen entwickelt und nach einer ausgiebigen Qualitätssicherungsphase zum Implementieren freigegeben. Anschließend werden die Normen in produktiven Projekten realisiert.

Mittlerweile hat sich dieser Standard in der Branche gut etabliert, sodass man innerhalb der BiPRO Community die Herausforderungen der naheliegenden Zukunft angeht. Eines dieser Projekte ist RNext. Beim Projekt RNext geht es darum, einen Teil der etablierten Praktiken aus dem Spektrum der Open-Collaboration-Modelle zu übernehmen und somit den Standardisierungsprozess für die nächste Generation der BiPRO-Normen zu definieren. Ein wesentlicher Aspekt der nächsten Generation ist, dass man neben der eigentlichen Spezifikation, die in Open API Specification formalisiert wird, gleichzeitig auch die Standardimplementierung in Form von Code und Binär-Artefakten für alle gängigen Plattformen ausliefern möchte. Die Nutzung der Standardimplementierung erspart in großem Umfang Arbeit aufseiten des Implementierers, da er einen Teil der Anwendung von BiPRO e.V. beziehen kann. Des Weiteren soll die Verwendung der Standardimplementierung dafür Sorge tragen, dass der eigentliche BiPRO-Standard möglichst konsequent eingehalten wird.

Die operative Zusammenarbeit innerhalb der Arbeitsgremien findet in GitLab statt. GitLab ist eine Collaboration-Plattform, die es ermöglicht, Software, Spezifikationen oder beliebig andere Arbeitsergebnisse gemeinsam und dezentral zu entwickeln. Hier kann man z.B. mit dem bereits erwähnten Open Source Model „Fork & Pull“ an einer BiPRO-Norm mit mehreren Personen, bzw. Teams, zusammenarbeiten.

Die einzelnen Normen sollen kleiner geschnitten und die Abhängigkeiten zu den anderen Normen möglichst aufgehoben werden. Dadurch werden ein separates Lifecycle pro Norm ermöglicht und der eigentliche Release-Zyklus enorm verkürzt.

Die im Rahmen des Projekts RNext erzielten Arbeitsergebnisse sind vielversprechend und die BiPRO Community ist sehr gespannt, wann die ersten produktiven Normen nach dem neuen Vorgehensmodell und mit der entsprechenden Toolchain spezifiziert werden.

Fazit

Zu standardisieren bedeutet in erster Linie, eine Einigung zu erzielen. Insbesondere bei digitalen Standards gilt, dass sie kein einmaliges Ereignis sind. Ein Standard lebt und unterliegt somit einem permanenten Einigungsprozess, welcher möglichst effizient ablaufen sollte. Die bisherigen Vorgehensmodelle, wie Open Collaboration oder Open Source, geben hierzu eine sehr gute Orientierung. Des Weiteren sollte die Spezifikation eines Standards so präzise wie möglich sein, damit die verschiedenen Implementierungen möglichst kompatibel sind. Eine Default-Implementierung beispielsweise und ihre Akzeptanz ermöglichen dabei eine sehr hohe Kompatibilität. Schließlich ist eine optimale Organisationsstruktur unabdingbar, damit das Projekt dauerhaft erfolgreich sein kann.

Ob ein Standardisierungsprojekt am Ende tatsächlich „Open“ ist, ist nicht entscheidend. Was zählt, ist die Community, deren Expertise und ein Konsens, der der eigentlichen Sache dient!aj

Quellen:

• The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, ISBN: 1536884960, Verlag: O’Reilly Media; Auflage: 1 (1. Februar 2001), Eric S. Raymond (Autor)
• What are open standards? https://opensource.com/resources/what-are-open-standards
• Levine, Sheen S., & Prietula, M. J. (2013). Open Collaboration for Innovation: Principles and Performance. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1096442
• The Internet Engineering Task Force https://www.ietf.org/