Alle für eines!

Präsident und Ausschuss-Vorsitzende zur geplanten neuen BiPRO-Normengeneration „RNext“

RNext ist neu. Und wie vieles Neue, sorgt es zunächst auch für Unsicherheit. Dabei steht RNext für die Zukunft der digitalen Arbeitsweise der Branche. Mit der geplanten nächsten BiPRO-Normengeneration werden schlanke und serviceorientierte Arbeitsprozesse, neue Geschäftsmodelle sowie eine deutlich agilere Software- und Schnittstellenentwicklung möglich. Im Interview mit Tim Schmidt erläutern Jörg Treiner, Vorsitzender des Normungsauschusses, Frank Dünnleder, Vorsitzender des Marktausschusses und Frank Schrills, Geschäftsführender Präsident des BiPRO e.V., warum sie RNext als ein wesentliches Zukunftsprojekt des Vereins sehen.

Der BiPRO-Tag und die Ankündigung von RNext haben für eine Aufbruchstimmung, aber auch Irritationen gesorgt. Warum soll RNext eingeführt werden und was kann man sich darunter vorstellen?

Frank Schrills: Nachdem im Juni der Community erste Ergebnisse eines Proof of Concept (PoC) zum Thema RNext vorgestellt wurden, hat das Präsidium des BiPRO e.V. nun entschieden, RNext als neue Releasegeneration und Zukunftstechnologie zu entwickeln. Der Beschluss sieht vor, dieses neue Release parallel zu den bisherigen Normreleases mit R1 und R2 (nachfolgend RClassic genannt) mit so vielen interessierten Mitgliedern wie möglich in Einzelschritten zu erproben und schrittweise zu etablieren. Denn es gilt, getreu unserem Motto „Nachhaltigkeit und Innovation“, sich als Normungsinstitut einerseits weiterzuentwickeln sowie wichtige Trends und Möglichkeiten bezüglich Technologie und Fachlichkeit nicht zu verschlafen. Andererseits, und dies möchte ich an dieser Stelle ausdrücklich betonen, werden die aktuellen RClassic-Normen selbstverständlich weiter gepflegt und damit Investitionssicherheit geleistet.

Jörg Treiner: Die dahinterstehenden Prinzipien sind vor allen Dingen das Domain driven Design und eine agile Vorgehensweise. Dies sind zwei wesentliche Ansätze, um RNext zu entwickeln. Das neue Release unterscheidet sich dabei von dem heutigen Release RClassic insofern, als dass am Ende eine fertige, direkt nutzbare cloud-fähige Softwarekomponente steht.

Welche Vorteile bringt diese neue Releasegeneration?

Treiner: Zunächst setzt RNext auf eine REST basierte API-Architektur und ist damit cloudfähig und sehr interoperabel. Zudem werden durch die Designprinzipien die Integrationsaufwände verringert. Das hängt zum einen am Domain driven Design und zum anderen am Integrationsansatz generell. Durch die Domänenschnitte, also die Bausteine, verkürzen wir die Time to Market und reduzieren die Kosten, Schnittstellen zu entwickeln oder später zu verändern.

Darüber hinaus nutzt es den BiPRO-Mitgliedern, dass diese Softwareartefakte von der BiPRO quellcode-offen distribuiert werden. So können diese direkt heruntergeladen und in den einzelnen Unternehmen implementiert werden. Das führt zu einer deutlichen Reduktion der Design- und Entwicklungskosten, da die RNext-Bausteine durch die Mitgliedschaft innerhalb der BiPRO zusammen entwickelt und finanziert werden. Dadurch entfällt ganz zwangsläufig ein großer Teil des Aufwands innerhalb der einzelnen Häuser.

Frank Dünnleder: Ein weiterer Effekt ist, dass mögliche Interpretationsfehler vermieden werden können. Da alle Fachinformationen direkt in den Softwareartefakten hinterlegt sind und es sich um ausführbare Software handelt, entfällt künftig die Auslegungsarbeit. Diese musste bisher bei RClassic von jedem Unternehmen geleistet werden. Dies führte dazu, dass trotz einer Norm, eine hundertprozentige Gleichheit bei unterschiedlichen Unternehmen nicht zwingend gegeben war oder ist. Bei einem in sich „geschlossenen“ qualitätserprobten Softwareartefakt ist dies von vornherein ausgeschlossen.

