RNext

– BiPRO spricht in Zukunft Code

Für den Verein ist RNext der richtige Schritt in eine volldigitale Zukunft. Um bereits vor dem Start der RNext-Vorhaben einige Fragen zu beantworten, wurde eine Liste mit Antworten auf wesentliche Fragestellungen erstellt. In einer Umfrage erhalten alle Mitglieder zudem die Möglichkeit, sich in die Planung der ersten Vorhaben einzubringen. So können sie mitentscheiden, welche Prozesse als erstes im neuen Verfahren normiert werden.

zu den Fragen und Antworten

RNext Kontakt

Dr. Kamil Bieder
Leiter IT- und Innovationsmanagement

Tel: +49 211 690750-76
bieder@bipro.net

RNext

– BiPRO spricht in Zukunft Code

Für den Verein ist RNext der richtige Schritt in eine volldigitale Zukunft. Um bereits vor dem Start der RNext-Vorhaben einige Fragen zu beantworten, wurde eine Liste mit Antworten auf wesentliche Fragestellungen erstellt. In einer Umfrage erhalten alle Mitglieder zudem die Möglichkeit, sich in die Planung der ersten Vorhaben einzubringen. So können sie mitentscheiden, welche Prozesse als erstes im neuen Verfahren normiert werden.

zu den Fragen und Antworten

RNext Kontakt

Dr. Kamil Bieder
Leiter IT- und Innovationsmanagement

Tel: +49 211 690750-76
bieder@bipro.net

Interview – alles für eines!

Weitere wichtige Fragen und Antworten finden Sie hier.

RNext-Tagebuch

Hier können Sie regelmäßig Meldungen nachlesen, um so die Entwicklung von RNext und die Entscheidungen der Gruppen zu beobachten.

mehr erfahren
mehr erfahren

Interview – alles für eines!

Weitere wichtige Fragen und Antworten finden Sie hier.

mehr erfahren

RNext-Tagebuch

Hier können Sie regelmäßig Meldungen nachlesen, um so die Entwicklung von RNext und die Entscheidungen der Gruppen zu beobachten.

mehr erfahren

Weitere Informationen im Überblick:

Umfrage zum RNext Stimmungsbild am Markt

Eine Umfrage unter den Mitgliedern soll erfassen, welche Themen möglicherweise in ersten RNext-Labs beleuchtet werden.
Gestalten Sie RNext aktiv mit indem Sie sich an der Umfrage beteiligen.

Weitere Informationen im Überblick:

Klicken Sie auf die Lupe, um sich die Grafiken anzuschauen.

Umfrage zum RNext Stimmungsbild am Markt

Eine Umfrage unter den Mitgliedern soll erfassen, welche Themen möglicherweise in ersten RNext-Labs beleuchtet werden.
Gestalten Sie RNext aktiv mit indem Sie sich an der Umfrage beteiligen.

Fragen und Antworten

Vorbemerkung

Ende vergangenen Jahres hat sich der Verein dazu entschlossen, die Gestaltung der neuen Normgeneration (RNext) operativ agil und ohne Vorgaben (außer den bisher definierten Design Prinzipien) anzugehen. Dies impliziert natürlicherweise, dass fachliche, technische, organisatorische und kommunikative Fragenstellungen innerhalb der Entwicklung zutage treten und erst sukzessive durch Fachgremien entschieden werden können. Es ist daher zum jetzigen Zeitpunkt nicht möglich, alle Fragen hinreichend zu beantworten. Das Interesse an RNext ist vorhanden und die Entwicklungen werden grundsätzlich in der Community positiv gesehen. Jedoch müssen „Lessons learned“ aus den vergangenen Monaten nun konsequent umgesetzt werden, um damit die Effizienz der gemeinschaftlichen Entwicklungen der neuen Normgeneration zu steigern.

In der Build-Pipeline werden u.a. OpenAPI, GitLab, Maven, und Nexus verwendet. Im Prinzip sehen Anwender aber nur das fertige Resultat im Nexus, welches man herunterladen kann. Sollten Anwender selber eine Build-Pipeline aufbauen wollen, dann ist es ratsam, die genannten Tools zu verwenden.

