Durchgängige Modellierung von Geschäftsprozessen

in einer Service-orientierten Architektur

Stephan Buchwald

, Thomas Bauer

, Manfred Reichert

2

lementierung eines Fachprozesses notwendigen komplexen Transformationen in

einen ausführbaren Workflow schwer nachvollziehbar sind. Dadurch gehen fachli-

che Anforderungen verloren und es entsteht ein hoher Aufwand bei späteren Pro-

zessanpassungen. Im vorgestellten Ansatz wird ein sog. Abbildungsmodell einge-

führt, das Zugehörigkeiten von Aktivitäten des Fachmodells zu denen des System-

modells (d.h. technische Spezifikation des Informationssystems) explizit dokumen-

tiert. Dadurch werden im Software-Entwicklungsprozess automatisierte Konsis-

tenzprüfungen zwischen den Modellebenen möglich. Werden später Prozessanpas-

sungen erforderlich, so lassen sich die zu einer fachlichen Aktivität gehörenden

technischen Aktivitäten direkt erkennen, was die Durchführung der Anpassung er-

ist insbesondere eine Verbesserung des Zusammenspiels zwischen Fachbereichen und

IT-Abteilungen bei der Software-Entwicklung erforderlich. Dieser Aspekt wird auch als

Business-IT-Alignment bezeichnet: Informationssysteme sollen die fachlichen Anforde-

rungen exakter treffen als bisher. Hierzu müssen Informationsverlust und Verfälschun-

gen bei der Entwicklung des (prozessorientierten) Informationssystems reduziert wer-

den. Falls Änderungen an fachlichen Anforderungen erfolgen, sollen diese korrekt, un-

verfälscht und zeitnah in die Implementierung des Informationssystems einfließen. Au-

ßerdem kann es in einer SOA zu Änderungen in der Umgebung kommen, z.B. wenn

Services wegfallen (d.h. abgeschaltet werden) oder zu einer neuen Version migrieren.

Um solchen Szenarien flexibel zu begegnen, ist eine zusätzliche Modellebene notwen-

ihrer Implementierung im geplanten Informationssystem nachvollziehbar ist. So muss

für jede Aktivität des fachlichen Modells (und damit für deren Eigenschaften und Anfor-

derungen) ableitbar sein, in welche Aktivität(en) des Systemmodells sie eingeflossen ist

(vgl. Abbildung 1). Dies ist normalerweise nicht ohne weiteres erkennbar, da für IT-

Implementierungen meist Vorgaben für Aktivitätenbezeichnungen bestehen, die nicht

mit denen der Fachabteilungen übereinstimmen.

Ein Beispiel einer einfachen Transformation zeigt Abbildung 1 mit der Umbenennung

der fachlichen Aktivität [Änderungsantrag stellen] in [HT_..._Request-

Change] im Systemmodell. Während solche Namensunterschiede noch einfach hand-

habbar sind, sind bei der Abbildung eines Fachmodells auf ein ausführbares Modell

ganz weggelassen. Ein Beispiel ist die Aktivität [Änderung umsetzen] in

Abbildung 1. IT-unterstützte Prozessschritte hingegen sind im Fachprozess häufig nur

grob beschrieben, so dass sie verfeinert oder sogar zusätzlich hinzugefügt werden müs-

sen. Andere fachliche Aktivitäten werden in mehrere IT-gestützte Aktivitäten (Benutzer-

interaktionen, Service-Aufrufe und Datentransformationen) aufgespaltet. So wird in

unserem Beispiel die Aktivität [betroffene Bauteile angeben] in eine Be-

nutzerinteraktion (Human Task) und einen Service-Aufruf aufgespaltet. Schließlich ist

zu beobachten, dass Fehler- und Ausnahmefälle (z.B. Rücksprünge bei unvollständigen

Daten) in Fachprozessmodellen meist nicht abgebildet werden, um die Komplexität in

dieser frühen Phase gering zu halten.

Änderung

ist abge-

GetPartData

Changeable

antrag

stellen

Änderung

Änderung

Antragsteller

e-Mail

Baureihen

verantwortl.

Ausführung einer SOA-Anwendung wichtig, die von Umgebungsänderungen betroffe-

