Beteiligte Rollen

Für die umfassende Entwicklung automatisierter Geschäftsprozesse auf Basis von SOA und der zu-gehörigen Webservices werden im Allgemeinen mehrere Rollen unterschieden. Zusammengefasst reichen diese Rollen vom Geschäftsanalysten und Prozessmodellierer über den SOA-Architekten, den Dienstentwickler und Tester bis hin zu verschiedenen Administratoren.²¹²

Darüber hinaus wird im Kontext der Komplementierung von Geschäftsprozessmanagement mit Techniken der Ereignisverarbeitung aufgrund der hohen Komplexität und des erforderlichen Spe-zialwissens die weitere Rolle eines Ereignismodellierers vorgeschlagen. In dessen Verantwortungs-bereich liegt die technische Integration der Ereignisquellen, die Definition der zu verarbeitenden Ereignistypen, die Spezifizierung der Ereignisverarbeitungsregeln in der jeweiligen Ereignisverar-beitungssprache der verwendeten CEP-Engine sowie die Bestimmung der damit verbundenen Echt-zeitreaktionen.²¹³ Angesichts der neuartigen Möglichkeit der modellbasierten Entwicklung von Er-eignisverarbeitungsregeln im Rahmen von [moby]^dbpmsowie insbesondere aufgrund der Tatsache, dass die hierfür konzipierte Notation der EPMN an die weitverbreitete BPMN angelehnt ist (siehe Kapitel 6), kann in der vorliegenden Methode dieser Arbeit auf eine solche Spezialrolle verzichtet werden. Dies deckt sich überdies mit einem Ergebnis der bereits zitierten Umfrage von ebizQ, wo-nach die Spezifizierung von Ereignisverarbeitungsregeln in der Praxis mehrheitlich von fachlich orientierten Experten durchgeführt wird.²¹⁴

Da in dieser Arbeit zudem weniger die Entwicklung von neuen Webservices als vielmehr die Nutzung bestehender Dienste im Rahmen der Modellierung dynamischer Geschäftsprozesse im Fo-kus ist, können die oben genannten Rollen aus typischen SOA-Projekten zur Vereinfachung um die spezifischen Rollen der SOA-Entwicklung reduziert werden.

Zur Durchführung der Methode [moby]^dbpmwerden in dieser Arbeit drei Rollen vorgeschlagen, die sich im Unternehmen für die einzelnen Aktivitäten des Vorgehens verantwortlich zeichnen:

Modellierer, Entwickler und Administrator.

Die Rolle des Modellierers, der mit einem Geschäftsanalysten mit fachlichem Know-how ver-gleichbar ist, übernimmt dabei die vollständige Modellierung auf Geschäftsprozessebene inklusive der Bildung von Dynamikeinheiten in der Wechselwirkung mit Ereignissen aus der Ereignisverar-beitungsebene. Aufgrund der fachlichen Orientierung des in dieser Arbeit konzipierten arbeitungsmodells verantwortet er darüber hinaus auch die grafische Modellierung der Ereignisver-arbeitungsregeln in EPMN auf der Ereignisverarbeitungsebene.

212vgl. Bieberstein u. a. 2006, S. 76–81; Zimmermann und Mueller 2004

213vgl. von Ammon u. a. 2008

214vgl. ebizQ 2007, S. 16

Die eher technische Aufgabe der Spezifizierung des Ereignismodells mit den verwendeten Ereig-nistypen entfällt auf die Rolle des Entwicklers. Dieser ist zudem für die technische Komplettierung beider Modelle für die Ausführung verantwortlich. Hierzu ist die automatisierte Transformation des Ereignisverarbeitungsmodells in ausführbaren Code anzustoßen. Überdies gewährleistet der Entwickler die technische Anbindung der genutzten elektronischen Dienste und Ereignisquellen.

Abschließend sorgt die Rolle des Administrators für das Deployment der entwickelten Modelle in die entsprechenden Engines, wobei das Geschäftsprozessmodell in einer BPMN 2.0-Engine und das Ereignisverarbeitungsmodell in einer CEP-Engine läuft. Der Administrator verantwortet auch deren reibungslose Ausführung innerhalb dieser automatisierten Ausführungsumgebung.

Tabelle 4.2 fasst die in [moby]^dbpmzum Einsatz kommenden Rollen und die von ihnen ausgeführ-ten Aktivitäausgeführ-ten des Vorgehens in der Übersicht zusammen.

Rolle Verantwortete Aktivitäten

Modellierer 1. a. Modellierung von Geschäftsprozess in BPMN 2.0 ohne Dynamik 1. b. Bildung von Dynamikeinheiten in der Wechselwirkung mit Ereignissen 2. a. Modellbasierte Entwicklung von Ereignisverarbeitungsregeln in EPMN Entwickler 2. b. Spezifizierung des Ereignismodells

3. a. Transformation des Ereignisverarbeitungsmodells in ausführbaren Code 3. b. Technische Anbindung von Diensten und Ereignisquellen für Ausführung Administrator 4. a. Deployment des Geschäftsprozessmodells in BPMN 2.0-Engine

4. b. Deployment des Ereignisverarbeitungsmodells in CEP-Engine

Tabelle 4.2:Beteiligte Rollen und deren Verantwortlichkeiten

Um diese Aktivitäten des Vorgehens ausführen zu können, ist für die vorgeschlagenen Rollen vor-nehmlich das in Tabelle 4.3 aufgeführte fachliche und methodische Know-how erforderlich.

Rolle Erforderliches Know-how

Modellierer – Fachliche Kenntnisse über den dynamischen Geschäftsprozess – Know-how bezüglich der grafischen Modellierung in BPMN 2.0

– Grundlegendes Verständnis von Ereignisverarbeitung und Ereignisverarbeitungsregeln – Know-how bezüglich der grafischen Modellierung in EPMN

Entwickler – Technisches Verständnis von Ereignisverarbeitung und Ereignisverarbeitungsregeln – Technisches Know-how in XML, XML Schema und JSON (JavaScript Object Notation) – Technisches Know-how in Webservice- und Messaging-Technologien

Administrator – Technisches Know-how für die Administration der BPMN 2.0-Engine, hier Activiti²¹⁵ – Technisches Know-how für die Administration der CEP-Engine, hier Esper²¹⁶

Tabelle 4.3:Erforderliches Know-how zur Ausführung der Aktivitäten des Vorgehens

215siehehttp://www.activiti.org ²¹⁶siehehttp://esper.codehaus.org

Dieses Kapitel betrachtet im Rahmen der konzipierten Methode die Modellierung auf Geschäftspro-zessebene, wofür aufgrund der in Abschnitt 2.1.2 beschriebenen Vorzüge die BPMN 2.0²¹⁷verwendet wird. Im ersten Schritt wird das fachliche Geschäftsprozessmodell ohne dynamische Eigenschaften im Zuge von Ereignisverarbeitung entworfen, wobei jedoch alle erforderlichen Aktivitäten bereits berücksichtigt werden. Anschließend wird das fachliche Geschäftsprozessmodell in Einheiten aus einer Aktivität oder einem Teilprozess segmentiert, die in einen dynamischen Zusammenhang zu Ereignissen gesetzt werden. Für diese sogenannten Dynamikeinheiten muss zuletzt noch die Aus-führungssemantik auf der technischen Geschäftsprozessebene spezifiziert werden.

5.1 Modellierung von Geschäftsprozessen ohne Dynamik

Für die Entwicklung automatisierbarer Geschäftsprozessmodelle in BPMN 2.0, mit denen primär sta-tische Geschäftsprozesse aus der Realität softwaretechnisch abgebildet werden, existieren verschie-dene Methoden und Frameworks, die auch in der Praxis bereits erfolgreich eingesetzt werden. Diese zielen meist darauf ab, auf fachlicher Ebene von einem strategisch orientierten Geschäftsprozessmo-dell, das nur wenige Basissymbole der Notation nutzt, um den Geschäftsprozess grob zu skizzieren und mit einem eingängigen Modell für fachliche Anwender verständlich zu gestalten, durch vertie-fende Diskussionen zu einem analytischen Geschäftsprozessmodell zu gelangen, das unter Nutzung aller BPMN-Symbole die operativen Prozessabläufe konkret abbildet. Daraus kann schließlich das technische Geschäftsprozessmodell abgeleitet werden, welches die entsprechende Ausführungsse-mantik mittels des zugrunde liegenden XML-Modells der BPMN 2.0 hinzufügt.²¹⁸ Dieser Vorgang bei der Geschäftsprozessmodellierung mit BPMN 2.0 wird in Abbildung 5.1 veranschaulicht.

Ebene 1

Ebene 2

Ebene 3 Fachlich

Technisch

Inhalt:

Ziel:

Semantik:

Umsetzung:

Geschäsprozess im Überblick Schnelles Verständnis für Diskussion Logisch-abstrakt

Wenige Basissymbole der BPMN 2.0 Inhalt:

Ziel:

Semantik:

Umsetzung:

Operative Geschäsprozessabläufe Abstimmung von Details

Physisch-konkret

Alle Symbole der BPMN 2.0 Inhalt:

Ziel:

Semantik:

Umsetzung:

Ausführungssemantik

Sowaretechnische Umsetzung Physisch-konkret

XML-Spezifikation der BPMN 2.0

Strategisches

Geschäsprozessmodell

Analytisches

Geschäsprozessmodell

Technisches

Geschäsprozessmodell

Abbildung 5.1:Modellierungsframework mit BPMN (Business Process Model and Notation)²¹⁹

Zur Vereinfachung der Modellierungspraxis ist es ratsam, den realen Geschäftsprozess auf Möglich-keiten der Nutzung bekannter Entwurfsmuster, englisch Workflow Patterns, hin zu untersuchen.²²⁰

217vgl. OMG 2011

218vgl. Freund und Rücker 2010, S. 14–17; Silver 2009, S.

2196–8in Anlehnung an Freund und Rücker 2010, S. 15

220vgl. van der Aalst u. a. 2003a, S. 5 ff.

Unter einem Entwurfsmuster wird generell die systematische Beschreibung einer Lösung für ei-ne häufig wiederkehrende Problemstellung in eiei-nem bestimmten Kontext verstanden, um eiei-ne ho-he Wiederverwendbarkeit zu erzielen.²²¹Im Zusammenhang mit der Geschäftsprozessautomatisie-rung wird die SondieGeschäftsprozessautomatisie-rung und Beschreibung von Entwurfsmustern von der sogenannten Workflow Patterns Initiative²²²als gemeinsames Bestreben der Technischen Universitäten in Eindhoven und Queensland betrieben. Ziel der Initiative ist die Bereitstellung von konzeptuellen Basiskonstrukten in Geschäftsprozessen mittels generischer und plattformunabhängiger Dokumentation der entspre-chenden Charakteristika, um einerseits nützliche Entwurfsmuster für reale Anforderungen bei der Geschäftsprozessmodellierung zur Verfügung zu stellen und andererseits die verfügbaren Model-lierungssprachen auf ihre Ausdrucksmächtigkeit hin zu evaluieren.²²³Betrachtet werden insbeson-dere Kontrollflussmuster, englisch Control Flow Patterns,²²⁴ aber auch Muster für Ressourcen²²⁵, Daten²²⁶und die Ausnahmebehandlung²²⁷in Geschäftsprozessen sowie für die Darstellung von Ge-schäftsprozessen²²⁸. Eine umfassende Behandlung dieser Entwurfsmuster ist an dieser Stelle nicht vorgesehen, kann aber der jeweils genannten Literatur entnommen werden.

