Erhöhung der Durchgängigkeit und Flexibilität prozessorientierter Applikationen mittels Service ...

133 Pages·2012·4.54 MB·German

by  Stephan Buchwald

Institut für Datenbanken und Informationssysteme
(Leiter: Prof. Dr. Peter Dadam)
Erhöhung der Durchgängigkeit und
Flexibilität prozessorientierter Applikationen
mittels Service-Orientierung
Dissertation
zur Erlangung des Doktorgrades Dr. rer. nat.
der Fakultät für Ingenieurwissenschaften und Informatik
der Universität Ulm
vorgelegt von
Stephan Buchwald
aus Ulm
2012
Amtierender Dekan: Prof. Dr. Klaus Dietmayer
Gutachter: Prof. Dr. Manfred Reichert
Prof. Dr. Franz Schweiggert
Prof. Dr. Thomas Bauer
Tag der Promotion: 23. Oktober 2012
für Sabrina...

Zusammenfassung
Höhere Flexibilität für IT-gestützte Prozesse ist eine der zentralen Erwartungen, die von An-
wenderseite an eine Service-orientierte Architektur (SOA) gestellt wurden. Insbesondere sollen
fachlicheAnforderungenanGeschäftsprozesseraschinbetrieblicheInformationssysteme,d.h.die
technische Implementierung der Prozesse, überführt werden können. Des Weiteren ist die Fähig-
keit, auf Änderungen der fachlichen oder technischen Ebene schnell und korrekt zu reagieren,
unabdingbare Voraussetzung für den Betrieb prozessorientierter Applikationen in einer SOA.
Eine Herausforderung ist in diesem Zusammenhang die Diskrepanz zwischen den Anforderun-
gen der Fachbereiche und den vom IT-Bereich realisierten technischen Implementierungen (sog.
Business-IT-Gap). Um den genannten Herausforderungen gerecht zu werden, bedarf es einer
durchgängigen Definition, Verwaltung und Pflege von Prozessen, Services und Datenobjekten,
sowohl auf fachlicher als auch auf technischer Ebene.
Informationen zum Beziehungsgeflecht zwischen fachlichen und technischen Prozessen, Services
und Datenobjekten sind in heutigen Unternehmensarchitekturen meist nicht vorhanden, was zu
weiteren Problemen führt. So ist etwa bei Außerbetriebnahme eines Services nicht immer nach-
vollziehbar, welche (prozessorientierten) Applikationen davon betroffen sind. Dadurch ist es wie-
derumschwierigsicherzustellen,dassdieDeaktivierungeinzelnerServicesoderService-Versionen
in der Folge nicht zu unerwarteten Fehlern führt, etwa dass ein implementierter Geschäftspro-
zesses nicht mehr ausführbar ist.
DievorliegendeArbeitadressiertmitENPROSO(EnhancedProcessManagementthroughService
Orientation) diese Problemfelder und stellt einen Ansatz zur Verbesserung der Konsistenz zwi-
schen fachlichen Anforderungen und implementierten Prozessen dar. Die Verwaltung und Kon-
sistenzsicherung des komplexen Beziehungsgeflechts fachlicher und technischer Artefakte wird
durch geeignete Methoden und Vorgehensmodelle für eine durchgängige Prozessmodellierung
unterstützt. So lassen sich bereits bei der fachlichen Modellierung benötigte Informationen (z.B.
über wiederverwendbare Services) explizit dokumentieren. Dadurch entsteht bereits während der
fachlichen Analyse und Konzeptentwicklung eine detaillierte Beschreibung des zu implementie-
renden Sachverhalts. Zudem ist es möglich, fachliche Anforderungen schon in frühen Phasen der
Softwareentwicklung vollständig zu dokumentieren und dadurch Aufwände für die Implementie-
rung in späteren Phasen zu reduzieren. Zur Verwaltung der von einer SOA benötigten Artefakte
ist ein umfassendes und generisches Repository-Metamodell notwendig, das die konsistente Spei-
cherung aller Artefakte mit allen relevanten Beziehungen ermöglicht. Auf diese Weise kann die
Konsistenz der gegenwärtig im Repository dokumentierten Artefakte sichergestellt werden.
v

