RNextDesignPrinciples: Unterschied zwischen den Versionen

Aus BiPRO Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „__NOTOC__ = BiPRO-RNext Design Principles = Dr. Manuel Reimer <br>Jörg Treiner <br>April 2017 # Use before Re-use (Praxisbezug) # #dp2|Ein digit…“)
 
Zeile 6: Zeile 6:
<br>Jörg Treiner
<br>Jörg Treiner
<br>April 2017
<br>April 2017
== Inhalt ==


# [[#dp1|Use before Re-use (Praxisbezug)]]
# [[#dp1|Use before Re-use (Praxisbezug)]]
Zeile 21: Zeile 23:
verstanden werden, bevor es Teil der Norm wird (Inkubationsphase); kein Front-Up Engineering
verstanden werden, bevor es Teil der Norm wird (Inkubationsphase); kein Front-Up Engineering
(Overhead, Komplexität, Mismatch mit der Realität).
(Overhead, Komplexität, Mismatch mit der Realität).


== <span id="dp2"></span>Ein digitaler Standard ist Software ==
== <span id="dp2"></span>Ein digitaler Standard ist Software ==
Zeile 36: Zeile 37:
Programmlogik in jeder Implementierung erfolgen muss, d.h. das Konzept führt auf keinen
Programmlogik in jeder Implementierung erfolgen muss, d.h. das Konzept führt auf keinen
Fall zu einer Verschlechterung der Situation.
Fall zu einer Verschlechterung der Situation.


== <span id="dp3"></span>Modularisierung ‒ Domain Driven Design ==
== <span id="dp3"></span>Modularisierung ‒ Domain Driven Design ==
Zeile 49: Zeile 49:
Beispiele für Domänen: Komposit vs. LV/PKV, TAA vs. Bestandsänderungen vs.
Beispiele für Domänen: Komposit vs. LV/PKV, TAA vs. Bestandsänderungen vs.
Schadenprozesse.
Schadenprozesse.


== <span id="dp4"></span>Lokale Erweiterungen (DE-AT) ==
== <span id="dp4"></span>Lokale Erweiterungen (DE-AT) ==
Zeile 64: Zeile 63:
Daher sollte das Basisdatenmodell kontextlos sein. Das Basis-DM sollte für DE und AT
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.
identisch sein und durch abgeleitete Datenmodelle mit Kontext ergänzt werden.


== <span id="dp5"></span>Trennung von Technik und Fachlichkeit ==
== <span id="dp5"></span>Trennung von Technik und Fachlichkeit ==
Zeile 74: Zeile 72:
unterschiedliche Domänen vor, wobei wir am Ziel festhalten, die Anzahl der Stacks auf das
unterschiedliche Domänen vor, wobei wir am Ziel festhalten, die Anzahl der Stacks auf das
notwendige Mindestmaß zu reduzieren.
notwendige Mindestmaß zu reduzieren.


== <span id="dp6"></span>Standardisierung von Services, nicht nur von Schnittstellen ==
== <span id="dp6"></span>Standardisierung von Services, nicht nur von Schnittstellen ==
Zeile 87: Zeile 84:
Geschwindigkeit hält, ist ein agiler Standard die Voraussetzung, um im Markt bestehen zu
Geschwindigkeit hält, ist ein agiler Standard die Voraussetzung, um im Markt bestehen zu
können.
können.


== <span id="dp7"></span>Agiles Normierungs-Setup ==
== <span id="dp7"></span>Agiles Normierungs-Setup ==
Zeile 98: Zeile 94:


“Governance by contribution” -> Mitmachen!
“Governance by contribution” -> Mitmachen!


== <span id="dp8"></span>Agiles Release-Management ==
== <span id="dp8"></span>Agiles Release-Management ==

Version vom 5. November 2018, 12:50 Uhr


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: