Vorfreude auf DMN 1.2?

Das Decision Model and Notation (DMN) hat dem Thema Decision Management zusätzlichen Schwung verliehen. Inzwischen kommt der OMG-Standard bei etlichen Unternehmen zum Einsatz. Der Einstieg ist besonders leicht, wenn man ohnehin schon mit dem Schwesterstandard BPMN 2.0 arbeitet. Auch die viadee setzt DMN bereits bei mehreren Kunden ein.

Die OMG arbeitet an einer neuen  Version ihres Standards, DMN 1.2. Ein genauer Termin steht noch nicht fest, doch konkretisieren sich die geplanten Änderungen. Erwartungsgemäß wird nicht alles auf den Kopf gestellt, denn vieles hat sich bewährt. DMN 1.2 ist vielmehr eine sanfte Anpassung aufgrund der praktischen Erfahrungen mit DMN 1.1.

Wir wollen kurz auf die wichtigsten Änderungen eingehen und aus unserer Erfahrung im Berateralltag bewerten:

• Diagramm-Layout wird mitgespeichert
• Kommentarspalten in Entscheidungstabellen
• Transformationslogik in Entscheidungstabellen
• Feinschliff an der Friendly Enough Expression Language (FEEL)
• Wiederverwendung von Decision Services durch Decisions

Diagramm-Layout wird mitgespeichert

Die grafische Anordnung der Elemente im Decision Requirement Diagramm (DRD) wird mit abgespeichert und bleibt folglich nach einem Datenaustausch erhalten. Das ist ein unerlässliches Feature um echte Unabhängigkeit von Tools zu erreichen. Ein Diagramm, das mit der Fachabteilung besprochen wurde, muss wiedererkennbar sein, auch wenn es mit einem anderen Programm geöffnet wird.

Dasselbe Thema gab es bereits bei BPMN, das zunächst auch ohne Speicherung des Layouts spezifiziert wurde. Die BPMN-Community war dann hocherfreut über die Ergänzung des Features!

Die OMG hat dazu ein eigenes XML Schema, DMN Diagram Interachange, definiert, welches alle nötigen Darstellungsaspekte beinhaltet, vor allem natürlich Größe und Position der einzelnen Elemente. Die Hersteller der Modellierungstools, wie camunda, die eine solche Funktionalität schon implementiert hatten, werden vermutlich peu à peu auf das neue Standardformat schwenken.

Kommentarspalten in Entscheidungstabellen

Decision Tables bekommen Kommentare. Auch hier war camunda  schon einen Schritt voraus. camunda erlaubt über die von der OMG geplanten Änderungen von DMN 1.2 hinaus Kommentare an einzelnen Tabellenzellen, wie wir das von Microsoft Excel kennen.

Zu einer guten Geschäftsregel gehört eine Dokumentation, vor allem dann wenn mehrere Mitarbeiter oder sogar mehrere Abteilungen damit arbeiten. Und je näher die Dokumentation an der Regel steht, umso besser. Die Einführung der Kommentarspalten, nun auch als Element im Standard, zeigt die Bereitschaft, aus der Praxis zu lernen.

Transformationslogik in Entscheidungstabellen

Jede Zeile einer Entscheidungstabellen enthält die Bedingungen, die erfüllt sein müssen, damit die jeweilige Regel feuert. Eine einzelne Bedingung bezieht sich dabei auf die Inputvariable im Spaltenkopf. Bisher war es möglich, konkrete Werte als Bedingung zu formulieren, oder Wertintervalle. Beispiele:

Die Entscheidungstabellen kamen an ihre Grenzen, wenn man die Inputvariable vor dem Vergleich mit den eingetragenen Werten noch einer Transformation unterziehen wollte. Vielleicht wollte man einen Text erst noch in Großbuchstaben konvertieren, Zahlen runden oder das Vorzeichen streichen. Da Entscheidungstabellen so etwas nicht anboten, war man gezwungen, die Transformation im Programmcode zu verstecken, der vor der Ausführung der Entscheidungslogik steht. Für Menschen, die Entscheidungstabellen pflegen, war die Transformationslogik dann nicht sichtbar, obwohl es bei der Formulierung der Regeln ja durchaus relevant ist.  

Jetzt wird es möglich, die Transformationslogik direkt in der Entscheidungstabelle zu formulieren. Das ist in vielen Fällen eine Erleichterung. Die Inputvariable wird dabei durch ein Fragezeichen symbolisiert:

Über die Nutzung dieses neuen Features sollte von Fall zu Fall entschieden werden. Passiert zu viel der eigentlichen Entscheidungslogik außerhalb der Entscheidungstabelle, so ist das Verhalten für die Lesenden nicht mehr transparent. Umgekehrt verringert Programmcode innerhalb der Tabelle die Verständlichkeit für Fachkräfte. Die neuen Möglichkeiten sind auf jeden Fall zu begrüßen!

