Analyse der Überführbarkeit zwischen fachlichen und technischen Prozessmodellen für eine service-orientierte Architektur
©2007
Diplomarbeit
141 Seiten
Zusammenfassung
Inhaltsangabe:Einleitung:
Die Konzepte der Service-orientierten Architektur (SOA) zeigen eine flexible Ausrichtung der IT an den Geschäftsprozessen eines Unternehmens. Typischerweise werden diese Geschäftsprozesse technisch und fachlich modelliert. Um eine effiziente, dauerhafte Ausrichtung der IT an den Geschäftsprozessen zu gewährleisten, müssen die jeweiligen technischen und fachlichen Prozessmodelle konsistent zueinander sein. Zur Sicherung dieser Konsistenz ist eine automatisierte Überführung zwischen den technischen und fachlichen Prozessmodellen anzustreben. Es existieren Ansätze für eine solche automatisierte Überführung, allerdings sind die realisierten Überführungsstrategien sehr ungenau oder gar nicht beschrieben.
Ziel dieser Arbeit ist Überführungsstrategien zu identifizieren bzw. zu definieren. Dafür ist es notwendig, geeignete technische und fachliche Modellierungsnotationen für die Entwicklung einer Service-orientierten Architektur (SOA) auszuwählen. Auf den geeigneten Überführungsstrategien aufbauend, sollen Überführungsregeln entwickelt werden, die durch eine geeignete Realisierungstechnik prototypisch umzusetzen sind. Damit wird die Funktionsweise der entwickelten Überführungsregeln nachgewiesen. Die Arbeit ist in vier Teile gegliedert. Der erste Teil fokussiert sich auf die Funktionsweise der Service-orientierten Architektur (Kapitel 2 - Service-orientierte Architektur). Dieses Verständnis ist notwendig, um die Anforderungen an eine fachübergreifende Modellierung im Umfeld einer SOA zu identifizieren.
Anhand dieser Anforderungen werden im zweiten Teil dieser Arbeit die verschiedenen Modellierungsnotationen untersucht (Kapitel 3 - Modelle). Ziel ist hierbei die Festlegung auf eine technische und eine fachliche Modellierungsnotation, um diese anschließend zu vergleichen. Dabei stehen die wesentlichen Differenzierungsmerkmale im Mittelpunkt. Auf Grundlage des Vergleiches werden Überführungsstrategien hergeleitet. Im dritten Teil der Arbeit werden diese Überführungsstrategien (Kapitel 4 - Überführung) analysiert und bewertet. Dabei liegt der Schwerpunkt auf der Entwicklung von Überführungsregeln. Im darauf folgenden praktischen Teil der Arbeit (Kapitel 5 - Realisierung) wird eine Überführungsstrategie mit Hilfe einer geeigneten Realisierungstechnik prototypisch implementiert.
Problemstellung:
Die Konzepte der service-orientierten Architektur (SOA) versprechen eine flexible Ausrichtung der IT an die Geschäftsprozesse eines […]
Die Konzepte der Service-orientierten Architektur (SOA) zeigen eine flexible Ausrichtung der IT an den Geschäftsprozessen eines Unternehmens. Typischerweise werden diese Geschäftsprozesse technisch und fachlich modelliert. Um eine effiziente, dauerhafte Ausrichtung der IT an den Geschäftsprozessen zu gewährleisten, müssen die jeweiligen technischen und fachlichen Prozessmodelle konsistent zueinander sein. Zur Sicherung dieser Konsistenz ist eine automatisierte Überführung zwischen den technischen und fachlichen Prozessmodellen anzustreben. Es existieren Ansätze für eine solche automatisierte Überführung, allerdings sind die realisierten Überführungsstrategien sehr ungenau oder gar nicht beschrieben.
Ziel dieser Arbeit ist Überführungsstrategien zu identifizieren bzw. zu definieren. Dafür ist es notwendig, geeignete technische und fachliche Modellierungsnotationen für die Entwicklung einer Service-orientierten Architektur (SOA) auszuwählen. Auf den geeigneten Überführungsstrategien aufbauend, sollen Überführungsregeln entwickelt werden, die durch eine geeignete Realisierungstechnik prototypisch umzusetzen sind. Damit wird die Funktionsweise der entwickelten Überführungsregeln nachgewiesen. Die Arbeit ist in vier Teile gegliedert. Der erste Teil fokussiert sich auf die Funktionsweise der Service-orientierten Architektur (Kapitel 2 - Service-orientierte Architektur). Dieses Verständnis ist notwendig, um die Anforderungen an eine fachübergreifende Modellierung im Umfeld einer SOA zu identifizieren.
Anhand dieser Anforderungen werden im zweiten Teil dieser Arbeit die verschiedenen Modellierungsnotationen untersucht (Kapitel 3 - Modelle). Ziel ist hierbei die Festlegung auf eine technische und eine fachliche Modellierungsnotation, um diese anschließend zu vergleichen. Dabei stehen die wesentlichen Differenzierungsmerkmale im Mittelpunkt. Auf Grundlage des Vergleiches werden Überführungsstrategien hergeleitet. Im dritten Teil der Arbeit werden diese Überführungsstrategien (Kapitel 4 - Überführung) analysiert und bewertet. Dabei liegt der Schwerpunkt auf der Entwicklung von Überführungsregeln. Im darauf folgenden praktischen Teil der Arbeit (Kapitel 5 - Realisierung) wird eine Überführungsstrategie mit Hilfe einer geeigneten Realisierungstechnik prototypisch implementiert.
Problemstellung:
Die Konzepte der service-orientierten Architektur (SOA) versprechen eine flexible Ausrichtung der IT an die Geschäftsprozesse eines […]
Leseprobe
Inhaltsverzeichnis
Christoph Bley
Analyse der Überführbarkeit zwischen fachlichen und technischen Prozessmodellen für
eine service-orientierte Architektur
ISBN: 978-3-8366-0379-9
Druck Diplomica® Verlag GmbH, Hamburg, 2007
Zugl. Technische Universität Dresden, Dresden, Deutschland, Diplomarbeit, 2007
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplom.de, Hamburg 2007
Printed in Germany
Aufgabenstellung
Seite III
Aufgabenstellung
Name, Vorname:
Bley, Christoph
Studiengang:
Informatik
Matr.-Nr.: 2698287
Thema:
Analyse der Überführbarkeit zwischen fachlichen und technischen
Prozessmodellen für eine service-orientierte Architektur
Zielstellung
Die Konzepte der service-orientierten Architektur (SOA) versprechen eine flexible Ausrichtung der
IT an die Geschäftsprozesse eines Unternehmens. Grundprinzip der SOA sind lose gekoppelte,
voneinander unabhängige Dienste (Services).
Durch ihren hohen Standardisierungsgrad bieten sich Webservices zur Realisierung von Services
gerade in heterogenen Systemlandschaften an. Um Geschäftsprozesse flexibel zu unterstützen,
können Webservices mit Hilfe vorwiegend XML-basierter Sprachen zu komplexen Aktivitäten
orchestriert werden.
Für die fachliche Modellierung der Geschäftsprozesse eignen sich solche Sprachen hingegen nicht,
da die erforderlichen technischen Details für die Geschäftsprozessmodellierung zu komplex sind
und technische Aspekte für die fachliche Modellierung keine Rolle spielen. Für die fachliche
Modellierung wird eine Notation benötigt, die von technischen Details abstrahiert und mit der
einfach und flexibel Geschäftsprozessdiagramme (BPD) erstellt werden können.
Die Konsistenz fachlicher und technischer Prozessmodelle ist Voraussetzung für eine effiziente
und dauerhafte Ausrichtung der IT an den Geschäftsprozessen. Um diese Konsistenz zu sichern, ist
eine automatisierte Überführbarkeit zwischen den spezifischen Modellierungssprachen
wünschenswert. Ansätze zur automatisierten Überführung sind vorhanden und auch spezifiziert,
doch werden oft nur einfache Modelle überführt und die Spezifikation ist sehr oberflächlich bis
ungenau. Ziel dieser Arbeit ist es zu analysieren, welche grundsätzlichen
Differenzierungsmerkmale fachlicher und technischer Modellierungsnotationen existieren und in
wieweit ausgewählte Notationen automatisiert in einander überführt werden können. Die
Ergebnisse sollen anhand einer prototypischen Notationsüberführung an einem Beispielprozess
belegt werden.
Schwerpunkte
o
Einordnung fachlicher und technischer Modellierungsnotationen in das Geschäftsprozess-
management (BPM)
o
Identifizierung wesentlicher Differenzierungsmerkmale technischer und fachlicher
Modellierungsnotationen anhand ausgewählter Notationen
o
Analyse der ausgewählten Modellierungsnotationen hinsichtlich ihrer Eignung zur
Transformation
o
Analyse bestehender Transformationsmechanismen auf deren Eignung und ihrer Grenzen
o
Realisierung einer prototypischen Notationsüberführung anhand eines Beispielprozesses
Inhaltsverzeichnis
Seite V
Inhaltsverzeichnis
Aufgabenstellung ... III
Zielstellung ... III
Schwerpunkte ... III
Inhaltsverzeichnis ... V
1
Einleitung ... 1
2
Service-orientierte Architektur ... 3
2.1 Einleitung
...
3
2.2 Grundlagen
...
3
2.3 Architekturebenen
...
6
2.4 Dienste
(Services)
...
7
2.5
Anforderungen der Bereiche ... 9
2.6 SOA
Infrastruktur
...
11
2.7 Realisierungsbeispiel
...
13
2.8 Fazit
... 14
3
Modelle ... 15
3.1 Einleitung
...
15
3.2
Bedeutung des Business Process Management (BPM) ... 15
3.3 Modellierungsnotationen
...
17
3.3.1 Fachliche
Modellnotationen
...
17
3.3.2 Technische
Modellnotationen
...
21
3.4
Bewertung der Modellnotationen ... 25
3.5 Verwendete
Notationen
...
29
3.5.1 Einleitung
... 29
3.5.2 BPMN
...
29
3.5.3 BPEL
... 34
3.5.4 Vergleich
...
37
3.6 Zusammenfassung
...
42
Seite VI
4
Überführung ... 43
4.1 Einleitung
...
43
4.2 Überführungsstrategien
...
43
4.2.1 Einleitung
...
43
4.2.2 Beispielprozess
...
43
4.2.3 Transformation von BPMN zu BPEL ... 44
4.2.4 Transformation von BPEL zu BPMN ... 49
4.2.5 Bewertung
...
52
4.3 Regeln
...
56
4.3.1 Einleitung
...
56
4.3.2 Regeln - Structure Maximization (BPMN zu BPEL) ... 56
4.3.3 Regeln - Flattening (BPEL zu BPMN) ... 58
4.4 Bestehende
Überführungsmechanismen
...
60
4.4.1 Einleitung
...
60
4.4.2 ARIS
Integration
...
60
4.4.3 Oracle
Integration
...
61
4.4.4 SemTalk
Integration
...
61
4.4.5 BABEL
Projekt
...
62
4.4.6 Fazit
... 63
4.5 Zusammenfassung
...
63
5
Realisierung ... 65
5.1 Einleitung
...
65
5.2 Realisierungstechniken
...
65
5.2.1 Einführung
...
65
5.2.2 XSL Transformation (XSLT) ... 65
5.2.3 JAVA
... 67
5.2.4 Model Driven Architecture (MDA) ... 67
5.2.5 Bewertung
...
69
5.3
Voraussetzungen für die MDA Überführung ... 70
5.3.1 Einleitung
...
70
Inhaltsverzeichnis
Seite VII
5.3.2 Metamodelle
...
70
5.3.3 Metamodell
konforme
Ausgangsmodelle
...
72
5.3.4 Überführungssprache
...
73
5.3.5 Entwicklungsumgebung
...
74
5.4 Einordnung
der
Überführungsstrategie
...
74
5.4.1 Einleitung
... 74
5.4.2 Überführungsstrategie
...
74
5.4.3 Abstraktionsstufen
...
75
5.4.4 Modifikation der Metamodelle ... 75
5.5
Umsetzung der Überführungsstrategie ... 77
5.5.1 Einleitung
... 77
5.5.2 Regeln auf Basis der Metamodelle ... 77
5.5.3 Regelrealisierung mit ATL ... 82
5.5.4 Beispielüberführung
...
87
5.6 Bewertung
...
91
5.7 Fazit
... 92
6
Auswertung ... 93
6.1 Zusammenfassung
...
93
6.2 Fazit
... 93
6.3 Ausblick
...
94
6.4 Aufbauende
Forschungsfragen
...
95
Abbildungsverzeichnis ... IX
Tabellenverzeichnis ... XI
Verzeichnis der Quellcodesequenzen ... XII
Abkürzungsverzeichnis ... XIII
Literaturverzeichnis ... XV
Anhang ... XXI
A.1
BPMN Flow Objects Spezialisierung ... XXI
A.1.1 Event Spezialisierung ... XXI
A.1.2 Activity Spezialisierung ... XXII
Seite VIII
A.1.3 Gateway Spezialisierung ... XXIII
A.2
BPEL - Activitites ... XXV
A.3
Vergleich BPMN und BPEL ... XXVII
A.3.1 Vergleich Darstellungsformen (BWW Modell) ... XXVII
A.3.2 Vergleich des Arbeitsflusses ... XXVIII
A.4 Überführungsstrategien
...
XXXI
A.4.1 Überführungsstrategie Structure Maximization ... XXXI
A.4.2 Überführungsstrategie Flattening
...
XXXIV
A.5 Prototypische
Realisierung
...
XXXVII
A.5.1 ATL Überführungsregeln ... XXXVII
A.5.2 Ausgangsmodell - BPMN Beispielprozess (Versandprozess) ... XLII
A.5.3 Zielmodell - BPEL Beispielprozess (Versandprozess) ... XLIV
Abbildungsverzeichnis Anhang ... XLIX
Tabellenverzeichnis Anhang ... L
Verzeichnis der Quellodesequenzen Anhang ... LI
1 Einleitung
Seite 1
1 Einleitung
Die Konzepte der Service-orientierten Architektur (SOA) zeigen eine flexible Ausrichtung
der IT an den Geschäftsprozessen eines Unternehmens. Typischerweise werden diese
Geschäftsprozesse technisch und fachlich modelliert. Um eine effiziente, dauerhafte
Ausrichtung der IT an den Geschäftsprozessen zu gewährleisten, müssen die jeweiligen
technischen und fachlichen Prozessmodelle konsistent zueinander sein. Zur Sicherung
dieser Konsistenz ist eine automatisierte Überführung zwischen den technischen und
fachlichen Prozessmodellen anzustreben. Es existieren Ansätze für eine solche
automatisierte Überführung, allerdings sind die realisierten Überführungsstrategien sehr
ungenau oder gar nicht beschrieben.
Ziel dieser Arbeit ist Überführungsstrategien zu identifizieren bzw. zu definieren. Dafür ist
es notwendig, geeignete technische und fachliche Modellierungsnotationen für die
Entwicklung einer Service-orientierten Architektur (SOA) auszuwählen. Auf den
geeigneten Überführungsstrategien aufbauend, sollen Überführungsregeln entwickelt
werden, die durch eine geeignete Realisierungstechnik prototypisch umzusetzen sind.
Damit wird die Funktionsweise der entwickelten Überführungsregeln nachgewiesen.
Die Arbeit ist in vier Teile gegliedert. Der erste Teil fokussiert sich auf die Funktionsweise
der Service-orientierten Architektur (Kapitel 2 - Service-orientierte Architektur). Dieses
Verständnis ist notwendig, um die Anforderungen an eine fachübergreifende Modellierung
im Umfeld einer SOA zu identifizieren. Anhand dieser Anforderungen werden im zweiten
Teil dieser Arbeit die verschiedenen Modellierungsnotationen untersucht (Kapitel 3 -
Modelle). Ziel ist hierbei die Festlegung auf eine technische und eine fachliche
Modellierungsnotation, um diese anschließend zu vergleichen. Dabei stehen die
wesentlichen Differenzierungsmerkmale im Mittelpunkt. Auf Grundlage des Vergleiches
werden Überführungsstrategien hergeleitet. Im dritten Teil der Arbeit werden diese
Überführungsstrategien (Kapitel 4 - Überführung) analysiert und bewertet. Dabei liegt der
Schwerpunkt auf der Entwicklung von Überführungsregeln. Im darauf folgenden
praktischen Teil der Arbeit (Kapitel 5 - Realisierung) wird eine Überführungsstrategie mit
Hilfe einer geeigneten Realisierungstechnik prototypisch implementiert.
2 Service-orientierte Architektur
Seite 3
2 Service-orientierte Architektur
2.1 Einleitung
In diesem Kapitel wird der Aufbau und die Funktionsweise einer Service-orientierten
Architektur (SOA) erklärt. Zu diesem Zweck werden zunächst die Grundlagen dargestellt,
um darauf aufbauend eine SOA zu definieren. Anhand der verschiedenen
Architekturebenen und Betrachtungsweisen auf eine SOA werden die Anforderungen an
die Entwicklung einer SOA umrissen. Auf diesen Erkenntnissen baut das Kapitel 3 auf.
Nachdem die Infrastruktur vorgestellt und einzelne Elemente veranschaulicht wurden, wird
die Umsetzung bzw. Realisierung einer SOA exemplarisch gezeigt. Das Kapitel endet mit
einem Fazit.
2.2 Grundlagen
Die Anforderungen an die heutige Informationstechnik werden immer komplexer. Um den
wirtschaftlichen Erfolg des Unternehmens nicht zu gefährden, müssen Veränderungen
schnell, effizient und kostengünstig umgesetzt werden. Typischerweise stehen die
implementierten Funktionalitäten jeweils nur in einem in sich geschlossenen System zur
Verfügung. Die Kommunikation und der Austausch zwischen solchen Systemen gestaltet
sich oft problematisch und ist mit einem hohen Aufwand verbunden (Abbildung 2-1).
Dadurch sind wertvolle Funktionalitäten in ihren Systemen isoliert und müssen
unnötigerweise mehrfach entwickelt werden. Gleichzeitig kann die Informationstechnik
zur Automatisierung von Unternehmensabläufen genutzt werden. Diese Arbeitsabläufe
(Prozesse) überschreiten jedoch inzwischen die Grenzen einzelner Anwendungen oder gar
die des Unternehmens. Solche übergreifende Prozesse zu automatisieren ist schwierig und
teuer.
Funktionen
monolithische
Systeme
System 1
System 2
übergreifender
Prozess
geschlossener
Prozess
Black
Box
Abbildung 2-1 : Klassische Informationstechnik logische Sicht
Seite 4
Mit der traditionellen Informationstechnik kann eine solche Automatisierung nur mit viel
Aufwand realisiert werden (S.15, [Woo04]). Die Lösung liegt in einer Service-orientierten
Architektur. In diesem Architekturparadigma werden die Funktionalitäten aus den in sich
geschlossenen Systemen herausgelöst und in einzelne Dienste (Services) gekapselt. Durch
die Kapselung der Funktionalität und der Verwendung von einheitlich, standardisierten
Schnittstellen können die Services lose miteinander gekoppelt und damit deren
Wiederverwendung gesteigert werden (Abbildung 2-2). Unter diesem Gesichtspunkt kann
eine SOA folgendermaßen definiert werden:
"An enterprise-wide IT architecture that promotes loose coupling, reuse, and
interoperability services between systems." (S. 4, [BBF
+
05])
Funktionen
monolithische
Systeme
System 1
System 2
übergreifender
Prozess
geschlossener
Prozess
Abbildung 2-2 : SOA Architekturparadigma
Eine SOA besteht aber nicht nur aus den Services (vgl. Abbildung 2-3), sondern ist ein
Konzept einer Softwarearchitektur, in deren Zentrum das Anbieten, Suchen und Nutzen
von Services über ein Netzwerk steht (S.7, [DJM
+
05]). Die Services werden von
Anwendungen oder anderen Services genutzt, wobei es unerheblich ist, welche Hard- oder
Software, Programmiersprache oder welches Betriebssystem die einzelnen Beteiligten
verwenden. Vielmehr ist die Unabhängigkeit von der jeweiligen Implementierung Voraus-
setzung für eine prozessorientierte Zerlegung, um somit eine unabhängige Kombination zu
ermöglichen, die nicht durch hardware- oder softwarespezifische Details beschränkt wird.
Durch einheitliche Standards ist es möglich mit entsprechenden Suchfunktionen die
Services in einem Service-Repository zu finden und anzubieten. Ein weiteres
Infrastrukturelement einer SOA neben dem Service-Repository ist der Service-Bus mit
dessen Hilfe der Datenfluss zwischen den Kommunikationspartnern einfach und
protokollunabhängig realisiert werden kann.
2 Service-orientierte Architektur
Seite 5
Eine SOA benötigt nicht zwingend alle Infrastrukturelemente und kommt beispielsweise.
auch ohne einen Service-Bus aus. Durch Einbeziehen der Infrastrukturelemente wird eine
SOA wie folgt definiert:
"A Service-Oriented Architecture (SOA) is a software architecture that is based on the key
concepts of an application frontend, service, service repository, and service bus. A service
consists of a contract, one or more interfaces, and an implementation." (S.57, [KBS05])
Service
Contract
Interface
Implementation
Data
Business Logic
Abbildung 2-3 : Service Strukturmodell
Die zuvor angesprochenen Probleme heutiger Informationstechnik lassen sich nicht allein
durch technische Maßnahmen lösen. Damit übergreifende Unternehmensprozesse
automatisiert werden können, ist es ebenfalls nötig die Funktionalität eines Services
hinsichtlich betriebswirtschaftlicher Gesichtspunkte zu beleuchten. Diese Funktionalitäten
sind prozessorientiert, und deshalb stehen die Unternehmensprozesse oder auch
Geschäftsprozesse im Mittelpunkt des organisatorischen Denkens. Ziel ist es, die Services
nicht auf der Grundlage technischer Funktionen zu entwickeln sondern auf Basis der
Wertschöpfung des zugrunde liegenden Prozesses. Somit verkörpern die Services
Prozessfragmente, die einfach bei Veränderung des Prozesses durch Komposition und
Koordination flexibel neu kombiniert werden können. Aus betriebswirtschaftlicher Sicht,
unter der Voraussetzung der nötigen fachlichen und prozessorientierten Ausrichtung der
Services, lässt sich eine SOA wie folgt definieren:
"A set of business, process, organizational, governance, and technical methods to reduce
or eliminate frustration with IT and to quantifiably measure the business value of IT while
creating an agile business environment for competitive advantage." (S. 4, [BBF
+
05])
SOA ist demnach ein Architekturparadigma mit technischen und fachlichen Facetten,
welches diskrete Leistungen vorhandener Informationstechnik über Services zur
Verfügung stellt. Das übergeordnete Ziel ist diese Leistungen entsprechend des
Seite 6
Wertschöpfungsprozesses eines Unternehmens flexibel zu komplexen Prozessen
zusammen zustellen. Dabei wird die technische Realisierung ausgeblendet und stattdessen
die Koordination von fachlichen Funktionen in den Mittelpunkt gerückt. Die SOA verfolgt,
mit Hilfe modularer und flexibilisierter Services, das Ziel, die Anpassungsfähigkeit und die
kontinuierliche Produktverbesserung mit der Informationstechnik zu unterstützen und
somit die Unternehmensproduktivität zu steigern.
Im folgenden Abschnitt werden auf der Grundlage des Wertschöpfungsprozesses die
Architekturebenen eingeführt.
2.3 Architekturebenen
Eine Architektur stellt ein Rahmenwerk zur Verfügung, welche die vom Unternehmen zur
Erreichung seiner Ziele benötigte Plattform definiert und beschreibt [Jen99]. Um das
Unternehmensziel zu erreichen, werden Produkte und Leistungen auf Basis der
Geschäftsstrategie des Unternehmens entwickelt und dem Kunden angeboten. Anhand des
Wertschöpfungsprozesses (vgl. Abbildung 2-4) wird deutlich, inwieweit die Geschäfts-
prozesse, die Anwendungssysteme und letztendlich die IT-Infrastruktur benötigt werden,
um das Unternehmensziel zu erreichen.
Produkte
Prozesse
Anwendung
IT - Infrastruktur
Produkte und Leistungen die auf Basis
der Geschäftsstrategie den
Kunden angeboten werden
Geschäftsprozesse, die notwendig sind,
die Produkte und Leistungen
für den Kunden zu erbringen
Anwendungssysteme, die die IT-technische
Umsetzung der Funktionalität
der Geschäftsprozesse unterstützt
IT-Infrastruktur mit Netzwerken, Hardware und
Betriebssystemen, die zur operativen Nutzung
der Anwendungssysteme notwendig sind.
Bede
utun
g v
on S
tr
ategie
u
nd
We
ttbe
w
erb
hoch
niedrig
Abbildung 2-4 : Wertschöpfungsprozess (S. 13 [Kri05])
Eine korrespondierende Unternehmensarchitektur muss dementsprechend aus mehreren,
miteinander in Beziehung stehenden und aufeinander abgestimmten Architekturebenen
bestehen. Jede Ebene verkörpert analog des Wertschöpfungsprozesses eine bestimmte
Sicht, an die jeweils bestimmte Anforderungen gestellt werden. Die vierschichtige
Architektur besteht aus einer Geschäfts-, einer Informations-, einer Applikations- und einer
Infrastruktur-Architektur. Hierbei betreut der fachliche Bereich die Geschäfts- und
Informationsarchitektur, wohingegen der technische Bereich bzw. der IT-Bereich die
2 Service-orientierte Architektur
Seite 7
Applikations- und Infrastrukturarchitektur beaufsichtigt. Ähnlich dem Wertschöpfungs-
prozess (Abbildung 2-4) stehen bei der Unternehmensarchitektur die jeweiligen Ebenen in
Abhängigkeit zueinander. Das führt dazu, dass Anforderungen und Erwartungen an die
Geschäftsarchitektur gleichzeitig auch bestimmte Anforderungen an die darunter liegenden
Ebenen nach sich ziehen. Werden z.B. Kostensenkungen gefordert, hat dies Auswirkungen
auf alle Ebenen. Erfolgt beispielsweise auf der Ebene der Geschäftsarchitektur eine
Optimierung, so muss diese auch in den darunter liegenden Ebenen zum tragen kommen.
Letztlich wird deutlich, dass Änderungen die auf einer Ebene angestrebt werden, die
Betrachtung dieser und der darunter liegenden Ebenen einschließt. Daraus folgt das eine
Zusammenarbeit zwischen Fach- und IT-Bereich nötigt ist.
Geschäftsarchitektur
Informationsarchitektur
Applikationsarchitektur
Infrastruktur-Architektur
Beschreibt die Geschäftprozesse mit
funktionalen und operativen Eigenschaften
Beschreibt die Geschäftsdaten und
deren Beziehungen zueinander.
Beschreibt die IT-Applikationen, die für
die Geschäfts-Architektur notwendig sind.
Basisumgebung für die IT-Applikationen.
Abbildung 2-5 : Architekturebenen (in Anlehnung an [Jen99])
Aufbauend auf die festgelegten Architekturebenen (vgl. Abbildung 2-5) und deren
Betreuung durch den Fach- und IT-Bereich widmet sich der folgende Abschnitt den
Diensten (Services) einer SOA.
2.4 Dienste (Services)
Mit Services werden diskrete Leistungen zur Verfügung gestellt. Diese Leistungen
verkörpern unter betriebswirtschaftlichen Gesichtspunkten Prozessfragmente und bilden
damit die Basis einer SOA. Entsprechend des Wertschöpfungsprozesses des Unternehmens
werden diese Prozessfragmente flexibel zu komplexen Unternehmens- bzw. Geschäfts-
prozessen zusammengestellt. Der modulare Aufbau und die standardisierten Schnittstellen
der Services ermöglichen durch Neukombination oder Austausch von Services eine sehr
schnelle und flexible Veränderung der Geschäftsprozesse. Unter Geschäftsprozessen sind
Transaktionen oder eine planmäßige Folge von Transaktionen zwischen betrieblichen
Objekten im Rahmen der Leistungserzeugung zu verstehen. Transaktionen können hierbei
in Wechselwirkung mit einem oder mehreren Objekten bzw. Daten stehen [Mie02]. Neben
Seite 8
den standardisierten Schnittstellen beinhaltet der Service außerdem die eigentliche
Implementierung und einen Contract (vgl. Abbildung 2-3). Der Contract ist eine Art
Servicebeschreibung, in dem die Schnittstellen und Funktionen, die der Service anbietet,
beschrieben werden. Diese Beschreibung ist unabhängig von der Implementierung, der
verwendeten Programmiersprache sowie der Plattform (S. 13, [DJM
+
05]). Dadurch wird
das ,,Information Hiding" also die Kapselung der eigentlichen Implementierung
gewährleistet. Die Implementierung ist die technische Realisierung des Contract. Durch
das Interface werden die angebotenen Funktionen anderen Services oder Applikationen
gemäß der Schnittstellenbeschreibung zur Verfügung gestellt. Dabei ist die technische
Realisierung aber nicht das Schwierige bei der Serviceentwicklung. Viel schwieriger
erscheint die Tatsache, dass die von einem Service angebotenen Funktionalitäten auch
betriebswirtschaftlichen Gesichtspunkten genügen müssen. Im Mittelpunkt steht demnach
nicht die technische Realisierung sondern die prozessorientierte Ausrichtung. Damit dies
gelingt, muss der fachliche Bereich die jeweiligen Prozessfragmente identifizieren, deren
Funktion ein Service übernehmen soll. Die Entwicklung eines Service wird demzufolge
vom fachlichen Bereich angestoßen.
Geschäftsarchitektur
Informationsarchitektur
Applikationsarchitektur
Infrastruktur-Architektur
Fachliche Komponente
,
die einen geschäftlichen Wert mit
unternehmensweitem Nutzen anbietet.
Fachliche Komponente
,
anhand deren Geschäftsmetriken
unmittelbar nachvollzogen werden können.
Technische Komponente
,
die den geschäftlichen Wert der Anwendung
wohl definiert verfügbar macht.
Technische Komponente
,
zur standardisierten Kommunikation
zwischen verschiedenen Endpunkten.
Komponente, die eine
wohl definierte gekapselte Funktionalität
Über eine
standardisierte Schnittstelle
anbietet und
die
Brücke zwischen IT und Fachseite
bildet.
Service
Abbildung 2-6 : Erwartungen an einen SOA Service
Ausgehend von der Geschäftsarchitektur durchläuft der Service alle darunter liegenden
Ebenen, bis er letztendlich in der Infrastrukturarchitektur durch den technischen Bereich
(IT-Bereich) umgesetzt wird (vgl. Abbildung 2-6). Durch die fachliche Ausrichtung der
Funktionalität der Services und die technische Realisierung bildet der Service eine
wesentliche Brücke zwischen dem Fach- und dem IT-Bereich. Bei der Identifizierung der
Services durch den fachlichen Bereich und der anschließenden Implementierung durch den
IT-Bereich werden unterschiedliche Modellierungswerkzeuge eingesetzt. Diese sind den
Anforderungen, Bedürfnissen und Gewohnheiten der jeweiligen Bereiche angepasst.
Häufig sind für den technischen Bereich fachliche Aspekte irrelevant und umgekehrt
2 Service-orientierte Architektur
Seite 9
liegen technische Details nicht im Fokus des fachlichen Bereiches. Das birgt die Gefahr,
dass unabhängig voneinander und somit auch aneinander vorbei entwickelt wird. Um
dieser Entwicklung entgegen zutreten, erscheint es unabdingbar, dass der fachliche und
technische Bereich bei der Modellierung von Services stärker zusammenarbeiten. Eine
einheitliche Modellierung kann nur erreicht werden, wenn anhand der unterschiedlichen
Anforderungen eine gemeinsame Basis geschaffen wird. Die Anforderungen der jeweiligen
Bereiche sind Inhalt des folgenden Abschnittes.
2.5 Anforderungen der Bereiche
Wie im vorhergehenden Abschnitt gezeigt wurde, ist die Serviceentwicklung eine
ebenenübergreifende Entwicklung, an welcher der fachliche und der technische Bereich
gleichermaßen beteiligt sind. Im Zuge der Geschäftsprozessmodellierung, die durch den
fachlichen Bereich angestoßen wird, werden alle relevanten Aspekte eines Geschäfts-
prozesses in einer Beschreibungssprache dargestellt bzw. beschrieben. An eine solche
Beschreibungssprache werden abhängig von der Motivation des jeweiligen Bereiches
unterschiedliche Anforderungen gestellt. Der fachliche Bereich nutzt diese Beschreibungs-
sprache um ausgehend von der Geschäftsarchitektur betriebswirtschaftliche Funktionen
eines Services zu identifizieren und zu dokumentieren. Weiterhin werden solche Prozess-
modelle zur Reorganisation und Optimierung von Prozessen eingesetzt und unterstützen
damit die Organisationsgestaltung (Abbildung 2-7).
Organisationsgestaltung
Anwendungssystemgestaltung
Organisations-
dokumentation
Auswahl von
ERP-Software
Prozessorientierte
Reorganisation
Kontinuierliches
Prozess-
management
Zertifizierung
Benchmarking
Wissens-
management
Modellbasiertes
Customizing
Software-
entwicklung
Workflow-
management
Simulation
Abbildung 2-7 : Einsatzzwecke von Prozessmodellen [Hin05]
Der technische Bereich beschäftigt sich hingegen maßgeblich mit der Implementierung der
Services und der damit verbundenen Simulation. Das Augenmerk liegt hierbei auf der
Anwendungssystemgestaltung. Bedingt durch diese verschiedenen Modellierungsziele und
die verschiedenen Verwendungszwecke ergeben sich unterschiedliche Anforderungen der
jeweiligen Bereiche an die Geschäftsprozessmodellierung.
Seite 10
Verwendungszweck
Anforderung
Prozessorientierte
Reorganisation
anschauliche Prozesse um Schwachstellen erkennen zu
können (Struktur, Leistung)
Organisationsdokumentation Transparenz
über
Prozesse herstellen, intuitive Modelle
(Verständlichkeit)
Zertifizierung Modellverwaltung
in
zentralen Repository, intuitive
Modelle, eindeutige Modellierung
Kontinuierliches
Prozessmanagement
Prozess-Controlling, z.B. Zeitvorgaben je Funktion und
möglichst automatisierte Aktualisierung der IST- Werte
Tabelle 2-1 : Fachliche Anforderungen an Prozessmodelle [Hin05]
Wie in Tabelle 2-1 ersichtlich, fordert der fachliche Bereich im Zuge einer prozess-
orientierten Reorganisation anschauliche Prozesse, um die Schwachstellen besser erkennen
zu können. Bei der Softwareentwicklung ist dem technischen Bereich hingegen wichtig,
dass detaillierte Attribute oder Datenstrukturen in dem Modell beschrieben werden,
wohingegen betriebswirtschaftliche Faktoren kaum Beachtung finden. Die daraus
abgeleiteten Anforderungen unter Berücksichtigung des Verwendungszwecks werden in
Tabelle 2-1 für den fachlichen Bereich und für den technischen Bereich in Tabelle 2-2
aufgeführt.
Verwendungszweck
Anforderung
Simulation Zeit-,
Mengen-
und
Kostendaten, Verteilungen
Workflowmanagement hohe
Granularität: Input- und Outputdaten, incl.
Datenstrukturen, Applikationen
Auswahl von ERP-Software Vergleichbarkeit mit Prozessmodellen der ERP-Software
Software - Entwicklung
Requirements Engineering: detaillierte Attribute,
Datenstrukturen etc, weniger betriebswirtschaftliche
Faktoren
Tabelle 2-2 : Technische Anforderungen an Prozessmodelle [Hin05]
Daraus lassen sich für die fachübergreifende Modellierung der Services folgende
Anforderungen der jeweiligen Seiten formulieren:
Fachliche Anforderungen
Der fachliche Bereich setzt die Modellierung einerseits zur Identifizierung von Services
ein und andererseits um Prozesse zu reorganisieren, zu dokumentieren und kontinuierlich
zu managen. Abgeleitet aus der Tabelle 2-1 ergeben sich daraus die Anforderungen nach
Veranschaulichung der Prozesse zur Reorganisation (Ausdrucksmächtigkeit),
Transparenz und Verständlichkeit zur Dokumentation (Visualisierbarkeit) und
Prozesscontrolling zum Prozessmanagement (Formalisierbarkeit).
2 Service-orientierte Architektur
Seite 11
Technische Anforderungen
Die Anforderungen des technischen Bereichs werden aus der Tabelle 2-2 abgeleitet. Die
Prozessmodellierung wird hierbei für die Simulation und Ausführung (Ausführbarkeit/
Simulation) von Prozessmodellen, bestehend aus Services, genutzt. Weiterhin fordert der
technische Bereich die Analyse der Modelle (Analyse/ Validierbarkeit) und letztendlich
wird vom technischen Bereich die Werkzeugunterstützung bzw. methodische
Unterstützung (Entwicklungsunterstützung) gefordert. Daraus ergeben sich pro Bereich
folgende spezifische Anforderungen an eine Modellierungssprache bzw. an eine
Modellierungsnotation (Tabelle 2-3).
Fachliche Anforderungen
Technische Anforderungen
· Ausdrucksmächtigkeit
· Visualisierbarkeit
· Formalisierbarkeit
· Ausführbarkeit / Simulation
· Analyse / Validierbarkeit
· Entwicklungsunterstützung
Tabelle 2-3 : abgeleitete Anforderungen an Prozessmodelle
Um eine bereichsübergreifende Modellierung einer SOA zu ermöglichen, bedarf es einer
Modellnotation für den fachlichen und technischen Bereich. Das Kapitel 3 befasst sich
ausführlich mit möglichen Modellierungsnotationen.
Abschließend erscheint es für das Verständnis richtig und sinnvoll die Infrastruktur und
den architektonischen Aufbau einer SOA näher darzustellen und an einem Realisierungs-
beispiel nochmals zu verdeutlichen.
2.6 SOA Infrastruktur
Dieser Abschnitt hat den Aufbau einer SOA als Inhalt und soll die Rolle der einzelnen
Infrastrukturelemente verdeutlichen. Beleuchtet werden dabei das Zusammenspiel der
Elemente und deren Bedeutung für eine SOA. Im Mittelpunkt einer SOA stehen die
Services, welche über ein Netzwerk gesucht, angeboten und genutzt werden können. Dabei
bietet der Service Provider die jeweiligen Services an und die Service Consumer nutzen
diese. In Abbildung 2-8 wird dieser logische Zusammenhang verdeutlicht und es wird
erkennbar, dass durch Services verborgene Funktionalitäten aus den Anwendungen heraus-
gelöst werden können. Die Anwendung agiert dabei als Service Provider, welcher alle
Funktionalitäten der Anwendung als Service veröffentlicht und somit eine
providerübergreifende Nutzung ermöglicht. Diese Basis-Services können einerseits direkt
genutzt oder andererseits zu komplexeren Services zusammengestellt werden. Zusammen-
gesetzte Services werden von Service Consumern genauso genutzt wie Basis-Services.
Durch die unterschiedliche Markierung der Basis-Services in Abbildung 2-8 wird die
redundante und providerübergreifende Nutzung der Services verdeutlicht und dadurch
Seite 12
besser nachvollziehbar. Service Consumer können wiederum Anwendungen, Portale oder
auch Geschäftspartner sein.
Service
Consumer
Basis
Service
Service
Orchestrierung
Service
Provider
B2B-Partner
Portal
Anwendung
Anwendung 1
Anwendung 2
Anwendung 3
Abbildung 2-8 : Architekturskizze einer SOA logische Sicht
Wie bereits dargestellt, betrachtet die logische Sicht den Zusammenhang zwischen Service
Consumer und Service Provider. Mit Hilfe der Systemsicht wird hingegen der Zusammen-
hang zwischen fachlichen und technischen Prozessen geklärt sowie Infrastrukturelemente
wie beispielsweise der Enterprise Service Bus (ESB) eingeordnet. Auf der Grundlage des
fachlichen Prozesses werden jene Prozessteile identifiziert, die durch Informationstechnik
realisiert werden sollen. Abhängig von der Komplexität kann dieser Prozessteil weiter in
Prozessfragmente (in Abbildung 2-9 als Quadrat symbolisiert) zerlegt werden. Diese
Fragmente besitzen wiederum eine technische Repräsentation als Service (in Abbildung
2-9 als Kreis symbolisiert). Abhängig von der fachlichen Zusammensetzung der Prozess-
fragmente werden auf der technischen Seite die korrespondierenden Services kombiniert.
Diese fachübergreifende Koordination von fachlichen und deren korrespondierenden
technischen Prozessen wird durch das Business Prozess Management (BPM) unterstützt
bzw. realisiert.
Unterstützend greift auch der Enterprise Service Bus als intelligentes Routingwerkzeug
ein. Der ESB ist für die Koordination des Datenflusses zuständig und wird auch als
Integrationsnetz (S. 20, [DJM
+
05]) bezeichnet. Durch Datentransformation und Protokoll-
unabhängigkeit wird es jedem Service ermöglicht, der auf das Netzwerk zugreifen kann,
den ESB zu nutzen. Die zentrale Aufgabe eines ESB ist es mittels virtueller Kanäle eine
günstige Topologie zwischen den Services zu ermöglichen. Dadurch ist es möglich, dass
ein Service nur noch eine Verbindung zum ESB benötigt und somit ein n:m
Verbindungsaufbau zwischen den Services unnötig wird. Ein Enterprise Service Bus ist
2 Service-orientierte Architektur
Seite 13
wie das Business Process Management aber nur ein unterstützendes Infrastrukturelement,
das für eine SOA Umsetzung nicht zwingend benötigt wird.
technischer
Prozess-
Ablauf
Verteilung
technischer
Prozess
Aufbau
Services
Provider
Workflow - Engine
EJB
Legacy Systeme
Datenbanken
Prozess-Engine
Prozess-Engine
Enterprise Service Bus
BPM
Abbildung 2-9 : Architekturskizze einer SOA System-Sicht
1
2.7 Realisierungsbeispiel
In diesem Abschnitt wird die Realisierung einer SOA anhand der Web Service Architektur
kurz erläutert. Dabei werden auf die einzelnen Bestandteile und deren Funktion einer Web
Service basierten Umsetzung eingegangen.
Wie bereits die Namensverwandtschaft schlussfolgern lässt, werden die Web Services zur
Realisierung von SOA Services eingesetzt. Unter Web Services wird dabei eine
standardisierte Softwaretechnologie verstanden mit deren Hilfe eingebettete Software-
funktionen für eine breite Anzahl von Nutzern geöffnet werden können. Damit eignen sich
Web Service sehr gut zur Realisierung von SOA Services. Da das Anbieten, Suchen und
Nutzen eines Services über ein Netzwerk bei einer SOA im Mittelpunkt steht, werden bei
der Realisierung mittels Web Services entsprechende Komponenten für Kommunikation,
Dienstbeschreibung und Verzeichnisdienst benötigt. Eine mögliche Realisierung der
notwendigen Komponenten in einer Web Service Architektur wäre hinsichtlich der
Kommunikation das SOAP Protokoll (Simple Object Access Protocol), für die Dienst-
beschreibung der Web Services bietet sich die WSDL-Sprache (Web Service Definition
Language) an und ein nötiger Verzeichnisdienst könnte durch UDDI (Universal
Description, Discovery and Integration Protocol) realisiert werden. Die genannten
Realisierungsformen sind als Beispiel zu verstehen, da durch die Vielzahl von
Spezifikationen im Umfeld der Web Services verschiedene Realisierungen möglich sind.
1
Durch den technischen Prozess wird die nötige Komposition der jeweiligen Services dargestellt, diese sind
durch entsprechende Markierungen den physischen Services des jeweiligen Providers zugeordnet.
Seite 14
Ein mögliches Anwendungsszenario wäre das der Dienstnutzer, welcher die
Servicebeschreibung (WSDL) beim Verzeichnisdienst (UDDI) sucht und nach der
Initialisierung der Schnittstellen über das XML-basierte Nachrichtenprotokoll SOAP mit
dem Service interagiert.
Durch die Vielzahl von Spezifikationen im Umfeld der Web Service Architektur und die
Plattformunabhängigkeit mittels XML (eXtensible Markup Language) bietet sich die SOA-
Realisierung mittels Web Service Architektur an. Weitere Informationen zur einer Web
Service basierten SOA Umsetzung können in dem Buch ,,Service-orientierte Architekturen
mit Web Services" [DJM
+
05] und den jeweiligen Spezifikationen nachgeschlagen werden.
2.8 Fazit
Mit Hilfe der Service-orientierten Architektur werden Geschäftsprozesse unter
betriebswirtschaftlichen Gesichtspunkten in der Informationstechnik abgebildet. Durch die
Services werden Funktionen aus monolithischen Systemen herausgelöst und
plattformübergreifend zur Verfügung gestellt. Dadurch lassen sich Funktionalitäten wieder
verwenden. Durch den modularen Aufbau dieser Services kann eine fachliche Änderung
des Prozesses schnell durch Neukombination von Services in der Informationstechnik
abgebildet werden. Dafür ist es aber notwendig, dass die Funktionalitäten eines Services
betriebswirtschaftlich ausgerichtet sind. Damit dies gelingt ist eine enge Zusammenarbeit
zwischen fachlichem und technischem Bereich bei der Entwicklung von Services
notwendig. Aufgrund der unterschiedlichen Motivationshintergründe der jeweiligen
Bereiche ergeben sich unterschiedliche Anforderungen an eine Service Entwicklung. Das
Infrastrukturelement BPM kann bei einer bereichsübergreifenden Entwicklung der
Services helfen. Auf Grundlage der Erkenntnisse dieses Kapitels beschäftigt sich das
Kapitel 3 mit den verschiedenen Modellierungsmöglichkeiten der jeweiligen Bereiche.
Darauf aufbauend soll anschließend mit Hilfe des BPM eine bereichsübergreifende
Modellierungsmöglichkeit gefunden und untersuchen werden.
3 Modelle
Seite 15
3 Modelle
3.1 Einleitung
Das Kapitel 2 bot einen Überblick über die Service-orientierte Architektur. Als zentrale
Merkmale einer SOA wurden herausgearbeitet, dass erstens die Geschäftsprozesse im
Mittelpunkt stehen und zweitens diese Prozesse durch Zusammenstellung von Services
realisiert werden. Bei der Zusammenstellung dieser Services und der entsprechenden
Prozesse werden durch den fachlichen und technischen Bereich unterschiedliche
Beschreibungssprachen verwendet. Mit diesen Beschreibungssprachen oder auch
Modellierungsnotationen ist es möglich Modelle mit fachlicher bzw. technischer
Ausprägung zu erstellen. Schwerpunkt dieses Kapitels sind die bereichstypischen
Modellnotationen und deren Modelle. Dabei wird besonders auf die Unterstützung durch
das Business Process Management eingegangen. Abschnitt 3.3 soll einen Überblick über
die jeweiligen Modellnationen geben. Anschließend wird die Tauglichkeit zur bereichs-
übergreifenden Modellierung im Umfeld einer SOA untersucht. Ziel ist es eine geeignete
fachliche und technische Modellierungsnotation zu finden, welche die Anforderungen des
jeweiligen Bereiches erfüllen, um darauf aufbauend eine bereichsübergreifende
Modellierung zu ermöglichen.
3.2 Bedeutung des Business Process Management (BPM)
Mit dem Business Process Management wird seitens des fachlichen Bereiches die Vision
einer von der IT losgelösten Prozessmodellierung und Prozesszusammenstellung verfolgt.
Durch geeignete BPM Tools (z.B. Process Engines) wird das entstehende Prozessmodell
abgearbeitet und zur Ausführung gebracht. Diese Tools kombinieren entsprechend dem
Prozessmodell die physischen Services miteinander. Somit baut das BPM auf der SOA auf.
Der fachliche Bereich ist bei Prozessänderungen nicht mehr auf die IT angewiesen, da die
Modellumsetzung von BPM Tools übernommen wird. Damit schrumpft die Bedeutung der
herkömmlichen Programmierung und Applikationsentwicklung, denn Prozessänderungen
werden durch die Ausführungstools in die IT abgebildet. In dieser visionären Idee soll sich
die IT nur noch mit der Implementierung der Services beschäftigen. Damit kann diese
zugegeben radikale Vision als: ,,Don't bridge the business-IT divide obliterate it" [SF03]
bezeichnet werden.
Diese rein fachliche Umsetzung von Prozessmodellen lässt sich aber nicht so einfach
realisieren, da die BPM Ausführungstools nur Modelle mit ausreichenden technischen
Details sinnvoll umsetzen können. Somit ist eine Modellüberführung ohne technische
Unterstützung zumindest gegenwärtig nicht möglich. Der technische Bereich wird also
dazu benötigt, die durch den fachlichen Bereich modellierten Modelle mit den nötigen
technischen Details anzureichern, damit die BPM Ausführungstools dieses Modell sinnvoll
umsetzen können. Hierbei ist es üblich, dass der technische Bereich auf Grundlage des
fachlichen Prozessmodells ein neues technisches Prozessmodell entwickelt, welches durch
Seite 16
eine Prozess Engine abgearbeitet bzw. ausgeführt wird. Bei der Modellneuentwicklung
durch den technischen Bereich entstehen Überführungsfehler, da durch die technische
Fokussierung notwendige fachliche Merkmale nicht berücksichtigt werden. Die Vision
einer BPM liegt darin, die Prozessmodelle in der IT ohne Überführungsfehler abzubilden.
Durch eine manuelle Überführung der Prozessmodelle ist dies jedoch nur sehr bedingt
möglich.
Dieses Problem könnte durch eine einheitliche Modellnotation gelöst werden, die sowohl
vom fachlichen als auch vom technischen Bereich genutzt wird. Damit wäre eine
Überführung hinfällig und Überführungsfehler könnten nicht auftreten. Durch die Ver-
wendung eines einheitlichen Modellierungswerkzeuges werden jedoch die verschiedenen
Anforderungen der jeweiligen Bereiche nur bedingt erfüllt. Aus diesem Grund ist es ratsam
jeweils ein Werkzeug für jeden Bereich einzusetzen. Diese spezialisierten Modellierungs-
werkzeuge unterstützen den jeweiligen Bereich in ihrer Arbeit am Besten und liefern durch
höhere Akzeptanz auch bessere Ergebnisse als ein gemeinsam genutztes Werkzeug. Bei
der getrennten Modellierung des fachlichen und technischen Bereiches, besteht die
Herausforderung, die getrennt modellierten Modelle fehlerfrei ineinander zu überführen.
Überführung
technisches
Prozess-
Modell
technischer
Prozess
Aufbau
fachliches
Prozess-
Modell
Benutzer -
Interaktion
Abbildung 3-1 : BPM Überführung
Im Fokus dieser Arbeit steht die automatisierte Überführung zwischen den fachlichen und
technischen Modellen. Durch diese Überführung sollen Fehler vermieden werden, denn
damit werden unabhängig von den jeweiligen Interessensschwerpunkten alle nötigen
Details innerhalb der Prozessmodelle zur Verfügung gestellt. Im Gegensatz zur manuellen
Überführung können bei der automatisierten Überführung keine Details verloren gehen.
Um solch eine Überführung zwischen fachlich und technisch motivierten Prozessmodellen
realisieren zu können, ist es zunächst notwendig, die in Frage kommenden Modell-
notationen zu identifizieren. Im folgenden Abschnitt werden potentielle fachliche und
technische Modellnotationen vorgestellt.
3 Modelle
Seite 17
3.3 Modellierungsnotationen
3.3.1 Fachliche Modellnotationen
In diesem Abschnitt werden Modellierungsnotationen für den fachlichen Bereich jeweils
kurz vorgestellt. Die recht große Anzahl von existierenden Modellierungsnotationen wurde
auf die Möglichkeit einer textuellen Beschreibung und die Notationen Petrinetze,
Programmablaufplan, Ereignisgesteuerte Prozessketten, Aktivitätsdiagramm der UML,
LOVEM (Line of Visibility Enterprise Modeling) und BPMN (Business Process
Management Notation) eingeschränkt. Diese Einschränkung orientiert sich an den
Akzeptanzwerten der einzelnen Notationen. Hierbei werden exotische oder spezialisierte
Modellierungsnotationen nicht betrachtet. Die Auswertung im Hinblick auf die
Überführung in eine geeignete fachliche Notation findet im Abschnitt 3-4 statt.
Textuelle Beschreibung
Geschäftsprozesse können durch Text beschrieben werden, denn durch eine einfache
Sprache kann man alle Elemente und Verbindungen eines Geschäftsprozesses beschreiben.
Der Prozess kann sowohl völlig umgangssprachliche dargestellt als auch auf Basis von
Geschäftsprozessschablonen beschrieben werden. Die umgangssprachliche Darstellung
unterliegt keiner syntaktischen Norm. Durch Geschäftsprozessschablonen lässt sich die
textuelle Beschreibung zum Teil formalisieren [Mie02].
Petrinetze
Petrinetze wurden von Carl Adam Petri in seiner Dissertation [Pet62] eingeführt und sind
eine grafische Beschreibungssprache, bei der mit Hilfe eines Markenflusses ein Prozess
beschrieben wird.
Bestellung
eingegangen
Bestellung
nötig
Bestellung
erfasst
...
Ende
Vorbereitung
...
...
Ereignis
Funktion
Abbildung 3-2 : Auszug aus einem erweiterten Petrinetz
Seite 18
Ein Petrinetz ist ein gerichteter, bipartiter Graph (auch Netzgraph), der aus Stellen und
Transitionen besteht. Diese sind durch gerichtete Kanten miteinander verbunden.
Transitionen verkörpern Ereignisse, welche die Marken auf die entsprechende Stellen
schalten. Eine Stelle symbolisiert die zu erbringende Funktion und eine Marke den
Prozessfluss. Bei erweiterten Petrinetzen können Stellen verschiedene Sorten von Marken
aufnehmen, dies wird meistens durch unterschiedliche Einfärbung der Marken symbolisiert
(Abbildung 3-2).
Programmablaufplan
Seit der Entwicklung der strukturellen Programmierung Anfang der 70er-Jahre gilt es als
,,Stand der Technik" nur die vier Kontrollstrukturarten Sequenz, Auswahl, Wiederholung
und Aufruf anderer Algorithmen zu verwenden (S. 38, [Mie02]). Die bekannteste grafische
Darstellung dieser Kontrollstrukturen ist der Programmablaufplan (PAP), bei dem
grafische Symbole durch Linien miteinander verbunden werden (Abbildung 3-3).
Programmablaufpläne sind seit 1969 genormt [DIN83] und gehören zur Gruppe der Block-
diagramme.
Bestellung
eingegangen
Bestellung
erfassen
Ende
Bestätigung
...
ja
nein
Sachbe-
arbeiter
Organisationseinheit
Ereignis
Funktion
Abbildung 3-3 : Auszug aus einem PAP
Ereignisgesteuerte Prozessketten (EPK)
Eine ereignisgesteuerte Prozesskette ist eine semiformale, grafische Modellierungssprache,
die von Prof. Scheer an der Universität Saarbrücken in Kooperation mit dem
Softwareanbieter SAP im Jahre 1992 entwickelt wurde. EPK stellen prinzipiell eine
Erweiterung der Petri Netze dar [Reis91]. Basis der einfachen EPK sind Ereignisse die
Funktionen auslösen. Durch geeignete Verknüpfungsoperatoren kann die Prozesskette
aufgeteilt werden [Sch97].
3 Modelle
Seite 19
Erweiterte Ereignisgesteuerte Prozessketten (eEPK) enthalten zusätzlich Informations-
objekte und Organisationseinheiten (Abbildung 3-4). Dabei werden jeder Funktion die
beteiligten Informationsobjekte und die ausführende Einheit in der Organisation
zugeordnet [Gli06].
Bestellung
Bestellung
eingegangen
Bestellung
erfassen
Lieferauftrag
Sachbe-
arbeiter
Informationsobjekte
Organisationseinheit
Ereignis
Funktion
X
...
...
Verknüpfungsoperator
Abbildung 3-4 : Auszug aus einem eEPK
Aktivitätsdiagramme der UML
Die Unified Modeling Language (UML) ist eine von der Object Management Group
(OMG) entwickelte und standardisierte Sprache für die Modellierung. Mit Hilfe dieser
Sprache werden Modellierungsnotationen definiert, wie beispielsweise das Aktivitäts-
diagramm (AKD) für die Darstellung von Geschäftsprozessen.
Einkäufer
Poststelle
Sachbearbeiter
Bestellung
abgegeben
Bestellung
erfassen
Bestellung
öffnen
Bestellung
Antrag
Antrag
Funktion
Informations-
objekt
Organisations-
einheit
Abbildung 3-5 : Auszug aus einem AKD
Seite 20
Wie fast alle daten- und kontrollflussorientierten Notationen gehen AKD zumindest
konzeptionell auf Petrinetze zurück, in der Version 2 lehnt sich der Standard sogar explizit
an Petrinetze an (S. 194, [Stö05]). Abbildung 3-5 zeigt, das die Grundelemente des AKD
die Aktionszustände (action state) sind, welche durch Transitionen miteinander verbunden
werden. Mit Hilfe von Entscheidungen (decisions) können abhängig von der jeweiligen
Wächterbedingung (guard conditions) alternative Aktionsabläufe eingebunden werden.
Darüber hinaus sind durch Verzweigungen (fork node) und Verschmelzungen (join node)
parallele Abläufe modellierbar. Jede beteiligte Organisationseinheit wird durch eine
Partition (partition) dargestellt und führt nur die Aktionen innerhalb der eigenen Partition
aus (Abbildung 3-5).
Line of Visibility Enterprise Modeling (LOVEM)
LOVEM ist eine Modellnotation mit der Geschäftsprozesse und Arbeitsflüsse (Workflows)
in einer kundenorientierten Weise visualisiert werden können [IBM06]. Das Haupt-
augenmerk liegt dabei auf den Schnittstellen der Kundenprozesse. Dieses Konzept wurde
erstmals 1994 im Harvard Business Magazin von Lynn Shostack publiziert und wird
vorwiegend von IBM eingesetzt [Lis04]. In dieser Prozessnotation werden sowohl externe
als auch interne Ansichten vereint und als eine Sicht dargestellt. Durch grafische
Modellierungstechniken wird die Interaktion zwischen Kundenprozessen und den
unternehmensinternen Prozessen visualisiert, wodurch eine Verbesserung der
Kundenbeziehungen erreicht wird [IBM06]. Abbildung 3-6 veranschaulicht wie die
Kundenprozesse und die gekoppelten unternehmensinternen Prozesse miteinander in einem
Workflow interagieren.
Input/
Output
Funktion
Abteilung
Rolle
Aufgabe
Medium
LOV
Kunden
Prozess
Prozess mit
Kundenkontakt
Unterstützungs-
Prozess
Unterstützungs-
Prozess
Prozess mit
Kundenkontakt
Kunden
Prozess
Kunde
Unternehmen
T
eam
arbei
ter
Abbildung 3-6 : Auszug aus einem LOVEM
3 Modelle
Seite 21
Business Process Modeling Notation (BPMN)
Die Business Process Modeling Notation ist eine grafische Spezifikationssprache
(Abbildung 3-7) mit der Geschäftsprozesse modelliert werden können und wurde im Jahr
2002 von den Mitglieder der Business Process Management Initiative (BPMI) entwickelt.
Im Jahr 2005 wurde die Spezifikation BPMN 1.0 zur Weiterentwicklung an die Object
Management Group übergeben. Ziel ist es eine Notation zu erarbeiten, die sowohl vom
Analysten (business analyst) als auch vom Entwickler (technical developer) einfach
verstanden wird und somit die Lücke zwischen dem fachlichen Prozessdesign (business
process design) und der Prozessimplementierung (process implentation) schließt
[OMG06a]. Mit der BPMN werden fachliche Prozessdiagramme (business process
diagram (BPD)) erstellt. Diese basieren auf Flussdiagrammen und sind auf die grafische
Repräsentation von Geschäftsprozessen zugeschnitten [OMG06a]. Ein weiteres Ziel der
Notation ist es XML basierte Ausführungssprachen von Geschäftsprozessen mit Hilfe der
BPD zu visualisieren. Die OMG verfolgt mit der BPMN das Ziel, alle vorhandenen
Geschäftsprozessnotationen in BPMN zu konsolidieren.
Organisationseinheit
Funktion
Einkäufer
Poststelle
Sachbearbeiter
Bestellung
abgegeben
Bestellung
erfassen
Bestellung
öffnen
Verknüpfungsoperator
Abbildung 3-7 : Auszug aus einem BPD
3.3.2 Technische Modellnotationen
Dieser Abschnitt widmet sich den Modellnotationen des technischen Bereichs. Dabei liegt
das Augenmerk auf Notationen, welche die Services einer SOA kombinieren, koordinieren
und wenn möglich automatisch ausführen können. Aufgrund der breiten Akzeptanz der
Web Service Architektur bei der Realisierung einer SOA werden Sprachen betrachtet, die
mit Web Services als SOA Servicerealisierung arbeiten können. Dadurch wurden die
technischen Modellnotationen auf ebXML, BPSS, BPML, WSCI, WS-CDL, XPDL und
BPEL eingeschränkt. Die Auswertung im Hinblick auf die Überführung findet im
Abschnitt 3-4 statt.
Seite 22
ebXML BPSS (Electronic Business XML Business Process Specification Schema)
Die OASIS (Organisation for the Advancement of Structured Information Standards) und
UN/ CEFACT (United Nations Centre for Trade Facilitation and Electronic Business)
begannen im Jahr 1999 mit der Entwicklung der ebXML (electronic business XML). Unter
ebXML versteht man eine modulare Sammlung von Spezifaktionen die es einem
Unternehmen ermöglichen, standardisiert Geschäftsdaten über das Internet auszutauschen
[OAS06b]. Mit Hilfe des Schema für die Spezifikation von Geschäftsprozessen (BPSS
oder ebBP) können im Rahmen der ebXML Geschäftsprozesse einheitlich und konsistent
definiert werden. Durch die standardisierten Geschäftsprozesse ist eine
Prozesskommunikation bzw. eine Kopplung von Geschäftsprozessen über
Unternehmensgrenzen hinweg möglich. Die ebBP beschreibt eine standardisierte Sprache
zur Konfiguration von Geschäftssystemen, sodass eine unternehmensübergreifende
Geschäftsprozessausführung möglich ist [OAS06c]. Mit der ebXML BPSS werden
Geschäftsprozesse definiert mit dem Ziel im Umfeld der ebXML eine einheitliche,
standardisierte Geschäftsprozesskommunikation zu realisieren. Damit konzentriert sich die
ebXML Spezifikationsfamilie stärker auf die einheitliche Geschäftsprozess-
kommunikation. Dies wird realisiert, indem die öffentlichen Schnittstellen zwischen
Geschäftspartnern definiert werden (vgl. Abbildung 3-8).
Teilnehmer
A
Teilnehmer
B
privat
privat
öffentlich
ebXML
BPML
BPML
Anbindung
an
Interne
Prozesse
Anbindung
an
Interne
Prozesse
öffentliche Prozesse -
Kopplung
Abbildung 3-8 : interne und externe Geschäftsprozesse (Anlehnung an [Cov01])
BPML (Business Process Markup Language)
Die Business Process Markup Language wurde von der BPMI entwickelt und im Juni 2005
durch den Zusammenschluss von BPMI und OMG an die OMG übergeben. BPML ist eine
XML-basierte plattformunabhängige Metasprache zur Modellierung von Geschäfts-
prozessen und beinhaltet ein abstraktes Ausführungsmodell zur Beschreibung von
Geschäftsprozessinteraktionen mit deren Hilfe Aktivitäten kombiniert bzw. orchestriert
3 Modelle
Seite 23
werden können [Cov01]. Geschäftsprozesse werden als eine Gruppe von Flüssen,
bestehend aus Datenflüssen, Kontrollflüssen und Ereignisflüssen, definiert und mittels
synchron und asynchron verteilte Transaktionen verbunden (S. 23, [JMS06]). BPML
unterstützt das Modellieren von komplexen Geschäftsprozessen mit erweiterter Semantik.
Dazu gehören z.B. verschachtelte Prozesse und komplexe kompensierte Transaktionen,
sowie Fehlerbehandlung und Datenmanagement. Nach dem Verständnis der BPMI besteht
ein Geschäftsprozess zwischen den jeweiligen Partnern aus einer einheitlichen öffentlichen
Schnittstelle und einer privaten Schnittstelle. Die öffentliche Schnittstelle zwischen den
Prozessen ist für alle Geschäftspartner identisch und wird mit Hilfe von z.B. ebXML
beschrieben. Die private Schnittstelle pro Geschäftspartner hingegen kann durch BPML
definiert werden [Cov01]. Damit fokussiert sich die Spezifikation BPML auf die interne
Geschäftsprozessmodellierung und auf deren Koordinierung (vgl. Abbildung 3-8).
WSCI (Web Service Choreography Interface)
Die WSCI (Web Service Choreography Interface) ist eine Sprache, mit welcher der
Nachrichtenaustausch zwischen Web Services im Kontext von Prozessen beschrieben
werden kann. Damit ist es möglich das Verhalten der Web Services beim Nachrichten-
austausch zu beschreiben. Ebenfalls lässt sich ein nachrichtenorientierter Überblick über
das Verhalten von Web Services gewinnen (S. 24, [JMS06]). Die durch ein Hersteller-
konsortium der Web Service Choregography Working Group des W3C (World Wide Web
Consortium) Komitees im Jahr 2002 vorgelegte XML-basierte Schnittstellen-
beschreibungssprache WSCI beschreibt, wie Web Services choreographiert werden können
[W3C02]. Im Mittelpunkt steht dabei die Schnittstellenbeschreibung um den
Nachrichtenaustausch bzw. den Nachrichtenfluss zwischen den Web Services zu
beschreiben. Dabei wird nicht der Prozess definiert oder das interne Verhalten des Web
Service sondern der Nachrichtenaustausch aus Sicht des Web Service beschrieben.
WS-CDL (Web Service Choreography Description Language)
Die durch die Web Service Choreography Working Group des W3C entwickelte WS-CDL
(Web Service Choreography Description Language) ist eine XML-basierte Sprache um
Punkt zu Punkt Interaktionen zwischen Web Services durch die Definition des Verhaltens
zu beschreiben [W3C05]. Wie WSCI beschreibt WS-CDL durch Schnittstellen aus einer
externen Sicht das Verhalten eines Web Services in einer Choreographie. Doch beschränkt
sich WS-CDL nicht auf die Schnittstellenbeschreibung wie WSCI. Zur Spezifikation des
Verhaltens der Web Services kann optional die WS-DL (Web Service Definition
Language) benutzt werden. WS-CDL ist keine Ausführungssprache oder
Programmierungssprache. Die Wahl der Sprache, in der eine WS-CDL Choreographie
umgesetzt wird, bleibt ausdrücklich dem Nutzer überlassen [W3C05]. Durch WS-CDL
kann ein Regelset erstellt werden, mit dessen Hilfe definiert wird, wie Web Services mit
einander agieren sollen (S. 24, [JMS06]). Sie hilft den Geschäftspartnern das externe
Verhalten der zu choreographierenden Geschäftsprozesse zu verifizieren (S. 25, [JMS06]).
Seite 24
XPDL (XML Process Definition Language)
Die XPDL (XML Process Definition Language) ist eine durch das Workflow Managenent
Coalition (WfMC) veröffentlichte XML-basierte Sprache zum Beschreiben von
Geschäftsprozessen bzw. Arbeitsabläufen (workflows). Mit XPDL wird das Interface 1
von 5 Interfaces im Workflow Reference Model der WfMC implementiert [WfM05]. Das
Interface 1 verbindet die so genannten ,,Process Definition Tools" mit dem ,,Enactment
Service". Dabei werden die Prozessdefinitionstools genutzt um Prozessdefinitionen zu
erstellen während das ,,Enactment System" die jeweilige Prozessdefinition ausführt. Das
Interface 1 realisiert durch die Sprache (XPDL) den Import und Export der jeweiligen
Prozessdefinitionen. Die Prozessdefinitionen bestehen aus einem Netzwerk von
Aktivitäten und deren Beziehungen, Kriterien für den Start und den Abbruch des Prozesses
sowie individuelle Informationen über die Aktivitäten wie z.B. die Teilnehmer oder
involvierte IT-Anwendungen.
In der Version 2.0 wurden bisher fehlende Elemente der BPMN sowie notwendige
grafische Elemente (Pools, Swim Lanes, Gateways und Events - Abbildung 3-9) mit in die
Beschreibungssprache integriert. Damit kann XPDL als Dateiformat für BPMN genutzt
werden [WfM05]. Somit entwickelt sich XPDL zu einem Austauschformat für Prozess-
definitionen.
BPMN spezifischen Erweiterungen
Process
(W. Process)
Type
Declaration
Data Field
Application
Participant
Activity
ActivitySet
(Embedded Sub-Process)
Transition
SequenceFlow
Pool
Lane
Task/Tool
Block Activity
Route
SubFlow
Gateway
Event
W. Relevant Data
System Data
Enviroment Data
Resource
Repository
Abbildung 3-9 : XPDL 2.0 Metamodell
BPEL (Business Process Execution Language)
BPEL (Business Process Execution Language) ist eine XML-basierte Sprache zur
Beschreibung von Geschäftsprozessen basierend auf Web Services. BPEL (auch WS-
BPEL oder veraltet BPEL4WS) ist durch die Firmen IBM, Bea und Microsoft entwickelt
wurden und durch OASIS standardisiert. Das Prozessmodell BPEL ist eine Kombination
der kalkülbasierten XLANG (Web Services for Business Process Design) Sprache von
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2007
- ISBN (eBook)
- 9783956362484
- ISBN (Paperback)
- 9783836603799
- Dateigröße
- 1.2 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Technische Universität Dresden – Informatik, Studiengang Informatik
- Erscheinungsdatum
- 2007 (Juni)
- Note
- 1,2
- Schlagworte
- business process management prozessmodell informatik