Eine möglichst erschöpfende Erstellung des fachlichen Geschäftsprozessmodells aus solchen Ba-siskonstrukten wird in dieser Arbeit vornehmlich für die Kontrollflussmuster angeraten, welche den Ablauf des Geschäftsprozesses charakterisieren. Die Workflow Patterns Initiative unterscheidet 43 Kontrollflussmuster in acht Kategorien, von denen einige beispielhaft aufgeführt werden:²²⁹

○ Sequenz von Aktivitäten, englisch Sequence Pattern

○ Parallele Spaltung des Kontrollflusses in mehrere Pfade, englisch Parallel Split Pattern

○ Exklusive Auswahl eines von mehreren Pfaden, englisch Exclusive Choice Pattern

○ Strukturiert synchronisierte Zusammenführung von optionalen Pfaden bei vorhergehender Mehrfachauswahl, englisch Structured Synchronizing Merge Pattern

○ Strukturierte Schleife mit wiederholter Durchführung, englisch Structured Loop Pattern

○ Explizite Terminierung des Geschäftsprozesses, englisch Explicit Termination Pattern

Derartige Kontrollflussmuster stellen eine hilfreiche Unterstützung für die Modellierungspraxis dar und bewirken gleichzeitig die Erstellung konsistenter und verständlicher Geschäftsprozessmodel-le im Unternehmen. Da sich mit BPMN 2.0 die meisten Kontrollflussmuster modellieren lassen,²³⁰ werden diese für die Aktivität 1. a des Vorgehens von [moby]^dbpmempfohlen. Gleichwohl existieren zahlreiche Freiheitsgrade bei der grafischen Darstellung von BPMN 2.0, sodass zusätzliche Stilvorga-ben für die Modellierung nahegelegt werden. Diese sollen möglichst unternehmensweit eingehalten werden, um eine Einheitlichkeit und damit ein verbessertes Verständnis von fachlichen Geschäfts-prozessmodellen auch über verschiedene Parteien hinweg zu erzielen.²³¹

221vgl. Alexander u. a. 1977, S. x (im Kontext des Städte-baus); Gamma u. a. 1995, S. 2 f. (im Kontext der objekt-orientierten Softwareentwicklung)

222siehehttp://www.workflowpatterns.com 223vgl. van der Aalst u. a. 2003a, S. 2–4

224vgl. Russell u. a. 2006b

225vgl. Russell u. a. 2004b

226vgl. Russell u. a. 2004a

227vgl. Russell u. a. 2006a

228vgl. La Rosa u. a. 2011a; La Rosa u. a. 2011b

229vgl. Russell u. a. 2006b

230vgl. Saxena 2011

231vgl. Freund und Rücker 2010, S. 19; Silver 2009, S. 47–

56 und 169–180

Da die Modellierung statischer Geschäftsprozesse in Forschung und Praxis bereits intensiv un-tersucht wurde, soll dieser kurze Abriss an dieser Stelle genügen. Basierend auf dem Vorgehen von [moby]^dbpmfolgt auf die Erstellung des statischen Geschäftsprozessmodells in BPMN 2.0 die Berück-sichtigung von Ereigniskonstrukten zur Dynamisierung des Geschäftsprozessmodells, welche im nachfolgenden Abschnitt im Detail erläutert werden. Bezugnehmend auf Abbildung 5.1 wird hier weiterhin die fachliche Geschäftsprozessebene betrachtet, allerdings wird das analytische Geschäfts-prozessmodell nun geeignet segmentiert, woraufhin durch Hinzufügen von Ereigniskonstrukten so-genannte Dynamikeinheiten gebildet werden. Abschnitt 5.3 widmet sich schließlich der technischen Geschäftsprozessebene mit einer Betrachtung der Ausführungssemantik dieser Dynamikeinheiten.

Im Dokument Eine Methode zur Entwicklung dynamischer Geschäftsprozesse auf Basis von Ereignisverarbeitung (Seite 75-79)