Decision Model and Notation

Der Brückenschlag: Warum DMN den Business-Rules-Engines-Markt aufmischt

Bernd Rücker

©iStockphoto.com/SireAnko

Decision Model and Notation (DMN) ist der neue Standard zu Entscheidungen von der Object Management Group (OMG), die auch BPMN oder UML standardisiert hat. Die wichtigste Zielsetzung dabei ist, eine Notation zu definieren, die Fachseite und IT gleichermaßen verstehen, um damit eine Brücke zwischen beiden Welten zu bauen.

In diesem Artikel betrachten wir anhand des Praxisbeispiels „Skill-based Routing“, also der automatisierten Entscheidung, welcher Sachbearbeiter eine bestimmte Aufgabe durchführen soll, warum DMN die Brücke zwischen IT und Fachabteilung sein kann. DMN unterscheidet dafür zwischen Entscheidungsanforderungen (Decision Requirements) und Entscheidungslogik (Decision Logic). Die theoretische Seite beleuchtete bereits Marcus Winteroll in seinem Artikel „Entscheidungen mit der DMN analysieren und modellieren“ im Business Technology 2.2015 [1]. Wieder zurück zum Praxisbeispiel: Nehmen wir an, Sie melden einen Autounfall an Ihre Versicherung. Daraufhin muss der Versicherer wichtige Entscheidungen treffen, z. B. ob der Schaden automatisch reguliert werden kann, um Aufwand zu sparen, oder falls nicht, welcher Sachbearbeiter den Schaden bearbeiten soll. Die zweite Entscheidung wird als Skill-based Routing bezeichnet, da man aus einer Menge von Mitarbeitern anhand deren Fähigkeiten (Skills) den am besten geeigneten Mitarbeiter heraussuchen möchte. Sollte nicht so schwer sein, oder?

ruecker_bernd-101x130Treffen Sie Bernd Rücker auf der JAX 2016:

Open-Source-Workflows mit BPMN, Business Rules mit DMN und Case Management mit CMMN in Action – mit Camunda BPM

Erwarten Sie plumpes Marketing für unsere BPM-Plattform. Ähm, wie bitte? Nein, natürlich das genaue Gegenteil! Im Vortrag möchte ich live demonstrieren (und codieren), wie bestimmte Sachverhalte in den Standards BPMN 2.0 (Workflows für „starre“ Abläufe“), CMMN (Case Management für mehr Flexibilität) oder auch DMN (Business Rules mit z.B. Entscheidungstabellen) grafisch modelliert und dann direkt auf einer Java Engine ausgeführt werden. Dazu verwende ich die quelloffene Camunda-BPM-Plattform, sodass alles direkt zu Hause nachgebaut werden kann. In der Session diskutiere ich mögliche Architekturen von klassischer SOA bis zu auf Spring Boot basierenden Microservices. Natürlich dürfen Best Practices sowie ein bisschen Meinung nicht fehlen, z.B. dass „Zero-Code-Lügen“ in die Märchenbücher gehören – und nicht in Marketingmaterialien der Hersteller.

Dienstag, April 19, 2016 – 14:45 bis 15:45

Decision Requirements: Anforderungen an Entscheidungen definieren

In einem Praxisprojekt haben wir in einem Workshop die Anforderungen an diese Entscheidung herausgekitzelt und modelliert. Hierbei ist das so genannte Decision Requirements Diagram (DRD) eine große Hilfe: Es zerlegt die eigentliche Entscheidung, hier „passender Mitarbeiter“, in mehrere Teilentscheidungen (Abb. 1). Im Beispiel wird zuerst die notwendige Kompetenz ermittelt (Rechteck = Entscheidung). Dazu wird als Input (= abgerundetes Rechteck) der Schadensfall benötigt. Des Weiteren soll die Erfahrung des Mitarbeiters einbezogen werden, die allerdings in keinem System gepflegt wird. Im Workshop haben wir herausgefunden, dass es eine Freigabekompetenz gibt, also welche Schadenshöhe ein Mitarbeiter noch freigeben darf. Aus dieser Kompetenz soll die Erfahrung abgeleitet werden. Mit diesen Informationen werden alle verfügbaren Mitarbeiter gescort, also Punkte vergeben, wie geeignet ein Mitarbeiter für den aktuellen Fall ist. Den konkreten Mitarbeiter zu bestimmen, ist dann einfach: Es ist der Mitarbeiter mit dem höchsten Score.

