Stephen White von IBM, der als „Vater“ der BPMN gilt, sprach in seiner Keynote über die Geschichte, den aktuellen Stand und die Zukunft der BPMN. Wird es eine BPMN 3.0 geben? Im Augenblick gibt es keine konkreten Aktivitäten, doch ist davon auszugehen, dass es irgendwann schon dazu kommen wird. Aktuell arbeiten viele der BPMN-Entwickler an einem Standard für eine Case Management-Notation mit. Eines der Ziele bei der BPMN-Entwicklung war die Unabhängigkeit von konkreten Vorgehensweisen. Die Notation enthält viele Elemente, die nicht immer gebraucht werden. Einerseits wird häufig die Komplexität der BPMN beklagt, andererseits wird es auch bemängelt, wenn man bestimmte Sachverhalte nicht darstellen kann. Whites Rat: Man soll sich einfach herausgreifen, was man jeweils braucht. Es muss auch nicht jede Information im grafischen Modell dargestellt werden. Er betonte auch, dass BPMN-Modelle nur einen Aspekt des Prozessmanagements darstellt. Andere genauso wichtige Aspekte sind z. B. Daten, Ressourcen, User Interfaces etc.
Betrachtet man unterschiedliche Prozesstypen, so ist die BPMN eher für klar strukturierte Prozesse geeignet. White erwartet, dass sich die Notation einerseits auch in Richtung schwach strukturierter Prozesse entwickeln wird (auch im Zusammenhang mit der geplanten Case Management Notation CMMN), andererseits könnten auch noch mehr technische Details für eine Service Modellierung hinzukommen. Zur Unterstützung des Case Managements könnten die Ad hoc-Unterprozesse zu eigenständigen Prozessen entwickelt werden. Er würde sich außerdem eine Unterstützung verschiedener Sichten auf ein- und dasselbe Modelle wünschen, z. B. eine High Level-Sicht und eine detaillierte Sicht. Auch die Abbildung von Varianten könnte ein Thema sein.
Das bereits angesprochene Thema Case Management ist momentan ein „Hot Topic“. Ganz einfach ausgedrückt geht es um eine Verbindung von Content und Prozessen. Außer dem Ad hoc-Unterprozess bietet die BPMN bisher nicht viele Möglichkeiten für Prozesse, deren Ablauf nicht genau vorher bestimmt werden kann. Hier wären noch weitere Aktivitätstypen hinzukommen.
Sonstige Erweiterungsmöglichkeiten, die er ansprach: Meilensteine in Lebenszyklen von Cases, weitere Ereignisse (z. B. für Zustandsänderungen), Bedingungen, Abhängigkeiten und Überlappungen von Aktivitäten. Auch die Änderungen von Prozessmodellen zur Laufzeit könnte ein Thema sein.
White stellte auch einen Vorschlag für die Service-Modellierung vor. Auf den ersten Blick ähnelt das Modell einem BPMN-Modell, doch handelt es sich eher um einen Mikro-Flow, der nicht von einer Process Engine abgearbeitet wird. Stattdessen können beispielsweise User-Interaktionen und Screenflows modelliert werden.
Vormittags-Session
Morgens stand die dritte Session des wissenschaftlichen BPMN-Workshops auf dem Programm. Luisa Parody von der Universität Sevilla erläuterte eine Methode, wie man die geeignete Reihenfolgen von Aktivitäten in Prozessen festlegt. Dabei müssen Datenabhängigkeiten berücksichtigt werden. So kann eine Aktivität, die Daten von einer anderen Aktivität benötigt, erst gestartet werden, wenn diese andere Aktivität abgeschlossen ist. Nicht immer kann man bereits während der Modellierung bestimmen, welche Reihenfolge die beste ist. So können bei einer Reisebuchung Hotel- und Flugbuchung prinzipiell parallel durchgeführt werden. Möchte man hingegen den besten Gesamtpreis erreichen, so ergeben sich plötzlich Abhängigkeiten. Beispielweise könnte das Reisedatum geändert werden, weil der Flugpreis einen Tag früher deutlich billiger ist. Dann ändern sich auch die Daten für die Hotelbuchung. Die vorgeschlagene Methode zur Lösung solcher Probleme erweitert die BPMN um einen neuen Kombinations-Unterprozess, der sich um die optimale Reihenfolge bestimmter Aktivitäten kümmert.
Amin Jalali von der Universität Stockholm präsentierte eine Erweiterung der BPMN um die Modellierung von Aspekten. Wie in der Aspekt-orientierten Programmierung geht es um Querschnittsthemen wie Sicherheit oder die Protkollierung von Aktivitäten. Solche Aspekte wirken sich auf ganz verschiedene Teile eines Prozesses aus. Sollen Änderungen bzgl. eines solchen Aspekts durchgeführt werden, so ist es schwierig alle Stellen zu finden, an denen der Prozess angepasst werden muss. Jalali verwendet Bedingungsereignisse an den Aktivitäten, die von einem bestimmten Aspekt betroffen sind. Von dort gibt es Verweise auf separate Prozessmodelle mit Empfehlungen, wie der entsprechende Aspekt umgesetzt wird, z. B. in Form von Überprüfungen, Archivierungsaktivitäten etc. Diese Aspekt-bezogenen Prozesse können an vielen Stellen wiederverwendet werden. Auf diese Weise werden die betreffenden Aspekte aus dem eigentlichen Modell ausgelagert, halten dieses schlanker, und Änderungen sind nur an weniger Stellen durchzuführen.
Der letzte Vortrag dieser Session wurde von Oliver Kopp von der Universität Stuttgart gehalten. Er zeigte eine Notation für Topologien und Management-Pläne für Cloud-Anwendungen. Zur Beschreibung von Services solcher Anwendungen werden Templates verwendet. Diese umfassen einerseits ein Topologie-Templates, die z. B. die verwendeten Server, Betriebssysteme, Anwendungsserver enthalten. Außerdem gibt es Aktivitäten für die Implementierung und das Management der einzelnen Komponenten, z. B. das Starten und Stoppen von Servern. Zur Modellierung von komplexeren Management-Abläufen, wie z. B. das Deployment einer komplexen Anwendung wird BPMN4TOSCA verwendet. Grafisch ist dies eine Erweiterung verschiedener Elemente der BPMN um spezielle Icons. Inhaltlich sind die entsprechend gekennzeichneten Elemente mit der Topologie und den Management-Aktivitäten verbunden.