nen Prozesse und Aktivitäten zu identifizieren. Nur so wird es möglich, entsprechend

schnell auf anstehende Änderungen wie “Service-Abschaltungen“ reagieren zu können.

In Kapitel 2 stellen wir die Anforderungen an das zu entwickelnde Konzept vor, insbe-

Prozesstransformationen. Der Ansatz wird in Kapitel 4 detailliert. Kapitel 5 diskutiert

verwandte Arbeiten, bevor mit einer Zusammenfassung geschlossen wird.

Die Modellierung von Geschäftsprozessen aus fachlicher Sicht dient, neben der Prozess-

analyse und -optimierung, vor allem der Dokumentation fachlicher Anforderungen sei-

tens der Fachabteilungen und Prozessverantwortlichen. Da Letztere meist wenig oder

keinen IT-Hintergrund haben, werden die Inhalte eines fachlichen Modells nicht formal

beschrieben. Stattdessen werden einfache graphische Notationen und textuelle Beschrei-

aber auch andere Aspekte (z.B. erfolgt im Fachprozess noch keine detaillierte Festlegung

von Datenstrukturen). Hingegen muss ein implementierter Workflow von einer

Workflow-Engine ausgeführt werden, weshalb die entsprechende technische Prozessbe-

schreibung (ausführbares Modell) vollständig und formal sein muss. Außerdem muss sie

den Vorgaben des von der Workflow-Engine verwendeten Metamodells genügen (z.B.

[Rei00]).

Bei der Transformation eines Fachprozesses in einen Systemprozess ist es wichtig, dass

das Systemmodell geeignet angepasst (d.h. umstrukturiert) wird. Da die durchgängige

Realisierung solcher Umstrukturierungen den Schwerpunkt dieses Beitrags bildet, wer-

den die verschiedenen Typen von Strukturänderungen entlang des in Abbildung 1 darge-

wird die Änderung detailliert und bewertet. Abhängig von dieser Bewertung wird ent-

schieden, ob das Änderungsvorhaben umgesetzt wird oder nicht.

Im Folgenden werden häufig vorkommende Transformationstypen beschrieben.

Typ 1 (Übernahme einer Aktivität inkl. Umbenennung): Im einfachsten Fall

wird eine Aktivität des Fachprozesses auf genau eine Aktivität des Systemmodells

abgebildet. So kann eine Benutzerinteraktion zum Ausfüllen eines Formulars z.B.

als Human Task [Agr07] in einem BPEL-Prozess realisiert werden. Da für Aktivi-

täten auf IT-Ebene aber häufig Namenskonventionen existieren (z.B. um die zu-

gehörige Applikation im IT-Betrieb erkennen zu können), ergeben sich meist unter-

schiedliche Namen für Aktivitäten und Daten im fachlichen Modell und im Systemmo-

Change] im Systemmodell realisiert (vgl. Abbildung 1).

auch Daten mit Backend-Systemen austauschen. Da solche Einheiten aber kaum wieder-

verwendbar sind, entsprechen sie nicht der Grundphilosophie einer SOA. Im Beispiel

aus Abbildung 1 ist es deshalb notwendig, die fachlich zusammengehörige Aktivität

[betroffene Bauteile angeben] in eine Benutzerinteraktion zur Eingabe der

führbare Prozessmodell abgeleitet. Außerdem wird aufgezeigt, wie Beziehungen zwi-

schen diesen Ebenen in Prozessmodellierungsumgebungen explizit dokumentiert werden

können. Dieser Aspekt wird in Kapitel 4 detailliert.

bzw. -eignern ermittelt. Häufig wird diesen Personen der Fachprozess graphisch darge-

stellt, so dass sie ihre eigenen Prozessschritte in den Fachprozess einordnen oder Fehler

erkennen können. Deshalb ist die wichtigste Anforderung an ein fachliches Modell, dass

es leicht verständlich ist. Zudem liegt die Verantwortung für die Erstellung des Fachmo-

IT-Bereich. In vielen Unternehmen, die sich als IT-Anwender verstehen, gibt es solche

xcvc

indem zusätzliche Transformationstypen für evtl. zukünftig benötigte Transformationen