Abb. 1: Das Decision Requirements Diagram (DRD) zeigt das Big Picture der Entscheidung

Abb. 1: Das Decision Requirements Diagram (DRD) zeigt das Big Picture der Entscheidung

Das DRD war im Workshop sehr hilfreich, um strukturiert über die Gesamtentscheidung diskutieren zu können. Im Projekt haben wir die Inputs noch feingranularer modelliert, sodass wir auf Basis jedes Attributs klären konnten, ob und in welchem IT-System es zur Verfügung steht. In einer großen Runde aus Fachbereich und IT ließ sich so effizient der Projekt-Scope abstecken, da die Wünsche des Fachbereichs und die Machbarkeit in der IT schnell abgeglichen wurden. An noch nicht zur Verfügung stehende Inputs ließ sich sofort ein grobes Preisschild hängen. Dadurch konnte der Fachbereich entscheiden, ob er dieses Geld in die Hand nehmen möchte, oder doch besser die Entscheidungsfindung anpasst.

Decision Logic: Entscheidungen automatisiert umsetzen

Entscheidungen zu verstehen oder aus Compliance-Gründen zu dokumentieren, ist gut; richtig spannend ist aber vor allem das automatisierte Umsetzen von Entscheidungen. DMN definiert für die Entscheidungslogik zwei Werkzeuge: Entscheidungstabellen und eine eigene Expression Language. Abbildung 2 zeigt die Entscheidungstabelle zu „Notwendige Kompetenz“. Die Tabelle ist recht intuitiv: Auf der linken Seite sind Inputs eingetragen, auf der rechten Seite die Outputs. Wenn die Bedingungen auf der linken Seite zutreffen, wird der Output auf der rechten Seite zurückgegeben. Zusätzlich lässt sich eine Bemerkung pro Zeile erfassen, in der die Motivation oder die Begründung der Regel Platz findet. Oft ist dies auch ein Hinweis auf gesetzliche Anforderungen oder interne Richtlinien.

Abb. 2: Die DMN-Entscheidungstabelle führt vom Schadensfall zum passenden kompetenten Mitarbeiter

Abb. 2: Die DMN-Entscheidungstabelle führt vom Schadensfall zum passenden kompetenten Mitarbeiter

Ein spannendes Detail der Entscheidungstabelle ist die so genannte Hit Policy. Sie definiert, was passiert, wenn mehrere Zeilen einer Tabelle zutreffen. Im Beispiel wird die Hit Policy „Collect“ (abgekürzt: C) verwendet. Das bedeutet, es können beliebig viele Zeilen zutreffen, und alle Ergebnisse werden in einer Liste gesammelt. Die Tabelle liefert eine Liste mit allen notwendigen Kompetenzen, um einen gewissen Schaden bearbeiten zu dürfen. Für das Scoring der Mitarbeiter sowie das Ermitteln der Erfahrung lassen sich eigene Entscheidungstabellen erstellen. Bei Interesse ist das gesamte Beispiel inklusive lauffähigem Quellcode online verfügbar.

DMN Hit Policy

Die Hit Policy entscheidet, wie viele Zeilen einer Entscheidungstabelle zutreffen können und wie mit den Ergebnissen umgegangen wird. Der erste Buchstabe des Namens wird in der linken oberen Ecke der Tabelle angezeigt, um die Hit Policy zu kennzeichnen.

Single Hit Policies erlauben nur ein Ergebnis. Es darf also nur eine Zeile zutreffen:

  • U(nique): Es muss genau eine Zeile zutreffen.
  • A(ny): Beliebig viele Zeilen können zutreffen, müssen dann aber das gleiche Ergebnis liefern.
  • F(irst): Die erste Zeile, die zutrifft, bestimmt das Ergebnis.
  • P(riority): Die Zeile mit der höchsten Priorität trifft zu. Die Prioritätsermittlung ist nicht ganz trivial und wird hier nicht weiter erläutert.

