Auf dem Laufenden bleiben?
Erhalten Sie immer die neuesten Infos!

Warum Sie vermutlich ein Mapping in Ihrem BPMN-Roundtrip möchten

Anreicherung in der Modellierung?

Anreicherung in der Modellierung?


Die BPMN 2.0 erhält immer mehr Aufmerksamkeit, und ich glaube einen gewissen Trend in der aktuellen Diskussion zu erkennen: „BPMN ermöglicht es sowohl Fachabteilungen als auch Software-Entwicklern, mit demselben Prozessmodell zu arbeiten.“

Die Idee des Roundtrips wird also anscheinend durch die Idee des „Alleskönner-Modells“ ersetzt. Tatsächlich glaube ich aber an dieses eine Killer-Modell nicht! Oder anders ausgedrückt: Wir brauchen eine bessere Definition, was „dasselbe“ Modell genau sein soll. In diesem Blog Post will ich ein paar meiner Gedanken zu diesem Thema erläutern.

Das wesentliche Ziel, das wir erreichen müssen, ist dass das fachliche und das technische Modell konsistent und „in sync“ bleiben, sich also weder inhaltlich widersprechen noch sich mit der Zeit auseinander entwickeln. Gerade der zweite Punkt erweist sich in der Praxis als ausgesprochen wichtig, wenn man das BPM-Engagement im Unternehmen am Leben und die fachlichen Prozessmodelle aktuell halten möchte. Jakob hat die korrekte Anwendung von Pools in BPMN in seinem Blog Post „BPMN – just DO it!“ erklärt. Dieses Thema ist bereits ein wichtiger erster Schritt, wie wir in unseren Kundenprojekten festgestellt haben. Dieses Pattern ermöglicht es, den Prozess aus der jeweiligen Perspektive unterschiedlicher Rollen zu modellieren, z.B. den Prozess des Account Managers, der mit dem Kunden über bestimmte Incidents spricht, ohne zu wissen was der Second Level Support genau tut (wer gerade nicht weiß, wovon ich spreche, möge bitte einmal kurz auf dieses Prozessmodell schauen).

Ein solches Vorgehen führt zu einem eigenen Pool, der die Process Engine repräsentiert. Und der kann direkt automatisiert werden, stimmt’s? Prinzipiell: Ja! Und das sind die guten Nachrichten 🙂

Aber ich habe hierzu noch ein paar Anmerkungen: Zunächst einmal möchte man in der Regel nicht, dass die Entwickler direkt in dem Modell „herumpfuschen“, das man in seinem eigenen Repository vorhält. Kleiner Hinweis: Das ist offensichtlich eine Aussage aus Sicht des Business, denn „Herumpfuschen“ heißt in Wirklichkeit, dass jemand die eigentliche Arbeit macht um den Prozess tatsächlich ausführbar zu machen 🙂
Und die Entwickler brauchen herfür ein zusätzliches Tooling, wie ich in meinem letzten Blog Post beschrieben habe. Deshalb war der beste Ansatz, den wir in unseren Projekten angewandt haben, den Pool der Process Engine in ein eigenes Repository zu kopieren, in der Regel in ein SVN o.ä. Also kopieren wir den Process Engine Pool und haben eine Entwickler-Version. Und jetzt möge man mir sagen: Ist das noch ein einziges Modell, oder sind es zwei separate? In der Regel bekomme ich auf diese Frage unterschiedliche Antworten, ganz abhängig davon, wen ich frage! Ich würde sagen: Es sind nur zwei verschiedene Versionen desselben Modells!

In der Sprache der Entwickler ist das nur eine Art „Branch“. Damit verbunden gibt eine besondere Herausforderung, und zwar das „Mergen“! Denn möglicherweise ändert ein Entwickler das Modell, z.B. weil ein neuer Service Task hinzugefügt werden muss, um die Informationen für eine automatisierte Entscheidung zu bekommen. Etwas, was in der fachlichen Modellierung häufig vergessen wird.

Anreicherung in der Modellierung?

Anreicherung in der Modellierung?


