RNextDesignPrinciples

BiPRO-RNext Design Principles

Dr. Manuel Reimer
Jörg Treiner
April 2017

Inhalt

1. Use before Re-use (Praxisbezug)
2. Ein digitaler Standard ist Software
3. Modularisierung ‒ Domain Driven Design
4. Lokalisierung durch Erweiterung
5. Trennung von Technik und Fachlichkeit
6. Standardisierung von Services, nicht nur von Schnittstellen
7. Agiles Normierungs-Setup
8. 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)