Darüber hinaus wird die Anzahl der Gesamtreleases deutlich verringert. Denn eine Änderung macht es künftig nicht mehr notwendig, das Gesamtpaket neu zu veröffentlichen. Durch die Domänenschnitte können die Änderungen direkt in den Baustein eingearbeitet werden und nur dieses Teilstück wird neu zur Verfügung gestellt werden.

Können Sie kurz die wichtigsten Erkenntnisse des Proof of Concept (PoC) zu RNext skizzieren?

Treiner: Der RNext PoC diente dazu, die generelle Durchführbarkeit des Vorhabens zu belegen. Hier wurde ein kleiner Teilbereich, nämlich Schadenmeldung, angeschaut, um die Realisation der wichtigsten Designprinzipien und Werkzeuge abzuklären. Dies betrifft vor allem das Domain driven Design, aber auch die gesamte API Productionspipeline. Das Ergebnis ist dabei eindeutig: RNext lässt sich realisieren! Einige Fragen, die noch offen sind, beispielsweise der vielfach diskutierte Domänenschnitt, sind noch unklar. Man kann solche fachlichen Domänenschritte nicht am „Reißbrett“ im Vorfeld erarbeiten. Dies bedingt eine gemeinschaftliche explorative Vorgehensweise – daher die geplanten Labs.

Wie soll RNext nun innerhalb der BiPRO entwickelt werden?

Schrills: Wir werden neue Teams aufstellen, um der notwendigen Arbeitsweise von RNext Sorge zu tragen. So werden zukünftige Labs und sicherlich auch spätere Projekte von einem Development und IT-Operations Manager sowie einem Fachlichen Leiter geführt. Sie sorgen dafür, dass sowohl die technische als auch die fachliche Sicht innerhalb der Entwicklung bedacht wird und vermitteln zugleich zwischen beiden.

Darüber hinaus werden wahrscheinlich deutlich weniger Mitglieder in einem Lab teilnehmen können. Nur mit einer Gruppengröße von ca. zehn Unternehmen wird es uns gelingen, die Agilität zu erhalten, die für ein solches Vorhaben notwendig ist. Da jedoch – im Gegensatz zu heute – nicht nur eine Domäne entwickelt und gepflegt wird, ist der Einsatz möglichst vieler Vereinsmitglieder weiterhin unabdingbar.

Wie wollen Sie so noch die Neutralität und vor allem das Gleichgewicht der Stimmen innerhalb der Branche wahren, für das die BiPRO steht? Je kleiner die Gruppe, desto leichter könnte ein Ungleichgewicht zwischen den einzelnen Interessengruppen innerhalb der Versicherungswirtschaft entstehen.

Schrills: Das ist ein Faktor, den wir bedacht haben. Denkbar wäre hier, beispielsweise mehrere „Sub-Labs“ zu einem Thema parallel laufen zu lassen und dann nach Vorliegen der Ergebnisse in eine weitere Evaluationsphase einzusteigen.

Insbesondere die Geschäftsstelle muss Sorge dafür tragen, dass sowohl die Labs als auch die entstehenden Normen koordiniert und im Sinne des Standardisierungsgedankens geführt werden. Gleichzeitig muss gewährleistet werden, dass der Normungsprozess, der bisher so langwierig war, dem Agilitätskonzept nicht zuwiderläuft.

Jetzt sprechen Sie die ganze Zeit von Labs, wo ist der Unterschied zu den bisherigen Normprojekten?

