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