Multiple Hit Policies erlauben, dass mehrere Zeilen zutreffen:

  • R(ule Order): Liste der Ergebnisse in der Reihenfolge der Tabellenzeilen.
  • C(ollect): Liste aller Ergebnisse ohne Reihenfolge. Es kann optional eine der folgenden Funktionen hinzugefügt werden: + (Sum), < (Min), > (Max), # (Count).
  • O(utput Order): Liste der Ergebnisse in der Reihenfolge der Priorität.

DMN mit der Decision Engine der Wahl ausführen

Entscheidungstabellen in DMN können als XML-Datei gespeichert und dann von einer DMN-fähigen Decision Engine ausgeführt werden. Vielen von Ihnen wird vermutlich eher der Begriff „Rules Engine“ geläufig sein, der aber mittelfristig abgelöst werden dürfte. Die Vision hinter DMN ist Herstellerunabhängigkeit: Man kann das Modellierungswerkzeug der Wahl mit der Engine der Wahl kombinieren. Da der Standard sehr jung ist, ist die Toolunterstützung zwar noch überschaubar, aber die deutliche Bewegung im Markt ist spürbar. Wer DMN ausprobieren möchte, kann dies mit der Open-Source-Plattform Camunda BPM tun, die einen grafischen Modeler sowie eine Decision Engine, aber auch ein Repository zur Regelwerkversionierung, eine History für Auditdaten sowie eine Webanwendung zum Monitoring bereitstellt.

Damit die Entscheidungstabelle wirklich ausgeführt werden kann, müssen die Inhalte formal definiert werden. Dafür spezifiziert DMN eine eigene Expression Language namens FEEL: (Business) Friendly Enough Expression Language. FEEL ist fachbereichstauglich, die Decision Engine kann sie aber eindeutig interpretieren. Sie lässt sich gut mit Excel-Formeln vergleichen. Dabei sind beispielsweise Operatoren (Beispiel: <, >, =), aber auch Bereiche (Beispiel: [1..5]) und Datumsfunktionen definiert. Es können außerdem von außen Daten in die Regelausführung übergeben werden, gegen die verglichen wird.

In Camunda BPM lassen sich die technischen Details zum Erzeugen der vollständigen FEEL-Ausdrücke direkt in der Tabelle einblenden (Abb. 3). Die Ausführung ist dann entsprechend einfach, so kann dieses Regelwerk mit wenigen Zeilen Code ausgeführt werden (Listing 1).

Abb. 3: DMN-Entscheidungstabelle mit technischen Details zur Ausführung

Abb. 3: DMN-Entscheidungstabelle mit technischen Details zur Ausführung

DmnEngine dmnEngine = new DefaultDmnEngineConfiguration().buildEngine();
DmnDecision decision = dmnEngine.parseDecision(
  "notwendigeKompetenz", 
  DecisionStarter.class.getResourceAsStream("/notwendigeKompetenz.dmn"));
DmnDecisionTableResult result = dmnEngine.evaluateDecisionTable(
  decision,
  Variables.createVariables().putValue("claim", someClaimObject));
// Multiple Hit Policiy, daher potenziell Liste von Ergebnissen:
for (DmnDecisionRuleResult outputRow : result) {
// Es gibt nur eine Output-Spalte (singleEntry):
  System.out.println("Notwendige Kompetenz: " + outputRow.getSingleEntry());
}

Decision Engines können vollständig zustandslos arbeiten und Entscheidungen auf gegebenem Input treffen. Typischerweise bieten entsprechende Werkzeuge aber auch Möglichkeiten, Regelwerke zu versionieren und eine Historie der getroffenen Entscheidungen zu speichern. So können Sie jederzeit nachvollziehen, wann und warum welches Ergebnis herausgekommen ist, oder auch Statistiken über Ergebnishäufigkeiten erstellen. Abbildung 4 zeigt eine beispielhafte Scoring-Tabelle in der „History-Ansicht“, also das Ergebnis eines konkreten Durchlaufs.

Abb. 4: Historische Sicht auf eine konkrete Entscheidung