Treiner: Die Labs bilden eine agile Arbeitsumgebung außerhalb der engen Bahnen des durch die Vereinssatzung strukturierten Projektzyklus. Innerhalb dieser Labs werden die Teams die Möglichkeit haben, schnell zu praxistauglichen Ergebnissen zu kommen.
Die fachliche Betrachtung von Prozessen sowie die Eruierung dafür notwendiger Datenstrukturen werden bei neuen Themen grundsätzlich weiterhin zunächst von Projekten gewährleistet, entsprechende Diskussionen inklusive. Hierfür muss es im Rahmen einer Normierung selbstverständlich weiterhin Raum geben. Wie sich der Zeitrahmen für künftige Projekte darstellt und der Übergang zu Labs und Digitalisierungsoffensiven genau gestaltet, wird sich dann nach den gemachten Erfahrungen ergeben.

Wann sind erste Ergebnisse zu erwarten?

Dünnleder: Es ist geplant, die ersten Labs zu RNext bis Ende Mai 2019 abzuschließen. Unser Ziel ist es, so schnell wie möglich Erkenntnisse zu gewinnen, um Richtlinien für die offenen Fragen, beispielsweise zum Domänenschnitt, festlegen zu können.

Treiner: Der aktuelle Plan sieht vor, in einer ähnlichen Arbeitsweise wie bei Scrum zu verfahren. Das heißt es wird innerhalb eines vordefinierten Zeitrahmens, z.B. von drei Monaten, zweiwöchige, sogenannte Sprints geben. Hierbei müssen die Teilnehmer nicht zwingend anwesend sein, sondern können diese Arbeiten auch online erledigen, so wie das heute in vielen Open Source Softwareprojekten sogar weltweit funktioniert. Nach wenigen Sprints steht ein einsetzbares Ergebnis. Ich möchte hier darauf hinweisen, dass das Ergebnis, auch wenn es in einem „Lab“ entwickelt wurde, natürlich in der Praxis einsetzbar ist, es ist also ein MVP (minimum viable product), ein Produkt, das marktfähig ist und den wesentlichen Nutzen hebt. Dieses MVP lässt sich daher sofort an die Mitglieder distribuieren. Selbst wenn zu einem späteren Zeitpunkt Änderungen, z.B. durch weitere Mitglieder anfallen sollten, ließe sich das Softwareartefakt erneut zeitnah bearbeiten und durch diese sogenannte Build Pipeline schicken, also erneut distribuieren.

Bis Mitte kommenden Jahres ist es noch ein wenig hin, die meisten Projekte für die Digitalisierung in den Unternehmen sind aber bereits budgetiert. Warum sind Sie der Ansicht, dass die noch auf RClassic vorgesehenen Projekte trotzdem nicht gestoppt werden sollten, um auf RNext zu warten?

Treiner: Es besteht aus technischer und betriebswirtschaftlicher Sicht keine Notwendigkeit, geplante Projekte von RClassic zu stoppen. Das hat vielfache Gründe. Der Wichtigste ist aus meiner Sicht, dass der Hauptaufwand beim Implementieren von BiPRO-Normen in der Umsetzung der Fachlichkeit liegt. Sprich, der größte Aufwand – technisch wie fachlich – liegt darin, aus den Backendsystemen alle notwendigen Informationen und Daten so herauszuziehen, dass sie für den Service zur Verfügung stehen. Viele Kollegen berichten, dass hier gut 70 Prozent des Aufwands einer Implementierung liegen. Und dieser Aufwand ist in vielen Teilen unabhängig von der API-Architektur, die oberhalb dieser Services liegt. Der Schritt von RClassic auf RNext ist also möglich, ohne die Businesslogik der zugrundeliegenden Services neu zu entwickeln.
Weiterhin ist meine allgemeine Beobachtung, dass die meisten Unternehmen für die Entwicklung ihrer eigenen Customer Journeys im Web und bei Apps ohnehin REST-basierte APIs entwickeln. Hier entsteht also eine unternehmensinterne Synergie mit sehr positiven Effekten.