Diese Änderungen müssen in das fachliche Modell zu einem bestimmten Zeitpunkt zurück-gemerged werden. Und um ehrlich zu sein: Das ist der schwierige Teil, vor allem weil das grafische Visualisieren von Unterschieden im Modell eine anspruchsvolle Anforderung an die Tools ist! Wir hoffen, dass die Anbieter für dieses Problem eine Lösung finden, und haben es bereits an einige herangetragen. Bis dahin bedeutet „Mergen“ in unseren Pilotprojekten im Wesentlichen, den Process Engine Pool im BPMN-Diagramm zu überschreiben.

Aber mit diesem Ansatz des Modell-Kopierens ist eine „low hanging fruit“ verbunden, auf die ich hinweisen möchte: In diesem Schritt können wir zusätzliche Funktionalität sehr einfach im Modell hinzufügen. Ich nenne das „Enrichment“, wie man im realistischen Beispiel zur Linken sehen kann 😉 In camunda fox haben wir die Möglichkeit eingebaut, individuelle Anreicherungen in der Phase der Modellüberführung vorzunehmen, was bedeutet dass wir sehr flexibel sind. Ein paar Beispiele hierzu:

  • Im fachlichen Modell enthält ein Service Call vielleicht nur den Namen des Services aus dem Service Repository. Im technischen Modell brauchen wir alle technischen Details, z.B. ob es sich um einen Web Service oder „nur“ eine EJB handelt.
  • Blanko-Zwischenereignisse im fachlichen Modell markieren „organisatorische Meilensteine“ des Prozesses anhand einer Bezeichnung. Da sie überwacht werden sollen, muss das technische Modell entsprechend angereichert werden, damit eine Nachricht an die Monitoring Software geschickt wird, wenn der Meilenstein erreicht wurde.
  • Wir haben einige einfache Übersetzungen von Bezeichnern vorgenommen, da die fachlichen Prozessmodelle i.d.R. auf Deutsch bereitgestellt werden müssen, die technischen hingegen auf Englisch (spätestens, wenn die Entwicklung outgesourced wird).
  • Derzeit machen wir sogar noch ein Mapping von BPMN auf jBoss jBPM 3 – Modelle, da die Ausführung von BPMN 2.0 noch nicht stabil funktioniert.

Diese Anreicherungen können später sogar ausgetauscht werden, z.B. wenn sich die Software-Infrastruktur verändert. In der Vergangenheit hatten wir z.B. den Anwendungsfall, dass ein Unternehmen ein zu stark limitiertes UDDI Repository durch ein sehr viel mächtigeres ausgetauscht hat, das auch EJB und JMS unterstützen konnte. Aber das ist im Wesentlichen ein allgemeiner Vorteil von modellgetriebenen Entwicklungsansätzen.

Das waren jetzt nur ein paar wenige Beispiele. Also, reden wir immer noch über ein einziges Prozessmodell für Business und IT? Ist es „korrektes“ BPMN 2.0, wenn einige technische Details „nur“ noch in der Anreicherungsphase hinzugefügt werden? Ich denke schon, zumal es ein sehr gutes Argument für diese Meinung gibt: In der Praxis funktioniert es ziemlich gut! Und mir ist es egal ob man das jetzt „ein Modell für beide“ oder „Roundtrip“ nennt, solange ein Entwicklungsansatz etabliert wird, der in Ihrem Unternehmen funktioniert! Beiißen Sie sich nicht an dem Glauben fest, dass „ein Modell“ auch „eine Datei“ bedeutet, und fürchten Sie sich nicht vor dem Wort „Roundtrip“. Tatsächlich funktioniert ein solcher Roundtrip ziemlich gut wenn Sie „kompatible“ Sprachen auf beiden Seiten haben, z.B. „fachliches“ und „technisches“ BPMN. Der Roundtrip war nur bei BPEL wirklich kaputt 😉

Schon gelesen?

Scientific performance benchmark of open source BPMN engines

Why BPMN is not enough

Decision Model and Notation (DMN) – the new Business Rules Standard. An introduction by example.

Neues Whitepaper: Der Mythos Zero-Coding BPM

4 Kommentare

Hinterlassen Sie eine Antwort