Bruce Silver macht sich in seinem Blog Sorgen um die BPMN 2.0. Der BPMN-Spezifikationsentwurf sieht verschiedene Konformitätsklassen für Modellierungstools vor, z. B. kann ein Tool die reine Prozessmodellierung unterstützen oder etwa die Choreographiemodellierung oder auch die Ausführung von Modellen durch eine Process Engine. Das Problem hierbei: Damit ein Tool die Prozessmodellierungskonformität erfüllt, muss es im Prinzip sämtliche Detailattribute unterstützen, die eigentlich nur für eine spätere Prozessausführung benötigt werden. Da man diese Details für eine rein fachliche Prozessmodellierung nicht benötigt, müsste ein Modellierungstool auf dieser Ebene die genannten Details nicht unterstützen. Das wäre vielleicht nicht so schlimm. Dann hat man eben Attribute zur Verfügung, die nicht verwendet werden. Silver befürchtet, dass es jedoch zum Problemen beim Austausch von Modellen zwischen unterschiedlichen Tools werden könnte, wenn etwa die (eigentlich nicht benötigten) Details mit den Datenstrukturen von Process Engines ins Gehege kommen, die aufgrund vorhandener Implementierungen nicht 100% BPMN-konform sind.
Die vorgeschlagenen Lösung besteht darin, verschiedene Untermengen der BPMN-Elemente zu definieren, die jeweils nur die aus fachlicher Sicht benötigten Attribute umfassen. Das Austauschformat müsste dann auch den Austausch von Modellen mit nur diesen Attributen ermöglichen, also auch ohne die ausführungsbezogenen Details. Ein entsprechender Entwurf für eine solche Einteilung der Modellelemente wurde von Robert Shapiro vorgeschlagen und zwischenzeitlich der BPMN Task Force vorgelegt. Die vielfach kritisierte Benennung einer dieser Klassen als „DODAF“ wurde in „analytisch“ umgewandelt.
Silver fordert die Leser dazu auf, ihre Unterstützung dieses Vorschlags an die BPMN Revision Task Force zu mailen (über die Projektleiterin ivana.trickovic@sap.com, die man um die Weiterleitung an die gesamte Task Force bitten soll).
In einem Kommentar teilt Keith Swenson mit, dass die Klasse „Simple“ mit den einfachsten und wichtigsten Elementen bereits gestrichen worden sei. Er beklagt, dass die OMG BPMN offensichtlich nur als Sprache zur Spezifikation ausführbarer Prozesse sieht. Das entspräche natürlich nicht dem Ziel einer gemeinsamen Sprache von Business und IT.
Ich verstehe ehrlich gesagt die Aufregung nicht ganz, und erst recht nicht, inwiefern das Business-Modellierer einschränken soll.
Ich verstehe wohl, dass es vorallem für kleine Hersteller (deshalb ist das hier auch meine Meinung und nicht notwendigerweise die der Firma die ich in der FTF vertrete) schwierig ist, rechtzeitig (oder gleichzeitig mit großen Konkurrenten) auf den Markt zu kommen, wenn sie auf Anhieb das volle Spektrum unterstützen müssen. Aus Anwendersicht sehe ich in der großen Conformance-Klasse allerdings den Vorteil, dass eben wo BPMN 2.0 draufsteht auch wirklich BPMN 2.0 drin ist. Und zwar so, dass es auch austauschbar ist. Das war schon bei BPEL immer ein Problem, dass zwar jeder behauptet hat es zu ünterstützen, es dann aber in der Breite nicht getan hat.
Für den Businessmodellierer ändert sich m.E. nichts. Er kann nachwievor so frei modellieren wie er möchte. Es wird allerdings sichergestellt, dass alle im Metamodel verankerten Elemente und Attribute auch von den Tools unterstützt werden. Dabei geht es keineswegs nur um die Ausführbarkeit. Wenn ich ein Data Object in mein Modell einbaue und es durch meinen Kontrollfluß reiche, dann soll doch auch diese Beziehung erhalten bleiben, insbesondere beim Austausch zwischen Modellierungswerkzeugen. Das ist doch der wichtige Schritt von 1.2 zu 2.0, dass die Modelle nicht nur die visuelle Komponente haben, sondern auch ein Metamodell darunter liegt, welches (auch) die Bedeutung sichert.
Der Knackpunkt wird wohl sein, wie die Toolanbieter die Spezifikation umsetzen. Es ist natürlich richtig: Wenn alle Anbieter die Spezifikation korrekt umsetzen, müsste es auch möglich sein, ein Modell ohne technische Details in ein Ausführungssystem zu übernehmen und dort den ausführungsrelevanten Informationen anzureichern. Insofern müsste ein reines Fach-Modellierungstool darauf verzichten können, sämtliche ausführungsbezogene Attribute und Konstrukte anzubieten (wie z. B. Interfaces und Endpoints, die im Gegensatz zu Datenflüssen wohl kaum in fachlichen Modellen auftauchen), wenn es nur sicherstellt, eine gültige Exportdatei zu erzeugen. Allerdings wäre es offiziell nicht konform mit der BPMN Prozessmodellierungs-Klasse, da es nicht alle Konstrukte umsetzt.
Auch das ist in der Praxis vielleicht wirklich nicht so bedeutsam. Dennoch scheint sich die OMG sehr viele Gedanken um die Ausführbarkeit zu machen und wesentlich weniger um die Eignung zur fachlichen Modellierung, wie z. B. eine bessere Anbindung an die Organisationsmodellierung.
Selbstverständlich sind hier auch die Toolhersteller gefragt. So kenne ich eine Reihe von reinen BPMN-Modellierungstools, die zwar sämtliche technische Attribute zur Verfügung stellen, aber die eigentlich vorgesehene Möglichkeit zur Definition eigener Attribute nicht nicht anbieten. Diese wäre aber gerade für fachliche Modellierer wichtig um z. B. Bearbeitungszeiten, Kostensätze usw. zu erfassen.