Dünnleder: Das bedeutet auch, dass die Kosten einer Umstellung, selbst wenn sie später erfolgt, im Vergleich zu den generellen Projektkosten, gering sind. Insofern ist ein Budget für die Einführung einer BiPRO-Norm in jedem Fall sinnvoll genutzt – unabhängig von RClassic oder RNext. Sollte es aktuell aus innerbetrieblichen Gründen nicht möglich oder nicht gewünscht sein, von Beginn an auf RNext umzustellen, empfehle ich daher unvermindert mit RClassic weiterzumachen. Dies gilt ausdrücklich auch für die Digitalisierungsoffensiven (DiO) Schaden und die DiO Bestand, zu welchen Labs angeboten werden sollen. Hinzu kommt auch, dass eine gesamte Umstellung aller bestehenden Normen im Sinne eines „Big-Bang“ auch gar nicht funktioniert und daher auch nicht vorgesehen ist. Es wird „scheibchenweise“ umgestellt und erprobt, welche Prozesse sich anbieten – und auch, welche Prozesse sich vielleicht nicht anbieten. Insofern stehen wir also auch nicht vor der Frage, wann RNext das bisherige Release ablöst. Vielmehr wird es so sein, dass beide Releases lange Zeit parallel neben einander stehen werden, sodass Services in beiden Technologien zur Verfügung stehen. Meine Prognose ist auch, dass die Consumerseite sich auf beides einstellen wird; dies wurde mir von einigen namhaften Consumern bereits bestätigt. Beide Lösungsansätze werden unterstützt werden, von Consumer- wie von BiPRO-Seite aus.

Projekte gar nicht umzusetzen oder zu stoppen hieße dagegen, die Digitalisierung zu verlangsamen = ohne fachliche, wirtschaftliche oder technische Notwendigkeit.

Welche Botschaften zu RNext sind noch für Sie wichtig?

Dünnleder: Die Planung und Einführung einer neuen Releasegeneration ist im Softwareumfeld fast immer mit „mehr oder weniger Ruckeln“ verbunden. Aber wenn wir als Verein und damit als Interessenvertretung eines Großteils der Branche, nicht rechtzeitig auf zukunftsfähige Technologie setzen, würden wir unserer Aufgabe nicht nachkommen. Aus diesem Grunde möchte ich die Entscheidung des Präsidiums unterstreichen und dazu aufrufen, möglichst viele neue Labs in RNext zu realisieren. Denn zweifelsohne ist eine API-Economy für die Zukunft unabdingbar.

Schrills: Das ist vollkommen richtig. Schließlich ist es kein Geheimnis: die Innovations- und Entwicklungszyklen von Technologien werden immer kürzer. In der API-Economy entstehen neue Business Cases. Nach USPs suchende Unternehmen oder konsortial angelegte Plattformen versuchen Antworten zu finden, erreichen jedoch fast immer nur einen (kleinen) Teil der Branche. Dabei wird der Endkunde immer stärker in die digitale Geschäftsprozesse mit einbezogen. Und überdies drängen immer mehr Unternehmen anderer Branchen in die Assekuranz etc. Vor diesem Hintergrund gilt es, als Gemeinschaft zukunftsorientierte Angebote für unternehmensübergreifende Prozesse zu machen. Ein alleiniges Festhalten an den aktuellen RClassic-Normreihen wird nicht ausreichen, um eine Re-Individualisierung einhergehend mit einer De-Standardisierung unserer Prozesswelt zu verhindern. Letztlich würde sich die Branche so entscheidend schwächen. Vor dem Hintergrund eines Service- und Kostenwettbewerbs ist daher die strategische Entscheidung des Präsidiums so zu verstehen, unseren Unternehmen mit RNext die Möglichkeit zu geben, effektiv und effizient an der API-Economy teilzunehmen. Zusammenfassend könnte man – vielleicht etwas ungeschliffen – auch sagen: Wer nicht mit der Zeit geht, geht mit der Zeit!

Daher ruft der BiPRO e.V. seine Mitglieder jetzt und hier dazu auf, RNext aktiv mitzugestalten. Helfen Sie dabei, die noch anstehenden Fragen schnellstmöglich in den Labs zu klären, sodass die neue Releasegeneration so früh wie möglich zu einer breiten Marktreife gebracht und ausgerollt werden kann. Wie immer in der Normierung gilt: wer sich engagiert, bestimmt mit, kann sich mit vielen Partnern gleichzeitig austauschen und sammelt dabei frühzeitig wichtige Erfahrungen im Umgang mit dem entstehenden Standard. Packen wir’s an!