04. September 2017 / von Gunnar von der Beck

KPI's

und

Graph

datenbanken

Eine kleine BPM Story

Weshalb Neo4j erste Wahl zur praxisgerechten Analyse von Prozessdaten ist

KPI – schon wieder so ein Buzzword aus der BPM-Welt. KPI steht für Key Performance Indicator. Auf Deutsch dreht es sich völlig banal um Kennzahlen. Auch wenn KPI natürlich deutlich mehr nach teurem Analysten-Know-How klingt. Wie weit her es dann aber mit dem konkreten Verständnis ist, erkennt man in der Praxis an einer Meinungsvielfalt von „Lass uns doch erst mal schauen was das System X schon an KPIs bietet“ bis hin zu „Es ist besser wir speichern einfach mal alles, weil <Begründung Ihrer Wahl>“. Von der Notwendigkeit eines kompletten BI-Projekt-Teams bis hin zur völligen Vernachlässigung des Themas ist alles vertreten. Dabei gibt es praxisnahe Lösungsansätze die eben ohne viel Aufwand bereits einen erheblichen Mehrwert bieten. Mit einem solchen Ansatz beschäftigt sich dieser Artikel.

Fachliche KPIs im BPM Projekt

Dass durch den Einsatz von BPMN 2.0 und einer Prozess-Engine immer ein grundlegender Satz an Kennzahlen vorhanden ist, dürfte bekannt sein. Fachlich motivierte Modellierung vorausgesetzt, erhalten Sie damit bereits einen guten Überblick über Ihr Geschäft. Beispiele für solche von einer Prozess-Engine gelieferten KPIs wären „Wie viele Prozesse und welche Aktivitäten wurden in welcher Zeit beendet und welche nicht“. Klar, dass Sie alleine aufgrund des Prozesspfads beispielsweise erfolgreiche Buchungen von nicht erfolgreichen Buchungen unterscheiden können.

Jeder Entwickler und Architekt weiß nun, dass nicht alle fachlichen Daten vollständig im Prozess vorhanden sind. Nur die entscheidungsrelevanten Attribute werden verwaltet. Darüber hinaus sind fachliche Domain-Objekte (z.B. die Order) nur als Referenzen vorhanden. Altes SOA-Prinzip. Genau damit wird klar, dass die Menge der KPIs, die eine Prozess-Engine automatisch zur Verfügung stellen kann, Lücken im Gesamtbild hinterlässt. Egal, wie gut Sie modelliert haben. Es fehlt schlicht und ergreifend der Bezug zu wichtigen fachlichen Klassifizierungen Ihrer Business Domäne die dem Prozess verborgen sind.

Ist in obigem Prozess etwas über die Art der Order bekannt? Offensichtlich nicht. Nehmen Sie ein Beispiel aus dem Logistik-Umfeld: „Anteil der abgelehnten Buchungen je Zielort“. Nimmt Ihr Prozess einen anderen Pfad, wenn Sie Güter nach Bayern statt nach Hessen senden wollen?

Erst durch die Verknüpfung von Prozessdaten mit Daten aus dem Business-Kontext entsteht eine echte Grundlage zur Analyse und Optimierung.

Nachfolgend soll ein Lösungsansatz zur Extraktion derartiger Daten beim Einsatz der Camunda BPM Prozess-Engine aufgezeigt werden.

Warum Graph-Datenbanken?

Wie wir gesehen haben, benötigt man zur Gewinnung praxisrelevanter Kennzahlen die Verknüpfung/Vernetzung verschiedener Prozess- und Domain-Artefakte. Schauen wir uns also zunächst an, was Graph-Datenbanken als Wettbewerbsvorteil in diesem Umfeld mitbringen.

Die Entwicklung von Graph-Datenbanken rührt von dem Bedürfnis her, reale Sachverhalte in Datenbanken zu speichern, ohne künstliche Konstrukte zu erzeugen (z. B. Primär-Fremdschlüssel, Relationstabellen) oder die Informationen aufzuteilen (z. B. in die Dritte Normalform). Mit Graph-Datenbanken sollen Objekte und deren Beziehungen untereinander in „natürlicher“ Art und Weise zusammengehörig gespeichert werden.

Wenn Sie in relationalen Datenbanken Informationen eines solchen Graphen extrahieren wollen, landen Sie sehr schnell bei aufwendigen Joins über komplexe Tabellenstrukturen. Schlimmer noch: Joins werden erst zum Query-Zeitpunkt ausgewertet und sind Rechen- und Speicher-intensiv – die Kosten steigen exponentiell.

In Graph-Datenbanken hingegen werden Beziehungen als First-Class Citizens geführt und direkt physikalisch optimiert verwaltet:

Diese Form der optimierten Speicherung, bei der die Graph-Datenbank direkten Zugriff auf alle Beziehungen hat, bietet neben den Möglichkeiten einer speziellen Query-Language insbesondere einen gewaltigen Performance-Vorteil. Massendaten willkommen.

Darüber hinaus haben moderne NoSQL Graph-Datenbanken wie Neo4j (neo4j.com) den Charme, dass kein festes Datenbank-Schema definiert werden muss.

Beispiel Objekt-Graph-Model

Um unsere gewünschten KPI-Daten zu speichern, definieren wir uns also zunächst ein Object-Graph-Model welches aus Nodes, Labels und Relationships besteht. Im Logistik-Umfeld könnte ein vereinfachtes Beispiel wie folgt aussehen:

Die linken Nodes enthalten wesentliche Prozessinformationen, die rechten hingegen eine komprimierte Darstellung der für Ihre Domäne essentiellen fachlich relevanten Daten. Eine Order kann im Beispiel auch durch mehrere Prozesse abgearbeitet werden bis die zu transportierten Güter an Ihrem Zielort angelangt sind. Denken Sie an Umbuchungen, Transportplanänderungen etc. Erst durch die Verknüpfung bekommen Sie ein umfassendes Bild.

In Neo4j haben Sie dann die Möglichkeit über einen Database Browser leicht verständliche Graph-Queries auszuführen und sich die Ergebnisse sowohl klassisch in Tabellenform als auch graphisch in einer interaktiven Visualisierung präsentieren zu lassen:

Soweit so schön und gut. Stellt sich nur noch die Frage wie wir unsere Informationen in die Graph-Datenbank bekommen. Damit beschäftigt sich der nächste Abschnitt.

Anbindung der Neo4j Graph-Datenbank an Camunda BPM

Als Ausgangsbasis sind wir in der glücklichen Lage als Prozess-Engine Camunda BPM zur Verfügung zu haben – eine leichtgewichtige Open-Source-Plattform zur Prozessautomatisierung im Java-Umfeld. Weiterhin gehen wir davon aus, dass unsere Prozesslösung nicht nur fachliche Prozesse, sondern neben Schnittstellen zu diversen Fremdsystemen auch eine eigene Persistenz für wesentliche Anteile der Domänen-Objekte erfordert. Unseren Erfahrungen nach kein unübliches Szenario.

Daraus ergibt sich eine Architektur ähnlich dem nebenstehend grob skizzierten Muster. Gezeigt wird ein Ansatz für JEE. Spring Boot und andere Plattformen unterscheiden sich nicht wesentlich.

Der wichtigste Ansatzpunkt zur Integration wird von Camunda selber geliefert. Camunda bietet auf einfache Art und Weise die Möglichkeit eigene HistoryEventHandler zu schreiben und einzubinden.

Der Original DbHistoryEventHandler bleibt natürlich bestehen, es wird lediglich unser Custom Handler hinzugefügt.

Im Beispiel interessieren uns aufgrund kurzlaufender Prozesse nur die End-Events der Prozesse. Die Daten wandeln wir in einen komprimierten ProcessEndEvent um und publizieren diesen via CDI.

Die Verarbeitung der neuen Events erfolgt schließlich asynchron in einem separaten Service. Womit eine Entkopplung von der eigentlichen Prozessverarbeitung gewährleistet ist.

Die Implementierung eines Object-Graph-Model ist in Neo4j dank Annotationen schnell erledigt. Erfasst werden NodeEntities mit Attributen und Relationen:

Sind Attribute auf Relationen gewünscht, so ist dies durch eigene RelationShipEntities möglich:

Fertig ist das Object-Graph-Model. Ein Grundgerüst für eine derartige Verarbeitung ist tatsächlich schnell implementiert. Neben Extraktion der Domain-Daten und einem passenden Mapping besteht die eigentliche Arbeit darin ein angemessenes Object-Graph-Model zu definieren. Schwierig? Ohne fachliches Verständnis der Domäne in der Sie sich bewegen sind Sie kaum in der Lage BPMN 2.0 Prozesse zu modellieren, Datenflüsse zu verstehen und umzusetzen. Das Know-How ist also da und muss nur genutzt werden.

 

Um die Ergebnisse zu extrahieren, bietet Neo4j die Graph-Query-Language Cypher. Diese Ergebnisse lassen sich – wenn es einfach und pragmatisch sein soll – mittels einer der zahlreichen Chart-Libraries (Google Charts, ChartJS, …) visualisieren und in eine Web-Seite einbinden. Soll es etwas mehr sein ist auch die Einbindung in existierende Reporting-Tools durch einen optionalen Neo4j JDBC-Driver gewährleistet

Fertig ist die praxisorientierte KPI-Extraktion.

Fazit

Beim Thema KPIs geht es aus technischer Sicht zunächst darum, vorhandene Daten, die im Rahmen Ihrer Prozessapplikation sowieso zur Verfügung stehen, optimiert vorzuhalten und auszuwerten. Bedenken Sie, dass Sie die Laufzeitdatenbank – gerade bei umfangreicheren Vorhaben – irgendwann von alten historischen Prozess-Instanzen bereinigen. Entsprechend ist eine eigens dafür zuständige Datensenke das Mittel der Wahl. Muss es dabei immer gleich eine volle BI-Lösung mit schwergewichtigen ETL-Prozessen sein? Meiner Meinung nach nein. Schlanke effiziente Lösungen bieten ein erheblich besseres Kosten-Nutzen-Verhältnis. Und machen ganz nebenbei mehr Spaß. Einen solchen Lösungsansatz haben wir aufgezeigt.

Von Amazon CTO Werner Vogel stammt das Zitat „For anything with multiple relationships, multiple connections, Neo4j absolutely rocks!“.

Ich bin der Meinung: „Neo4j ist erste Wahl zur praxisgerechten Gewinnung von Prozess-KPIs“.

Detaillierte Informationen zu Neo4j finden Sie auf neo4j.com. Weitere Informationen rund um Camunda BPM finden Sie auf www.camunda.com und unserer Seite http://accso.de/leistungen/loesungen/bpm/camunda/.

Weitere Artikel

Das könnte Sie auch interessieren