Feinschliff an Programmiersprache FEEL

Die OMG hält fest an FEEL, wird SFEEL hingegen aufgeben. Zur Erinnerung, FEEL ist die Ausdrucks- und Programmiersprache von DMN. SFEEL ist wiederum eine Teilmenge von FEEL, also ein geringerer Funktionsumfang. Da sich beides bislang nicht in der Praxis durchsetzen konnte, werden die meisten DMN-Nutzenden die Ankündigung mit einem Schulterzucken hinnehmen. Gewissermaßen steckt die OMG hier in einem Dilemma. Zweifelsohne lässt sich Entscheidungslogik nicht vollständig ohne Programmieranteile definieren. Verzichtet die OMG auf eine Standardisierung der Programmierung, so wäre dieser Teil nicht mehr herstellerunabhängig und ein Hindernis beim Austausch und der Ausführung von DMN-Dateien. Es ist jedoch schwer, sich mit einer neuen Programmiersprache gegen etablierte Programmiersprachen wie JavaScript oder Groovy durchzusetzen, wenn diese auch von den Herstellern der Decision Engines unterstützt werden.

Offenbar will die OMG noch nicht aufgeben und schließt mit DMN 1.2 einige Lücken, die in anderen ausgereiften Programmiersprachen schon lange kein Thema mehr sind, wie etwa Schleifen mit Indizes, Escape von Sonderzeichen und Moduloberechnung.

Entwickler und Entwicklerinnen, die heute etwas umsetzen wollen, müssen auf das zurückgreifen, was die eingesetzte Decision Engine kann, und das ist häufig bloß ein schmaler Ausschnitt von FEEL.

Wiederverwendung von Decision Services durch Decisions

Es ist oft sinnvoll, die Durchführung mehrerer Decisions technisch zusammenzufassen. Die Konsumentin, wie zum Beispiel eine BPMN Prozessinstanz, muss dann nicht mehrmals die Decision Engine rufen und dabei vielleicht sogar jedes Mal dieselben Inputvariablen übergeben. In der DMN-Nomenklatur ruft die Konsumentin einen Decision Service.

DMN 1.1 bot bisher die Möglichkeit, Decision Services im DRD als abgerundetes Rechteck um die betroffenen Decisions darzustellen. Oberhalb der Trennlinie stehen die Decisions, die dem Konsumenten als Ergebnis zurückgeliefert werden. Unterhalb der Trennlinie fanden sich weitere, indirekt benötigte Decisions.

Das abgerundete Rechteck des Decision Services war quasi eine eigene grafische Ebene im DRD ohne Verbindungslinien zu anderen Elementen. Es gab keine Möglichkeit für andere Decisions einen Decision Service aufzurufen. Das ändert sich jetzt.

Decision Services können in DMN 1.2 von Decisions sowie von Business Knowledge Models aufgerufen werden. Wiederverwendung eines Decision Services durch eine Decision:

In DMN 1.1 war die Abbildung derselben Zusammenhänge auch schon möglich, bloß musste man mehrere Verbindungslinien zeichnen, nämlich von jeder verwendeten Decision aus.

Was nützt die Änderung?

• Der Komfortgewinn ist marginal.
• Es ist fraglich, ob man überhaupt die Frage des technischen Schnitts der Schnittstellen einer Decision Engine in die an sich fachlich ausgerichteten DRDs tragen will.
• Die meisten DRD Modellierungstools boten Decision Services bislang nicht an. Daher wurden zusätzliche Verbindungslinien auch nicht vermisst.
• Die Generierung einer Web-Service-Schnittstelle für einen Decision Service wäre theoretisch möglich, vorausgesetzt man verzichtete auf komplexe Datenstrukturen, die sich nicht abbilden lassen. Ohne Generierung dienen Decision Services rein der Dokumentation.

Fazit

Gut zu wissen, dass der Standard lebt und die Praxiserfahrung in die Spezifikation einfließt! Einige der geplanten Änderungen machen das Leben kurzfristig leichter. Bei anderen ist noch nicht abzusehen, ob sie sich auf den DMN-Alltag auswirken:

Geplante Änderung in DMN 1.2	Praxisrelevanz
Diagramm-Layout wird mitgespeichert
Kommentarspalten in Entscheidungstabellen
Transformationslogik in Entscheidungstabellen
Feinschliff an FEEL
Wiederverwendung von Decision Services durch Decisions

Weitere Informationen zum Thema:

Der neue DMN-Standard der OMG im Praxistest

Ausblick von Denis Gagné, Mitarbeiter an DMN 1.2