Die Domänen lassen sich am besten durch eine Matrix (siehe beispielhafte Grafik) beschreiben. In der Spalte der Matrix stehen die verschiedenen Sparten und in der Zeile gibt es verschiedene Gruppierungen von GeVos. Dies ist aber ein vereinfachtes Bild. Grundsätzlich sollen alle Domänen passend geschnitten werden. Es wird mit einer Anzahl von ca. 20 bis 100 gerechnet.

Durch die Unabhängigkeit der Domänen untereinander lassen sich die Normen u.a. schneller implementieren. Die Vorteile sind, dass sich Benutzer nicht mit dem gesamten Datenmodell beschäftigen müssen, sondern nur mit den Daten, die in der jeweiligen Domäne liegen.

Da es sich bei der vorgestellten Arbeit um ein Proof of Concept (PoC) handelt und der Use Case nicht die komplette Schadenmeldung abdeckt, kann der Code in dieser Form nicht benutzt werden. Es muss prinzipiell in einem Vorhaben herausgearbeitet werden, wie groß diese Domäne zu schneiden ist. Hier ist mittlerweile ein RNext-Gruppe Schadenmeldung entstanden. Deren Ergebnisse werden auf dem BiPRO-Tag 2019 vorgestellt.

Eine Umfrage im Präsidium und unter Teilnehmern der Arbeitsgruppe hat ergeben, dass sich viele Unternehmen hier eine „schlanke“ Implementierung wünschen. Es gibt jetzt aber die Möglichkeit, sich an der Umfrage der aktuellen Vorschläge für RNext zu beteiligen und somit die nächsten Schritte mit zu gestalten.

Moderne Webservices nutzen JSON-REST als Basis. Deshalb ist dieser Architekturstil aus unserer Sicht am sinnvollsten. Die JSON-REST-Community ist heute deutlich aktiver als die der SOAP-Welt. Somit gibt es mehr Tools, die sich um JSON-REST gruppieren, als um SOAP. Andere Technologien werden aber nicht grundsätzlich ausgeschlossen. Die eingesetzten Technologien werden im Rahmen des jeweiligen RNext-Vorhabens vereinbart.

Dies entscheiden die Mitglieder und die Teilnehmer, die RNext in einem konkreten Vorhaben erproben wollen. Aktuell sind folgende RNext Vorhaben gestartet oder vorgeplant:

  • Schaden
  • bAV
  • Bestandsprozesse
  • Industrie- und Gewerbeversicherungsprozesse
  • TAA (Österreich)

Jedes Mitglied des BiPRO e.V. kann RNext aktiv mitgestalten. Die Themenfelder, die zur Auswahl stehen, werden durch die Mitglieder selbst bestimmt. Ähnlich wie bei einem bisherigen Norm-Projekt wird die Teilnahme individuell kalkuliert und anteilig berechnet.

Davon ist derzeit nicht auszugehen, da es bereits gut funktionierende Services gibt. Außerdem stellt sich die Frage, wie wirtschaftlich sinnvoll ein Ersatz wäre. Ziel ist es daher zunächst, einzelne Bereiche zu benennen, die mit RNext umgesetzt werden und bei denen die Design-Prinzipien gut zu den Geschäftsmodellen der jeweiligen BiPRO-Mitglieder passen. Dies werden aus jetziger Sicht vor allem Bereiche sein, bei denen gar keine Normen vorhanden sind und die Marktdurchdringung derzeit noch nicht vorhanden oder gering ist.

Der Start erster RNext-Vorhaben hat im Winter 2018 begonnen.

Die individuelle technische Unterstützung obliegt weiterhin den Beratungs- und Dienstleistungsunternehmen.

Alle Mitglieder haben die Gelegenheit, sich an Umfragen zu RNext zu beteiligen und generell Themenvorschläge einzubringen. Daneben können sie in der Mitgliederversammlung Anträge und Ideen äußern.