Abb. 4: Historische Sicht auf eine konkrete Entscheidung

Begriffsklärung: Decison vs. Rule

Wir sprechen von Entscheidungen (Decisions), die auf Basis von Entscheidungslogik (Decision Logic) getroffen werden. Diese Logik ist über eine Reihe von Regeln (Rules) definiert, die oft als Entscheidungstabelle (Decision Table) zusammengeführt sind. Einzelne Zeilen einer Entscheidungstabelle oder FEEL-Ausdrücke sind also Regeln, und die Entscheidungstabelle ist ein Regelwerk.
DMN fokussiert bewusst auf die Entscheidungen als Ergebnis und nicht auf die Regeln als notwendige Leitplanken. Die Praxis untermauert dieses Vorgehen: Entscheidungen werden als etwas Positives und Regeln als etwas Begrenzendes/Negatives wahrgenommen. Daher präferiere auch ich den Begriff „Decision Management“ gegenüber dem heute verbreiteten Begriff „Business Rules Management“.

Der Decision-Management-Regelkreis

Es hat sich bewährt, bei der Aufnahme der Anforderungen – parallel zum DRD – früh erste beispielhafte Entscheidungstabellen zu erstellen. Abbildung 5 zeigt dies für unser Fachbeispiel. Dies macht Entscheidungen wesentlich konkreter und greifbarer. So kann man iterativ das DRD und die Beispieltabellen weiterentwickeln, bis man mit dem Ergebnis zufrieden ist. Auf dieser Basis kann schnell ein lauffähiger Prototyp erstellt werden. Dies erlaubt es spielerisch, das Entscheidungsdesign zu validieren. Eventuell reicht sogar ein einfacher Simulator.

Abb. 5: Entscheidungslogik implementiert Entscheidungen im DRD

Abb. 5: Entscheidungslogik implementiert Entscheidungen im DRD

In Projekten arbeiten wir nach dem in Abbildung 6 dargestellten Regelkreis: Nach einer ersten Analyse sollte in kurzen Iterationen das finale Regelwerk erstellt werden, das dann live gestellt wird. Zur Laufzeit erlauben wir oft direkte Regeländerungen, die sich aber auf kleine inhaltliche Änderungen beschränken. Beispiel: Die Grenzwerte der Schadenshöhe für die notwendige Kompetenz werden kurzfristig geändert, weil aufgrund eines Unwetters viele Hagelschäden eingehen. Damit verteilen sich Schadensmeldungen sofort auf mehr Sachbearbeiter. In diesem Fall werden Strukturen der Regeln nicht geändert, daher kann die Änderung direkt der Fachbereich bewerkstelligen. Trotzdem empfiehlt sich natürlich eine inhaltliche Validierung, also ein Testen des geänderten Regelwerks. Dafür sollten dann idealerweise auch fachbereichstaugliche Testtools zum Einsatz kommen, wie das FitNesse-Framework.

Abb. 6: Im Decision-Management-Regelkreis entsteht nach einer ersten Analyse in kurzen Iterationen das finale Regelwerk, das dann live gestellt wird

Abb. 6: Im Decision-Management-Regelkreis entsteht nach einer ersten Analyse in kurzen Iterationen das finale Regelwerk, das dann live gestellt wird

DMN und BPMN gehören zusammen

Geschäftsprozesse, oder auch Workflows, sind heute als BPMN abgebildet. Der DMN-Standard wurde explizit mit dem Ziel entwickelt, sich in BPMN zu integrieren. Konkret lässt sich der so genannte Business-Rules-Task direkt mit einer DMN-Entscheidung verbinden. Dies erfordert aktuell noch proprietäre Erweiterungen, an einer standardisierten Verknüpfung wird aber bereits gearbeitet. Abbildung 7 zeigt einen stark vereinfachten Schadensabwicklungsprozess, der das beschriebene Regelwerk verwendet. In der Praxis ist es wichtig, den Prozessfluss von der Entscheidungslogik zu trennen, also nicht beispielsweise eine Entscheidung durch einige Entscheidungspunkte (Gateways) zu modellieren. Einerseits wird der Prozess sonst schnell unübersichtlich, andererseits ändern sich Regeln meist häufiger als die eigentliche Prozessstruktur.

