RNextDesignPrinciples
Das Präsidium des BiPRO e.V. hat auf seiner Klausurtagung im März 2017 die Strategie des Vereins bis 2025 diskutiert. Dabei wurde beschlossen, eine Modernisierung der technischen Grundlagen der BiPRO-Normen (bisher SOAP) zu untersuchen. Herr Dr. Reimer und Herr Treiner wurden beauftragt, Anforderungen an eine neue technische Basis zu definieren und dem Präsidium vorzustellen.
Diese „Design Principles“ wurden im April 2017 erstellt und waren erste Thesen für die neue Release-Generation RNext.
BiPRO-RNext Design Principles
Dr. Manuel Reimer
Jörg Treiner
April 2017
Inhalt
- Use before Re-use (Praxisbezug)
- Ein digitaler Standard ist Software
- Modularisierung ‒ Domain Driven Design
- Lokalisierung durch Erweiterung
- Trennung von Technik und Fachlichkeit
- Standardisierung von Services, nicht nur von Schnittstellen
- Agiles Normierungs-Setup
- Agiles Release-Management
Use before Re-use (Praxisbezug)
Jedes Element eines Normierungsartefaktes (Attribute) muss praktisch eingesetzt und verstanden werden, bevor es Teil der Norm wird (Inkubationsphase); kein Front-Up Engineering (Overhead, Komplexität, Mismatch mit der Realität).
Ein digitaler Standard ist Software
Die Erzeugung von reinen Papiernormen erzeugt keinen Mehrwert für die Digitalisierung unserer Branche.
Regellogik, die heute in den Normen oder im Datenmodell als Prosa beschrieben ist, kann durch Regeln in ausführbaren Code (also Beschreibung durch eine Programmiersprache) überführt werden. Diese Logik ist dann interpretationsfrei und kann direkt in den Consumer- und Provider-Implementierungen genutzt werden.
Die Wahl der konkreten Beschreibungssprache sollte sich am Markt-Mainstream orientieren, ist aber nicht die entscheidende Frage, weil auch heute die Übersetzungsarbeit von Prosa in Programmlogik in jeder Implementierung erfolgen muss, d.h. das Konzept führt auf keinen Fall zu einer Verschlechterung der Situation.
Modularisierung ‒ Domain Driven Design
Normen und ihre Artefakte werden domain-spezifisch beschrieben und ausgerollt. Die Artefakte können eigenständig weiterentwickelt werden. Dieses fachliche Design bietet demnach die Grundlage für die Entwicklung von Microservices.
Normierungsartefakte, die tatsächlich in unterschiedlichen Domänen wiederverwendet werden können, werden in ein Basismodell verschoben. Dies bedeutet de facto die Aufgabe des Prinzips einer vollkommenen Redundanzfreiheit.
Beispiele für Domänen: Komposit vs. LV/PKV, TAA vs. Bestandsänderungen vs. Schadenprozesse.
Lokale Erweiterungen (DE-AT)
Für die Ableitung in den lokalen Märkten werden länderspezifische Normierungsartefakte in eine lokale Erweiterung des Standards verschoben.
Dieses Prinzip kann domänen- und prozessspezifisch angewandt werden (d.h. der Schieberegler für Global und Lokal kann unterschiedlich gesetzt werden): Deutschland und Österreich haben viele grundlegende Gemeinsamkeiten, aber viele Unterschiede im Detail. Zu den Unterschieden gehören andere Datentypen, wie Schlüssellisten, oder andere Regeln, wie die Länge einer VSNR. Unterschiedlich sind aber auch gesetzliche Anforderungen (anderes VVG) und länderspezifische Produkte (z.B. Riester etc.).
Daher sollte das Basisdatenmodell kontextlos sein. Das Basis-DM sollte für DE und AT identisch sein und durch abgeleitete Datenmodelle mit Kontext ergänzt werden.
Trennung von Technik und Fachlichkeit
Die notwendigen technischen Basisstandards orientieren sich an der faktischen Begebenheit in der fachlichen Domäne oder dem Prozess (vgl. IoT-Protokolle versus Nutzung von MQ in Schadennetzwerken). Eine allgemeine Zukunftsprognose der Formate und Protokolle ist herausfordernd (vgl. Trend zu asynchroner Kommunikation in Microservices). Das heißt: Wir sehen potentiell unterschiedliche technische Protokoll-Stacks für unterschiedliche Domänen vor, wobei wir am Ziel festhalten, die Anzahl der Stacks auf das notwendige Mindestmaß zu reduzieren.
Standardisierung von Services, nicht nur von Schnittstellen
Technik beschreibt Interoperabilitätsprinzipien eines kompletten Services, nicht nur Standardisierungsprinzipien der Schnittstelle.
Wesentliches Merkmal digitaler Standards ist die Fähigkeit, mit anderen Ökosystemen interoperabel agieren zu können. Dies bedeutet eine Reduktion auf den absoluten Marktmainstream der digitalen Kommunikation und die breite Unterstützung dieser Prinzipien durch Open Source Software. Ein wesentliches Grundprinzip für die Service-Implementierung ist die Einhaltung von Cloud-native Prinzipien (beispielsweise 12-Factor App). Da davon auszugehen ist, dass die Geschwindigkeit der technischen Innovation mindestens die Geschwindigkeit hält, ist ein agiler Standard die Voraussetzung, um im Markt bestehen zu können.
Agiles Normierungs-Setup
Agile Team-Aufstellung = Product Owner, Designer und Entwickler (DevOp) per Product
Wie passt das zu unserem Gremien-Setup des Vereins (vgl. Entwicklungen in der Allianz oder Nürnberger die Linienhierarchie aufzugeben)? Wir benötigen verstärkt auch nebenläufige Normierungsprozesse, um die Marktgeschwindigkeit zu halten (vgl. Open Source Entwicklungsprojekte auf Basis Github)
“Governance by contribution” -> Mitmachen!
Agiles Release-Management
Domain-spezifische Normen können in sehr kleinen Inkrementen (Sprints) ausgerollt werden. Durch die agile Software-Entwicklung gibt es die Forderung nach einer sehr kurzfristigen Bereitstellung von Sub-Releases mit benötigten Change Requests.
Quelle:
- BiPRO-RNext - Design Principles (Thesenpapier, April 2017, PDF-Dokument)