Darüber hinaus hat der Verein einen Koordinationsgruppe sowie vier Arbeitsgruppen (Fachlich/Technisch/Organisatorisch/Markt & Kommunikation) gebildet, die sich auch mit diesen Fragestellungen auseinandersetzen. Hier können alle Mitglieder teilnehmen.

Ein agiles Release-Management ist in RNext unabdingbar. In RNext wird zudem eine semantische Versionierung angewendet werden können, die die Auswirkungen von Änderungen berücksichtigt.

Ja, da dies normale Themen im Release 2 sind und unabhängig von RNext.

Zwischen RNext und Blockchain besteht zunächst einmal kein Zusammenhang. Dies schließt aber nicht aus, dass es in Zukunft einzelne RNext-Vorhaben und möglicherweise Projekte in Verbindung mit der Blockchain-Technologie geben wird.

Es wird einen Master-Zweig in der Entwicklung geben. Dieser könnte theoretisch mit dem Status einer offiziellen Norm vergleichbar sein. [Ist derzeit noch in der Diskussion.]

Ja, für branchenfremde Unternehmen, die Berührungspunkte mit der Versicherungsbranche haben (z.B. SmartHome oder eHealth), wird dies diskutiert.

Das Mapping ins Backend wird wesentlich einfacher, da man sich nur mit den relevanten Attributen beschäftigen muss und alle anderen nicht vorhanden sind. Im Prinzip sind andere Fähigkeiten gefragt, aber weiterhin ist fachliches Know-how zwingend erforderlich, um dies in Gänze zu verstehen.

Viele Regeln entfallen, da dies bereits durch die Domänenschnitte gelöst wird.

Bsp:

  • IF Schaden == Kfz-Schaden THEN…
  • ELSE IF Schaden == Wohngebäude-Schaden THEN…

Einen solchen Fall sollte es in RNext nicht geben. Einige Regeln, die in einer Domäne auftauchen, werden hingegen bereits bei der Modellierung der Schnittstelle berücksichtigt.

Bei RNext gibt es eine laufende Erweiterung von Ergebnissen. Diese werden durch die Personengruppe, zu der die Domäne gehört, kontinuierlich weiterentwickelt. Dies geschieht durch Arbeiten in einem schnell agierenden Team mit der Adaption von bewährten Methoden sowie Konventionen (Best Practice).

Derzeit gibt es zwei RNext-DiO-Gruppen in der BiPRO. Dies sind „Schadenmeldung“ und „Bestandspflege“. Man kann hier jederzeit mitwirken und die ersten Erfahrungen sammeln. Nach dem BiPRO-Tag wird es zu den beiden Gruppen einen Aufruf an die Mitglieder geben, sich an Folgethemen der RNext-Gruppen zu beteiligen.

Einige Versicherungen und Consumer sind schon aktiv. Aber es könnten unter Nachhaltigkeitsaspekten mehr sein. Der Know-How-Transfer könnte auch effizienter gestaltet werden. Momentan sind die gleichen Personen aktiv. Wir lernen aus den jetzigen Erfahrungen und werden das Format weiterentwickeln (z.B. Boot-Camp, Präsenztreffen)

Die Schnittstellenspezifikation in Form eines Swagger-Files ist das Mindeste, was ausgeliefert wird. Dies kann bei Bedarf durch Bibliotheken in gängigen Programmiersprachen erweitert werden. Die Build-Pipeline als drittes Artefakt ggf. auch, wenn es für die Integration der Artefakte in die Systemlandschaft der Häuser förderlich ist. Dies wird wahrscheinlich so sein, wird aber derzeit noch verifiziert.

Die API-Sprache ist Englisch, d.h. sämtliche Attribute haben englische Namen. Eine Dokumentation wird auf Englisch und Deutsch erstellt.

Im Wesentlichen ist dies:

  • RClassic: Wsdl-Dateien, EA-Modelle, XML-Schemata und umfangreiche Dokumentationen in Word
  • RNext: Schnittstellenspezifikation als Swagger-Yaml-Datei, Bibliotheken inkl. Dokumentationen zu Build-Prozessen sowie ggfls. der Build-Pipeline selber.

Ab dem BiPRO-Tag 2019 stehen zwei MVP (Minimum Viable Product)zur Verfügung. Schadenmeldung und Bestand. Die schnellstmögliche Bereitstellung aller Artefakte (siehe Frage 4) über die beiden RNext-DiO-Gruppen hinaus ist angestrebt.

Release 2 ist nach wie vor Branchenstandard und dieser wird weiterhin fachlich betreut. Die Geschäftsstelle stellt jedoch ausschließlich die fachliche Unterstützung sicher. Es erfolgt keine Projekt- oder Implementierungsberatung. Zum Release 2:

  • Eine über eine Mittelfristigkeit (5 bis 10 Jahre) hinausgehende bestehende Dualität zweier Standards ist aus betriebswirtschaftlicher Sicht und unter Betrachtung des rasanten technologischen Wandels nicht sinnvoll.
  • Ein End-of-Service scheint daher mittelfristig realistisch und möglich. Dies hängt auch von der Verbreitung bestehender RNext-Lösungen ab.

Grundsätzlich ja, da RNext nicht alle Aspekte des Release 2 derzeit abdecken kann und ggf. auch nicht wird. Es sollte aber auch davon abhängen, ob RNext-Entwicklungen in konkreten Planungen sind.

In RNext unterliegt jeder Service seinem eigenen Release-Management. Bei der Versionskennzeichnung wird Semantic Versioning verwendet. Ein wesentlicher Vorteil ist grundsätzlich, dass unterschiedliche Releases nicht mehr voneinander abhängig sind – im Gegensatz zur heutigen RClassic-Normgeneration. (Stichwort: Monolithisches Datenmodell)

Grundsätzlich arbeiten die jeweiligen Domänen autark. Es ist jedoch unabdingbar, dass eine domänenübergreifende Orchestrierung der Fachprozesse gewährleistet wird. In Welcher Form bzw. in welcher Ausprägung dies geschieht, wird derzeit diskutiert.

Neue, veränderte, durch BiPRO ausgelieferte Artefakte sind schneller in die eigenen Systeme integrierbar. Dies ist eine normale Vorgehensweise bei einer agilen Schnittstellenentwicklung. Natürlich muss ggf. die Anbindung in bestehende Systeme zusätzlich sichergestellt werden.

Die Möglichkeit der Erweiterung wird es auch bei RNext geben. In welcher Form ist noch nicht zu 100 % geklärt. Die Integration möglicher Individualitäten (z.B. über ein Plug-in) kann am „Anfang“ innerhalb der Build-Pipeline, irgendwo „dazwischen“ oder am „Ende“ stattfinden. Die derzeitige Tendenz geht eher in Richtung „Ende“. Je weiter „hinten“ desto höher die Sicherstellung des Standards.

Wenn ein Unternehmen sich an einer RNext-Entwicklung beteiligen möchte, ist zu beachten, dass das Hauptziel eine Referenzimplementierung darstellt. Dies bedeutet, dass nicht nur ein klares Commitment an die geplanten angebundenen Partner erfolgen muss, sondern auch für einen festdefinierten Zeitraum Ressourcen für die RNext-Entwicklung, die Umsetzung der Artefakte im Unternehmen sowie die Anbindung des Partners verbindlich bereitstehen.

Wie die Normierung in Zukunft sichergestellt wird, befindet sich aktuell in den unterschiedlichen Gremien in Diskussion.

  • Fachlich/Technisch/Organisatorisch àHerr Jäger und Herr Dr. Bieder
  • Strategisch/Kommunikation àHerr Schrills und Herr Kern

Vorweg: Eine schnellstmögliche Veröffentlichung/Distribution im Sinne einer agilen Entwicklung und Verbreitung der Normen wird seitens des Vereins natürlich weiterhin angestrebt.
Mit welchen (Open Source-) Lizenzen zukünftig die RNext-Artefakte distribuiert werden, unterliegt vielen Fragestellungen (Kartellrecht, Ressourcenaufwand, Finanzierung, faire Lastenverteilung, etc.), die derzeit im Präsidium geprüft und diskutiert werden.