Inhaltsverzeichnis
I. Motivation 1
1. Einleitung 3
1.1. Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Beitrag der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Grundlagen 11
2.1. Service-Orientierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1. Service-Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2. SOA-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2. Geschäftsprozess-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1. Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2. Fachmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.3. Ausführbares Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.4. Systemmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.5. Modellierungsebenen und -aspekte . . . . . . . . . . . . . . . . . . . . . . . . 22
3. Anwendungsszenario und Anforderungen 23
3.1. Anwendungsszenarien aus der betrieblichen Praxis . . . . . . . . . . . . . . . . . . . 23
3.1.1. Umsetzungsprojekte für Prozessapplikationen . . . . . . . . . . . . . . . . . 24
3.1.2. Zentrale Vorgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.3. Bereitstellung einer IT-Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.4. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2. Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3. Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4. Service-orientierte IT-Infrastruktur 51
4.1. Anwendungsszenario und Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2. Ausbaustufen einer IT-Infrastruktur für SOA . . . . . . . . . . . . . . . . . . . . . . 54
4.2.1. IT-Infrastrukturen vor einer SOA-Einführung . . . . . . . . . . . . . . . . . 54
4.2.2. Ausbaustufe 1: Minimale Service-orientierte IT-Infrastruktur . . . . . . . . 55
4.2.3. Ausbaustufe 2: Service-orientierte IT-Infrastruktur . . . . . . . . . . . . . . 61
4.3. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
vii
II. Konzept 71
5. Maßnahmen zur Flexibilisierung Service-orientierter Architekturen 73
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2. Entwicklung von Prozessapplikationen . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.1. Beschreibung fachlicher Anforderungen (P1: Fachliche Analyse) . . . . . . 75
5.2.2. Definition von Fachprozessen (P2: Fachliche Modellierung) . . . . . . . . . 77
5.2.3. IT-orientierte Sichtweise auf Fachprozesse (P3: Technische Modellierung) . 80
5.2.4. IT-Implementierung (P4: Workflow Modellierung und Implementierung) . 84
5.2.5. Deployment (P5: Deployment der Softwareartefakte) . . . . . . . . . . . . . 86
5.2.6. Ausführung und Überwachung (P6: Process Execution and Monitoring). . 87
5.3. Änderungen der Umgebung einer Prozessapplikation . . . . . . . . . . . . . . . . . . 88
5.3.1. Änderung an der Service-Lokation . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.2. Service-Ausfall oder -Überlastung. . . . . . . . . . . . . . . . . . . . . . . . . 91
5.3.3. Versionswechsel und Abschaltung von Services . . . . . . . . . . . . . . . . . 91
5.3.4. Austausch von Infrastrukturkomponenten . . . . . . . . . . . . . . . . . . . . 93
5.3.5. Änderungen am Organisationsmodell . . . . . . . . . . . . . . . . . . . . . . 94
5.4. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6. Durchgängige Modellierung von Prozessapplikationen 101
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.1.1. Anwendungsbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.1.2. Verwendungszweck eines durchgängigen Modells . . . . . . . . . . . . . . . . 103
6.2. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.2.1. Anforderungen an eine nachvollziehbare Dokumentation . . . . . . . . . . . 106
6.2.2. Anforderungen an die Änderbarkeit von Prozessapplikationen . . . . . . . . 106
6.2.3. Anforderungen an Konsistenz . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.3. Konzept zur Prozesstransformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.3.1. Umstrukturierung des Fachprozesses . . . . . . . . . . . . . . . . . . . . . . . 108
6.3.2. Verwaltung der Beziehungen zwischen Fach- und Systemmodell . . . . . . . 111
6.3.3. Überführung eines Systemmodells in ein ausführbares Modell . . . . . . . . 115
6.4. Gestaltung des Abbildungsmodells . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.4.1. Struktur des Abbildungsmodells . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.4.2. Konsistenz im Abbildungsmodell . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.4.3. Strukturelle Konsistenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.5. Konsistenzsicherung nach Veränderungen . . . . . . . . . . . . . . . . . . . . . . . . 122
6.5.1. Versionierung von Modellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.5.2. Veränderungen unterschiedlicher Modellversionen . . . . . . . . . . . . . . . 125
6.5.3. Ermittlung betroffener Objekte auf anderer Modellierungsebene . . . . . . 128
6.5.4. Anpassung durch verantwortlichen Modellierer . . . . . . . . . . . . . . . . . 129
6.5.5. Erstellung einer konsistenten Konfiguration . . . . . . . . . . . . . . . . . . . 131
6.6. Werkzeuggrenzen und Modellerstellung . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.6.1. Überwindung von Tool-Grenzen. . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.6.2. Vorgehen zur Erstellung der Modelle . . . . . . . . . . . . . . . . . . . . . . . 134
6.7. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.8. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
7. Frontloading und Look-ahead 143
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
7.2. Anforderungen und Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
7.2.1. Anforderungen an Frontloading . . . . . . . . . . . . . . . . . . . . . . . . . . 145
7.2.2. Anforderungen an Look-ahead. . . . . . . . . . . . . . . . . . . . . . . . . . . 148
7.3. Frontloading am Beispiel von Bearbeiterzuordnungen . . . . . . . . . . . . . . . . . 149
7.3.1. Ansätze zur fachlichen Modellierung von Bearbeiterzuordnungen . . . . . . 151
7.3.2. Übernahme der Bearbeiterzuordnungen in das Systemmodell . . . . . . . . 156
7.4. Frontloading am Beispiel von Flexibilitätsmarkierungen . . . . . . . . . . . . . . . . 158
7.4.1. Flexibilität im Fachprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7.4.2. Umsetzungsmöglichkeiten für Flexibilitätsmarkierungen im Systemprozess 161
7.5. Look-ahead am Beispiel Service-Auswahl. . . . . . . . . . . . . . . . . . . . . . . . . 164
7.5.1. Verwendung existierender Services . . . . . . . . . . . . . . . . . . . . . . . . 165
7.5.2. Arten der Bereitstellung fachlicher Beschreibungen . . . . . . . . . . . . . . 167
7.5.3. Service Look-ahead auf Systemmodellebene. . . . . . . . . . . . . . . . . . . 168
7.6. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
7.7. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
8. SOA-Repository und Applikationsübergreifende Konsistenzsicherung 175
8.1. Anforderungen an ein SOA-Repository . . . . . . . . . . . . . . . . . . . . . . . . . . 176
8.1.1. Fachprozessmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
8.1.2. Spezifikation und Implementierung von Prozessapplikationen . . . . . . . . 177
8.1.3. Architekturmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
8.1.4. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
8.1.5. Business Activity Monitoring (BAM) . . . . . . . . . . . . . . . . . . . . . . 179
8.1.6. SOA-Governance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
8.1.7. Service-Konsumenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
8.1.8. Durchgängige Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
8.1.9. Analysen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
8.2. Basismodell eines SOA-Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
8.2.1. Verwaltung von Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
8.2.2. Service-Nutzungsvertrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
8.2.3. Service-Operationen und Datenobjekte . . . . . . . . . . . . . . . . . . . . . 186
8.2.4. Service-Entwicklung und -Installation . . . . . . . . . . . . . . . . . . . . . . 188
8.3. Erweitertes SOA-Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
8.3.1. Fachliche und technische Prozesse . . . . . . . . . . . . . . . . . . . . . . . . 190
8.3.2. Durchgängige Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
8.4. Analysen gespeicherter Repository-Informationen . . . . . . . . . . . . . . . . . . . 195
8.4.1. Ist-Analysen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
8.4.2. Zukunftsanalysen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
8.5. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
8.5.1. Electronic Business using XML (ebXML) . . . . . . . . . . . . . . . . . . . . 207
8.5.2. Universal Description, Discovery and Integration (UDDI) . . . . . . . . . . 208
8.5.3. CentraSite Active SOA (Software AG) . . . . . . . . . . . . . . . . . . . . . . 208
8.5.4. Oracle Enterprise Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
8.5.5. IBM WebSphere Service Registry and Repository (WSRR) . . . . . . . . . 209
8.5.6. HP SOA Systinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
8.5.7. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
8.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
III.Validation und Zusammenfassung 213
9. Validation 215
9.1. Proof-of-Concept-Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
9.1.1. Durchgängige Modellierung: Umsetzung im ARIS Business Architect . . . 216
9.1.2. Konsistenz zwischen Modellierungsebenen und Modellversionen . . . . . . . 221
9.1.3. Implementierung eines SOA-Repository . . . . . . . . . . . . . . . . . . . . . 222
9.1.4. Ist- und Zukunftsanalysen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
9.2. Fallstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
9.3. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
10.Zusammenfassung und Ausblick 233
Literaturverzeichnis 237
IV.Anhang 257
A. ENPROSO-Repository-Objekte und -Beziehungstypen 259
Abkürzungsverzeichnis 269
Abbildungsverzeichnis 273
Tabellenverzeichnis 277
Listings 279