BPMN 2.0 “Sub-Classes”
February 10 2010 by Jakob Freund · 7 Comments
Vorschlag von Shapiro
Eines ist jedenfalls erfreulich: Endlich ist in der Breite angekommen, dass BPMN nicht zwangsläufig “zu kompliziert fürs Business” ist, sondern das sehr davon abhängt, wie man sie einsetzt. Man kann auch ganz einfache Modelle mit BPMN machen, und darum geht es bei den Klassen, die von Shapiro vorgestellt werden. Hierbei handelt es sich übrigens nicht um ein offizielles Zwischenergebnis der Finalization Task Force (FTF) der BPMN 2.0, der wir ja auch angehören. Insofern bleibt abzuwarten, ob und was genau von diesem Vorschlag in die Spec zur 2.0 wirklich eingehen wid.
Die Idee der Sub-Classes, oder auch “Subsets”, ist nicht neu. Sie wurde bereits von Bruce Silver in seinem Buch “BPMN Method and Style” aufgegriffen, und auch wir haben im camunda BPMN-Framework, das in unserem Praxishandbuch BPMN beschrieben wird, verschiedene Ebenen der Modellierung festgelegt. Es gibt aber zwei Aspekte an der aktuellen Diskussion bzw. an dem Glauben an die Subsets, der mich stört:
- Der Glaube, dass man die benötigten Symbole pauschalisieren könnte
- Der Glaube, dass eine Einschränkung der Symbole der Schlüssel für eine vereinfachte Modellierung ist
Zu Punkt 1: Auch wir empfehlen auf Ebene 1 unseres Frameworks eine bestimmte Symbolpalette, die der Empfehlung von Shapiro zumindest ähnelt (bei uns enthält die Palette zur Ebene 1 die Symbole von “Simple” und fast alle von “Descriptive”). Aber schon für Ebene 2 schreiben wir im Buch Folgendes:
Praxishandbuch BPMN, Abschnitt 4.6
 Häufigkeit der Symbole in unseren BPDs auf Ebene 2 Es gibt also kein einziges BPMN-Symbol, das man für die Verwendung auf Ebene 2 allgemeingültig ausschließen kann. Falls Sie die Symbolpalette auf dieser Ebene unbedingt einschränken wollen, müssen Sie diese Entscheidung selbst treffen. In der Abbildung haben wir als erste Orientierung einmal zusammengestellt, welche Symbole wir in unseren Projekten bislang mit welcher Häufigkeit eingesetzt haben. Wir haben auch die neuen Symbole der BPMN 2.0 aufgenommen. Weil die neue Version erst seit Kurzem als Entwurf verfügbar ist, konnten wir bislang kaum praktische Erfahrungen mit ihr sammeln. Deshalb ist die Darstellung in Bezug auf BPMN 2.0 unsere Einschätzung aus heutiger Sicht. |