definiert werden. Alle Veränderungen sind direkt erkennbar und die Beziehungen von

Aktivitäten des Fach- und Systemmodells sind bidirektional nachvollziehbar.

Ein Abbildungsmodell stellt das Verbindungsglied zwischen Fachprozess und System-

prozess dar. Es wird von heutigen Prozessmodellierungswerkzeugen nicht direkt unter-

stützt. Wir zeigen im Folgenden, wie ein Abbildungsmodell prinzipiell gestaltet werden

muss, damit die Beziehung zwischen Fach- und Systemprozess nachvollziehbar ist.

Erstellung und Speicherung: Das Abbildungsmodell wird während der Erstellung des

Prozesses auf Systemmodell-Ebene (vgl. Abbildung 2) erzeugt. Da beide Modelle in der

Verantwortung des IT-Bereichs liegen, sollten dasselbe Modellierungswerkzeug und

kanten verwendet werden. Abbildung 3 zeigt exemplarisch das zu dem in Abbildung 1

eingeführten Beispiel gehörende Abbildungsmodell in einer „neutralen“ Notation. Hier

werden die Transformationsknoten durch Achtecke repräsentiert, um sie leicht von Akti-

vitäten unterscheiden zu können; Transformationskanten werden gestrichelt dargestellt.

dell aktualisierte Menge fachlicher Aktivitäten mit der bereits vorhandenen. Sind be-

stimmte Aktivitäten nicht mehr enthalten, wurden diese aus dem Fachprozess gelöscht

(bzw. zusätzliche wurden erzeugt).

2. Verwendet das Werkzeug zur Fachprozessmodellierung zugreifbare Zeitstempel für

Aktivitäten-Objekte, sind Veränderungen einzelner fachlicher Aktivitäten erkennbar.

Die Konsistenzanalyse vergleicht nicht nur die aktualisierte mit der bereits vorhande-

nen Aktivitätsmenge, sondern zusätzlich die Zeitstempel einzelner Aktivitäts-Objekte.

3. Analog können bei Veränderungen in der Umgebung der Prozessapplikation, etwa die

Abschaltung eines Services (vgl. Abbildung 1, Service_GetPartData), mit die-

sem Ansatz leicht betroffene fachlichen Aktivitäten (betroffene Bauteile

FKT08]. Allerdings sind solche Ansätze nicht immer realisierbar. Dies trifft auch auf

von zusätzlichen Aktivitäten, schwer realisierbar, da für diese keine entsprechende Akti-

vität im fachlichen Modell existiert. In dem von uns betrachteten Anwendungsfall ist

eine Wiederverwendung vordefinierter Patterns in unterschiedlichen Geschäftsprozessen

nicht realistisch. Deshalb muss für jeden Geschäftsprozess individuell entschieden wer-

den, wie eine entsprechende technische Repräsentation im Systemmodell aussieht.

Von Fachbereichen erstellte Prozessmodelle müssen strukturell adaptiert werden, bevor

sie mittels Prozess-Management-Systemen implementiert werden können. Hierbei ist es

Konzept des Abbildungsmodells entwickelt. Es ermöglicht weiterhin, die bei der Erstel-

lung des Systemmodells benötige „freie Geschäftsprozess-Modellierung“, aber erzielt

dennoch einen hohen Grad an Nachvollziehbarkeit. Diese Nachvollziehbarkeit wird

genutzt, um Prozessimplementierungen schneller erstellen bzw. anpassen zu können. Sie

gewährleistet zudem die Konsistenz zwischen den verschiedenen Modellebenen. Ent-

wurfsalternativen und eine prototypische Umsetzung sind in [BBR09] dargestellt.

Literatur

[Agr07] A. Agrawl et al.: WS-BPEL Extension for People Specification. Technical Report, Ac-

[All07] T. Allweyer: Erzeugung detaillierter und ausführbarer Geschäftsprozessmodelle durch

[Bau08] P. Bauler et.al.: Usage of Model Driven Engineering in the context of Business Process

[BBR09] S. Buchwald, T. Bauer, M. Reichert: Durchgängige Modellierung von Geschäftsprozes-

[Rei00] M. Reichert: Dynamische Ablaufänderungen in Workflow-Management-Systemen.