Abb. 7: Ein BPMN-Prozess referenziert eine DMN-Entscheidung über den Business-Rules-Task

Abb. 7: Ein BPMN-Prozess referenziert eine DMN-Entscheidung über den Business-Rules-Task

Mit Decision Flows die Entscheidungslogik in eine Reihenfolge bringen

Es bleibt aber ein Haken. Sehen Sie das Problem mit der Verbindung des BPMN und unserer Entscheidung? Die finale Entscheidung ist in unserem Beispiel aus mehreren Entscheidungstabellen zusammengesetzt, wie das DRD in Abbildung 5 gezeigt hat. Leider ist jedoch ein DRD – noch? – nicht ausführbar. Dies liegt vor allem an der unterschiedlichen Sichtweise: Ein DRD möchte die Entscheidung aus einer logischen Sicht beschreiben und dabei von technischen Randbedingungen abstrahieren. Bei der Ausführung kann man gewisse nicht funktionale Anforderungen aber nicht ignorieren. So wird man in einem realen System eher nicht alle 5 000 Mitarbeiter scoren, um dann festzustellen, dass nur fünf die erforderlichen Kompetenzen haben. Auch vermischt das DRD Multiplizitäten: Teilweise wird eine Entscheidungslogik mit genau einem Objekt – dem Schadensfall – durchgeführt, teilweise aber auch mehrfach für jeden Mitarbeiter. Am Schluss soll wieder ein Mitarbeiter ausgewählt werden. Dies lässt sich im DRD aktuell noch nicht ausdrücken. An einer Verbesserung wird aber bereits gearbeitet.

Daher empfehlen wir, zur Ausführung der zusammengesetzten Entscheidungslogik einen „Decision Flow“ zu modellieren. Dies ist ein BPMN-Prozess, der die Entscheidungslogik in eine konkrete Reihenfolge bringt und dabei Datenfluss und Multiplizitäten sauber umsetzt. Dieser BPMN-Prozess kann direkt auf einer BPMN Engine automatisiert werden. Optimal ist natürlich eine BPM Engine, die beide Standards unterstützt. Abbildung 8 zeigt die Gesamtentscheidung als automatisierbaren Decision Flow, der nur Mitarbeiter lädt, die auch wirklich verfügbar sind und die notwendige Kompetenz besitzen. Dieses Laden inklusive Filtern erfolgt dabei nicht über DMN, sondern über einen einfachen Serviceaufruf oder ein entsprechendes SQL Statement. Das DRD ist also die logische Anforderungssicht auf die Entscheidung und der Decision Flow die IT-Umsetzung.

Abb. 8: Der Decision Flow bildet die IT-Umsetzung der Entscheidung ab

Abb. 8: Der Decision Flow bildet die IT-Umsetzung der Entscheidung ab

Use Cases und Nutzen

Use Cases für Decision Management oder Business Rules Management gibt es viele. So ist bereits die reine Analyse von Entscheidungen zum Erkenntnisgewinn oder die Dokumentation aus Compliance-Gründen ein wichtiges Feld. Der aus meiner Sicht spannendere Aspekt ist aber die Automatisierung von Entscheidungen mit einem Industriestandard, der sich weltweit durchsetzen wird. Letzteres ist natürlich eine Hypothese, aber es gibt bereits heute deutliche Zeichen, dass sich DMN ähnlich gut wie BPMN entwickeln wird. Ein kleiner Hinweis noch: Wenn DMN von Entscheidungen spricht, sind eher (automatisierbare) operative Entscheidungen gemeint, also die vielen tagtäglichen Entscheidungen im normalen Geschäft und weniger die großen strategischen Richtungsentscheidungen, die sich typischerweise schlecht strukturieren und erst gar nicht automatisieren lassen.