Insofern habe ich erstmal nichts dagegen, Vorschläge für die Einschränkung der Symbolpalette zu liefern. Aber sobald es um eine “operative” Modellierung geht, sollten dies wirklich unverbindliche Vorschläge sein, die es den Anwendern bewusst offen lassen, sie für sich anzupassen. Oder noch strikter formuliert: Ich glaube, dass die Unternehmen selbst entscheiden müssen, wie ihre jeweiligen Subsets aussehen sollten. Denn ich habe einfach viel zu oft erlebt, dass die Bedürfnisse bei den verschiedenen Firmen sehr sehr unterschiedlich sind, was die Präzision und “Schmerzgrenze” in der operativen Prozessmodellierung (also bei uns die Ebene 2) angeht.
Zum zweiten Punkt, und der ist fast noch wichtiger: Es reicht bei Weitem nicht, einfach die Symbolpalette einzuschränken. Es müssen viel mehr Entscheidungen getroffen werden, um BPMN zielgruppengerecht verwenden zu können, z.B.
- Zum Zweck und “Scope” des Prozessmodells auf den jeweiligen Ebenen: Wofür wird es gemacht? Wer ist der Betrachter? In welcher Projektphase? Was betrachten wir auf dieser Ebene, und was lassen wir weg (ich meine jetzt nicht Symbole, sondern konkrete Aspekte des Prozesses, z.B. Ausnahmen)?
- Zusammenhang zwischen den Ebenen: Wie komme ich von einer Ebene in die darunter liegende? Bestimmt nicht einfach über eine Teilprozessverfeinerung, das funktioniert nicht!
- Orchestrierung / Choreographie: Eine typische Frage bei BPMN ist ja immer wieder, ob “ich jetzt Pools nehme oder Lanes”. Die Antwort auf diese Frage kann nicht sein, dass man Pools “halt nimmt, um eine B2B-Zusammenarbeit darzustellen, also wenn es um verschiedene Firmen geht”. Das ist weder die Intention der BPMN, noch ermöglicht diese Pauschalisierung ein Business-IT-Alignment
- Naja, und noch diverse weitere Fragen…
Ich bin sehr gespannt, was es mit den DoDAF-Pattern auf sich hat, die Shapiro in seinem Webinar erwähnt. Diese Pattern sind m.E. einer der Schlüssel für eine erfolgreiche Arbeit mit BPMN. Leider ist dieses Thema im Webinar recht kurz gekommen, genauso wie die o.g. Fragen. Aber ich werde mal versuchen, sie mir anzuschauen, sofern ich ich sie bekomme.
So wie es aussieht, findet demnächst ein FTF Meeting in Deutschland statt. Wir freuen uns auf die Teilnahme und werden gerade dieses Thema besonders aufmerksam verfolgen, um so gut es geht mitzuhelfen, dass ein vernünftiger Pattern-Approach noch in die Spec aufgenommen wird.
Hallo Jakob,
2010-02-10 um 12.39 pm Uhr. Verfasst von Martin Bartonitzwas der BPMN Spezifikation daher unbedingt auch braucht, ist ein Vorgehensmodell, wie ihr es in Eurem Buch beschrieben habt. Daran lassen sich ja dann Klassen besser ableiten, als das in der Präsentation durch Robert Shapiro vorgestellt wurde. Hier waren es wohl eher die technischen Aspekte zur Implentierung von Prozessausführungen, die die bisherige Klassifizierung getrieben haben.
Habt Ihr Euer Vorgehensmodell in der Spzifikationsgruppe der OMG vorstellen können?
Gruß Martin
Hallo Martin,
nein, wir haben es noch nicht vorgestellt. Aber ich denke ebenfalls, dass es dringend Zeit wird, das zu tun. Es muss ja gar nicht auf Teufel komm raus unser Framework dann 1:1 in der Spec sein. Vielleicht ist die Spec auch das falsche Dokument dafür. Wichtig wäre mir aber, dass die Fragen, denen wir uns im Kontext des Frameworks widmen, in der Spec so gut es geht aufgegriffen (wenigstens genannt) werden und im Zweifel dann irgendwo hin verwiesen wird, wo diese Fragen dann diskutiert und Lösungsvorschläge geliefert werden.
Viele Grüße
Jakob
2010-02-10 um 1.05 pm Uhr. Verfasst von Jakob FreundHallo Jakob,
Hintergrund zur Entwicklung DoDAF Subclass gibt es hier: http://www.bpm-research.com/2010/02/03/primitives-and-the-bpmn-dodaf-subset/ inklusive Links zur Spezifikation. Wir arbeiten im DoD gerade an einer Revision. Ich werde sie verlinken sobald wir die Freigabe haben.
Cheers
Michael zur Muehlen
2010-02-10 um 6.04 pm Uhr. Verfasst von Michael zur MuehlenSuper, vielen Dank erstmal!
2010-02-10 um 6.08 pm Uhr. Verfasst von Jakob FreundHallo Jakob,
die Sub-Classen sind m.E. nicht primär dazu gedacht, den Modellierer einzuschränken, sondern die Tools zu standardisieren. Jedes BPMN-Tool sollte BPMN-SIMPLE können (Modellierung, ggf. Ausführung, Monitoring, …, je nach dieser dazu orthogonalen Klassifizierung), manche mehr.
Wenn sich der Prozessmodellierer auf BPMN-SIMPLE beschränkt, kann er davon ausgehen, in Zukunft eine breite Auswahl an Tools für den Prozess nutzen zu können. Nutzt er BPMN-Complete, geht es ihm vielleicht nur um die Zeichnung. Die Ausführung wird, wenn überhaupt, vielleicht nur durch ein teures Tool unterstützt.
Es geht also nicht primär darum “die benötigten Symbole zu pauschalisieren” oder “um die Vereinfachung der Modellierung”, sondern um einen Formalismus, den Tradeoff zwischen Ausdrucksstärke und Toolunterstützung auszudrücken. Ist Portabilität wichtig, sollte man sich bei der Modellierung beschränken.
Bei der Sprache OWL (Web Ontology Language der W3C) wurden erfolgreich die Sub-Sprachen OWL-Lite, OWL-DL und OWL-Full definiert. Der Modellierungskomfort steigt, die Breite der Toolunterstützung sinkt.
Viele Grüße,
2010-02-16 um 1.27 pm Uhr. Verfasst von Norbert WeißenbergNorbert
Hallo Norbert,
ja danke für den Hinweis, diese Intention hatte ich gar nicht berücksichtigt im Posting.
Das liegt daran, dass ich in der Praxis sehr oft auf Leute treffe die den Sub-Classes-Ansatz als Möglichkeit zur Vereinfachung der Arbeit mit BPMN begreifen, mit den beschriebenen Problemen. Diese Diskussion dominiert derzeit bei unseren Kunden und generell unter Praktikern, das Thema Austauschbarkeit schon weniger, und deshalb hatte ich reflexartig in diese Richtung reagiert.
Aber für das Thema Portabilität und Differenzierung der BPMN-Konformität von Tools ist der Ansatz natürlich durchaus hilfreich.
Viele Grüße
Jakob
2010-02-17 um 10.43 am Uhr. Verfasst von Jakob Freund… wobei das natürlich schon auch Hand in Hand geht, die Intention der Vereinfachung und die Intention der Portabilität. Das sieht man auch ganz deutlich in der Präsi von Shapiro. Und hier muss ich eben gleich wieder den mahnenden Zeigefinder heben
2010-02-17 um 10.45 am Uhr. Verfasst von Jakob Freund