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

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,
Norbert

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

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