Für die Automatisierung mit einer Decision Engine sprechen vor allem zwei Argumente: Die fachliche Lesbarkeit und die Extraktion der Entscheidungslogik. Die Fachbereiche können Entscheidungstabellen mindestens lesen, validieren und freigegeben. Oft kann auch die Pflege der Regeln, also der Zeilen einer Entscheidungstabelle und der FEEL-Ausdrücke, durch den Fachbereich selbst erfolgen. Die Erstellung der Struktur der Regeln erfolgt meist gemeinsam mit der IT, welche die Spalten dann auch technisch verdrahten kann. Diese Arbeitsteilung funktioniert in der Praxis sehr gut. Die Entscheidungslogik wird nicht tief im Quellcode oder in Prozessmodellen vergraben, sondern explizit sichtbar. Neben Verbesserungen bei Monitoring und Operations erlaubt dies vor allem die leichte Anpassung von Regelwerken, teilweise sogar ohne den großen Deployment-Zyklus anzuwerfen. Der übrigens überschaubare Aufwand, eine Decision Engine einzuführen, rechtfertigt sich meist recht schnell, da Entscheidungen und die dahinterstehenden Regeln mitunter sehr häufigen Änderungen unterworfen sind, oder andersherum ausgedrückt: Es ist für Unternehmen nicht nur ein strategischer Vorteil, sondern oft eine unumgängliche Notwendigkeit, auf Reize von außen schnell reagieren zu können. Typische Use Cases für automatisierbare Entscheidungen sind:

  • Machbarkeitsprüfung oder Genehmigung: Ob ein Kunde für ein bestimmtes Produkt qualifiziert ist oder auch ob ein Schadensfall vollautomatisiert reguliert wird.
  • Validierung: Ob eine Antrag oder auch eine Schadensmeldung vollständig und inhaltlich gültig ist.
  • Betrugserkennung: Ob eine Kreditkartenzahlung oder Schadensmeldung auffällig ist.
  • Risikobewertung: Ob ein Kreditlimit oder ein bestimmter Bestellbetrag per Rechnung gewährt werden kann.
  • Berechnung: Die Fracht oder Rabattberechnung eines Auftrags.
  • Zuweisung: Wie das Skill-based Routing.
  • Maximierung: Die Geschäftswertbewertung eines Auftrags zur Bestimmung der richtigen Priorität oder eine Kundenklassifizierung.
  • Zielgruppenansprache: Welche Produkte auch interessieren könnten oder welcher Werbebanner angezeigt wird.

Fazit

DMN ist extrem spannend, da die Modelle für die Verständigung zwischen Fachbereich und IT sehr gut geeignet sind. Entscheidungstabellen und die Expression Language FEEL können direkt ausgeführt werden. Die weltweite Verbreitung nimmt rasant Fahrt auf. Es gibt bereits Werkzeuge, die DMN in der aktuellen Version 1.1 unterstützen, inklusive eines Open-Source-Werkzeugs.

Abb. 9: Nach einer Umfrage von Camunda sind die meisten Befragten mit dem Ansatz der Regelausführung nicht wirklich zufrieden

Abb. 9: Nach einer Umfrage von Camunda sind die meisten Befragten mit dem Ansatz der Regelausführung nicht wirklich zufrieden

Wir erwarten dank DMN eine starke Verbesserung der Agilität bei Regelwerken, wie es eigentlich schon mit Rules Engine und Business Rules Management vor Jahren versprochen wurde. Leider wurde dieses Versprechen mit den alten Rules Engines nie eingelöst, wie auch eine Umfrage von Camunda im September 2015 mit 474 Teilnehmern gezeigt hat (Abb. 9). Ich bin überzeugt, dass Dank der Standardisierung der Entscheidungslogik und der Entstehung einer neuen Generation von leichtgewichtigen Decision Engines nun endlich das Versprechen eingelöst werden kann! Am besten probieren Sie es selbst einmal aus.

Verwandte Themen:

Geschrieben von
Bernd Rücker
Bernd Rücker
Bernd Rücker hat vor camunda BPM aktiv an der Entwicklung der Open Source Workflow Engines JBoss jBPM 3 und Activiti mitgearbeitet. Bernd begleitet seit 10 Jahren Kundenprojekte rund um BPM, Process Engines und Java Enterprise. Er ist Autor mehrerer Fachbücher, zahlreicher Zeitschriftenartikel und regelmäßiger Sprecher auf Konferenzen.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.