Serviceorientierte Architektur: Architekturprinzipien und Umsetzung in die Praxis GERMAN [1 ed.] 3540723579, 9783540723578 [PDF]

Zitiervorschau

Business Engineering Herausgegeben von H. Österle, R. Winter, W. Brenner

Business Engineering V. Bach, H. Österle (Hrsg.) Customer Relationship Management in der Praxis 2000. ISBN 978-3-540-67309-5 H. Österle, R. Winter (Hrsg.) Business Engineering, 2. Auflage 2003. ISBN 978-3-540-00049-5

G. Riempp Integrierte Wissensmanagement-Systeme 2004. ISBN 978-3-540-20495-4 T. Puschmann Prozessportale 2004. ISBN 978-3-540-20715-3

R. Jung, R. Winter (Hrsg.) Data-Warehousing-Strategie 2000. ISBN 978-3-540-67308-8

H. Österle, A. Back, R. Winter, W. Brenner (Hrsg.) Business Engineering − Die ersten 15 Jahre 2004. ISBN 978-3-540-22051-0

E. Fleisch Das Netzwerkunternehmen 2001. ISBN 978-3-540-41154-3

R. Zarnekow, W. Brenner, U. Pilgram Integriertes Informationsmanagement 2005. ISBN 978-3-540-23303-9

H. Österle, E. Fleisch, R. Alt Business Networking in der Praxis 2001. ISBN 978-3-540-41370-7

U. Baumöl, H. Österle, R. Winter Business Engineering in der Praxis 2005. ISBN 978-3-540-20517-3

S. Leist, R. Winter (Hrsg.) Retail Banking im Informationszeitalter 2002. ISBN 978-3-540-42776-6 C. Reichmayr Collaboration und WebServices 2003. ISBN 978-3-540-44291-2 O. Christ Content-Management in der Praxis 2003. ISBN 978-3-540-00103-4

R. Zarnekow, A. Hochstein, W. Brenner Serviceorientiertes IT-Management 2005. ISBN 978-3-540-20532-6 J. Schelp, R. Winter Integrationsmanagement 2005. ISBN 978-3-540-20506-7 R. Zarnekow, W. Brenner, U. Pilgram Integrated Information Management 2006. 978-3-540-32306-8

E. von Maur, R. Winter (Hrsg.) Data Warehouse Management 2003. ISBN 978-3-540-00585-8

R. Zarnekow Produktionsmanagement von IT-Dienstleistungen 2007. ISBN 978-3-540-47457-9

L. M. Kolbe, H. Österle, W. Brenner (Hrsg.) Customer Knowledge Management 2003. ISBN 978-3-540-00541-4

R. Heutschi Serviceorientierte Architektur 2007. ISBN 978-3-540-72357-8

R. Alt, H. Österle Real-time Business 2003. ISBN 978-3-540-44099-4

W. Brenner, R. Wenger Elektronische Beschaffung 2007. ISBN 978-3-540-34017-1

Roger Heutschi

Serviceorientierte Architektur Architekturprinzipien und Umsetzung in die Praxis

Mit 51 Abbildungen und 52 Tabellen

123

Roger Heutschi [email protected]

ISSN 1616-0002 ISBN 978-3-540-72357-8 Springer Berlin Heidelberg New York

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. 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 vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2007 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. Herstellung: LE-TEX Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: WMX Design GmbH, Heidelberg SPIN 12060023

42/3180YL - 5 4 3 2 1 0

Gedruckt auf s¨ aurefreiem Papier

Geleitwort Der Automobilbau entwickelt neue Autos auf Basis von Komponenten, Systemen und Plattformen, die teilweise von anderen Modellen her verfügbar sind. Es ist der Traum des Software Engineering, ja des umfassenden Business Engineering, neue Software und Prozesse ebenso schnell und sicher zu entwickeln, wie dies die Automobilentwickler vormachen. In Teilbereichen ist dies seit einiger Zeit sehr gut gelungen, in anderen Fällen sind Vorhaben gescheitert. Die serviceorientierte Architektur gilt seit einiger Zeit als erfolgversprechender Weg in eine Welt von frei kombinierbaren Softwarekomponenten. Die datenbankorientierte, monolithische Architektur hat dreissig Jahre lang die Integration innerhalb von Unternehmen voran gebracht. Die serviceorientierte Architektur könnte die gleiche Rolle in der Kooperation zwischen Unternehmen, aber auch in heterogenen Welten innerhalb eines Konzerns spielen. Es gibt allerdings auch die Frage, was in den Konzepten der Serviceorientierung den Durchbruch gegenüber früheren Ansätzen bringen soll. Grundlegende Konzepte der Serviceorientierung, die Identifikation von Gleichteilen, die Wiederverwendung und freie Kombinierbarkeit von Komponenten und die einfache Kommunikation zwischen unabhängig voneinander entwickelten Prozessen und Systemen sind einleuchtend. Doch was bringt eine serviceorientierte Architektur in der Praxis wirklich und wie entwickelt man sie? Diesen beiden Fragen geht Heutschi anhand von vier Fallstudien in innovativen Unternehmen nach und kommt zum Schluss, dass eine serviceorientierte Architektur in diesen Unternehmen teilweise unterschiedlich angewandt wird, dass aber die vier Unternehmen einen grossen Teil ihrer damit verbundenen Ziele erreichen konnten. Aus der Literatur, aus den untersuchten vier Fällen und aus zahlreichen Workshops mit Unternehmen leitet Heutschi schliesslich Designkriterien und Massnahmen zur Umsetzung serviceorientierter Architekturen ab. Dass diese Kriterien in praxi erfolgreich anwendbar sind, beweist die Dissertation von Daniel Hanhart, der den Ansatz von Heutschi für das Domänendesign im Facility Management sehr überzeugend angewandt hat. Das vorliegende Buch präsentiert derzeit wohl die gründlichste, praxisbezogene Studie zur serviceorientierten Architektur. St. Gallen, im März 2007

Hubert Österle

Vorwort Bei steigendem Bedarf nach integrierter Abwicklung von Geschäftsprozessen und nach Flexibilität des Informationssystems ist eine serviceorientierte Architektur (SOA) ein Ansatz, Geschwindigkeit und Qualität der unternehmensweiten Applikationsentwicklung und -integration zu erhöhen und ihre Komplexität und Kosten zu senken. Eine SOA unterstützt die schnelle und wirtschaftliche Umsetzung von Innovationen des Geschäftsmodells im Informationssystem und steigert dadurch die unternehmerische Agilität. Das vorliegende Buch beschreibt ein Architekturmodell für SOA, das den Ansatz im Themengebiet Unternehmensarchitektur einordnet und grundlegende Architekturelemente und Designprinzipien erläutert. Anhand von vier Fallstudien zeigt es konkrete Ausprägungen sowie Treiber und Nutzenpotenziale des Architekturstils in der Praxis. Weiter identifiziert es Massnahmen zur Einführung einer SOA und diskutiert Ansätze für die Architekturentwicklung und -steuerung sowie für eine serviceorientierte Entwicklung von Applikationen. Die Grundlagen für diese Publikation entstanden zwischen 2002 und 2006 im Rahmen meiner Tätigkeit am Institut für Wirtschaftsinformatik der Universität St. Gallen. Ich möchte an dieser Stelle allen danken, die zum Gelingen der Arbeit beigetragen haben. Prof. Dr. Hubert Österle danke ich herzlich für die konstruktive und kritische Betreuung meiner Dissertation und das praxisnahe Forschungsumfeld, das er an seinem Lehrstuhl geschaffen hat. Ein grosser Dank geht auch an Prof. Dr. Walter Brenner für die Übernahme des Koreferats. Weiter danke ich meinen Kollegen aus dem Kompetenzzentrum Business Networking für die gute Zusammenarbeit und viele interessante Diskussionen in gemeinsamen Projekten: Prof. Dr. Rainer Alt, Dr. Marc Cäsar, Dr. Dimitrios Gizanis, Daniel Hanhart, Dr. Christine Legner, Dr. Florian Leser, Cornel Loser, Dr. Thomas Puschmann, Jan Schemm, Dr. Enrico Senger, Tobias Vogel, Kristin Wende und Oliver Wilke. Wertvolle Anregungen gaben auch die Vertreter der Partnerunternehmen des Kompetenzzentrums. Stellvertretend danke ich hier Prof. Dr. Ulrike Baumöl und Dr. Andreas Frei (Swiss Life), Karl-Heinz Schelhas (T-Com) und Dr. Andreas Schiesser (F. Hoffmann-La Roche). Ganz besonders möchte ich mich schliesslich bei meiner Freundin Fabienne Erni, meinen Eltern und meinem Bruder für ihre Motivation und Unterstützung bedanken. St. Gallen, im Mai 2007

Roger Heutschi

Inhaltsverzeichnis

1

2

3

Einleitung ....................................................................................................... 1 1.1

Problemstellung..................................................................................... 1

1.2

Nutzen und Adressaten des Buches....................................................... 3

1.3

Aufbau des Buches................................................................................ 5

Grundlagen .................................................................................................... 7 2.1

Architekturbegriff ................................................................................. 7

2.2

Unternehmensarchitektur und Business Engineering............................ 8

2.3

Integrationsmodell............................................................................... 10 2.3.1 Ebene Anwendungssystem...................................................... 11 2.3.2 Ebene Workflowintegration .................................................... 15 2.3.3 Ebene Desktopintegration ....................................................... 17

2.4

Informations- und Architekturmanagement ........................................ 18

2.5

Zusammenfassung............................................................................... 20

Prinzipien serviceorientierter Architekturen............................................ 21 3.1

Serviceorientierte Architektur ............................................................. 21

3.2

Architekturmodell und -komponenten ................................................ 22 3.2.1 Metamodell ............................................................................. 24 3.2.2 Architekturkomponenten auf Ebene Services ......................... 25

3.3

Designprinzipien ................................................................................. 30 3.3.1 Schnittstellenorientierung ....................................................... 31 3.3.2 Interoperabilität....................................................................... 36 3.3.3 Autonomie und Modularität.................................................... 39 3.3.4 Bedarfsorientierung................................................................. 42 3.3.5 Bedeutung der Designprinzipien............................................. 45

3.4

Abgrenzung der Serviceorientierung von verwandten Ansätzen ........ 47 3.4.1 Historische Entwicklung von Methoden für den Systementwurf ........................................................................ 47 3.4.2 Serviceorientierung, Objekt- und Komponentenorientierung....................................................... 49

X

4

5

Inhaltsverzeichnis

3.5

Technologien und Produkte zur Implementierung von SOA .............. 52 3.5.1 Technologiestandards.............................................................. 52 3.5.2 Produktplattformen ................................................................. 58

3.6

Zusammenfassung............................................................................... 61

Fallbeispiele zu SOA.................................................................................... 63 4.1

Auswahl der Unternehmen und Übersicht .......................................... 63

4.2

Deutsche Post Brief............................................................................. 64 4.2.1 Unternehmen........................................................................... 64 4.2.2 Ausgangslage .......................................................................... 64 4.2.3 Umsetzung einer SOA ............................................................ 65 4.2.4 Bisherige Erfahrungen ............................................................ 70

4.3

Credit Suisse........................................................................................ 73 4.3.1 Unternehmen........................................................................... 73 4.3.2 Ausgangslage .......................................................................... 73 4.3.3 Umsetzung einer SOA ............................................................ 74 4.3.4 Bisherige Erfahrungen ............................................................ 81

4.4

T-Com ................................................................................................. 84 4.4.1 Unternehmen........................................................................... 84 4.4.2 Ausgangslage .......................................................................... 84 4.4.3 Umsetzung einer SOA ............................................................ 86 4.4.4 Bisherige Erfahrungen ............................................................ 92

4.5

Zuger Kantonalbank............................................................................ 93 4.5.1 Unternehmen........................................................................... 93 4.5.2 Ausgangslage .......................................................................... 93 4.5.3 Entwicklung eines servicebasierten Beraterarbeitsplatzes ...... 95 4.5.4 Bisherige Erfahrungen .......................................................... 101

4.6

Erkenntnisse aus den Fallstudien ...................................................... 103 4.6.1 Treiber und Leidensdruck ..................................................... 103 4.6.2 Einsatzreichweite und Ziele .................................................. 104 4.6.3 Einordnung der Fallbeispiele im SOA-Ebenenmodell .......... 107 4.6.4 Anwendung der SOA-Designprinzipien ............................... 109 4.6.5 Nutzenpotenziale und Herausforderungen ............................ 111 4.6.6 Massnahmen zur Einführung einer SOA............................... 114

4.7

Zusammenfassung............................................................................. 117

Architekturmanagement und Servicedesign ........................................... 119 5.1

SOA-Ziele, Architekturprinzipien und Architektursteuerung ........... 120 5.1.1 Bestehende Qualitätsmodelle zur Bewertung von SOA........ 121 5.1.2 Priorisieren der Designprinzipien anhand der SOA-Ziele..... 122 5.1.3 Indikatoren für die Architekturqualität ................................. 126 5.1.4 Architekturreviews................................................................ 131

Inhaltsverzeichnis

6

XI

5.2

Entwicklung der Domänenarchitektur............................................... 133 5.2.1 Ziele der Domänenabgrenzung ............................................. 133 5.2.2 Vorgehensansätze für die Domänenabgrenzung ................... 136 5.2.3 Kriterien für die Domänenabgrenzung.................................. 143

5.3

Serviceidentifikation und -design...................................................... 147 5.3.1 Projektgetriebene und vorausplanende Identifikation von Services ................................................................................. 147 5.3.2 Methoden für das Servicedesign ........................................... 149 5.3.3 Servicetypologie.................................................................... 172

5.4

Architekturrollen und Verantwortlichkeiten ..................................... 176 5.4.1 SOA-Rollen in der Literatur.................................................. 177 5.4.2 Konsolidierung der Rollen .................................................... 179

5.5

Zusammenfassung............................................................................. 181

Zusammenfassung und Ausblick ............................................................. 183 6.1

Zusammenfassung............................................................................. 183

6.2

Ausblick ............................................................................................ 185

Anhang A

Definition der Metaentitätstypen ............................................ 189

Anhang B

SOA-Charakterisierungen ....................................................... 193

Anhang C

Ausprägung der Designprinzipien .......................................... 197

Abkürzungen...................................................................................................... 203 Literatur ............................................................................................................. 205 Index.................................................................................................................... 227

1 Einleitung 1.1

Problemstellung

Unternehmen sehen die Innovation von Geschäftsmodellen als primären Werttreiber in den kommenden Jahren [s. Borzo 2005, 2]. Die Fähigkeit, diese Innovationen schneller als die Konkurrenz im betrieblichen Informationssystem (IS) umzusetzen, ist ein wichtiger Erfolgsfaktor [s. Kagermann/Österle 2006, 250]. ISVerantwortliche bewegen sich heute in einem Spannungsfeld zwischen zunehmend kürzeren Innovations- und Anpassungszyklen bei sinkenden oder stagnierenden finanziellen Mitteln [s. Zarnekow et al. 2005, 34]. Budgetdruck und der Bedarf nach besserer Unterstützung von Geschäftsprozessen und schneller Umsetzung von Geschäftsinnovationen bestimmen seit längerem die Agenda von CIOs [s. McDonald et al. 2006, 5]. Gründe dafür sind einerseits Zweifel an der strategischen Bedeutung der Informationstechnologie (IT) [s. Carr 2003], andererseits über Jahrzehnte gewachsene Informationssysteme, die nur schwer beherrschbar und anpassbar sind: Unternehmenszusammenschlüsse, die Einführung einer Vielzahl neuer Applikationen für das E-Business, Zeitdruck bei der Produktivsetzung und ein mangelhaftes unternehmensweites Architekturmanagement führten oft zu Technologievielfalt, Redundanzen in Funktionen und Daten und unkoordinierten Schnittstellen zwischen Altsystemen und Neuentwicklungen. Abhängigkeiten zwischen Applikationen ziehen bei der Umsetzung neuer Geschäftsanforderungen die Anpassung vieler Anwendungssysteme und Schnittstellen nach sich und machen IT-Projekte umfangreich und teuer [s. Hagen 2004, 69]. Gemäss dem Analystenunternehmen CBDi behinderten unflexible Informationssysteme in den letzten Jahren die Realisierung neuer Geschäftsmodelle bei zwei Dritteln der Fortune 500 Unternehmen [s. Veryard 2004, 24]. In einer ForresterStudie gaben rund 80% von 145 befragten Unternehmen an, dass ihre bestehende Applikationslandschaft funktionsbereichsübergreifende Prozesse mangelhaft unterstützt und Prozessänderungen nur beschränkt zulässt [s. Kinikin 2004, 3]. Einige Beispiele illustrieren typische Herausforderungen: •

Ein Elektronikhersteller will seine Kunden global über alle Geschäftsbereiche hinweg einheitlich betreuen (one face to the customer). Die einheitliche Sicht auf Kunden ist aber schwer zu realisieren: Gegenwärtig halten über 40 Applikationen eigene Kundendaten. Sie verwenden unterschiedliche Datenmodelle und bieten in verschiedenen Technologien programmierte Schnittstellen.

•

Ein Telekommunikationsunternehmen muss in der Lage sein, in kurzer Zeit neue Produktbündel (bspw. Telefonanschluss mit Breitband-Internetzugang und Internet-Fernsehabonnement) auf den Markt zu bringen. Die bestehende IT-Architektur behindert aber eine schnelle Umsetzung der notwendigen produktübergreifenden Auftragsprüfungs- und Abwicklungsprozesse: Das Unternehmen hat über Jahre sein Produktangebot ständig erweitert und neue Kommunikationskanäle (Internet, Call Center, EDI-Schnittstellen etc.) eingeführt. Besonders die älteren, eigenentwickelten Applikationen für die Auftragsabwicklung und Produktion sind hochintegriert und monolithisch. Sie verknüp-

2

1 Einleitung

fen Präsentationslogik für einen bestimmten Zugangskanal (z.B. Call Center) sowie die Geschäftslogik für die Auftragserfassung und Fertigung spezifischer Produkte (z.B. DSL-Produkte) eng miteinander. Sie implementieren Geschäftslogik redundant, weisen viele mangelhaft dokumentierte Schnittstellen untereinander auf und bieten keinen Zugriff auf einzelne Geschäftsfunktionen (z.B. Verfügbarkeitsprüfung), die zur Steuerung einer integrierten produkt- und kanalübergreifenden Auftragsabwicklung notwendig sind. •

Ein IT-Dienstleister betreibt die zentralen Backoffice-Anwendungssysteme für mehr als 200 Kreditinstitute. Diese haben verschiedenste FrontofficeApplikationen im Einsatz, die sich hinsichtlich Plattform (z.B. J2EE, Microsoft .Net), Programmiersprache (u.a. Java, C#, Perl) und Schnittstellentechnologien (z.B. Java RMI, proprietäre RPC-Mechanismen) unterscheiden. Um diese mit der zentralen Backoffice-Anwendung zu verbinden, implementierte der IT-Dienstleister in der Vergangenheit für jede Frontoffice-Applikation eine individuelle Integrationslösung. Für den Betrieb einer Vielzahl an Entwicklungsplattformen und Integrationstechnologien und das notwendige spezialisierte Know-how seiner Mitarbeiter entstehen ihm heute grosse Aufwände. Beim Weiterausbau seines Leistungsangebots entstehen Zusatzaufwände, weil er für einen Kunden entwickelte Dienste nur schwer bei anderen Kunden wieder verwenden kann. Angesichts der Vielzahl und Heterogenität der eingesetzten Informationssysteme können viele Unternehmen Anpassungen an Geschäftsmodellen nur mit hohem Integrationsaufwand bewältigen. Jede neue Integrationsbeziehung beeinträchtigt die Wartbarkeit und Beherrschbarkeit des IS und ist mit Kosten verbunden: Gartner schätzt, dass die Integration von Anwendungssystemen rund 35% der Kosten für die Applikationsentwicklung und -wartung verursacht [s. Pezzini 2003, 2]. Nach einer Studie der Standish Group sind 95% der Integrationsprojekte nicht in der Lage, ihre Ziele innerhalb des vorgesehenen Zeitplans oder Budgets zu realisieren [s. Peterson 2004]. Häufige Probleme der Applikationsintegration sind (s. [Kossmann/Leymann 2004, 118], [Barkmeyer et al. 2003, 31ff.]): •

Plattformabhängigkeit. Applikationen laufen auf technisch inkompatiblen Hardware- und Betriebssystemplattformen mit unterschiedlichen Kommunikationsmechanismen und -protokollen, die nur über Adapter miteinander interagieren können. Diese Adapter lassen sich nur selten für eine weitere Integration mit anderen Systemen wieder verwenden.

•

Unterschiedliche Datenmodelle und Datenformate. Applikationen repräsentieren gleiche Geschäftskonzepte (z.B. „Kunde“) mit unterschiedlichen Datenmodellen oder verwalten Daten in unterschiedlichen Datenformaten (z.B. XML-Files, relationale Datenbanken, proprietäre Formate eines Softwareherstellers).

•

Unterschiedliche Funktionsmodelle. Eine Applikation verhält sich beim Ausführen einer Funktion nicht wie von einer anderen Applikation erwartet. Bspw. ruft ein Vertriebsportal die Preisfindungsfunktion eines Warenwirtschaftssystems auf und erwartet, dass dieses kundenspezifische Konditionen für die Preisberechnung anwendet. Stattdessen erhält es Standard-Katalogpreise zurückgeliefert.

1.2 Nutzen und Adressaten des Buches

3

•

Prozessabhängigkeit. Geschäftslogik ist in Applikationen so implementiert, dass Abläufe nur ganz oder gar nicht verändert werden können. Eine lokale Änderung einer Applikationskomponente (z.B. ein Upgrade oder eine funktionale Erweiterung) ist nicht möglich, da die Auswirkungen auf die anderen Komponenten nicht abschätzbar sind. Eine serviceorientierte Architektur (SOA) verspricht, die inner- und zwischenbetriebliche Integration heterogener Anwendungssysteme zu vereinfachen. Eine SOA ist eine geschäftsorientierte, mehrschichtige IS-Architektur, die Teile von Applikationen für eine vereinfachte Prozessintegration kapselt. Sie soll künftig die Anwendungslogik als autonome, plattformunabhängige Services (bzw. Dienste) bereitstellen, die sich dann beliebig verteilen und dynamisch zu Geschäftsprozessen verknüpfen lassen [Curbera et al. 2003, 30]. Gartner rechnet dank SOA mit einer Reduktion des Applikationsentwicklungs- und Integrationsaufwands um 20% [Feiman/Hotle 2004, 1] und sagt voraus, dass 2009 über 80% der neu entwickelten Applikationen auf Services basieren werden [Hayward 2005, 2]. Aberdeen Group prognostiziert den Global 2000 Unternehmen über die nächsten fünf Jahre Kosteneinsparungen von insgesamt 53 Mrd. USD bei höherer Leistungsfähigkeit und Flexibilität des IS [Mougayar 2005, 3]. Solchen Visionen stehen bisher nur beschränkt Erfahrungen mit der Umsetzung des SOA-Konzeptes und seinem produktiven Einsatz gegenüber (s. [Wilhelmi et al. 2005], [Mougayar 2005]). Viele Unternehmen äussern bspw. Unsicherheit bezüglich der Fragen •

welche Nutzenpotenziale eine SOA realisiert und für welche Problemstellungen sich ihr Einsatz eignet,

•

was „gute“ Services auszeichnet, welche Granularität sie aufweisen und welche Designprinzipien sie befolgen oder

•

welche Fähigkeiten, Architekturmanagement-Massnahmen und Organisationsformen eine SOA innerhalb des IT-Bereichs erfordert (s. [Hayward 2005, 10], [Quack 2004a]).

1.2

Nutzen und Adressaten des Buches

Dieses Buch entstand im Rahmen der Kompetenzzentren Business Networking 2 (CC BN2, 2002-2004) und Business Networking 3 (CC BN3, 2004-2006) am Institut für Wirtschaftsinformatik der Universität St. Gallen (IWI-HSG) als Teil des Forschungsprogramms „Business Engineering HSG“. Verschiedene Projekte den Kompetenzzentren dienten dazu, Problemstellungen und Potenziale von SOA zu identifizieren sowie Lösungsansätze zu entwickeln. Fragestellungen und Lösungsvorschläge wurden in Workshops mit einzelnen Unternehmen sowie in regelmässigen unternehmensübergreifenden Arbeitsgruppen-Meetings mit den Industriepartnern des CC BN3 diskutiert. Die begleitende Erhebung von Fallstudien bei Deutsche Post Brief, Credit Suisse, T-Com und Zuger Kantonalbank validierte theoretische Modelle und identifizierte Treiber, Potenziale, Herausforderungen sowie bewährte Architekturmassnahmen zur Einführung einer SOA.

4

1 Einleitung

Ziel des vorliegenden Buches ist, den Architekturansatz SOA hinsichtlich seiner Potenziale zu untersuchen und Unternehmen Handlungsempfehlungen für die Umsetzung einer SOA in der IS-Architektur zu geben. Dazu erarbeitet es folgende Kernergebnisse: •

Ein Architekturmodell definiert die wichtigsten Architekturelemente einer SOA sowie ihre Beziehungen zueinander. Die Publikation ordnet SOA im Architekturmodell des Business Engineering1 ein und beschreibt grundlegende Designprinzipien für Services und weitere SOA-Architekturelemente.

•

Vier Fallstudien untersuchen Ausprägungen von SOA in der Praxis. Sie beschreiben Architekturtreiber und Ziele der untersuchten Unternehmen. Sie zeigen weiter, welche Massnahmen zur Einführung einer SOA notwendig waren, welche Nutzenpotenziale sich realisieren liessen und welchen Herausforderungen die Unternehmen begegnen mussten.

•

Das Buch gibt methodische Hilfestellung für die Einführung einer SOA in der IS-Architektur und gibt Handlungsempfehlungen für verschiedene Architekturmanagement-Fragestellungen. Dazu gehören: − Eine Systematisierung von Architekturtreibern, Nutzenpotenzialen und Zielen einer SOA, − nach Zielen prorisierte Service-Designprinzipien und Messgrössen zur Architektursteuerung, − ein Vergleich von Ansätzen zur Strukturierung der Applikationsarchitektur im Rahmen einer SOA und für den Entwurf von Services in Applikationsentwicklungs- und Integrationsprojekten sowie

− zu definierende Architekturrollen für die Einführung und laufende Weiterentwicklung einer SOA. Dieses Buch richtet sich mit diesen Ergebnissen an Praktiker und Personen aus der Wissenschaft, die sich mit SOA und der Entwicklung und dem Management von Applikations- und Integrationsarchitekturen auseinandersetzen: IS-Architekturverantwortliche, Applikations- und Integrationsarchitekten unterstützt das Buch bei der Identifikation von Anwendungsfeldern und Nutzenpotenzialen einer SOA im eigenen Unternehmen. Es zeigt Massnahmen und Handlungsoptionen für ihre Umsetzung auf. Die detaillierte Darstellung der Fallstudien erlaubt Praktikern, Erfahrungen und erfolgreiche Konzepte anderer Unternehmen auf die eigenen Problemstellungen zu übertragen. Forschende unde Lehrende unterstützt das Architekturmodell bei der Einordnung des Architekturansatzes im Forschungsgebiet Unternehmensarchitekturen. Eine Konsolidierung aktueller Literatur zu SOA-Designprinzipien leistet einen Beitrag zur besseren Charakterisierung der Serviceorientierung und ihrer Abgrenzung von der objekt- oder komponentenorientierten Systementwicklung. Die Fallstudien zeigen den Stand der Umsetzung von SOA in der Praxis und können als Grundlage für eigene Forschungstätigkeiten oder die Lehre dienen.

1

s. Kap. 2.2

1.3 Aufbau des Buches

1.3

5

Aufbau des Buches

Abb. 1-1 gibt einen Überblick über den Aufbau des Buches und zeigt die Zusammenhänge zwischen einzelnen Kapiteln. Kapitel 1 schildert Herausforderungen heutiger IS-Architekturen und grenzt den Adressatenkreis und den Nutzen der Publikation ab. Kapitel 2 fasst die wesentlichen Grundlagen der Publikation zusammen. Es definiert den Begriff Architektur, gibt einen Überblick über das Business Engineering Modell und das Integrationsmodell als Strukturierungsrahmen für Unternehmensarchitekturen. Es ordnet weiter den Untersuchungsgegenstand des Buches im Informations- und Architekturmanagement ein. Kapitel 3 entwickelt auf Basis dieser Grundlagen ein Architekturmodell für SOA bestehend aus Ebenen, Sichten, Architekturkomponenten und Designprinzipien, grenzt SOA als Architekturstil von verwandten Ansätzen ab und geht auf Technologien und Produkte für die technische Implementierung von SOA ein. Kapitel 4 beschreibt die konkrete Ausprägung des SOA-Architekturmodells und der Designprinzipien in vier Fallstudien und identifiziert Treiber, Nutzenpotenziale, Herausforderungen und Architekturmassnahmen einer SOA-Umsetzung. Kapitel 5 detailliert Massnahmen zur Einführung und Weiterentwicklung einer SOA. Es geht auf projektübergreifende Aufgaben des Architekturmanagements ein sowie auf die Identifikation und den Entwurf von Services in Applikationsentwicklungs- und Integrationsprojekten. Es beschreibt ausserdem Architekturrollen im Umfeld einer SOA. Kapitel 6 fasst die Ergebnisse des Buches zusammen und gibt einen Ausblick auf zukünftige Entwicklungen.

6

1 Einleitung Kapitel 1

Einführung

Kapitel 2

Grundlagen Architekturbegriff Integrationsmodell

Unternehmensarchitektur und Business Engineering

Architekturmanagement als Teil des Informationsmanagements

Kapitel 3

Prinzipien serviceorientierter Architekturen Serviceorientierte Architektur Designprinzipien

Architekturmodell und Architekturkomponenten

Abgrenzung der Serviceorientierung von verwandten Ansätzen Technologien und Produkte zur Implementierung von SOA

Kapitel 4

Fallbeispiele zu SOA Deutsche Post Brief

Credit Suisse

T-Com

Zuger Kantonalbank

Erkenntnisse aus den Fallstudien

Kapitel 5

Architekturmanagement und Servicedesign Übergreifendes Architekturmanagement IS-Entwicklung SOA-Ziele, Architekturprinzipien und Architektursteuerung Serviceidentifikation und Servicedesign Entwicklung der Domänenarchitektur

Architekturrollen und Verantwortlichkeiten Organisation

Kapitel 6

Zusammenfassung und Ausblick

Abb. 1-1: Aufbau des Buches

2

Grundlagen

Die folgenden Abschnitte beschreiben die grundlegenden Begriffe und Modelle, auf denen dieses Buch basiert. Als Grundlage für das Architekturverständnis im Kontext von SOA definiert Kap. 2.1 den Begriff Architektur allgemein. Für eine spätere Einordnung einer SOA in der Unternehmensarchitektur gibt Kap. 2.2 einen Überblick über das Business Engineering Modell. Schwerpunkt der Publikation bildet die Ebene des Informationssystems und dort besonders die Integrationsarchitektur. Kap. 2.3 stellt deshalb ein Ebenen- und Sichtenmodell für Integrationsarchitekturen als Basis für ein SOA-Architekturmodell vor. Im Hinblick auf Massnahmen zur Einführung und Weiterentwicklung einer SOA geht Kap. 2.4 auf das Thema Architekturmanagement und seine Einordnung im Informationsmanagement ein.

2.1

Architekturbegriff

Architekturen unterstützen die Realisierung physischer oder logischer Systeme, indem sie die grundlegenden Strukturen ihrer Systemkomponenten und ihre Beziehungen zueinander beschreiben sowie Richtlinien für ihr Design und ihre Weiterentwicklung geben (vgl. [Shaw/Garlan 1996, 1], [Alt 2004, 124]). Sie besitzen einen Beschreibungsaspekt und einen Konstruktionsaspekt [s. Sinz 1997, 875]: Unter dem Beschreibungsaspekt dokumentiert eine Architektur im Sinne eines Bauplans die Komponenten eines Systems und ihre Beziehungen untereinander in einem Modellsystem, welches alle relevanten Modellebenen und die Sichten auf diese Modellebenen definiert. Eine Modellebene beschreibt dabei das System umfassend aus einem bestimmten Blickwinkel. Beispiele im Umfeld von Unternehmensarchitekturen sind der Aufgaben-, der Aufgabenträger- oder der Informationssystemblickwinkel [s. Sinz 1997, 875]. Zur Komplexitätsreduktion betrachtet eine Architektur Modellebenen aus verschiedenen Sichten. Eine Sicht beschreibt jeweils einen Teilaspekt der Modellebene, alle Sichten zusammen beschreiben sie – bezüglich des Ziels des Modells – vollständig. Bspw. lässt sich die Modellebene Informationssystem aus einer Daten-, einer Funktions- oder einer Verteilungssicht modellieren [s. Zachman 1987, 463]. Die Beziehung zwischen den Modellebenen wird durch die Verknüpfung von Gestaltungsobjekten einer Ebene mit Gestaltungsobjekten der darunter und darüber liegenden Ebenen definiert. So lässt sich zum Beispiel ein Gestaltungsobjekt „Funktion“ der Modellebene Informationssystem mit einem Gestaltungsobjekt „Aufgabe“ der Ebene Prozess verknüpfen [Österle/Blessing 2003, 81]. Unter dem Konstruktionsaspekt umfasst eine Architektur Regeln in Form von Vorschriften für die Erstellung des Modellsystems. Konstruktionsregeln definieren die für die Konstruktion verfügbaren Bausteine, die Beziehungen zwischen ihnen sowie Konsistenzbedingungen für ihre Verwendung. Sie können z.B. in Form von Methoden, Architekturmustern oder Architekturstilen ausgeprägt sein. Methoden stellen die Konsistenz der Entwurfsaktivitäten auf den verschiedenen Modellebe-

8

2 Grundlagen

nen sicher, indem sie Vorgehensmodelle (Entwurfsaktivitäten und ihre Ablauffolge), Techniken (Anleitungen zur Ergebniserarbeitung), Ergebnisdokumente, Rollen (Zuordnung von Entwurfsaktivitäten zu Ausführenden) und MethodenMetamodelle (Definition der Gestaltungsobjekte einer Methode in einem Datenmodell) definieren [s. Gutzwiller 1994, 11f.]. Architekturmuster bieten auf heuristischem Modellierungswissen basierende generische Lösungsansätze für wiederkehrende Designprobleme (vgl. [Alexander 1977], [Hasselbring 2006]). Einen Architekturstil definiert [Fielding 2000, 13] als „a coordinated set of architectural constraints that restricts the roles / features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style”. Beispiele von Architekturstilen für Informationssysteme sind Mainframe-, Client/Server-, Peer-to-Peer-, komponenten- und serviceorientierte Architekturen (s. [Hasselbring 2006, 48f.], [Alt 2004, 115ff.]). Die vorliegende Publikation baut auf diesem Architekturverständnis auf. Sie entwickelt ein Ebenenmodell für SOA (Beschreibungsaspekt) und charakterisiert SOA als Architekturstil mit einer Menge von Architekturkomponenten und Designprinzipien (Konstruktionsaspekt).

2.2

Unternehmensarchitektur und Business Engineering

Gestaltungsrahmen für die Anpassung des Unternehmens an geänderte Anforderungen ist die Unternehmensarchitektur. Eine Unternehmensarchitektur definiert ein Modellsystem und Konstruktionsregeln für die Beschreibung und Planung von Geschäftslösungen bzw. der Unternehmenswertschöpfung [s. Sinz 2004, 315]. Betrachtungs- und Gestaltungsebenen sind typischerweise Strategien und Marktleistungen eines Unternehmens, Geschäftsprozesse, Organisationsstrukturen sowie unterstützende Ressourcen (s. [Winter 2004 318], [Aier/Dogan 2004, 81]). Beispiele für Ansätze zur unternehmensweiten Modellierung und Konstruktion von Architekturen sind das Zachmann Framework [s. Zachman 1987], das Open Group Architecture Framework (TOGAF) [s. Open Group 2003], das Architekturmodell von [Krcmar 1990], das Business Engineering Modell [s. Österle/Blessing 2003], ARIS [s. Scheer 1998] oder das Semantische Objektmodell (SOM) [s. Ferstl/Sinz 1995].2 Dieses Buch orientiert sich zur Beschreibung und Strukturierung von Unternehmensarchitekturen am Business Engineering Modell (s. [Österle/Blessing 2003], [Winter 2003b]). Die Forschungsdisziplin Business Engineering wurde am Institut für Wirtschaftsinformatik der Universität St. Gallen entwickelt. Sie stellt eine methoden- und modellbasierte Konstruktionslehre zur Transformation von Unternehmen dar und beschäftigt sich mit Problemstellungen, die aus der Transformation der Industrie- in die Informationsgesellschaft erwachsen [s. Österle/Winter

2

Für einen vergleichenden Überblick über die Modelle s. bspw. [Sinz 1997], [Bernus et al. 1998], [Leist 2004] oder [Blowers et al. 2004, 37ff.].

2.2 Unternehmensarchitektur und Business Engineering

9

2003]. Business Engineering geht davon aus, dass Informationstechnologie ein wesentliches Hilfsmittel für Unternehmen ist, um am Markt erfolgreich zu sein. Der Ansatz unterscheidet Gestaltungsobjekte einer Unternehmenstransformation auf den drei Ebenen Geschäftsstrategie, Geschäftsprozesse und Informationssysteme [s. Österle/Blessing 2003, 81] (s. Abb. 2-1): Strategie

Geschäftsarchitektur

Prozess

Prozessarchitektur

System

Integrationsarchitektur Applikationsarchitektur Infrastrukturarchitektur

Abb. 2-1: Ebenen und Architekturen des Business Engineering Modells Auf der Ebene der Geschäftsstrategie werden die Entscheidungen zur mittel- bis langfristigen Entwicklung eines Unternehmens getroffen. Hierzu zählen bspw. die Positionierung im Wertschöpfungsnetzwerk und die Festlegung der Marktleistungen. Dabei sind auf der einen Seite Kundenbedürfnisse und Wettbewerbssituation („market based view“), auf der anderen Seite die eigenen Kernkompetenzen („resource based view“) zu berücksichtigen [s. Müller-Stewens/Lechner 2001, 17]. Die Geschäftsarchitektur legt die Grundsätze des Geschäfts fest und beschreibt auf der strategischen Ebene den Gesamtzusammenhang der Leistungsverflechtung in einem Wertschöpfungsnetzwerk, d.h. was ein Unternehmen wie erreichen will und welche Markt- und Wettbewerbsposition es dabei einnimmt [s. Alt 2004, 170]. Die Ebene der Geschäftsprozesse setzt die strategischen Entscheidungen um. Ein Prozess erbringt die Leistungen des Unternehmens und beinhaltet eine Abfolge von Aufgaben, die bestimmten Aufgabenträgern zugeordnet sind. Die Prozessarchitektur beschreibt den Gesamtzusammenhang der Leistungsentwicklung, der Leistungserstellung und des Leistungsvertriebs [s. Winter 2004, 318]. Sie hilft, die Aufgabenverteilung und Abläufe innerhalb und zwischen Organisationen zu definieren und bestimmt die Leistungsfähigkeit von Prozessen bezüglich Effizienz, Kundennutzen etc. [vgl. Alt 2004, 141]. Die Ebene Informationssystem (IS) unterstützt die Prozessebene informationstechnisch. Zur Abwicklung von Geschäftsprozessen kommen Anwendungen bzw. Applikationen zum Einsatz, die eine Menge von Funktionen unter Rückgriff auf Datensammlungen zur Verfügung stellen. Basis für die Implementierung von Applikationen bilden IT-Komponenten in Form von Hardware, Netzwerken oder Systemsoftware. Die Systemarchitektur überführt Entscheidungen auf Strategieund Prozessebene in die Strukturierung von Applikationen, Datensammlungen

10

2 Grundlagen

und Integrationsbeziehungen und umfasst die Gesamtheit der computergestützten Informationsverarbeitung innerhalb eines Unternehmens (vgl. [Vogler 2004, 40], [Alt 2004, 182]). Die Systemarchitektur lässt sich in weitere Teilarchitekturen gliedern: •

Die Applikationsarchitektur beschreibt die informationstechnischen Komponenten zur Unterstützung der Prozessarchitektur aus einer logischen, funktionalen Sicht (vgl. [Schwarze 1998, 127], [Puschmann 2003, 32]). Sie umfasst Anwendungssysteme, d.h. Transaktions- und Datenbanksysteme, welche Funktionen und Daten zur Unterstützung betrieblicher Aufgaben halten (s. [Mertens et al. 1997, 37], [Vogler 2004, 41]).3

•

Die Integrationsarchitektur beschreibt die Kopplung verteilter Funktionen und Daten über Applikationen hinweg [vgl. Schwinn 2006a]. Sie bietet Middlewarekomponenten mit standardisierten Schnittstellen und Protokollen und unterstützt eine transparente Kommunikation zwischen Applikationen, indem sie die Heterogenität von Systemplattformen überbrückt (s. [Alonso et al. 2003, 30], [Vogler 2004, 31]).

•

Die Infrastrukturarchitektur umfasst Plattform- und Netzwerkkomponenten für den Betrieb von Middleware und Applikationen [s. Puschmann 2003, 33]. Sie wird in diesem Buch nicht betrachtet. Zwischen den drei Ebenen des Business Engineering Modells bestehen Wechselbeziehungen: Neue Geschäftsstrategien sind erst dann wirksam, wenn sie sich in operativen Geschäftsprozessen und unterstützenden Informationssystemen niederschlagen. Umgekehrt können neue technische Potenziale Anpassungen an Geschäftsprozessen oder der Geschäftsstrategie auslösen und Restriktionen des Informationssystems die Gestaltungsfreiheit auf Geschäfts- und Prozessebene beschränken. Innovationen werden deshalb erst dann wirksam, wenn sie auf allen Ebenen umgesetzt sind [s. Österle 1995, 18].

2.3

Integrationsmodell

Für die spätere Betrachtung serviceorientierter Architekturen sind die Applikations- und besonders die Integrationsarchitektur von Bedeutung. Die folgenden Abschnitte beschreiben ein Sichten- und Ebenenmodell der Systemintegration [s. Vogler 2004, 53ff.], das im weiteren Verlauf dieses Buches als Grundlage für die Strukturierung der Architekturkomponenten einer SOA und ihrer Einordnung in der Unternehmensarchitektur dient: Die Ebene Desktopintegration vereint die zur Erfüllung von Aufgaben notwendigen betrieblichen Anwendungen an einem Arbeitsplatz. Sie rückt die Sichtweise einer Mitarbeiter- bzw. Benutzerrolle in den Vordergrund. Die Ablaufsteuerung eines rollen- und applikationsübergreifenden Geschäftsprozesses ist Gegenstand

3

Die Begriffe Anwendungssystem, Anwendung und Applikation werden in diesem Buch synonym verwendet.

2.3 Integrationsmodell

11

der Ebene Workflowintegration.4 Während die Ebenen Desktop- und Workflowintegration die übergreifende, prozessorientierte Kopplung von Applikationen betrachten, beschreibt die Ebene Anwendungssystem die Integrationsbeziehung zwischen zwei Anwendungssystemen auf Präsentations-, Funktions- oder Datenebene.5 Das Modell unterscheidet in Anlehnung an [Schwinn 2006a, 17] eine anwendungsbezogene Sicht und eine anwendungsneutrale Sicht. Die anwendungsbezogene Sicht konzentriert sich auf Architekturkomponenten, die fachliche Logik umsetzen (Applikationslogik, Workflows etc.). Die anwendungsneutrale Sicht beschreibt Integrationsmechanismen und Infrastrukturkomponenten ohne unmittelbaren fachlichen Bezug, die Dienste und Protokolle zur Implementierung der Systemintegration bereitstellen [s. Mantel et al. 2004, 4]. Abb. 2-2 gibt einen Überblick über die Ebenen, Sichten und wesentlichen Komponenten des Integrationsmodells.

Ebene Desktopintegration Perspektive Benutzerinteraktion

Ebene Workflowintegration Perspektive Ablaufsteuerung von Geschäftsprozessen

Ebene Anwendungssystem Perspektive Ressourcen

Anwendungsbezogene Sicht (Anwendungslogik)

Anwendungsneutrale Sicht (Integrationsmechanismen)

• • • •

• Portalplattformen / Composite-Application (CA) -Plattformen

Prozessportale Rollen Taskflows Tasks

• Workflows • Aktivitäten

• Workflow Management Systeme • Message Broker

• Applikationen • Funktionen • Informationsobjekte

• Applikationsschnittstellen • Middlewaredienste für Daten-, Funktions- oder Präsentationsintegration

Abb. 2-2: Ebenen, Sichten und Hauptkomponenten des Integrationsmodells 2.3.1

Ebene Anwendungssystem

Anwendungsbezogene Architekturkomponenten Die Ebene Anwendungssystem umfasst betriebliche Anwendungssysteme, die Applikationsfunktionen und Datensammlungen bzw. Informationsobjekte zur automatisierten Unterstützung von Geschäftsprozessen implementieren [s. Vogler 2004, 88f.]. Sie repräsentiert in diesem Modell die Ressourcensicht, welche die im IS vorhandene, potenziell zur Unterstützung betrieblicher Aufgaben nutzbare, fachliche Funktionalität enthält. Die anwendungsbezogene Sicht betrachtet auf 4

5

Um Verwechslungen zwischen Konzepten auf der Prozess- und der Systemebene der Business Engineering Architektur zu vermeiden, verwendet diese Publikation in Abweichung von [Vogler 2004, 54] den Begriff „Workflowintegration“ anstatt „Prozessintegration“. [Vogler 2004, 56] bezeichnet die Konzepte auf dieser Ebene als „Systemintegration“. Da auch die restlichen Ebenen Formen der Integration auf Systemebene behandeln und um herauszuheben, dass diese Ebene primär die von einer Applikation zur Verfügung gestellten Integrationsmechanismen betrachtet, wird hier der Begriff „Anwendungssystem“ verwendet.

12

2 Grundlagen

dieser Ebene den Anwendungssystem-Kern, der die eigentliche fachliche Logik in Form der Applikationsfunktionalität und Datenverwaltung enthält [s. Schissler et al. 2002, 460]. Moderne Anwendungssysteme sind mehrschichtig aufgebaut. Typischerweise werden die logischen Schichten Präsentation, Applikationsfunktionalität und Datenhaltung unterschieden, die sich je nach Architekturstil anders in einem Netzwerk verteilen lassen (s. [Alonso et al. 2003, 4ff.], [Riehm/Vogler 1996b, 29]). Die Präsentationsschicht ist für die Informationspräsentation und die Steuerung der Ein- und Ausgaben von bzw. an Nutzer des Anwendungssystems zuständig, z.B. über eine grafische Benutzerschnittstelle (Graphical User Interface, GUI). Die Applikationsfunktionalitätsschicht implementiert die fachliche Logik des Anwendungssystems in Form von Programmen bzw. Operationen. Die Datenhaltungsschicht verwaltet die vom Anwendungssystem für die Ausführung der Programme benötigten Informationsobjekte. Abb. 2-3 zeigt mögliche Verteilungen dieser Anwendungsschichten für die Architekturstile Mainframe, Client/ Server und Peer-to-Peer. Client/Server-Architektur

Peer-to-Peer-Architektur

Thin Client

Client

Peer

Präsentation

Datenhaltung

Mainframe

Applikationsfunktionalität

Anwendungssystem

Applikationsfunktionalität

Anwendungssystem

Präsentation (Benutzerinteraktionslogik)

Präsentation

Applikationsfunktionalität

Datenhaltung

Präsentation

Applikationsfunktionalität

Datenhaltung

Datenhaltung

Server

Peer

Anwendungssystem

Präsentation (Darstellung)

Anwendungssystem

Mainframe-Architektur

Abb. 2-3: Verteilung von Anwendungsschichten in Anlehnung an [Alonso et al. 2003, 11f.] Anwendungsneutrale Architekturkomponenten Betrachtungsgegenstand der anwendungsneutralen Sicht sind auf dieser Ebene Applikationsschnittstellen und Integrationsmechanismen, die den Zugriff auf Funktionen oder Daten einzelner Anwendungssysteme erlauben [s. Schissler et al. 2002, 460]. Basierend auf den drei logischen Anwendungsschichten lassen sich dabei die Daten-, die Funktions- und die Präsentationsintegration unterscheiden.

2.3 Integrationsmodell

13

Datenintegration Bei der Datenintegration kommunizieren zwei Anwendungssysteme, indem sie direkt auf die von den jeweiligen Systemen gespeicherten Daten zugreifen [s. Ruh et al. 2001, 63] (s. Abb. 2-4). Diese Form der Integration ermöglicht die gemeinsame Nutzung von Daten durch mehrere Anwendungssysteme unter Umgehung der Präsentations- bzw. Anwendungslogik [s. Mantel/Schissler 2002, 173]. Die datenorientierte Integration basiert entweder auf Datenschnittstellen (1), der Replikation zwischen Datenbanken (2) oder der Datenföderation (3) (vgl. [Linthicum 2000, 28ff.], [Kaib 2002, 64]). Bei einer Datenreplikation tauschen Datenspeicher physische Kopien von Datensätzen aus, die in den zu integrierenden Datenspeichern redundant vorliegen. Die Datenföderation bindet heterogene Datenquellen in ein einheitliches Datenschema ein (virtuelle Datenbank). Über diese einheitliche Sicht wird auf die physisch verteilten, nicht-redundanten Datenquellen zugegriffen. Präsentation

Präsentation

Applikationsfunktionalität

Applikationsfunktionalität 1

Datenhaltung 3

2

Virtuelle Datenbank

Datenhaltung 3

Abb. 2-4: Ansätze der Datenintegration (s. [Riehm/Vogler 1996a, 30], [Linthicum 2003, 8]) Aufgrund der frühen Entwicklung und weiten Verbreitung der Datenintegration haben sich eine Reihe datenorientierter Integrationsmechanismen herausgebildet. Diese umfassen bspw. datenorientierte Middleware wie Open DataBase Connectivity (ODBC) / Java DataBase Connectivity (JDBC), Replikationsmechanismen relationaler Datenbankmanagementsysteme sowie umfangreiche Integrationsmechanismen in Form föderierter Datenbankmanagementsysteme oder ExtractionTransformation-Load (ETL)-Werkzeuge. Funktionsintegration Die Funktionsintegration ist eine Integrationsform auf Ebene der Anwendungslogik (s. Abb. 2-5). Ihr Grundkonzept besteht darin, einzelne Teilfunktionen von Applikationen nach aussen als Dienste anzubieten und somit die gemeinsame Nutzung von Funktionalität durch mehrere Anwendungssysteme zu ermöglichen (vgl. [Ruh et al. 2001, 27ff.], [Kaib 2002, 65ff.]). Funktionsorientierte Integrationsmechanismen werden häufig unter dem Begriff funktionaler Middleware zusammengefasst.

14

2 Grundlagen

Präsentation

Präsentation

Applikationsfunktionalität

Applikationsfunktionalität

Datenhaltung

Datenhaltung

Abb. 2-5: Funktionsintegration [s. Riehm/Vogler 1996a, 30] Den grundlegenden Mechanismus zur funktionalen Integration von Anwendungssystemen stellt der Remote Procedure Call (RPC) dar. RPCs erlauben den Aufruf einer Prozedur bzw. Methode, die eine andere Applikation zur Verfügung stellt, über ein Netzwerk. Sogenannte Stubs bzw. Skeletons, die bei der aufrufenden und der aufgerufenen Applikation implementiert sind, übernehmen dabei die transparente Umsetzung des Methodenaufrufs in einen Nachrichtenaustausch, so dass sich für einen Entwickler der entfernte Aufruf syntaktisch nicht von einem lokalen unterscheidet [s. Riehm 1997, 142]. In der Regel sind RPCs synchron, d.h. die aufrufende Anwendung blockiert, bis die aufgerufene Prozedur beendet ist bzw. ein Ergebnis geliefert hat. Bei der Integration mehrerer Systeme mit einer komplexen Folge von Funktionsaufrufen über RPCs ist eine Synchronisierung der Aufrufe nötig, um eine konsistente Integration zu garantieren. Transaction Processing Monitors (TP Monitore) erweitern RPCs um die Möglichkeit der Transaktionsverarbeitung (vgl. [Alonso et al. 2003, 33], [Schelp/Winter 2002, 13]). Ihre Hauptaufgabe besteht darin, die Einhaltung der sog. ACID-Kriterien (Atomicity, Consistency, Isolation, Durability) zu überwachen. Object Broker und Object Monitors bilden das objektorientierte Gegenstück zu den prozeduralen RPCs und TP Monitoren. Object Broker ermöglichen den transparenten Aufruf von Methoden verteilter Objekte und wurden z.B. für die Common Object Request Broker Architecture (CORBA) umgesetzt. Object Monitors kombinieren diese Funktionalität mit der Funktionalität eines TP Monitors für einen transaktionalen Zugriff auf Objekte [vgl. Alonso et al. 2003, 59]. Mit Komponentenstandards wie J2EE Enterprise Java Beans (EJB) von Sun Microsystems wurde diese objektorientierte Middleware zu (Web-) Application Servern weiterentwickelt. Application Server bündeln verschiedene funktionale Integrationsmechanismen und erlauben den Zugriff auf gekapselte Anwendungslogik über standardisierte Web-Protokolle wie bspw. das HyperText Transfer Protocol (HTTP) [vgl. Sinz et al. 2000, 552]. Message Oriented Middleware (MOM) bietet weitere Möglichkeiten der Funktionsintegration über Nachrichtenaustausch. Durch den Nachrichtenaustausch über eine Warteschlange (Message Queue) unterstützt MOM neben der synchronen auch die asynchrone Kommunikation zwischen Anwendungen. Die beteiligten Systeme müssen somit weder laufend aktiv sein, noch blockiert ein System beim Aufruf einer Funktion eines anderen Systems bis zum Erhalt des Ergebnisses.

2.3 Integrationsmodell

15

Präsentationsintegration Unter Präsentationsintegration versteht man die Integration verschiedener Anwendungssysteme auf der Ebene der Darstellungs- bzw. Präsentationslogik (s. Abb. 2-6). Die Zusammenführung der zu integrierenden Systeme geschieht manuell (1) oder über die Simulation eines Benutzerdialogs (2, eine Applikation greift über die Präsentationsschicht auf Funktionen einer anderen Applikation zu) und stellt insofern lediglich eine „Notlösung“ für die Integration zweier Anwendungssysteme dar [s. Kaib 2002, 62]. Präsentation

1

Präsentation

2 Applikationsfunktionalität

Applikationsfunktionalität

Datenhaltung

Datenhaltung

Abb. 2-6: Ansätze der Präsentationsintegration [s. Riehm/Vogler 1996a, 30] 2.3.2

Ebene Workflowintegration

Anwendungsbezogene Architekturkomponenten Die Workflowintegration umfasst Beschreibungen und Umsetzungen von Ablauflogik zur Steuerung anwendungsübergreifender Geschäftsprozesse [s. Vogler 2004, 54]. Die Grundidee der Workflowintegration besteht in der Trennung von Ablauf- und Anwendungslogik, d.h. im Herauslösen fest programmierter Prozesslogik aus einzelnen Applikationen [s. Kaib 2002, 119ff.]. Im Rahmen einer Workflowintegration ist die Ablauflogik des Integrationssystems in Form eines ausführbaren Prozessmodells – eines Workflows – definiert. Ein Workflow stellt zur Ausführungszeit einen automatisierten (Teil-) Prozess dar, der Dokumente, Informationen oder Aufgaben anhand bestimmter Regeln von einer bearbeitenden Ressource zur nächsten weiterleitet [s. WFMC 1999, 8]. Er setzt sich aus einer Abfolge von Aktivitäten zusammen, die jeweils logische und fachlich zusammengehörende Arbeitsschritte innerhalb des automatisierten Prozesses gruppieren [s. Vogler 2004, 39f.]. Ein Arbeitsschritt ist eine elementare, nicht weiter zerlegbare Verrichtungseinheit. Arbeitsschritte werden unter Nutzung von Ressourcen ausgeführt, d.h. entweder manuell durch Personen oder automatisiert durch IT-Applikationen. Anwendungsneutrale Architekturkomponenten Eine Middlewaregrundlage für die applikationsübergreifende Workflowintegration sind Message Broker, oft auch als Integration Broker bezeichnet [s. Linthicum 2003, 154]. Message Broker sind Weiterentwicklungen von MOM. Sie zentralisieren Transformations-, Routing- und Filtermechanismen und realisieren eine ge-

16

2 Grundlagen

meinsame Kommunikationsinfrastruktur zwischen Applikationen in Form einer „hub-and-spoke“ bzw. „bus“-Architektur (s. Abb. 2-7, [Alonso et al. 2003, 71], [Keen et al. 2004, 78]). Damit unterstützen sie bspw. die Gruppenkommunikation nach dem Publish / Subscribe-Modell, bei welchem sich Anwendungen, die bestimmte Nachrichten erhalten wollen (subscriber), beim Message Broker registrieren. Die sendende Anwendung (publisher) muss dadurch die Empfänger nicht kennen. Sie liefert die Nachricht nur einmal an den Message Broker, welcher Kopien an die einzelnen Empfänger weiterleitet. Hub-and-spoke-Architektur

Applikation Applikation

Applikation Message Broker (Hub)

Applikation

Bus-Architektur Applikation

Applikation

Hub

Hub Hub

Applikation

Applikation Applikation

Abb. 2-7: Hub-and-spoke- und Bus-Architektur [vgl. Keen et al. 2004, 78] Die Entwicklung und Steuerung applikationsübergreifender Prozesse unterstützen Workflow Management-Systeme (WFMS) bzw. Business Process ManagementSysteme (BPMS), die auf der Adapter- und Kommunikationsschicht von Message Brokern aufbauen können [s. Alonso et al. 2003, 71]. Verschiedene Autoren fassen BPM als einen auf WFM aufbauenden „nächsten Schritt“ auf, der den Ansatz des WFM weiterentwickelt und besonders um Konzepte zur Analyse automatisierter Prozesse (Business Process Monitoring) ergänzt [s. van der Aalst et al. 2003, 4ff.]. WFM und BPM basieren aber auf den gleichen grundlegenden Integrationstechnologien und -konzepten (s. [Zhao/Cheng 2005, 3], [Zur Muehlen 2004, 2]), weshalb sie hier als gleichwertig angesehen werden. Die folgende Charakterisierung workfloworientierter Integrationsmechanismen basiert auf der Begriffswelt des WFM, lässt sich jedoch ohne weiteres auf die Begriffe aus dem Bereich BPM übertragen. WFMS bieten Werkzeuge zur Definition und zur automatischen Ausführung von Workflows (s. Abb. 2-8). Die Entwicklungsumgebung stellt Werkzeuge zur Definition von Workflow-Modellen zur Verfügung, welche in einer Datenbank, dem sog. Workflow Model Repository, verwaltet werden. Ein Workflow-Modell stellt eine automatisierbare Repräsentation eines Geschäftsprozesses dar [s. WFMC 1999, 52]. Die Laufzeitumgebung instanziiert zur Ausführungszeit die WorkflowModelle und verwaltet Statusinformationen im Workflow Instance Repository.

2.3 Integrationsmodell

17

Entwicklungsumgebung

WF Model Repository

WF Instance Repository

Laufzeitumgebung

Applikation

Abb. 2-8: Komponenten eines WFMS [vgl. Zur Muehlen 2004, 117]

2.3.3

Ebene Desktopintegration

Anwendungsbezogene Architekturkomponenten Die Desktopintegration stellt eine spezielle Form der Prozessintegration dar [s. Vogler 2004, 54]. Sie verfolgt das Ziel, dem Benutzer alle zur Erfüllung einer Aktivität notwendigen Anwendungssysteme an seinem Arbeitsplatz integriert zur Verfügung zu stellen [s. Vogler 2004, 84]. Die desktoporientierte Architekturebene realisiert die Einbindung der verschiedenen Applikationen im Arbeitsablauf und die Darstellung der erforderlichen Informationen in einer einheitlichen Benutzeroberfläche. Portale stellen die heute typische Form der Desktopintegration dar [s. Vogler 2004, 55]. Portale sind webbasierte Anwendungen, die Inhalte, Dienste und Funktionen benutzerspezifisch integrieren [s. Schelp/Winter 2002]. Sie bieten dem Benutzer einen einheitlichen, personalisierten Zugriff auf die Funktionen, die er zur Bearbeitung einer Aufgabenstellung benötigt. Prozessportale stellen eine Klasse von Portalen dar, die sich an den spezifischen Prozessen bestimmter Benutzerrollen (z.B. Kunden, Lieferanten, Mitarbeiter) orientiert und dazu unternehmensinterne und externe Leistungen für diese Prozesse bündeln [vgl. Puschmann 2004, 7]. Während die workfloworientierte Integrationssicht den Ablauf mehrerer Aktivitäten innerhalb eines anwendungsübergreifenden Geschäftsprozesses (Workflow) spezifiziert, beschreibt eine desktoporientierte Sicht die Abfolge einzelner Arbeitsschritte innerhalb einer Aktivität, die ein Benutzer an seinem Arbeitsplatz durchführt. Für den Steuer- und Datenfluss zwischen Arbeitsschritten innerhalb einer Aktivität verwendet [Vogler 2004, 55] den Begriff Taskflow.

18

2 Grundlagen

Anwendungsneutrale Architekturkomponenten Die desktoporientierte Integration wird typischerweise auf Portalplattformen umgesetzt. Diese kombinieren verschiedene Middleware- und Administrationsdiensten für die Integration, die Personalisierung, die Navigation und die Präsentation von Daten und Funktionen [s. Puschmann 2004, 61ff.]. Einige Softwarehersteller bieten inzwischen spezielle, über die Funktionalität typischer Portalplattformen hinausgehende Umgebungen zur Entwicklung von sog. „Composite Applications“ (CA) an [s. Woods 2003, 4]. Diese Plattformen bieten Mechanismen zur Modellierung und Ausführung von Taskflows sowie deren Einbindung in Bildschirmmasken. Beispielsweise hat SAP eine solche Umgebung in Form ihres Composite Application Framework auf dem Markt, welche u.a. auf der SAP Portalplattform aufbaut und die Definition von auf Services basierenden Taskflows in Form sog. Guided Procedures erlaubt [vgl. SAP 2004b].

2.4

Informations- und Architekturmanagement

Das Informationsmanagement (IM) beschäftigt sich als Teil der Unternehmensführung mit dem Erkennen und dem möglichst wirtschaftlichen und wirksamen Umsetzen der Potenziale der IT in Lösungen (s. [Zarnekow/Brenner 2003, 7], [Krcmar 2005, 1]). Die Literatur strukturiert die Aufgaben des IM unterschiedlich. [Heinrich/Lehner 2005, 33ff.] unterscheiden strategische Aufgaben zur unternehmensweiten Planung, Realisierung, Überwachung und Steuerung des Informationssystems, administrative Aufgaben im Rahmen der Umsetzung der strategischen Entscheidungen in IS-Projekten und operative Aufgaben für den laufenden Betrieb und die Nutzung des IS. Das St. Galler IM von [Österle et al. 1992, 28ff.] nennt die folgenden drei Aufgabenbereiche: •

Die Informationsbewusste Unternehmensführung betrachtet das IS aus unternehmerischer Sicht. Sie hat die Aufgabe, geschäftliche Potenziale der Informationstechnologie zu erkennen und in Geschäftslösungen umzusetzen.

•

Das IS-Management betrachtet die Informationsverarbeitung aus logischkonzeptioneller Sicht. Aufgaben umfassen das Formulieren einer IS-Strategie bzw. eines IS-Konzepts, die Entwicklung der unternehmensweiten IS-Architektur, das IS-Projektportfolio-Management, das IS-Projektmanagement und die IS-Betreuung.

•

Das Management der Informatik beinhaltet Aufgaben der Personalplanung und des Aufbaus technischer Infrastrukturen für die Entwicklung und den Betrieb des IS. [Zarnekow et al. 2005, 66ff.] stellen das Management von IT-Dienstleistungen in Anlehnung an einen integrierten Fertigungsprozess und unter der Anwendung marktwirtschaftlicher Mechanismen in den Vordergrund. Sie unterteilen das IM in die Kernprozesse Govern, Source, Make und Deliver und grenzen für die letzten drei die Ebenen Rahmenbedingungen, Zielsetzungen und Umsetzung ab. Dieses Buch betrachtet nicht sämtliche Aufgaben des IM im Kontext von SOA, sondern konzentriert sich auf den Teilbereich des IS-Architekturmanagements.

2.4 Informations- und Architekturmanagement

19

Dieser umfasst die Aktivitäten zur Planung, Verabschiedung, Umsetzung und Überwachung der IS-Architektur (vgl. [Niemann 2005, 23], [Müller et al. 2006, 187]). [Schelp et al. 2006, 223] unterscheiden vier Aufgabenbereiche des Architekturmanagements: Die Architekturführung definiert in Abstimmung mit der ITStrategie Architekturziele und führt eine laufende Architekturüberwachung anhand von Kennzahlen durch. Sie setzt den Rahmen für die Architekturentwicklung, welche die detaillierten Anforderungen an die Architektur identifiziert und Architekturartefakte (Architekturmodelle, Roadmaps, Architekturprinzipien etc. [s. Hafner 2005, 59ff.]) entwirft. Die Architekturkommunikation vermittelt die Architekturartefakte den verschiedenen Interessengruppen und schult sie in ihrer Anwendung. Die Architekturvertretung unterstützt architekturrelevante Projekte beratend oder durch Hilfestellungen bei der Implementierung. Die Architekturmanagement-Aufgaben lassen sich für einzelne IS-Teilarchitekturen weiter detaillieren. Nach [Schwinn 2006a, 157ff.] sind wichtige Managementaufgaben für den Teilbereich Integrationsarchitektur: •

Die Definition einer Integrationsstrategie und die Ableitung von Integrationszielen und Führungsgrössen,

•

das Strukturieren der Applikationsarchitektur in Applikationsdomänen zur Verminderung organisatorischer Komplexität oder zur Planung der SollApplikationsarchitektur,

•

die Definition von Architekturprinzipien für die Integration sowie

• die laufende Überwachung und Steuerung der Integrationsarchitektur. Der Aufgabenkomplex des Architekturmanagements betrifft in den oben aufgeführten IM-Modellen hauptsächlich Teile der strategischen und administrativen Aufgaben [s. Heinrich/Lehner 2005, 50], Teile der Aufgaben des IS-Managements [Österle et al. 1992, 26ff.] bzw. Teile des Govern-Prozesses und des Portfolio- und Entwicklungsmanagements im Make-Prozess des Modells von [Zarnekow et al. 2005, 66ff.]. Das Architekturmanagement steht in engem Zusammenhang mit der IS-Entwicklung (vgl. [Österle et al. 1992, 79], [Schwinn 2006a, 57f.]). Diese setzt Vorgaben des Architekturmanagements im Projektportfoliomanagement und in IS-Projekten zur Entwicklung von Geschäftsanwendungen oder Infrastrukturkomponenten um. Kennzahlen aus der IS-Entwicklung und Erfahrungen aus der Verwendung der Architekturartefakte fliessen in die Architekturführung und die Architekturentwicklung zurück. Abb. 2-9 zeigt die Aufgaben und Leistungsflüsse zwischen dem Architekturmanagement und der IS-Entwicklung.

20

2 Grundlagen

IS-Architekturmanagement Architekturführung

Entwicklungsaufträge Architekturartefakte Entwicklungsunterstützung

IS-Projektportfoliomanagement

Architekturentwicklung Architekturkommunikation Architekturvertretung

IS-Entwicklung

Entwicklungskennzahlen Anpassungsvorschläge für Architekturartefakte

IS-Projektmanagement

Abb. 2-9: IS-Architekturmanagement und IS-Entwicklung

2.5

Zusammenfassung

Architekturen beschreiben physische oder logische Systeme anhand ihrer grundlegenden Strukturen und Systemkomponenten und definieren ein Modellsystem und Konstruktionsregeln für ihre Modellierung und Planung. Eine Unternehmensarchitektur beschreibt und plant die unternehmerische Wertschöpfung und bildet den Gestaltungsrahmen für die Anpassung des Unternehmens an geänderte Anforderungen. Das Business Engineering Modell unterteilt die Unternehmensarchitektur in die drei Ebenen Strategie, Prozess und System. Bei der heutigen hohen ITDurchdringung in Unternehmen sind Geschäftsstrategien und Prozesse erst dann wirksam, wenn sie auf Systemebene informationstechnisch umgesetzt werden. Der Flexibilität der Systemarchitektur für eine schnelle Umsetzung neuer geschäftlicher Anforderungen kommt deshalb eine hohe Bedeutung zu. Dabei unterstützt die Integrationsarchitektur die Realisierung neuer oder geänderter Prozesse auf Basis bestehender Anwendungen. Sie bietet Mechanismen zur Kopplung von Applikationen und zur Implementierung applikationsübergreifender Prozesse auf den Ebenen Anwendungssystem, Workflowintegration und Desktopintegration. Die an den Geschäftszielen orientierte Planung, Verabschiedung, Umsetzung und Überwachung der Integrationsarchitektur ist Gegenstand des Integrationsarchitekturmanagements als Teilbereich des unternehmensweiten Informationsmanagements.

3 Prinzipien serviceorientierter Architekturen Das folgende Kapitel charakterisiert den Architekturstil SOA. Am Anfang steht dabei eine Definition der Begriffe SOA und Service in Kap. 3.1. Kap. 3.2 gibt einen Überblick über die grundlegenden Architekturkomponenten einer SOA und beschreibt ein Modell für ihre Einordnung in die Business Engineering Architektur. Kap. 3.3 leitet Designprinzipien einer SOA aus einem Literaturvergleich ab. Kap. 3.4 nimmt eine Abgrenzung von SOA mit verwandten Architekturkonzepten vor, während Kap. 3.5 auf technische Umsetzungsalternativen von SOA eingeht.

3.1

Serviceorientierte Architektur

Der Begriff SOA ist nicht neu, sondern wurde gemäss [Natis 2003] bereits 1996 von der Gartner Group geprägt. Einzelne Designprinzipien gehen gar bis auf die modulare und objektorientierte Programmierung der 70er- und 80er-Jahr zurück. Mit Web Services als Schnittstellentechnologie zeichnet sich in neuerer Zeit der Durchbruch des SOA-Paradigmas ab. Tabelle 3-1 führt eine Reihe von Definitionen der Begriffe SOA und Service auf. Quelle

Definition

[Arsanjani 2004]

A SOA is an enterprise-scale IT architecture for linking resources on demand. In a SOA, resources are made available to participants in a value net, enterprise, line of business (typically spanning multiple applications within an enterprise or across multiple enterprises). It consists of a set of business-aligned IT services that collectively fulfill an organization’s business processes and goals. A service is a software resource (discoverable) with an externalized service description. This service description is available for searching, binding, and invocation by a service consumer.

[Gioldasis et al. 2003, 12f.]

Service-Oriented Architecture (SOA) refers to an application software topology according to which business logic of the applications is separated from its user interaction logic and encapsulated in one or multiple software components (services), exposed to programmatic access via well defined formal interfaces. Each service provides its functionality to the rest of the system as a well-defined interface described in a formal markup language and the communication between services is platform and language independent.

22

3 Prinzipien serviceorientierter Architekturen Quelle

Definition

[Oasis 2005, 30f.]

[A SOA is] a software architecture of services, policies, practices and frameworks in which components can be reused and repurposed rapidly in order to achieve shared and new functionality. [...] SOA uses the object-oriented principle of encapsulation in which entities are accessible only through interfaces and where those entities are connected by well-defined interface agreements or contracts. [A service is] a behavior or set of behaviors offered by one entity for use by another according to a policy and in line with a service description.

[W3C 2004a], [W3C 2004b]

A Service Oriented Architecture (SOA) is a form of distributed systems architecture. [It consists of] a set of components which can be invoked, and whose interface descriptions can be published and discovered. A service is an abstract resource that represents a capability of performing tasks that form a coherent functionality from the point of view of providers entities and requesters entities.

Tabelle 3-1: Definitionen der Begriffe SOA und Service Serviceorientierung stellt einen Stil zur Gestaltung von Systemarchitekturen dar [s. Baresi et al. 2003, 69]. Dieser zeichnet sich durch bestimmte Architekturkomponenten und Designprinzipien aus, welche die Gestaltung dieser Architekturkomponenten und ihrer Beziehungen zueinander bestimmen. Die zentralen Architekturkomponenten einer SOA sind Services. In Anlehnung an die obigen Definitionen verwendet diese Publikation folgendes Begriffsverständnis für eine SOA: Eine SOA ist eine mehrschichtige, verteilte Informationssystem (IS)-Architektur, die Teile von Applikationen für eine vereinfachte Prozessintegration als geschäftsorientierte Services kapselt und dabei bestimmte Designprinzipien berücksichtigt. Ein Service stellt ein abstraktes Software-Element bzw. eine Schnittstelle dar, die anderen Applikationen über ein Netzwerk einen standardisierten Zugriff auf Anwendungsfunktionen anbietet. Die Definitionen einer SOA und eines Services sind hier bewusst generisch gehalten. Sie werden in den folgenden Abschnitten durch die Beschreibung der grundlegenden Architekturkomponenten und Designprinzipien vertieft.

3.2

Architekturmodell und -komponenten

Im Business Engineering Modell lässt sich SOA als mehrschichtige Integrationsarchitektur einordnen, welche die fachliche Prozessarchitektur mit der Applikationsarchitektur verbindet (s. Abb. 3-1). Sie erweitert das Integrationsmodell von Kap. 2.3 um eine Ebene Services (vgl. [Arsanjani 2004], [Erl 2005, 280ff.]). Die Ebene Services strukturiert und kapselt die auf Ebene Anwendungssystem vorhandenen Daten und Funktionen nach den Anforderungen systemübergreifen-

3.2 Architekturmodell und -komponenten

23

der Prozesse. Services übernehmen dabei insb. zwei wichtige Funktionen. Zum einen bilden sie eine architekturweit standardisierte Schnittstellen- und Kommunikationsschicht, die von der fachlichen und technischen Heterogenität der verschiedenen Applikationen auf Ebene Anwendungssystem abstrahiert [s. Erl 2005, 282]. Diese Heterogenität besteht darin, dass verschiedene Anwendungssysteme meist eigene interne Daten-, Funktions- und Prozessmodelle besitzen und auf verschiedenen technischen Plattformen implementiert sind, die jeweils unterschiedliche Schnittstellentechnologien (Kommunikationsprotokolle, Nachrichtenformate etc.) unterstützen. Zum anderen passen Services die Granularität der Schnittstellen auf Ebene Anwendungssystem den Prozessanforderungen an. Schnittstellen, wie sie in herkömmlichen Anwendungssystemen zur Verfügung stehen, sind oft auf eine Interaktion zwischen zwei Komponenten innerhalb des Anwendungssystems (z.B. zwischen einer GUI- und einer Serverkomponente) oder für eine spezifische Punkt-zu-Punkt-Kopplung zwischen zwei Anwendungssystemen ausgelegt und sind zu feingranular für eine prozessorientierte Integration (s. [Stojanovic 2005, 153], [Aier/Schönherr 2004b, 24]). In einer SOA greifen Portale und Workflows nicht direkt auf diese Applikationsschnittstellen zu, sondern nutzen dazu Services. Eine SOA verfolgt damit eine grössere Unabhängigkeit zwischen Applikationen sowie eine bessere Entkopplung applikationsübergreifender Präsentations- und Prozesslogik von der Fachlogik im IS. Die aus Anpassungen an Geschäftsprozessen resultierenden Entwicklungs- und Integrationsbedarfe im IS lassen sich so schneller und günstiger umsetzen.

24

3 Prinzipien serviceorientierter Architekturen Strategie

Geschäftsarchitektur

Prozessarchitektur

Prozess Serviceorientierte Architektur System

Integrationsarchitektur Ebene Desktopintegration Ebene Workflowintegration Ebene Services

Applikationsarchitektur Ebene Anwendungssystem

Infrastrukturarchitektur Portal / integrierter Arbeitsplatz

Automatisierte Aktivität

Task / Arbeitsschritt

Service

Applikationsdomäne

Abb. 3-1: Einordnung von SOA in das Business Engineering Modell 3.2.1

Metamodell

Abb. 3-2 zeigt das Metamodell einer SOA. Die Darstellung des Modells basiert auf einer vereinfachten Entity-Relationship-Notation, wobei Architekturkomponenten durch Knoten und die Beziehungen zwischen ihnen durch Kanten dargestellt sind [vgl. Österle 1995, 187ff.]. Die Pfeile der Kanten geben die Leserichtung der Beziehung an, und an den Enden der Kanten sind die Kardinalitäten definiert. Die Kardinalität „1“ steht für genau eine, „c“ für keine oder eine, „cn“ für keine, eine oder mehrere und „n“ für mindestens eine. Durch den Bogen wird ein exklusives Oder in Beziehungen zwischen Komponenten ausgedrückt. Definitionen aller Architekturkomponenten führt Anhang A auf.

3.2 Architekturmodell und -komponenten

25 Anwendungsneutrale Sicht (Integrationsmechanismen)

Anwendungsbezogene Sicht (Anwendungslogik) erzeugt

1

Geschäftsprozess

besteht aus 1 n

Aufgabe

n

n

1 Organisationseinheit n

Leistung

Ebene Desktopintegration

umfasst führt aus

cn

1 besteht aus n Task

c

n

Rolle

ist realisiert in unterstützt

Prozessportal

führt aus 1

1

implen mentiert 1 Portal- / CAplattform

cn

1

Ebene Workflowintegration

c

Manuelle Aktivität

nutzt

n

Ebene Service

Workflow

c n Aktivität

ist1 ist 1

Automatisierte Aktivität

n

steuert

n

implementiert

1

1 Workflow Management System n nutzt

c

nutzt c

c kommuniziert über n

cn

n

1

beschreibt

1

1

Servicespezifikation n

n n

enthält

n

bietet

1 Applikationsdomäne

nutzt

n Middlewaredienst

nutzt 1

Service n

Ebene Anwendungssystem

n

stösst an

cn

n

1

n

Taskflow

Nachricht

führt aus

1

Serviceverzeichnis

nutzt

Serviceschnittstelle

n

1 besitzt

implementiert / nutzt

n

cn nutzt cn

n n

gruppiert

Applikation

führt aus n Funktion

1

1

nutzt

1 bietet an

greift zu auf n

cn

Applikationsschnittstelle

n

Informationsobjekte

Abb. 3-2: SOA-Metamodell 3.2.2

Architekturkomponenten auf Ebene Services

Anwendungsbezogene Sicht Wesentliche anwendungsbezogene Architekturkomponenten einer SOA auf Ebene Services sind Services, Applikationsdomänen, Servicespezifikationen und Nachrichten (s. Abb. 3-3). Ein Service kapselt den Zugriff auf Funktionen und Daten einer oder mehrerer Anwendungen der Applikationsarchitektur und erbringt eine bestimmte Leistung (z.B. die Abfrage aktueller Börsenkurse). Er stellt ein abstraktes Software-Element bzw. eine Schnittstelle dar, deren Fachlogik und Fachdaten durch Applikationen (z.B. ein Kursverwaltungssystem) implementiert werden. Applikationsdomänen

26

3 Prinzipien serviceorientierter Architekturen

(z.B. eine Domäne Wertschriften) gruppieren fachlich zusammengehörige Applikationen bzw. Funktionen und Daten aus logischer Sicht. Sie dienen als Strukturierungshilfe um zu entscheiden, welche Integrationsbeziehungen zwischen Applikationen als Services auszuprägen sind und welche nicht (s. [Schlamann 2004, 60], [Herr et al. 2004, 230]): Eine Applikation, die einer fremden Domäne angehört, sollte nur über Services auf die Domänenfunktionalität zugreifen, während Applikationen innerhalb der Domäne über beliebige Schnittstellen und Integrationsmechanismen miteinander kommunizieren können. Eine Applikationsdomäne tritt somit gegen aussen als Serviceanbieter auf. Eine Servicespezifikation beschreibt die als Service gekapselte Leistung einer Domäne. Sie sollte möglichst eine vollständige, widerspruchsfreie und eindeutige Beschreibung der Aussensicht eines Services geben, die alle Informationen enthält, welche ein potenzieller Servicenutzer benötigt [vgl. Turowski et al. 2002, 3]. Sie definiert bspw. in WSDL einen Schnittstellenkontrakt, der funktionale und technische Eigenschaften des Services beschreibt (z.B. Serviceoperationen, Inputund Ausgabedatenstrukturen, unterstützte Netzwerkprotokolle, verwendete Nachrichtenformate, Service-Adresse etc.). Daneben umfassen Servicespezifikationen auch natürlichsprachliche Beschreibungen der Servicefunktionalität, Qualitätseigenschaften des Services (bspw. zu verwendende Sicherheitsmechanismen, Serviceverfügbarkeit, Antwortzeiten) etc.6 Auf Basis der Servicespezifikation implementieren Servicenutzer (z.B. ein Finanzportal) die für die Interaktion mit dem Service notwendige Client-Schnittstelle. Diese muss in der Lage sein, zum Schnittstellenkontrakt konforme Nachrichten an den Service zu senden und von diesem zu empfangen. Die ausgetauschten Nachrichten enthalten Header-Informationen mit Adress- bzw. Routing-Angaben sowie einen funktionalen Nachrichtenteil („Payload“), welcher die auszuführenden Operationen spezifiziert und die zu verarbeitenden Daten bzw. – im Falle der Antwortnachricht vom Service zum Servicenutzer – die Resultate der Verarbeitung enthält [s. Krafzig et al. 2004, 34]. Servicenutzer können nicht nur Workflows oder Portale, sondern auch andere Services oder beliebige weitere Anwendungssysteme (z.B. ein ERP- oder CRMSystem) sein.

6

Eine detailliertere Beschreibung der Inhalte einer Servicespezifikation liefert Kap. 3.3.1.

3.2 Architekturmodell und -komponenten

27

Ebene Desktopintegration

Finanzportal (Servicenutzer)

Service 1 einbinden

2

Servicespezifikation

Ebene Services

Funktionalität, Operationen, Datentypen, etc.

Service nutzen

Anfrage Symbol: CSG

Nachrichten Antwort Kurs: 68.9 Währung: CHF

Service Börsenkursabfrage Domäne Wertschriften

Ebene Anwendungssystem

Kursverwaltung

Abb. 3-3: Anwendungsbezogene Architekturkomponenten Ebene Services Je nach Interaktionsstil können Servicenutzer und Service ein Auftraggeber / Auftragnehmer- oder ein Konsumenten / Produzenten-Verhältnis eingehen [vgl. Riehm 1997, 41]. Der erste Fall ist beispielhaft in Abb. 3-3 dargestellt, wo der Servicenutzer aktiv eine Börsenkurs-Anfrage an den Service sendet und von diesem den aktuellen Kurs erhält (Request / Response-Stil). Ein Konsumenten / Produzenten-Verhältnis besteht z.B. wenn sich der Servicenutzer einmal beim Service registriert und dann beim Eintreffen bestimmter Ereignisse (z.B. nach Ablauf einer bestimmten Zeitperiode oder wenn der Aktienkurs einen Schwellwert überschreitet) darüber informiert wird. Die Interaktion geschieht hier einseitig, indem der Service dem Nutzer eine Nachricht sendet, ohne von diesem eine Antwort zu erwarten (Notification-Stil). Die Kommunikation kann synchron oder asynchron erfolgen und nur zwischen zwei Parteien oder in einer Gruppe von Services bzw. Servicenutzern (z.B. Publish / Subscribe-Stil) stattfinden (s. [Krafzig et al. 2004, 38ff.], [Newcomer/Lomow 2004, 81]). Anwendungsneutrale Sicht Anwendungsneutrale Hauptkomponenten auf Ebene Services sind Serviceschnittstellen und das Serviceverzeichnis. Aufbauend auf den Applikationsschnittstellen und Integrationsmechanismen auf Ebene Anwendungssystem bilden Services eine architekturweit standardisierte Adapter- und Kommunikationsschicht. Indem sie in den darunter liegenden Anwendungssystemen implementierte Funktionen und Daten kapseln und in der Serviceschnittstelle als Operationen verfügbar machen, stellen sie eine Ausprägung der Funktionsintegration dar. In Anlehnung an [Cheesman/Ntinolazos 2004,

28

3 Prinzipien serviceorientierter Architekturen

15] und [Alonso et al. 2003, 173] zeigt Abb. 3-4 schematisch die Implementierung eines Services. ServiceSchnittstelle

Technologiebindung Serviceebene

Ebene Services

Servicelogik

Technologiebindung Ebene Anwendungssystem

Ebene Anwendungssystem

Applikationsschnittstellen

Abb. 3-4: Implementierung einer Serviceschnittstelle Serviceschnittstellen sind im einfachsten Fall ein Technologiewrapper für eine Applikationsschnittstelle (z.B. eine Operation eines Java-Objekts oder eine Datenbankprozedur). Sie implementieren in diesem Fall keine eigene Fachlogik, sondern übernehmen lediglich die Technologieanbindung auf Serviceebene. Dabei kommen verschiedene Middlewaredienste zum Einsatz [s. Alonso et al. 2003, 163ff.]: Transportkonnektoren sind für den Empfang bzw. Versand von Nachrichten zuständig. Sie übernehmen ihre Adressierung und Ver- bzw. Entpackung (Binding) in das im Schnittstellenkontrakt definierte Transportprotokoll (z.B. HTTP). Sie leiten die Nachrichten anschliessend an einen Skeleton bzw. Message-Konverter weiter (z.B. einen SOAP-Konverter, falls der Schnittstellenkontrakt SOAP / XML als Nachrichtenformat vorsieht). Dieser validiert die Nachrichten auf ihre Konformität mit dem Schnittstellenkontrakt und übersetzt sie in die von der Serviceimplementierung intern verwendeten Datenformate und Protokolle (z.B. Umsetzung der SOAP-Nachricht in einen Java-Call). Im Falle asynchroner Kommunikation zwischen Service und Servicenutzer ist dem Transportkonnektor und dem Message-Konverter ein Message-Queue-Dienst zwischengeschaltet, der die eingehenden Nachrichten speichert, bis sie vom Message-Konverter verarbeitet werden können. Services sollen oft nicht einfach eine existierende Applikationsschnittstelle in der standardisierten Schnittstellentechnologie auf Serviceebene kapseln, sondern die bestehende Logik auch erweitern. Bspw. kann ein Service mehrere Applikationsschnittstellen kombinieren, um Servicenutzern in einem Aufruf das Speichern von Kundendaten mit gleichzeitiger Doubletten- und Risikoprüfung zu erlauben. In diesem Fall müssen Entwickler zusätzliche Servicelogik programmieren (z.B. auf

3.2 Architekturmodell und -komponenten

29

einem Application Server unter Nutzung einer Komponententechnologie wie EJB), welche die verschiedenen Anwendungsschnittstellen ansteuert und koordiniert. Je nachdem, in welcher Technologie die Servicelogik und die einzelnen beteiligten Anwendungssysteme implementiert sind, sind weitere Middlewaredienste zur Technologieanbindung auf Ebene Anwendungssystem notwendig, die eine Integration der Applikationsschnittstellen mit der Servicelogik unterstützen. Dazu kommen die verschiedenen in Kap. 2.3.1 aufgeführten Mechanismen für eine Daten-, Funktions- oder Präsentationsintegration zur Anwendung. Das Serviceverzeichnis dient der zentralen Verwaltung von Services. Serviceanbieter publizieren dort ihre Servicespezifikationen und machen sie so potenziellen Nutzern verfügbar. Das Serviceverzeichnis verwaltet Referenzen auf die Serviceschnittstellen, kategorisiert Services und bietet Nutzern Schnittstellen für eine automatisierte oder eine manuelle Suche nach Diensten (s. [Dostal et al. 2005, 15], [Cervantes/Hall 2005, 5]). Abb. 3-5 zeigt die Interaktion zwischen den Rollen Serviceanbieter, Servicenutzer und Serviceverzeichnis. Service suchen

2

3 Spezifikation liefern Serviceverzeichnis

Service- 1 beschreibung publizieren

Servicenutzer

Service 4 einbinden

5

Service nutzen

Nachricht

Servicespezifikation

Service

Serviceanbieter

Abb. 3-5: SOA-Interaktionsdreieck Analysten und Softwarehersteller fassen die Middlewaredienste auf Ebene Services in letzter Zeit unter dem Begriff Enterprise Service Bus (ESB) zusammen (s. [Keen et al. 2004, 71ff.], [Chappell 2004], [Wilkes 2004]). Gegenwärtig ist sich die Branche allerdings noch nicht darüber einig, welche Middlewarefunktionalität ein ESB enthält [s. Wilkes 2004, 10]. Nach [Wilkes 2004] und [Keen et al. 2004, 83] umfasst ein ESB im Kern Message-Broker-Integrationsfunktionalität und standardisierte Kommunikationsprotokolle zur Umsetzung einer Bus-Integrationsinfrastruktur (s. Kap. 2.3.2), ein Service-Verzeichnis sowie Sicherheits- und Servicemanagement-Infrastrukturdienste.

30

3 Prinzipien serviceorientierter Architekturen

3.3

Designprinzipien

Ziel dieses Abschnitts ist es, die grundlegenden Designprinzipien zur Gestaltung von SOA und Services herauszuarbeiten. Grundlage dazu bilden eine Reihe von SOA-Charakterisierungen durch Standardisierungsgremien, Wissenschaftler, Analysten und Softwareanbieter.7 Dabei besteht eine Herausforderung darin, dass •

unterschiedliche Autoren verschiedene Designprinzipien betonen,

•

sie die Designprinzipien verschieden detailliert definieren,

•

sich mit unterschiedlichen Begriffen bezeichnete Prinzipien inhaltlich überschneiden oder

• inhaltlich gleiche Prinzipien unterschiedlich benannt werden. Bspw. existieren divergierende Meinungen darüber, ob der Begriff SOA an die Verwendung von Web Service Standards gebunden ist (vgl. z.B. [Zimmermann et al. 2003, 161] und [Dostal et al. 2005, 26]) oder ob Services nur einen synchronen „Request / Reply“-Interaktionsstil [s. Natis 2003] oder auch eine asynchrone Kommunikation [s. Bloomberg 2004a] unterstützen. Viele Autoren bezeichnen die „lose Kopplung“ als eine Kerneigenschaft von SOA. Während aber [Brown et al. 2002, 4] darunter die Verwendung bestimmter auf Standards basierender Kommunikationsmechanismen versteht, bezieht sich der Begriff bei [Fritz 2004] auf eine logische Unabhängigkeit zwischen Architekturkomponenten, die eine voneinander entkoppelte Evolution erlaubt. [Papazoglou 2003, 3] verbindet mit loser Kopplung das Verbergen interner Strukturen, was andere Autoren eher unter der Eigenschaft Abstraktion einordnen (vgl. [Fritz 2004], [W3C 2004a]). Die folgenden Abschnitte erläutern die in der Literatur identifizierten Designprinzipien und fassen sie in vier Klassen zusammen: •

Schnittstellenorientierung. Serviceschnittstellen abstrahieren aus Sicht eines Servicenutzers von Implementierungsdetails. Ein Service stellt eine stabile, gemanagte Schnittstelle im Sinne eines Vertrags dar und ist über Metadaten technisch und fachlich umfassend spezifiziert.

•

Interoperabilität. Im Rahmen einer SOA werden auf Ebene Gesamtarchitektur verschiedene Standardisierungsentscheidungen getroffen, die beim Servicedesign zu berücksichtigen sind. Diese Standards sind sowohl für technische (z.B. zu verwendende Schnittstellentechnologien oder Datentypen) als auch für fachliche Belange (z.B. einheitliche Terminologien, standardisierte Datenmodelle für wichtige Geschäftsobjekte) zu definieren. Erst die Abstützung auf solche Standards ermöglicht die Interoperabilität eines Dienstes und seine Verwendung in unterschiedlichen Kontexten.

•

Autonomie und Modularität. Eine SOA nimmt eine Dekomposition der bestehenden Applikationsarchitektur vor und strukturiert sie in eine überschaubare Menge teilautonomer Subsysteme (Domänen und Services). Nach bekannten Prinzipien der Modul- oder Komponentenbildung werden dabei Funktionen

7

Eine Tabelle mit den wichtigsten verwerteten Quellen zur SOA-Charakterisierung befindet sich in Anhang B

3.3 Designprinzipien

31

oder Ressourcen mit grosser Abhängigkeit (Kohäsion) untereinander so zusammengefasst, dass sie gegenüber den anderen Subsystemen eine möglichst geringe Abhängigkeit (lose Kopplung) aufweisen. •

Bedarfsorientierung. Services orientieren sich bezüglich ihres Leistungsumfangs an geschäftlichen Objekten und Prozessaktivitäten. Sie bieten grob granulare, fachlich abgrenzbare und aus geschäftlicher Sicht sinnvolle und wertschöpfende Leistungen.

3.3.1

Schnittstellenorientierung

Abb. 3-6 gibt einen Überblick über die Designprinzipien der Klasse Schnittstellenorientierung.

• Abstraktion von der Serviceimplementierung • Umfassende, einheitliche Servicespezifikation • Stabile, gemanagte Servicekontrakte

Abb. 3-6: Desingprinzipien Schnittstellenorientierung

32

3 Prinzipien serviceorientierter Architekturen

Abstraktion von der Serviceimplementierung Gemäss dem W3C realisiert ein Service eine abstrahierte, logische Sicht auf Softwareelemente [s. W3C 2004a]. Serviceschnittstellen nehmen eine funktionale Abstraktion vor, indem sie anhand von Metadaten definieren, was ein Service leistet und wie er genutzt werden kann, nicht aber, wie der Service intern implementiert ist (vgl. [Balzert 1999, 342], [Newcomer/Lomow 2004, 76]). Spezifizierte Serviceoperationen und Parameter stellen den einzigen Zugriffspunkt auf Funktionen und Daten der darunter liegenden Softwareelemente dar, und Servicenutzer übergeben einem Service nur Daten, keine Steuerungsinformation. Serviceschnittstellen setzen damit das bis zur modularen Programmierung zurückreichende Prinzip des „Information Hiding“ [Parnas 1972, 1056] bzw. des Geheimnisprinzips [s. Balzert 1999, 137] um. Die Steuerung eines Services durch Übergabe eines SQL-Statements als Inputparameter stellt bspw. eine Verletzung des Designprinzips dar, weil sie Kenntnis der internen Datenstruktur des Services voraussetzt [s. Newcomer/Lomow 2004, 75]. Durch eine programmiersprachen-, plattform- und middlewareneutrale Servicebeschreibung [s. Dodd 2005d, 12] abstrahieren Serviceschnittstellen zur Design- und Entwicklungszeit auch von der technischen Implementierung eines Services. Unter Nutzung geeigneter Werkzeuge lassen sich aus Bestandteilen der Servicespezifikation (z.B. einem WSDL-Dokument) Codegerüste für die Implementierung von Serviceschnittstellen in unterschiedlichen Technologien (z.B. J2EE, CORBA, XML-Strukturen) generieren. Umfassende, einheitliche Servicespezifikation Services sollten architekturweit einheitlich und zentral beschrieben sein. Servicenutzer sollten keine über die Servicespezifikation hinausgehenden Informationen benötigen, um die Servicefunktionalität verwenden zu können. Eine umfassende Servicespezifikation vereinfacht die Serviceidentifikation und -integration für potenzielle Servicenutzer und die Wartung und Weiterentwicklung für Serviceanbieter. Sie beschreibt einen Service auf folgenden Ebenen (vgl. [Turowski et al. 2002], [Dodd 2005d], [Papazoglou/Georgakopoulos 2003, 26]): •

Die Schnittstellenebene einer Servicespezifikation enthält die Informationen, die der Herstellung der technischen Kommunikationsfähigkeit dienen. Dies sind einerseits die technischen Schnittstelleninformationen (zu verwendende Netzwerkprotokolle, Nachrichtenformate, Binding-Informationen und Netzwerkadresse), andererseits die unterstützten Operationen, Attribute, Fehlermeldungen und Ausnahmen.

•

Auf Verhaltens- und Informationsebene ergänzt die Servicespezifikation die primär syntaktische Beschreibung auf Schnittstellenebene um semantische Aspekte des Serviceverhaltens. Dazu gehört neben Vor- und Nachbedingungen und Invarianten der Servicenutzung auch das Service-Informationsmodell, das die dem Service bekannten Datenobjekte und die Effekte von Operationen auf diese Objekte beschreibt.

•

Die Abstimmungsebene beschreibt die Reihenfolge der Verwendung, notwendige Dialogsequenzen und die Synchronisationserfordernisse zwischen Servi-

3.3 Designprinzipien

33

ces bzw. Serviceoperationen. Bedingungen auf der Abstimmungsebene können sich sowohl auf von einem Service angebotene Dienste als auch auf von ihm genutzte Services beziehen. •

Die Aufgaben- und Terminologieebene einer Servicespezifikation verknüpft die auf den vorherigen Ebenen spezifizierten Elemente mit der geschäftlichen Diskurs- bzw. Begriffswelt. Dazu gehören z.B. Definitionen der verwendeten fachlichen Begriffe, Referenzen auf unterstützte fachliche Industriestandards (z.B. RosettaNet) oder eine Zuordnung des Services zu Prozessaufgaben. Eine Beschreibung von Services in einheitlicher geschäftlicher Terminologie erleichtert die Identifikation und Wiederverwendung von Services über verschiedene Organisationseinheiten hinweg [vgl. Newcomer/Lomow 2004, 77].

•

Die Qualitätsebene spezifiziert nichtfunktionale Eigenschaften und Nutzungsvoraussetzungen eines Services. Diese umfassen Sicherheits- und Laufzeitaspekte, Service Level Agreements (SLAs) und die Konformität zu Architekturstandards.

•

Die Vermarktungsebene beschreibt die wesentlichen Merkmale für die betriebswirtschaftliche und organisatorische Handhabung des Services. Dazu gehören u.a. Serviceklassifikationen, Releasestatus, Testtermine, Entwicklungs- und Betriebsverantwortlichkeiten oder Nutzungskonditionen. Eine detailliertere Auflistung der Elemente einer umfassenden Servicespezifikation führt Tabelle 3-2 auf. Element

Beschreibung

Servicespezifikation auf Schnittstellenebene Technischer Servicename

In Schnittstellendefinition verwendeter Servicename bzw. eindeutige Kennung des Services

Operationsnamen

In Schnittstelle verwendete Namen der Service-Operationen

Fehlermeldungen / Ausnahmezustände

Vom Service gelieferte Fehlermeldungen bzw. Fehlercodes

Input- und Outputattribute bzw. -Datenstruktur

Datenstrukturen der vom Service benötigten bzw. von ihm gelieferten Nachrichten

Datenformate / Typ

In Nachrichten-Datenmodellen verwendete Datentypen

Technische Anbindung

Implementierung / Schnittstellentechnologie (z.B. Web Service, EJB), Netzwerk- / Transportprotokolle (z.B. SOAP / HTTP, JMS, Websphere MQ)

Netzwerkadresse

Logische Adresse der Serviceschnittstelle

Adresse der Schnittstellenspezifikation

Z.B. URL zu WSDL-Dokument

34

3 Prinzipien serviceorientierter Architekturen Element

Beschreibung

Servicespezifikation auf Verhaltens- und Informationsebene Aufgabe einer Operation

Kurze Beschreibung der Operation

Operationstyp / -eigenschaften

Kommunikationsstil, z.B. transaktional / nicht-transaktional, update / read-only, synchron / asynchron, one-way, requestresponse, solicit-response, notification

Vor- / Nachbedingungen

Vor- und Nachbedingungen, die zur korrekten Ausführung einer Operation erfüllt sein müssen

ServiceInformationsmodell

Dem Service „bekannte“ bzw. durch den Service verwendete oder bearbeitete Daten- bzw. Informationsobjekte und ihre Beziehungen untereinander

Effekte von Operationen auf Daten

Effekte der Serviceoperationen im ServiceInformationsmodell

Invarianten

Logische Eigenschaften von bzw. Beziehungen zwischen Daten- / Informationsobjekten, die immer erfüllt sein müssen

Testfälle

Spezifikation von Anwendungsfällen zum Test des funktionalen Serviceverhaltens

Servicespezifikation auf Abstimmungsebene Abhängigkeiten und zwingende Sequenzen zwischen Serviceoperationen

Beschreibung der zeitlichen Reihenfolge und Bedingungen der Verwendung von Serviceoperationen im Zusammenhang mit anderen Services

Servicespezifikation auf Aufgaben- und Terminologieebene Begriffsdefinitionen

Lexikon mit Definitionen der wichtigsten Fachbegriffe und ihrer Beziehungen zueinander

Unterstützte betriebliche Aufgaben

Auflistung der unterstützten betrieblichen Aufgaben, ggf. untergliedert in Teilaufgaben

Referenzen auf (fachliche) unterstützte Industriestandards

Verweis auf allfällige, der Aufgabenzerlegung zu Grunde liegende Standards (z.B. RosettaNet PIP)

Zuordnung auf Dienste / Operationen und Datenstrukturen / Attribute

Verknüpfung der fachlichen Aufgaben und Begriffe zu Operationen und Parametern der Schnittstellenspezifikation und Daten- / Informationsobjekten im Service-Informationsmodell

3.3 Designprinzipien

35

Element

Beschreibung

Servicespezifikation auf Qualitätsebene Sicherheitskontext

Beschreibung unterstützter bzw. zur Verwendung vorausgesetzter Sicherheitsmechanismen (z.B. Authentisierung, Verschlüsselung der Kommunikation etc.)

Nachrichtenvolumen

Datenvolumen der bei Serviceaufrufen ausgetauschten Nachrichten

Durchsatz

Anzahl Aufrufe pro Zeiteinheit unter spezifischen Randbedingungen (z.B. bestimmte Tageszeiten, verwendete Integrationsinfrastruktur etc.)

Antwortzeiten

Maximal tolerierbare Antwortzeit, durchschnittliche Antwortzeit

Verfügbarkeiten

Geforderte bzw. tatsächliche Verfügbarkeit, Mean-TimeBetween-Failure, Maximale Ausfallzeit, geplanter Ausfall erlaubt (ja/nein), Vorwarnzeit für geplanten Ausfall

SLAs

Verbindliche Service Level Vereinbarung (involvierte Parteien, SLA Parameter bzw. gemessene Eigenschaften, Messgrössen, Messmechanismen bzw. -algorithmen, Messdauer, Stichprobengrösse, Gültigkeitsdauer, Massnahmen im Verletzungsfall)

Architekturzertifizierung

Bestätigung der Konformität des Services mit Architekturvorgaben bzw. Designrichtlinien

Unterstützung weiterer Standards

Bestätigung der Konformität mit durch Architekturrichtlinien nicht zwingend vorgegebenen Industriestandards, z.B. WS-I Basic Profile 1.1, WS-Security etc.

Servicespezifikation auf Vermarktungsebene Fachlicher Servicename

Natürlichsprachlicher Name des Services

Versionsnummer und -historie

Versionsnummer und -historie des Services

Releasestatus und geplante Releasezyklen

Releasestatus des Services (z.B. Identifiziert, in Entwicklung, Qualitätsprüfung, getestet, in Produktion), zukünftig geplante Releases

Domäne

Applikationsdomäne, welcher der Service zugeordnet ist

Geschäftsziele und -nutzen

Begründung der Serviceentwicklung bzw. Dokumentation der mit dem Service verfolgten Zielsetzung, der Messgrössen und der Zielerreichung

Fachliche Verantwortung

Fachlich verantwortliche Bereiche bzw. Personen

36

3 Prinzipien serviceorientierter Architekturen Element

Beschreibung

Entwicklungs- und Betriebsverantwortung

Verantwortliche für die Entwicklung und den Betrieb des Services

Herkunft

Herkunft des Services (z.B. Eigenentwicklung, Kauf, Outtasking)

Nutzer

Potenzieller Nutzerkreis, aktuelle Servicenutzer

Sourcing-Richtlinien

Nutzungspflichten bzw. alternative Sourcingoptionen für potenzielle Servicenutzer

Nutzungskonditionen

Preismodelle, Kompensation bei SLA-Verletzung, Zahlungsbedingungen, Eskalationsstufen etc.

Finanzielles Controlling

Kosten der Serviceentwicklung, des Servicebetriebs und der Servicenutzung

Tabelle 3-2: Elemente einer umfassenden Servicespezifikation Für die Spezifikation können formale Sprachen (z.B. Object Constraint Language), deskriptive Programmiersprachen (z.B. WSDL, OMG-IDL), grafische Notationen (z.B. UML-Diagramme, Prozessmodelle) sowie Normal- oder Gebrauchssprachen (z.B. Alltagssprachen, Fachnormsprachen) verwendet werden. [Turowski et al. 2002] oder [Dodd 2005d] machen Vorschläge für Notationssprachen auf den einzelnen Spezifikationsebenen. Stabile, gemanagte Servicekontrakte Serviceschnittstellen sind möglichst stabile, verbindliche Vereinbarungen zwischen Serviceanbietern und Nutzern. Mit dem Konzept der Schnittstelle als Vertrag geht eine Verpflichtung des Serviceanbieters einher, die Schnittstelle nur moderaten Änderungszyklen zu unterwerfen und Änderungen in formalisierten Prozessen vorzunehmen [vgl. Klesse et al. 2005, 262]. Serviceschnittstellen werden als eigenständige, gemanagte Architekturelemente in einem zentralen Repository verwaltet und nur in klar definierten Änderungszyklen über gesteuerte Prozesse und Qualitätschecks sowie unter Berücksichtigung der bestehenden Nutzer angepasst [s. Newcomer/Lomow 2004, 76f.]. Durch die explizite Trennung der Serviceschnittstelle von der Serviceimplementierung erhöhen SOA die Anpassbarkeit der gekapselten Softwareelemente: Solange Änderungen nur die Implementierung betreffen und die Serviceschnittstelle stabil bleibt, können Nutzer die Services unverändert weiter verwenden [s. Hagen 2004, 71]. Die Schnittstellenstabilität ist wichtiger, je mehr Nutzer einen Service verwenden und je umständlicher eine Abstimmung bei Änderungen ist.

3.3.2

Interoperabilität

Interoperabilität von Softwareelementen bezeichnet ihre Fähigkeit, Informationen untereinander auszutauschen und die ausgetauschten Informationen zu interpretieren bzw. zu verwenden (vgl. [IEEE 1990], [Mowbray/Zahavi 1995, 77]). Sie be-

3.3 Designprinzipien

37

trifft damit sowohl die technisch-syntaktische als auch die semantische und pragmatische Ebene der Kommunikation [s. Picot et al. 2001, 89f.]. SOA definieren Standards für eine applikations- und technologieübergreifende Kommunikation. Standardisierungsgegenstand sind Dienste, Schnittstellen und die Kommunikation zwischen Softwareelementen, nicht aber ihre Implementierung. Primäres Ziel ist es also nicht, Applikationen, Applikationsplattformen oder Programmiersprachen zu harmonisieren, sondern ihre Heterogenität zu überbrücken. Während einige Autoren nur einheitliche Schnittstellen- und Kommunikationsstandards auf technisch-syntaktischer Ebene als Charakteristikum einer SOA aufführen (s. bspw. [W3C 2004a], [Papazoglou 2003, 3], [McGovern et al. 2003, 48f.]), betonen andere auch die Bedeutung fachlich-semantischer Standards, um die Interoperabilität organisatorisch verteilt entwickelter Services zu erhöhen (s. bspw. [Newcomer/ Lomow 2004, 78], [Wilkes/Veryard 2004, 15f.]). Abb. 3-7 gibt einen Überblick über die Designprinzipien der Klasse Interoperabilität.

• Technische Schnittstellenstandardisierung • Fachliche Schnittstellenstandardisierung • Verwendung offener, verbreiteter Industriestandards

Abb. 3-7: Designprinzipien Interoperabilität Technische Schnittstellenstandardisierung Services besitzen einheitliche Schnittstellenbeschreibungen und kommunizieren über einheitliche Protokolle und Datenformate [s. Papazoglou 2003, 3]. Da Servicefunktionalität i.d.R. in unterschiedlichen Technologien implementiert ist, ist eine gemeinsame Middlewareinfrastruktur notwendig, die einheitliche technische Standards definiert, zentrale Dienste für die Serviceentwicklung, -publikation und -nutzung zur Verfügung stellt und plattformspezifische interne Datenformate und Kommunikationsprotokolle in die gemeinsamen Formate und Protokolle auf Serviceebene übersetzt (vgl. [McGovern et al. 2003, 48f.], [Newcomer/Lomow 2004, 75ff.]). Standardisierungsobjekte einer SOA aus technischer Sicht sind: •

Schnittstellen- und Kommunikationsstandards für die Servicespezifikation und -nutzung. Diese umfassen primär Notationssprachen für die Servicespezifikation, Datenformate der zwischen Services ausgetauschten Nachrichten (z.B. XML), zu verwendende Datentypen (Integer, String etc.), Kommunikationsstile (z.B. synchrone oder asynchrone, Einweg- oder Request / ReplyKommunikation) und Netzwerk- bzw. Kommunikationsprotokolle (z.B. SOAP / HTTP). Weiterführende mögliche Standards betreffen die Nachrich-

38

3 Prinzipien serviceorientierter Architekturen

tenverschlüsselung, die Nutzerauthentisierung, die Servicechoreographie und -orchestrierung etc.8 •

Eine zentrale Integrationsinfrastruktur. Neben Standards für technische Serviceschnittstellen und die Servicekommunikation benötigt eine SOA auch eine standardisierte bzw. zentralisierte Integrationsinfrastruktur. Um Services organisationseinheitsübergreifend identifizieren und nutzen zu können, sind gemeinsame Verzeichnisdienste, Authentisierungsdienste, Transformationsdienste, Kommunikationsdienste etc. notwendig, die alle Serviceanbieter und Servicenutzer verwenden müssen (s. Kap. 3.2).

Fachliche Schnittstellenstandardisierung Einheitliche plattformübergreifende Technologien erhöhen nur die technische Interoperabilität von Services. Um auch die semantische Heterogenität zwischen Services zu reduzieren und die Nutzung und Komposition mehrerer Services zu erleichtern, sollten SOA Vorgaben bezüglich semantischer Schnittstelleneigenschaften formulieren. Fachliche Standards [s. Turowski 2001, 270] bzw. „Domänenstandards“ [s. Szyperski et al. 2002, 29] definieren einheitliche Begriffssysteme und standardisieren Semantiken für betriebliche Aufgaben und Daten. Objekte fachlicher Standardisierung in einer SOA umfassen: •

Die Art und Weise der fachlichen Servicebeschreibungen bezüglich Inhalten, Struktur und Terminologie [s. Turowski 2001, 270],

•

einheitlich verwendete Datenmodelle und Datenwerte für serviceübergreifende Geschäftsentitäten bzw. Informationsobjekte, bspw. Datenmodelle für Partner und Produkte, einheitliche Codes für technische Fehlermeldungen etc. [s. Wilkes/Veryard 2004, 15f.],

•

übergreifende Funktions- und Prozessmodelle (z.B. auf Basis von IndustrieProzessstandards wie RosettaNet), Bezeichnungsschemata für Serviceoperationen oder Taxonomien zur Servicekategorisierung [s. Newcomer/Lomow 2004, 78].

Verwendung offener und verbreiteter Industriestandards SOA sollten für die technische und fachliche Standardisierung wenn möglich offene und verbreitete Industriestandards verwenden (s. [Dostal et al. 2005, 9], [Fritz 2004]). [IDABC 2004, 9] bezeichnet einen Standard dann als offen, wenn er von einer non-profit Organisation in einem allen interessierten Parteien offen stehenden Abstimmungsprozess veröffentlicht und weiterentwickelt wird, frei oder über eine nominelle Gebühr erhältlich ist und beliebig vervielfältigt und genutzt werden kann. Während Web Services einen weit verbreiteten und viel versprechenden Ansatz für hersteller- und plattformunabhängige Standards auf technischer Ebene darstellen (s. Kap. 3.5.1), sind fachliche Standards weniger verbreitet bzw. in Softwareprodukten umgesetzt (s. [Alt 2004, 207], [Szyperski et al.

8

Beispiele für entsprechende Standards führt Kap. 3.5.1 auf.

3.3 Designprinzipien

39

2002, 407f.], [Turowski 2001, 279]).9 Ursachen dafür sind u.a. die für eine Standardisierung zu hohe Änderungsgeschwindigkeit und Variantenvielfalt der betrieblichen Anwendungsdomäne, ungünstige Machtkonstellationen in Geschäftsnetzwerken oder Partikularinteressen marktmächtiger Softwarehersteller. Wenn einzelne Applikationsdomänen oder grössere Teile der Applikationsarchitektur auf Produkten von Softwareherstellern mit grosser Marktverbreitung basieren, kann es deshalb sinnvoll sein, deren proprietäre fachliche Standards auch auf Ebene Serviceschnittstelle zu verwenden. Für Unternehmen ist die Zukunftsfähigkeit und die Verbreitung eines Standards oft wichtiger als die Gefahr der Abhängigkeit von bestimmten Herstellern [s. Kagermann/Österle 2006, 230].

3.3.3

Autonomie und Modularität

Eine SOA gruppiert Anwendungslogik und Daten in eine überschaubare Menge teilautonomer Domänen und Services (vgl. [Klesse et al. 2005, 262], [McGovern et al. 2003, 42]). Diese übernehmen möglichst überschneidungsfrei abgrenzbare, nach aussen stabile und kombinierbare Funktionen, kapseln Logik und Daten mit grossen Abhängigkeiten untereinander (hohe Kohäsion) und weisen geringe Abhängigkeiten zu anderen Subsystemen auf (schwache Kopplung) (vgl. [Baldwin/ Clark 1997, 86], [Simon 2002, 24]). Services, bzw. die durch Services gekapselten Domänen, stellen autonome10 Einheiten dar, die sich möglichst isoliert voneinander entwickeln, betreiben und nutzen lassen. Abb. 3-8 gibt einen Überblick über die Designprinzipien der Klasse Autonomie und Modularität.

• Hohe Servicekohäsion und schwache logische Kopplung • Lose gekoppelte Kommunikation

Abb. 3-8: Designprinzipien Autonomie und Modularität

9

10

Beispiele fachlicher Industrie- bzw. Domänenstandards sind die Spezifikationen der OMG domain taskforces (s. [OMG 2006], [Szyperski et al. 2002, 397]), Ontologien aus dem Umfeld der Semantic Web Initiative des W3C [s. W3C 2001a], oder zwischenbetriebliche Prozess- und Dokumentenstandards wie UN/EDIFACT (s. http://www.unece.org/cefact/) oder RosettaNet (s. http://rosettanet.org). Einen Überblick über Prozess- und Daten-Industriestandards und ihre Verbreitung geben bspw. [Leser 2006, 220ff.], [Alt 2004, 201ff.], [Quantz/Wichmann 2003], [Esswein/Zumpe 2002] oder [Otto et al. 2002]. Nach [Özsu/Valduriez 1991, 69] bezieht sich der Begriff Autonomie auf die Verteilung von Kontrolle und bezeichnet den Grad, in welchem individuelle Teilsysteme unabhängig voneinander operieren können. [Hasselbring 2000, 37] unterscheidet dabei eine Design- und eine Kommunikationsbzw. Ausführungsautonomie.

40

3 Prinzipien serviceorientierter Architekturen

Hohe Servicekohäsion und schwache logische Kopplung Kohäsion und Kopplung sind Masse, welche die Abhängigkeiten bzw. logische Zusammengehörigkeit von Daten und Funktionen bewerten. Die Servicekohäsion betrachtet die "Innenbeziehung" der von einem Service gekapselten Funktionen und Daten und bezeichnet den Grad, in dem sie dazu beitragen, einen einzigen, wohl definierten Zweck zu erfüllen (vgl. [Papazoglou/Yang 2002, 59], [Stojanovic 2005, 99f.]). Ein Service kontrolliert möglichst alle und nur die Funktionen und Daten, die er zur Unterstützung einer eigenständigen, logisch abgeschlossenen Aufgabe benötigt. Gleichzeitig mit einer hohen Servicekohäsion wird auch in der Beziehung zwischen Services und zwischen durch Services gekapselten Softwareelementen eine schwache logische Kopplung angestrebt. Eine logische Kopplung besteht dann, wenn Services bzw. die sie implementierenden Softwareelemente ein gleiches Änderungsverhalten aufweisen, d.h. aufgrund gleicher geschäftlicher Anforderungen verändert werden müssen [s. Gall et al. 1998, 193]. Dies ist etwa dann der Fall, wenn sie direkt auf gemeinsame Daten zugreifen, Funktionalität redundant implementieren oder Vererbungsbeziehungen untereinander aufweisen (vgl. [Bennicke/Rust 2004, 42], [Newcomer/Lomow 2004, 80]). Kohäsionsgrade für Systemkomponenten, wie sie von [Yourdon/Constantine 1979, 108ff.] formuliert wurden, lassen sich auch auf Services übertragen [vgl. Vinoski 2005, 74]: •

Funktionale Kohäsion. Ein Service realisiert eine einzelne, abgeschlossene Funktion. Beispiele sind eine Benutzerauthentisierung oder eine Kreditkartenvalidierung.

•

Kommunikative Kohäsion. Ein Service bietet mehrere Funktionen, die auf den gleichen Daten (z.B. einem Geschäftsobjekt) operieren. Ein Beispiel ist ein Service "Kunde" mit Operationen für das Anlegen, das Lesen, das Modifizieren oder das Löschen von Kundendaten.

•

Sequenzielle Kohäsion. Ein Service kapselt hinter einem Aufruf mehrere Funktionen, die in einer bestimmten sequenziellen Ordnung ausgeführt werden. Ein Beispiel ist ein Service "Auftragsprüfung" mit den Funktionen "Auftraggeber authentisieren", "Verfügbarkeit prüfen", "Vertrag und Konditionen prüfen" und "Auftrag bestätigen".

•

Logische Kohäsion. Ein Service realisiert mehrere Funktionen, die in irgendeiner Form logisch zusammenhängen. Ein Beispiel ist ein "Ausgabeservice", der Daten in unterschiedliche Ausgabeformate wie pdf, Word-Dokument, Audiodatei etc. aufbereitet. Pro Serviceaufruf (Operation) wird nur eine Funktion ausgeführt.

•

Zufällige Kohäsion. Ein Service realisiert mehrere Funktionen, die keine logischen Zusammenhänge aufweisen. Obwohl die Literatur generell eine möglichst hohe Kohäsion und schwache logische Kopplung empfiehlt (vgl. [Vinoski 2005], [McGovern et al. 2003, 42f.]), können je nach Zielsetzung, die mit einem Service verfolgt wird, unterschiedliche Kohäsionsgrade geeignet sein. Services mit funktionaler oder kommunikativer Kohäsion sind stabiler und auch öfter wieder verwendbar als Services mit sequenzieller Kohäsion, da sich Geschäftsobjekte bzw. Geschäftsentitäten und einzelne

3.3 Designprinzipien

41

Geschäftsfunktionen i.d.R. weniger oft ändern als Geschäftsprozesse [vgl. Krafzig et al. 2004, 68ff.]. Eine Kapselung sequenziell abhängiger Funktionen in einem Service kann aber die Anzahl notwendiger Serviceaufrufe reduzieren und damit Performanzvorteile mit sich bringen sowie aus Sicht eines Servicenutzers den Integrationsaufwand verringern. Die Merkmale Kohäsion und Kopplung lassen sich auf einer höheren Abstraktionsstufe auch auf die Domänenarchitektur anwenden. Die Domänenabgrenzung verfolgt analoge Ziele wie die Serviceabgrenzung (isolierte Anpassungen bei neuen fachlichen Anforderungen, Redundanzfreiheit, Verteilungsflexibilität). Die Kopplung von Domänen über Services führt zu einer grösseren fachlich-logischen und technischen Unabhängigkeit zwischen Applikationsdomänen und erlaubt es z.B., in einzelnen Domänen Applikationen und Applikationsplattformen auszutauschen, ohne dass sich dies auf andere Domänen auswirkt. Lose gekoppelte Kommunikation Die lose gekoppelte Kommunikation zwischen Services und Servicenutzern ist ein Hilfsmittel zur Reduktion von Abhängigkeiten zur Laufzeit. Sie vermindert die Abhängigkeit vom Ort und von der Verfügbarkeit der Gegenpartei und verringert den Wiederaufsetzungsaufwand bei Systemausfällen. Massnahmen für eine lose gekoppelte Kommunikation sind •

eine dynamische Serviceadressierung,

•

eine asynchrone, nachrichtenbasierte Kommunikation und

• eine statuslose Serviceinteraktion. Bei einer dynamischen Adressierung adressiert der Servicenutzer den Service nicht über eine fixe Adresse (IP-Adresse oder Servername), sondern über einen logischen Namen, z.B. in Form einer URI (Uniform Ressource Identifier). Ein Verzeichnisdienst löst diese in eine physische Adresse auf [vgl. Riehm 1997, 110f.]. Die dynamische Adressierung ist ein wichtiger Mechanismus für die Identifikation und Einbindung von Services zur Laufzeit ohne gemeinsames Kompilieren von Service und Servicenutzer (s. [Kossmann/Leymann 2004, 118], [McGovern et al. 2003, 41]). Sie unterstützt ausserdem die Lastverteilung von Serviceaufrufen auf mehrere Serviceinstanzen bzw. die Umleitung von Serviceaufrufen beim Ausfall oder Ersatz eines Services [s. Mantel et al. 2000, 29]. Bei einer asynchronen, nachrichtenbasierten Kommunikation tauschen Services und Servicenutzer unter Verwendung einer Messaging Middleware (z.B. Java Messaging Service, WebSphere MQ) Nachrichten aus, die eigenständige, delegierte Arbeitseinheiten darstellen und nicht zwingend sofort bearbeitet werden müssen (vgl. [Chappell 2004, 88f.], [Brown et al. 2002, 4f.]). Servicekonsumenten behandeln entfernte Serviceoperationen nicht wie lokale Methodenaufrufe und verlassen sich nicht auf die Verfügbarkeit des Services. Dadurch werden sie bei temporärem Ausfall eines Services nicht blockiert. Services interagieren mit ihren Nutzern statuslos, wenn jeder Serviceaufruf vom vorherigen unabhängig ist und der Service zwischen Aufrufen keine Interaktionsinformationen speichert. Das bedeutet, dass z.B. Services, die in einer Datenbank gehaltene Entitäten wie „Kunde“ oder „Auftrag“ bearbeiten, die Daten nach jedem

42

3 Prinzipien serviceorientierter Architekturen

Aufruf dauerhaft in die Datenbank schreiben, sie in einem konsistenten Zustand lassen und die Bearbeitung der Entitäten durch andere Services zwischen zwei Aufrufen nicht blockieren [s. Colan 2004]. Servicenutzer müssen ausserdem bei jedem Aufruf sämtliche notwendigen Kontextinformationen (z.B. Objekt- bzw. Entitätsreferenzen oder Sicherheitszertifikate für die Authentifizierung) mitliefern [s. He 2003]. Eine statuslose Serviceinteraktion erhöht die Skalierbarkeit und Recovery-Fähigkeit des Systems. Sie ist Voraussetzung, wenn Serviceaufrufe dynamisch auf mehrere Serviceinstanzen verteilt werden, da ein Nutzer in diesem Fall nicht davon ausgehen kann, immer mit der gleichen Serviceinstanz zu kommunizieren (vgl. [Newcomer/Lomow 2004, 82], [Szyperski et al. 2002, 36]). Die lose gekoppelte Kommunikation nach diesen Prinzipien ist eine anzustrebende, aber keine zwingende Eigenschaft von SOA. Bspw. können Geschwindigkeitsanforderungen an den Serviceaufruf aus einer Benutzeroberfläche eine synchrone, RPC-ähnliche Kommunikation erforderlich machen. Einzelne Services und die Service-Integrationsinfrastruktur sollten aus diesem Grund unterschiedliche Kommunikationsstile unterstützen [s. Newcomer/Lomow 2004, 81].

3.3.4

Bedarfsorientierung

Die Umsetzung der Schnittstellenorientierung, der Interoperabilität und der Modularität in einer SOA ist mit Entwicklungs- und Laufzeitkosten verbunden: Die detaillierte Servicespezifikation, die Berücksichtigung von Architekturstandards, die Transformation von Nachrichtenstrukturen und Kommunikationsprotokollen, die Unterstützung lose gekoppelter Kommunikation etc. erhöhen den Aufwand für die Serviceentwicklung [s. Dietzsch/Goetz 2005, 1527f.], erfordern u.U. spezielle Middlewaredienste [s. Schwinn/Winter 2005, 596] und führen zu verminderter Performanz bei Serviceaufrufen [s. McGovern et al. 2003, 51]. Das Design der Serviceleistung muss solche Mehrkosten berücksichtigen, sich an den Anforderungen potenzieller Servicenutzer orientieren und aus Architektursicht einen „Mehrwert“ liefern. Designprinzipien dafür sind eine grobe, an geschäftlichen Konzepten orientierte Servicegranularität und die Generalisierung von Serviceleistungen. Abb. 3-9 gibt einen Überblick über die Designprinzipien der Klasse Bedarfsorientierung.

3.3 Designprinzipien

43

• An Geschäftskonzepten orientierte, grobe Servicegranularität • Generalisierung der Serviceleistung

Abb. 3-9: Designprinzipien Bedarfsorientierung An Geschäftskonzepten orientierte, grobe Servicegranularität Die Literatur fordert oft generell eine im Vergleich zu Objekt- oder Komponentenschnittstellen gröbere Granularität von Services (s. [Brown et al. 2002], [McGovern et al. 2003, 51]). Ziel dabei ist es, den „Servicewildwuchs“ mit einer für Entwickler kaum mehr überblickbaren Anzahl wieder verwendbarer Elemente zu verhindern [s. Stiemerling 2002, 437]. Ausserdem soll die Kapselung von viel Fachlogik den Wiederverwendungsnutzen steigern sowie die Anzahl notwendiger Serviceaufrufe verringern [s. Griffel 1998, 52]. Aus Sicht des fachlichen Servicedesigns sind dabei primär zwei Granularitätsarten von Bedeutung [vgl. McGovern et al. 2003, 50]: •

•

Die Funktionsgranularität ist ein Mass dafür, wie viel Fachlogik ein Service umfasst [s. Griffel 1998, 51]. Ein Service mit grober Funktionsgranularität kapselt viel Fachlogik, d.h. er führt in einem Aufruf bzw. in einem Interaktionsschritt viele Verarbeitungsschritte durch. Bspw. besitzt ein Service, der in einem Aufruf Kundenpersonendaten und die Kundenrolle (Interessent, Käufer etc.) anlegt, Dubletten prüft und gleichzeitig eine Kundenrisikoprüfung vornimmt, eine gröbere Funktionsgranularität als ein Service, der nur Kundenpersonendaten in eine Datenbank schreibt.

Die Schnittstellengranularität bezeichnet den Umfang des Datenmodells einer Serviceschnittstelle, d.h. die Anzahl Attribute, welche die ausgetauschten Nachrichten enthalten. Ein Service, der als Resultat lediglich einige Kundenattributwerte liefert (Name, ID etc.), besitzt eine feinere Schnittstellengranularität als ein Service, der einen kompletten Kundendatensatz mit allen Attributwerten zurückgibt. In verteilten Systemen ist es i.d.R. effizienter, viele Daten in einem Durchgang auszutauschen, als mehrere Serviceaufrufe auszuführen, die kleine Nachrichten mit wenig Daten liefern (s. [Newcomer/Lomow 2004, 83], [McGovern et al. 2003, 58f.]). Von Services angebotene Operationen sollten geschäftlichen Konzepten entsprechen, d.h. möglichst komplette Teilprozesse oder Prozessaktivitäten unterstüzen bzw. Informationen zu kompletten Geschäftsentitäten lesen und bearbei-

44

3 Prinzipien serviceorientierter Architekturen

ten (s. [McGovern et al. 2003, 50], [W3C 2004a], [Stojanovic 2005, 180]). Dadurch reduziert sich zum einen die Anzahl Interaktionen zwischen Services und Servicenutzern sowie die insgesamt in der Architektur angebotenen Serviceoperationen. Zum anderen erhöht eine Kapselung von Funktionen auf dieser Granularitätsebene auch die Verständlichkeit einer Serviceleistung für fachlich orientierte Servicenutzer. Sie hilft, die konzeptionelle Lücke zwischen der fachlichen Modellierung von Geschäfts- bzw. Benutzerprozessen und der in Anwendungssystemen typischerweise über Komponenten-, Objekt- oder API-Schnittstelllen verfügbaren Funktionen und Daten zu überbrücken (s. [Aier/Schönherr 2004b, 24], [Newcomer/Lomow 2004, 77]). Eine grobe Servicegranularität bringt aber auch Nachteile mit sich. Grosse zu übertragende Datenvolumina verlängern die Antwortzeiten eines Serviceaufrufs und damit die Wartezeiten der Servicenutzer. Services, die viel Fachlogik umfassen, ändern sich ausserdem häufiger aufgrund neuer fachliche Anforderungen [s. Schwinn/Winter 2005, 597] und weisen oft einen höheren Spezialisierungsgrad auf, was ihre Wiederverwendbarkeit reduziert (s. [Wilkes/Veryard 2004, 13], [Griffel 1998, 52]). So ist ein Service, der lediglich Kundendaten liest und schreibt, in mehr Geschäftsprozessen einsetzbar als ein Service, der vor dem Schreiben von Kundendaten eine Risikoprüfung vornimmt. Während ersterer aus fachlicher Sicht nur angepasst werden muss, wenn sich die Datenstrukturen der Geschäftsentität „Kunde“ ändern, können beim umfassenderen Service z.B. auch neue gesetzliche Anforderungen an die Risikoprüfung Anpassungen notwendig machen. Exakte Richtlinien für eine geeignete Servicegranularität lassen sich deshalb nicht festlegen, sondern hängen vom Anwendungskontext des Services ab. In vielen Fällen kann es sinnvoll sein, eine Serviceleistung in verschiedenen Granularitätsstufen anzubieten und z.B. den Zugriff auf feingranulare und darauf aufbauende grobgranulare „Composite Services“ zu erlauben (s. [McGovern et al. 2003, 53ff.], [Erl 2005, 291]). Generalisierung der Serviceleistung Der Grad an Generalisierung bzw. Spezialisierung eines Services bestimmt massgeblich seine Wiederverwendbarkeit durch unterschiedliche Nutzer (s. [Schwinn/Winter 2005, 596], [Newcomer/Lomow 2004, 75f.]). Der Generalisierungsgrad eines Services kann durch die Art seiner fachlichen Funktion gegeben sein; Z.B. ist ein Service zur Bonitätsprüfung von Kunden in weniger Geschäftsprozessen einsetzbar als ein Service, der die Geschäftsentität „Kunde“ bearbeitet und liest. Er lässt sich aber auch durch das Servicedesign beeinflussen. Massnahmen zur Generalisierung von Services sind z.B.: •

Eine gröbere Schnittstellengranularität. Je umfassender und generischer das Datenmodell einer Serviceschnittstelle ist, desto grösser ist die Wahrscheinlichkeit, dass der Service auch die Daten liefert, die zur Entwicklungszeit unbekannte, zukünftige Nutzer benötigen.

•

Eine Verfeinerung der Funktionsgranularität. Je weniger prozessspezifische Fachfunktionen ein Service zusammenfasst, desto mehr Geschäftsprozesse können ihn nutzen [s. Wilkes/Veryard 2004, 13].

3.3 Designprinzipien

•

45

Unterstützung unterschiedlicher Interaktionsstile. In vielen Fällen ist die von Services implementierte Fachlogik unabhängig von der Art und Weise, in der ein bestimmter Geschäftsprozess den Service nutzt. Die Unterstützung mehrerer Interaktionsstile durch einen Service erhöht seine Wiederverwendbarkeit durch unterschiedliche Nutzer [s. Newcomer/Lomow 2004, 81]: So können z.B. zwei Servicenutzer die gleiche Serviceleistung einmal aktiv anfragen und eine sofortige Antwort erhalten ("Request / Response"-Stil) oder passiv, bei Eintreten eines bestimmten Ereignisses, beziehen ("Publish / Subscribe"-Stil).

•

Verwendung verbreiteter fachlicher Standards. Die Verwendung von fachlichen Standards (Prozess-, Funktions- oder Datenmodelle), die viele Hersteller und Geschäftspartner unterstützen, erhöht die Wiederverwendbarkeit eines Services besonders im zwischenbetrieblichen Umfeld [s. Dodd 2005c, 29]. Wie bei der Wahl einer geeigneten Servicegranularität lassen sich auch bei der Servicegeneralisierung keine allgemein gültigen Aussagen machen. Die Generalisierung von Serviceleistungen erhöht zwar deren Wiederverwendbarkeit, ist aber auch mit steigenden Entwicklungs- und Nutzungskosten verbunden: Die Anforderungen unterschiedlicher Servicenutzer auf einen gemeinsamen Nenner zu bringen, kann zu einem erhöhten Kommunikations- und Abstimmungsaufwand in der Serviceentwicklung führen. Ausserdem können umfangreiche, generische Datenmodelle ausgetauschter Nachrichten deren Verständlichkeit für Servicenutzer mindern [s. Dodd 2005c, 29]. Erfahrungen aus der komponentenorientierten Softwareentwicklung zeigen, dass die Entwicklung einer wieder verwendbaren, generischen Komponente eineinhalb- bis dreimal teurer ist als die Entwicklung einer ähnlichen Komponente für den Einsatz in nur einer Anwendung [s. Griffel 1998, 48]. Der in die Generalisierung eines Services zu investierende Aufwand hängt damit letztlich von der geschätzten Wiederverwendungshäufigkeit und dem Wiederverwendungsnutzen des Services ab.

3.3.5

Bedeutung der Designprinzipien

Die aufgeführten Designprinzipien zeigen die Eigenschaften einer umfassenden Umsetzung des SOA-Architekturstils. Die unterschiedlich häufige Nennung in den zur Herleitung verwendeten Quellen (s. Tabelle 3-3) deutet darauf hin, dass sie je nach Anwendungskontext eines Services und Zielsetzung einer SOA unterschiedliche Bedeutung besitzen. Während die Abstraktion von der Serviceimplementierung über definierte Schnittstellen, die Beschreibung von Services über Metadaten oder die technische Standardisierung der Service-Integrationsinfrastruktur in vielen Quellen als wichtige Designprinzipien enthalten sind, werden etwa die Definition fachlicher Standards auf Serviceebene oder die Servicegeneralisierung bzw. die Senkung der Spezifität der Serviceleistung seltener aufgeführt. Dies mag unter anderem damit zu tun haben, dass SOA, geprägt von der Web Service Diskussion, stark als technisches Thema und als Mittel zur Überbrückung der technischen Heterogenität in der IS-Architektur aufgefasst wird. Eine Servicegeneralisierung und eine fachliche Schnittstellenstandardisierung sind besonders dann wichtig, wenn die Architekturverantwortlichen die Wiederverwendung von Serviceleistun-

46

3 Prinzipien serviceorientierter Architekturen



Umfassende, einheitliche Servicespezifikation







Schnittstellenorientierung Interoperabilität

Stabile, gemanagte Servicekontrakte Technische Schnittstellenstandardisierung Fachliche Schnittstellenstandardisierung Verwendung offener und verbreiteter Industriestandards

 

  

 





 

 







[W3C 2004a]



[Papazoglou 2003, 3]

[Fritz 2004]



[Newcomer/ Lomow 2004, 72f.]

[Erl 2005, 291f.]



[McGovern et al. 2003, 40f.]

[Brown et al. 2002, 4f.]

Abstraktion von der Serviceimplementierung

Designprinzip

[Klesse et al. 2005, 262ff.]

[Baskerville et al. 2005]

gen erhöhen und den Aufwand für die Übersetzung von Datenmodellen unterschiedlicher Services senken wollen. Für die von Web Service Standards angestrebte einfachere technische Integration verteilter Systeme besitzen sie keine Bedeutung. Eine Konsequenz daraus ist, dass Unternehmen die zu berücksichtigenden Designprinzipien je nach Zielsetzung, die sie mit einer SOA verfolgen, individuell priorisieren müssen (s. [O'Brien et al. 2005, 24], [Dietzsch/Goetz 2005, 1525]). Damit die zeitlich und organisatorisch verteilten Entwicklungsaktivitäten zur Umsetzung einer SOA zu einer zielgerichteten und konsistenten IS-Architektur führen, sind Architekturrichtlinien notwendig, die definieren, unter welchen Umständen welche Designprinzipien einzuhalten sind.









 

 

 





 



 



 



 

  



  



Bedarfsorientierung









Lose gekoppelte Kommunikation

 

An Geschäftskonzepten orientierte, grobe Servicegranularität

 

Generalisierung der Serviceleistung



 

 

 

[W3C 2004a]

[Newcomer/ Lomow 2004, 72f.]

 

[Papazoglou 2003, 3]

[McGovern et al. 2003, 40f.]

[Brown et al. 2002, 4f.]

[Klesse et al. 2005, 262ff.]



[Fritz 2004]

Hohe Servicekohäsion und schwache logische Kopplung

47

[Erl 2005, 291f.]

Autonomie, Modularität

Designprinzip

[Baskerville et al. 2005]

3.4 Abgrenzung der Serviceorientierung von verwandten Ansätzen





 







 



 



 







Tabelle 3-3: Nennungshäufigkeit der SOA-Designprinzipien

3.4

Abgrenzung der Serviceorientierung von verwandten Ansätzen

Die in Kap. 3.3 aufgeführten Designprinzipien besitzen viele Gemeinsamkeiten mit entwicklungshistorisch älteren Ansätzen zur Gestaltung von Informationssystemen. Dies führt verschiedentlich dazu, dass Services in einer SOA mit in Objekt- bzw. Komponententechnologien implementierten verteilten Objekten gleichgesetzt werden [s. Vogels 2003, 59]. Obwohl sich serviceorientiertes und objektbzw. komponentenorientiertes Systemdesign sinnvoll ergänzen können (s. [Stojanovic 2005, 41], [Veryard 2003]), unterscheiden sie sich in einigen Punkten und haben unterschiedliche Anwendungsbereiche. Die folgenden Abschnitte zeigen auf, welche Designprinzipien bereits in früheren Ansätzen zur Systemgestaltung angewendet wurden und wie sich die Serviceorientierung als Designkonzept von der Objekt- und Komponentenorientierung abhebt.

3.4.1

Historische Entwicklung von Methoden für den Systementwurf

Die unter den Begriffen „Schnittstellenorientierung“ sowie „Autonomie und Modularität“ aufgeführte Gliederung des IS in selbständige Teilfunktionen, die nach dem Prinzip des Information Hiding interne Datenstrukturen und Algorithmen

48

3 Prinzipien serviceorientierter Architekturen

verbergen und den Zugriff auf die gekapselte Funktionalität nur über definierte Operationen zulassen, wird in Entwurfsmethoden wie „modulares“ bzw. „strukturiertes Design“ oder „abstrakter Datentyp“ schon seit den frühen 70er-Jahren angewendet (s. [Parnas 1972], [Balzert 2001, 1033]). Auch das Ziel einer Lokalisierung von Systemanpassungen durch eine hohe Kohäsion innerhalb von Softwareeinheiten und durch ihre schwache Kopplung entstammt diesen Konzepten [s. Österle 1981, 108]. Das modulare bzw. strukturierte Design verwendete als Abstraktionsprinzip hauptsächlich die Komplexbildung, d.h. die Zusammenfassung von Teilfunktionen und Datentypen unter einem Oberbegriff [s. Oestereich 2005, 32]. Die in den 80er und 90er-Jahren aufkommende Objektorientierung führte das Klassenprinzip als primäres Abstraktionsmittel ein.11 Zentrale Entwurfsgegenstände des objektorientierten Designs waren Klassen bzw. Objekte, die Daten und Funktionen kapseln und sich an in der realen Welt vorkommenden Gegenständen orientieren. Objekte nehmen bestimmte Zustände ein und besitzen eine Objektidentität, die sie von anderen Objekten unterscheidet [s. Balzert 2001, 156]. Die Objektorientierung übernahm vom modularen Design Entwurfsprinzipien wie das Information Hiding, das Kohäsions- oder das Kapselungsprinzip und führte als eine wesentliche Neuerung das Vererbungsprinzip ein. Dieses erlaubt das Vererben von gemeinsamen Eigenschaften zwischen Klassen, die in einer Generalisierungs- / Spezialisierungsbeziehung zueinander stehen und stellt einen Mechanismus zur Strukturierung, Redundanzreduktion und Wiederverwendung von Programmcode dar [s. Griffel 1998, 27]. Mit der Entwicklung methodischer Ansätze wie dem „Design by Contract“ [s. Meyer 1992] wurde auch verstärkt Gewicht auf eine umfassendere, um semantische Inhalte wie Vor- / Nachbedingungen und Invarianten angereicherte Schnittstellenbeschreibung gelegt. Einige Autoren sehen die Komponentenorientierung als natürliche Erweiterung der Objektorientierung, während andere den Ansatz als eigenständiges Konzept verstehen, der den Mängeln der Objektorientierung und der objektorientierten Technologien bezüglich der Entwicklung wieder verwendbarer verteilter Software entgegenwirken soll (s. [Stojanovic 2005, 20], [Griffel 1998, 26ff.]). Die Komponentenorientierung teilt mit der Objektorientierung verschiedene Designprinzipien und baut auch aus technischer Sicht auf gleichen Entwicklungs- und Middlewareplattformen wie Object Monitors oder Application Servern auf (s. Kap. 2.3.1). Wichtige Unterschiede zwischen Komponenten und Objekten bestehen u.a. in ihrer Granularität bzw. ihrem Abstraktionsniveau: Die im objektorientierten Design gebildeten Objekte sind zu feingranular, um als sinnvoll verteilbare und wieder verwendbare Elemente in einem komplexen System zu dienen, welches sich schnell aus hunderten von Klassen zusammensetzen kann [s. Stojanovic 2005, 153]. Komponenten kapseln Funktionen und Daten auf einem höheren Abstraktionsniveau, umfassen also i.d.R. den Funktionsumfang mehrerer Klassen [s. 11

Die Abstraktion nach dem Komplexprinzip strukturiert Elemente nach Teil/Ganzes-Beziehungen. Ein Beispiel ist die Zusammenfassung der Bestandteile „Motor“, „Fahrgestell“, „Räder“ etc. zum Objekt „Auto“. Die Abstraktion nach dem Klassenprinzip betrachtet Spezialisierungs / Generalisierung-Beziehungen, z.B. die Spezialisierung des Objekts „Auto“ in „Cabriolet“, „Kombi“ oder „Limousine“.

3.4 Abgrenzung der Serviceorientierung von verwandten Ansätzen

49

Matthes 2005, 12]. Komponenten stellen ausserdem stärker in sich geschlossene Einheiten dar, die Vererbungsbeziehungen auf Code- bzw. Implementierungsebene vermeiden und das Ziel der Wiederverwendung von Software über Komposition verfolgen [s. Griffel 1998, 32]. Sie betonen auch eher das Prinzip technologieübergreifender Interoperabilität und standardisierter Schnittstellen (s. [Griffel 1998, 32], [Matthes 2005, 12]): Während z.B. eine herkömmliche Java-Klasse ihre nach aussen sichtbare Funktionalität über eine Java-Klassenspezifikation beschreibt, verwenden Komponententechnologien implementierungsunabhängige Schnittstellenbeschreibungssprachen und auf plattformübergreifenden Standards basierende Kommunikationsprotokolle. Schliesslich weisen verschiedene Autoren auf den Vermarktungsaspekt von Komponenten hin: Komponenten sollten wieder verwendbare, vermarktbare Softwarebausteine sein und für sich selbst stehende Güter darstellen, die auf einem offenen oder unternehmensinternen Markt gehandelt werden können (vgl. [Turowski et al. 2002, 1], [Szyperski et al. 2002, 487f.]).

3.4.2

Serviceorientierung, Objekt- und Komponentenorientierung

Serviceorientierung übernimmt bewährte Konzepte der früheren Designansätze und versucht solche zu vermeiden, die aus Sicht einer unternehmensweiten ISArchitektur zu mangelhafter Interoperabilität oder Wiederverwendbarkeit und komplexen Abhängigkeiten führen (s. [Zimmermann et al. 2004a], [Matthes 2005, 14ff.]). Wesentliche Unterschiede zwischen serviceorientiertem und objekt- oder komponentenorientiertem Systemdesign bestehen in der grösseren Entwurfsreichweite, dem höheren fachlichen Abstraktionsniveau, der Fokussierung auf eine prozessorientierte Komposition von IT-Funktionalität sowie in der stärkeren Betonung der Serviceautonomie durch lose gekoppelte Kommunikation (s. [Baker/Dobson 2005, 634ff.], [Matthes 2005, 19]). Tabelle 3-4 zeigt Unterscheidungsmerkmale der Ansätze im Überblick. Merkmal

Objektorientierung

Komponentenorientierung

SOA

Entwurfsreichweite

Applikation

Applikation / Applikationsfamilie

IS-Architektur

Abstraktionsniveau

Fachklasse, feingranulare Schnittstellen (Kommunikation zwischen Fachklassen)

Verteilbare Applikations- / Fachfunktion, feingranulare Schnittstellen (Kommunikation zwischen Applikationskomponenten, z.B. zwischen Clientund Serverkomponente)

Geschäftsaktivität bzw. Geschäftsdokument, grobgranulare Schnittstellen (Kommunikation zwischen Applikationen bzw. Applikationsdomänen)

50

3 Prinzipien serviceorientierter Architekturen Merkmal

Objektorientierung

Komponentenorientierung

SOA

Abstraktionsund Wiederverwendungsprinzip

Klassenprinzip, Wiederverwendung durch Vererbung

Komplexprinzip, Wiederverwendung durch Komposition

Komplexprinzip, Wiederverwendung durch Komposition

Entwicklungsziel und -zeitpunkt

Fokus Applikationsentwicklung, gleichzeitige und gemeinsame Entwicklung von Schnittstellenanbietern und Nutzern

Fokus Applikationsentwicklung (i.d.R. zur Entwicklungszeit absehbare Integrationsbeziehungen zwischen Systemkomponenten), gleichzeitige und gemeinsame Entwicklung von Schnittstellenanbietern und Nutzern

Fokus i.d.R. nachträgliche Integration und Komposition von Applikationsfunktionen (zur Entwicklungszeit nicht zwingend bekannte Integrationsbeziehungen), Schnittstellenabieter und Nutzer zeitversetzt und unabhängig entwickelt

Kommunikationskopplung / Plattformabhängigkeit

Statusbehaftete Kommunikation, hohe Plattformabhängigkeit

Statusbehaftete und statuslose Kommunikation, mittlere Plattformabhängigkeit

Statuslose Kommunikation, niedrige Plattformabhängigkeit

Tabelle 3-4: Abgrenzung Objekt-, Komponenten- und Serviceorientierung Gestaltungsgegenstände des objekt- und komponentenorientierten Systementwurfs sind i.d.R. einzelne Anwendungssysteme. Dagegen strukturiert das serviceorientierte Design die unternehmensweite IS-Architektur bzw. die IS-Architektur innerhalb grösserer Organisationseinheiten [s. Baskerville et al. 2005]. Typische Abstraktionseinheiten des objekt- und komponentenorientierten Designs sind Fachklassen und Applikationskomponenten innerhalb eines Anwendungssystems, welche eine Aufgabenkapselung auf den verschiedenen Anwendungsschichten übernehmen [vgl. Stojanovic 2005, 52f.]. Beispiele sind Dialog-Komponenten auf der Präsentationsschicht, welche die Darstellung und Dialogsteuerung mit Benutzern realisieren, oder fachliche Komponenten (Entitäts- und ControllerKomponenten), die fachliche Klassen (z.B. „Fahrzeug“) mit ihren Attributen und Operationen kapseln und in Systemanwendungsfällen definierte Abläufe zwischen den Fachklassen steuern (z.B. „Callcenter reserviert Fahrzeug“) [s. Oestereich 2005, 159ff.]. Sie bieten viele, meist feingranulare Schnittstellen (Bsp. „getFahrzeugNummer“, „getFahrzeugTyp“ etc.), die primär der Integration und Koordination von Komponenten innerhalb einer Anwendung dienen und nicht den Geschäftskonzepten (Aktivität bzw. Arbeitsschritt, Geschäftsentität bzw. -dokument) entsprechen, wie sie die fachliche Modellierung anwendungsübergreifender Geschäftsprozesse verwendet [vgl. Aier/Schönherr 2004b, 24]. Services abstrahieren die im IS verfügbaren fachlichen Funktionen und Daten auf einer gröberen, geschäftsprozessorientierten Abstraktionsebene. Serviceschnittstellen kapseln mehr

3.4 Abgrenzung der Serviceorientierung von verwandten Ansätzen

51

Funktionalität bzw. komplette Geschäftsentitäten anstatt einzelne Attribute [s. McGovern et al. 2003, 50]. Im Gegensatz zur Objektorientierung und ähnlich wie die Komponentenorientierung verwendet eine SOA stärker das Komplexprinzip und Komposition als Abstraktions- und Wiederverwendungsmechanismus (vgl. [Krafzig et al. 2004], [Zimmermann et al. 2004a]): Wie die Komponentenorientierung zerlegt die Serviceorientierung das zu modellierende System in Teilfunktionalität, die über Kompositionsbeziehungen zusammengefügt wird, und vermeidet Vererbungsbeziehungen.12 Der serviceorientierte Systementwurf betrachtet stärker als typische objekt- und komponentenorientierte Methoden die nachträgliche Integration und Komposition bestehender Anwendungssysteme [s. Veryard 2003, 16]). Services und ihre Nutzer werden öfter als Objekte bzw. Komponenten in organisatorisch verteilten Teams, zu unterschiedlichen Zeitpunkten und in verschiedenen Technologien entwickelt [s. Sessions 2004, 45]. Anders als bei objekt- bzw. komponentenbasierten Anwendungssystemen werden in serviceorientierten Anwendungen Dienstanbieter und -nutzer nicht gemeinsam kompiliert, sondern Servicenutzer binden die von ihnen benötigten Dienste zur Laufzeit ein [s. Cervantes/Hall 2005, 10]. Aus diesen Gründen legt das serviceorientierte Design ein besonderes Gewicht auf die Reduktion der Abhängigkeiten von einer bestimmten Laufzeitumgebung bzw. Plattform. Ein wichtiges Mittel dazu ist die statuslose Kommunikation zwischen Services und Servicenutzern (s. [Erl 2005, 332], [Vogels 2003, 62]). Entwicklungs- und Laufzeitplattformen für verteilte Objekt- bzw. Komponententechnologien bieten integrierte Mechanismen für ein automatisiertes Objektlebenszyklus- und -statusmanagement. Diese übernehmen z.B. die Instanziierung eines Objekts, wenn ein entfernter Dienstnutzer eine Operation ausführen will, managen die Weitergabe von Objektreferenzen für den Zugriff auf bestimmte Objektzustände, von weiteren Kontextinformationen (z.B. Authentisierung) in statusbehafteten Interaktionen und geben die Objekte im Anschluss an die Interaktion wieder frei [s. Vogels 2003, 61f.]. Die Verwendung solcher Mechanismen kann bei einer technologie- bzw. plattformübergreifenden Interaktion wegen fehlender Standardisierung zwischen Technologien und Produkten zu Interoperabilitätsproblemen führen. Services sollten deshalb statuslos interagieren und Referenzen auf zu bearbeitende Objekte (z.B. einen bestimmten Kunden) sowie weitere Kontextinformation explizit bei jedem Aufruf in den ausgetauschten Nachrichten spezifizieren.

12

[Zimmermann et al. 2004a] zeigen am Beispiel der Abwicklung von Automobil-Reparaturaufträgen exemplarisch die unterschiedlichen Ergebnisse eines objekt- und eines serviceorientierten Ansatzes für den Systementwurf. Der objektorientierte Entwurf bildet nach dem Prinzip der Klassenbildung primär Softwareobjekte wie „Fahrzeug“, „Kunde“, „Reparaturauftrag“ oder „Reparaturtermin“, die jeweils Geschäftsentitäten mit dem dazugehörigen Verhalten (anlegen, suchen, modifizieren, löschen) kapseln. Der serviceorientierte Ansatz zerlegt das System nach dem Komplexprinzip in an Prozessaktivitäten und Geschäftsentitäten orientierte Basisfunktionen, die zu Prozessen zusammengefügt werden (z.B. „Inventory“ Service mit Operationen zur Verfügbarkeitsprüfung, Reservation oder Bestellung von Ersatzteilen, „Scheduling“ Service zur Terminvereinbarung, „Customer“ Service für das Suchen und Bearbeiten von Kundendten, etc.).

52

3 Prinzipien serviceorientierter Architekturen

3.5

Technologien und Produkte zur Implementierung von SOA

Das folgende Kapitel untersucht die technische Umsetzung von SOA. Dabei geht es auf Technologiestandards wie Web Services oder Komponentenmodelle ein (Kap. 3.5.1) und führt beispielhaft einige Produktplattformen von Herstellern von Integrations- bzw. Anwendungssoftware auf (Kap. 3.5.2).

3.5.1

Technologiestandards

Web Services sind die neueste Technologie zur Umsetzung von SOA, sind aber noch nicht vollständig ausgereift [s. Dostal et al. 2005, 26]. Unternehmen entwickelten deshalb bisher SOA vorwiegend auf älteren verteilten Objekt- bzw. Komponententechnologien. Web Services Die Web Services Architecture (WSA) Group des W3C definiert einen Web Service wie folgt [s. W3C 2004a]: „A Web service is a software system designed to support interoperable machineto-machine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Webrelated standards.” Diese Definition nennt mit HTTP, XML, SOAP und WSDL konkrete Spezifikationen für die technische Umsetzung der in Kap. 3.2.2 aufgeführten SOA-Architekturkomponenten „Nachricht“ und „Servicebeschreibung“. Sie führt keine technische Spezifikation des Verzeichnisdienstes auf. Trotz zögerlicher Adaption in der Praxis [s. Newcomer/Lomow 2004, 20f.] gilt aber die Verzeichnistechnologie UDDI gemeinsam mit XML, SOAP und WSDL als Bestandteil des BasisTechnologie-Stacks von Web Services [s. Kossmann/Leymann 2004, 120]. Die Extensible Markup Language (XML) wurde vom W3C verabschiedet und ist eine Metasprache zur Definition von anwendungsspezifischen Dokumententypen. Eine entscheidende Eigenschaft von XML ist die klare Trennung von Struktur, Inhalt und Layout einzelner Informationseinheiten [s. Merz 2002, 234ff.]. XML – besonders XML Schema, eine Definitionssprache, welche die Beschreibung des Aufbaus und der möglichen Inhalte anwendungsspezifischer Dokumente erlaubt – stellt die Basis für Web Service Standards dar. Die weiteren Kernstandards SOAP, WSDL und UDDI sind konkrete XML Schema-Spezifikationen. SOAP13 ist das vom W3C momentan in der Version 1.2 verabschiedete StandardKommunikationsprotokoll für Web Services. Es legt die Grobstruktur und die

13

SOAP stand ursprünglich für „simple object access protocol“, wird seit der Version 1.2 aber nicht mehr als Akronym verwendet.

3.5 Technologien und Produkte zur Implementierung von SOA

53

Verarbeitungsvorschriften von Nachrichten fest [s. W3C 2003]. SOAP definiert den Austausch von strukturierten und typisierten Daten auf der Grundlage von XML und bietet Möglichkeiten zur Definition anwendungsspezifischer Erweiterungen, etwa für das Routing von Nachrichten. Neben XML-Daten lassen sich im SOAP-Body auch nicht-XML-Daten (z.B. binäre Bilddateien) versenden. SOAP unterstützt verschiedene Nachrichtenaustausch-Muster (z.B. one-way oder request-response) und ist transportneutral. Es kann also über jedes Transportprotokoll (HTTP, FTP, SMTP, JMS, IIOP etc.) genutzt werden, wobei das W3C lediglich die HTTP- und SMTP-Bindung explizit spezifiziert [s. W3C 2003]. Die Web Service Description Language (WSDL) wird vom W3C gegenwärtig in der Version 2.0 erarbeitet und erlaubt die Beschreibung von Web Service Schnittstellen über die Spezifikation der Nachrichtenstrukturen und Datentypen, die sie verarbeiten können [s. W3C 2005]. In der momentan empfohlenen Version 1.1 definiert ein WSDL-Dokument einen Web Service als eine Sammlung von Endpunkten (ports), die eine Kombination von Netzwerkadresse und Bindung (binding) darstellen. Bindungen beschreiben die beim Nachrichtenaustausch verwendeten Protokolle und Datenformate. Nachrichten (messages) sind abstrakte Definitionen der ausgetauschten Daten, und Endpunkttypen (port types) spezifizieren die Operationen, die ein Web Service ausführen kann [s. W3C 2001b]. Trotz unterschiedlicher Terminologie sind die grundlegenden Prinzipien in der WSDL Version 2.0 die gleichen [s. Kossmann/Leymann 2004, 121]. Universal Description Discovery and Integration (UDDI) ist in der Version 3.02 als OASIS-Standard verfügbar [s. Oasis 2004]. Es spezifiziert ein plattformunabhängiges und branchenneutrales Geschäfts- und Diensteverzeichnis, das es potenziellen Web Service-Kooperationspartnern ermöglichen soll, ihre Angebote standardisiert zu beschreiben und in eine vorgegebene Taxonomie einzutragen. Nutzer können die Verzeichnisse entweder mittels Browser über die Web-Seiten der Verzeichnisbetreiber oder über spezielle Clients durchsuchen. Es sind auch programmierbare Schnittstellen vorgesehen, die es einer Applikation erlauben sollen, dynamisch elektronische Dienste zu identifizieren und zu nutzen. Die elementaren Web Service Spezifikationen SOAP, WSDL und UDDI stellen mit standardisierten Kommunikationsprotokollen und technisch-syntaktischen Schnittstellenbeschreibungen nur rudimentäre Middlewarefunktionalität zur Verfügung. Daneben sind aus verschiedenen Gremien14 eine Vielzahl von Standardisierungsvorschlägen hervorgegangen, die weitere Aspekte der Servicespezifikation und -interaktion behandeln. Diese umfassen unter anderem Policy-Spezifikationen, die eine formalisierte Beschreibung von Qualitätseigenschaften oder geschäftlichen Informationen zulassen, Sicherheitsspezifikationen oder Spezifikationen für Transaktionen und Choreografien auf Basis von Web Services (s. [Kossmann/Leymann 2004, 122ff.], [Wilkes 2005], [Dostal et al. 2005, 29]). Tabelle 3-5 führt Beispiele für verabschiedete bzw. sich in Entwicklung befindliche Web Service Spezifikationen auf.

14

Die wichtigsten Gremien, welche Spezifikationen für Standards im Umfeld von Web Services entwickeln und verabschieden, sind W3C, OASIS, IETF und UN/CEFACT [s. Dostal et al. 2005, 35f.].

54

3 Prinzipien serviceorientierter Architekturen

Insgesamt sind heute über 100 verschiedene Standards im Umfeld von Web Services im Gebrauch oder noch in Entstehung [s. Dostal et al. 2005]. Sie werden von verschiedenen Gremien entwickelt, weisen unterschiedliche Reifegrade auf und überschneiden sich teilweise. So steht bspw. der von den Softwareherstellern IBM, Microsoft, Bea und Tibco entwickelte Standard WSRM in Konkurrenz zum Standard WS-Reliability von Fujitsu, NEC, Oracle, Sonic Software und Sun Microsystems [s. Vogels 2003, 61]. Neben der daraus entstehenden Komplexität können auch Freiräume bei der Interpretation von Spezifikationen zu inkompatiblen Implementierungen der Web Service Technologien in Produkten von Softwareherstellern führen [s. Dostal et al. 2005, 37]. Die resultierenden Web Services sind in der Folge nur eingeschränkt interoperabel. Das Industriekonsortium WS-I (Web Services Interoperability) hat es sich deshalb zur Aufgabe gemacht, die Interoperabilität von Web Service Implementierungen verschiedener Hersteller sicherzustellen [s. WS-I 2005]. WS-I zählt gegenwärtig über 100 Mitglieder, die sich aus Softwareanbietern, Standardisierungsgremien und Softwareanwendern zusammensetzen. Das Konsortium entwickelt Testwerkzeuge und Profile, die beschreiben, wie Standards zu nutzen sind, damit die Interoperabilität z.B. zwischen in Microsoft .Net und Sun J2EE implementierten Web Services erhalten bleibt [s. Dostal et al. 2005, 37]. Da dies aber nur für reife und implementierte Standards möglich ist, gehen die Arbeiten des Konsortiums langsam voran. Gegenwärtig hat es das Basic Profile 1.1 [s. WS-I 2004b], das Simple SOAP Binding Profile 1.0 [s. WS-I 2004c] sowie das Attachments Profile 1.0 [s. WS-I 2004a] verabschiedet. Das Basic Profile und das Simple SOAP Binding Profile behandeln den Nachrichtenaustausch mit SOAP 1.1 und HTTP, die Servicebeschreibung mit XML und WSDL 1.1, die Servicepublikation mit UDDI 2.0 sowie Sicherheit auf HTTPTransportebene. Das Attachments Profile spezifiziert den Versand von Anhängen in SOAP-Nachrichten.

3.5 Technologien und Produkte zur Implementierung von SOA Spezifikationsinhalt

55

Spezifikationen

Web Service Management System- / Verteilungsmanagement

WSDM, WS-Manageability

Servicebereitstellung

WS-Provisioning

Sicherheit Generell

WS-Security

Sicherheitspolicies

WS-SecurityPolicy

Konversationssicherheit

WS-SecureConversation

Vertraulichkeit

WS-Trust

Identitäts-Föderation

WS-Federation

Präsentation Portalpräsentation

WSRP

Transaktionen und Geschäftsprozesse Asynchrone Web Services

ASAP

Transaktionen

WS-AtomicTransaction, WS-Coordination

Web Service Orchestrierung

BPEL(4WS), WS-CDL, WS-CAF

Nachrichtenaustausch Ereignisse und Benachrichtigungen

WS-Eventing, WS-Notification

Routing und Adressierung

WS-Adressing, WS-MessageDelivery

Verlässlicher Nachrichtenaustausch

WSRM, WS-Reliability

Nachrichtenkapselung

SOAP, SOAP MTOM

Metadaten Servicepublikation und -identifikation

UDDI, WSDL

Policy

WS-Policy, WS-PolicyAssertions

Service- und Nachrichtenbeschreibung

WSDL

Metadatenbereitstellung

WS-MetadataExchange

Basistechnologien Datenformat

XML, XML Schema, XML Namespaces

Transport

HTTP, FTP, SMTP, JMS, IIOP

Tabelle 3-5: Web Service Technologie-Stack (vgl. [Wilkes 2005], [W3C 2004a]) Komponententechnologien Schon vor Web Services realisierten Unternehmen SOA auf Basis von Komponententechnologien. Komponententechnologien stellen von fachlichen Anwen-

56

3 Prinzipien serviceorientierter Architekturen

dungen unabhängige Integrationsfunktionalität wie Verzeichnis-, Vermittlungsoder Workflowdienste zur Verfügung, auf deren Basis sich physisch verteilte Softwarekomponenten zu neuen Anwendungen zusammenfügen lassen. [Turowski et al. 2002, 1] definieren den Komponentenbegriff wie folgt: „Eine Komponente besteht aus verschiedenartigen (Software-)Artefakten. Sie ist wieder verwendbar, abgeschlossen und vermarktbar, stellt Dienste über wohldefinierte Schnittstellen zur Verfügung, verbirgt ihre Realisierung und kann in Kombination mit anderen Komponenten eingesetzt werden, die zur Zeit der Entwicklung nicht unbedingt vorhersehbar ist. Eine Fachkomponente ist eine Komponente, die eine bestimmte Menge von Diensten einer betrieblichen Anwendungsdomäne anbietet.“ Heute weit verbreitete Komponententechnologien bzw. Komponenten-Implementierungsmodelle umfassen u.a. Microsofts Component Object Model (COM+), das CORBA Component Model (CCM) von der OMG und Enterprise Java Beans (EJB) als Bestandteil der J2EE-Plattform von Sun (s. [Dostal et al. 2005, 37f.], [s. Stojanovic 2005, 29ff.]). COM+ ist ein programmiersprachenunabhängiger Komponentenstandard von Microsoft. Microsoft hat 1993 mit COM eine erste Version veröffentlicht, diese 1995 mit distributed COM (DCOM) für verteilte Umgebungen erweitert und DCOM zusammen mit dem Microsoft Transaction Service (MTS) zu COM+ ausgebaut [s. Stojanovic 2005, 29]. In COM+ werden verteilte Komponenten mit der Microsoft Interface Definition Language (MIDL) beschrieben und kommunizieren untereinander über den RPC-Mechanismus DCOM. COM+ unterstützt mit dem MTS Transaktionen über verteilte Komponenten. Weitere Basisdienste umfassen die Lastverteilung über einen Component Library Balancing (LBC) Server, die Unterstützung asynchroner Kommunikation über Queued Components, Komponentenidentifikationsmechanismen oder ein rollenbasiertes Sicherheitskonzept (s. [Mantel et al. 2000, 15f.], [Stojanovic 2005, 29]). Die Rolle des Serviceintermediärs bzw. Verzeichnisdienstes übernimmt bei COM+ das Active Directory. Die Common Object Request Broker Architecture (CORBA) ist ein 1991 in der Version 1.0 veröffentlichter Standard der Object Management Group (OMG) [s. Szyperski et al. 2002, 237]. Sie ist Bestandteil der Object Management Architecture (OMA), welche neben den Spezifikationen für einen Object Request Broker auch Spezifikationen für CORBA Services umfasst [s. Mantel et al. 2000, 11]. Diese stellen generische Dienste u.a. zur Transaktionsverwaltung (Transaction Service), Verzeichnis- und Directory-Dienste (Naming Service, Trading Object Service), Dienste für eine asynchrone Kommunikation (Notification Service) oder verschiedene Sicherheitsmechanismen (Security Service) zur Verfügung [s. Szyperski et al. 2002, 239ff.]. CORBA ist ein sprachneutraler Standard, der auf der OMG Interface Definition Language (IDL) für eine Servicebeschreibung und dem General Inter-ORB Protocol (GIOP) bzw. dem Internet Inter-Orb Protocol (IIOP) für die Kommunikation zwischen verteilten Objekten basiert. Als Bestandteil der CORBA 3.0 Spezifikation hat die OMG ein Komponentenmodell (CORBA Component Model, CCM) entwickelt (s. [OMG 2002], [Stojanovic 2005, 31]). Eine Komponente stellt dort eine Erweiterung und Spezialisierung eines CORBA Objekts dar, die mit der Component Implementation Definition Language (CIDL)

3.5 Technologien und Produkte zur Implementierung von SOA

57

beschrieben wird und in einer Container-Laufzeitumgebung ausgeführt wird, welche verschiedene generische CORBA Services implementiert [s. Stojanovic 2005, 31f.]. Sun Microsystems führte 1998 Enterprise Java Beans (EJBs) als Bestandteil der J2EE Plattform ein. Dabei werden Komponenten („beans“) in der Programmiersprache Java auf einem EJB-Server implementiert und laufen in einem EJBContainer. Der Container ist für das Komponentenlebenszyklus-Management (das Erzeugen, Aktivieren, Deaktivieren und Löschen von EJBs) verantwortlich. Daneben übernimmt er die Aufgaben der Transaktionsverwaltung, das PersistenzManagement oder bietet Sicherheitsdienste [s. Mantel et al. 2000, 16]. EJBs bieten über sog. Remote Interfaces, die in Java bzw. Java-IDL beschrieben sind, Zugriff auf ihre Services [s. Stojanovic 2005, 31]. Serviceaufrufe erfolgen über Java Remote Method Invocation (JRMI) im Falle einer Kommunikation zwischen JavaKomponenten, über JAX-RPC für einen mit Web Services kompatiblen, SOAP / XML-basierten Nachrichtenaustausch oder über RMI-IIOP für einen Nachrichtenaustausch mit CORBA-Komponenten [s. Sun 2003]. Protokolle und Schnittstellen für eine asynchrone Kommunikation stellt der Java Messaging Service (JMS) zur Verfügung. J2EE macht mit der Java Naming and Directory Interface (JNDI) Spezifikation Vorgaben für einen Verzeichnisdienst. Tabelle 3-6 stellt die besprochenen Technologien zur Implementierung von SOA einander gegenüber. Der Vergleich zeigt, dass die Spezifikationen im Rahmen des Web Service Frameworks noch nicht die Reife erreicht haben, wie dies für etablierte Komponententechnologien wie CORBA, COM+ oder J2EE der Fall ist (s. [Vogels 2003, 62], [Hars/Schlüter-Langdon 2002, 16]). So stehen für Web Services bspw. gegenwärtig keine einheitlichen, ausgereiften Spezifikationen für Transaktionen oder eine asynchrone Kommunikation zur Verfügung. Auch der mit UDDI spezifizierte Verzeichnisdienst unterstützt nicht die volle Funktionalität der aus den Komponententechnologien bekannten Naming- und Directory-Dienste, sondern wurde in erster Linie als Katalog für Menschen konzipiert. Er ermöglicht zwar prinzipiell ein dynamisches Einbinden von Services zur Laufzeit (z.B. für einen Wechsel der Adresse des Web Services [s. Stiemerling 2002, 442]), eignet sich bspw. aber nicht für ein Management der Lastverteilung bei Performanzproblemen [s. Alonso 2002, 8].

58

3 Prinzipien serviceorientierter Architekturen Web Services

COM+

J2EE (EJB)

CORBA (CCM)

Schnittstellenbeschreibung

WSDL

MIDL

Java, JavaIDL

OMG-IDL, CIDL

Aufruf / Nachrichtenaustausch

SOAP

DCOM

JRMI, JAXRPC, RMIIIOP

IIOP, GIOP

Verzeichnis- / Directory-Dienste

UDDI

ADSI

JNDI

Naming Service, Trading Object Service

Asynchrone Kommunikation

(ASAP)

Queued Components

JMS

Notification Service

Transaktionen

(WS-Atomic Transaction etc.)

MTS

JTA

Transaction Service

Sicherheit

(WS-Security etc.)

MTS rolebased security

JAAS

Security Service

Tabelle 3-6: Beispiele von Technologien zur Implementierung von SOA Den aufgeführten Komponententechnologien werden verschiedentlich Unzulänglichkeiten vorgeworfen, besonders bezüglich ihrer Plattformabhängigkeit und Interoperabilität (s. [Baker 2002, 627], [Balzert 2001, 937], [Raptis et al. 2001, 167]): Sie basieren entweder auf proprietären Plattformen eines Herstellers (COM+), spezifischen Programmiersprachen (J2EE) oder die Spezifikationen sind je nach Hersteller unterschiedlich und teilweise untereinander inkompatibel implementiert (CORBA). Die Interaktion von Softwarebausteinen zwischen verschiedenen Komponentensystemen wird u.a. wegen unterschiedlichen Techniken für die Schnittstellenbeschreibung oder wegen technologiespezifischen Protokollen beschränkt, was spezielle Adapter erforderlich macht und die gemeinsame Nutzung der Dienste von Komponenten verschiedener Komponentensysteme erschwert. Aus diesem Grund werden Web Services als „Middleware für Middleware“ zur Integration verschiedener Komponentenplattformen grosses Potenzial zugesprochen [s. Baker 2002, 628].

3.5.2

Produktplattformen

In der Vergangenheit fehlten integrierte Produktplattformen für die Umsetzung von SOA. EAI- und Middlewareprodukte waren meist auf spezifische Einsatzspektren (komponentenbasierte Applikationsentwicklung, unternehmensinterne Applikationsintegration, zwischenbetriebliche Applikationsintegration etc.) ausgelegt [s. Vogel 2005, 24]). Unternehmen, die SOA auf Basis von Komponententechnologien umsetzen wollten, mussten sich ihre Infrastruktur aus Einzelprodukten eines oder mehrerer Hersteller individuell aufbauen [s. Richter et al. 2005,

3.5 Technologien und Produkte zur Implementierung von SOA

59

415]. Mit der zunehmenden Bedeutung von SOA in der Industrie und der Verbreitung von Web Services als hersteller- und technologieübergreifende Standards ist eine wachsende Konvergenz bisher isolierter Middlewaretechnologien in umfassenden Integrations- und Entwicklungsplattformen für SOA zu beobachten (s. Abb. 3-10). unternehmensinterne Integration (EAI)

Anwendungsentwicklung

Remote Procedure Call

unternehmensübergreifende Integration (B2B)

TP Monitors

Prozedurale, verteilte Programmierung

Object Brokers

Object Monitors

Objektorientierte, verteilte Programmierung

Message-oriented Middleware

Application Server

Composite Application- / Portalplattformen

Komponentenmodelle

Message Broker

B2B Integration Broker

nachrichtenbasierte Programmierung Workflow Management Systeme

Serviceorientierte Architektur Web Services

Abb. 3-10: Middlewarekonvergenz in SOA-Plattformen [vgl. Vogel 2005, 24] Dabei bauen nicht nur klassische Middleware- bzw. EAI-Anbieter ihr Produktportfolio aus. Auch Hersteller, die traditionell eher aus dem Bereich Anwendungssoftware kommen, bieten seit einiger Zeit umfassende SOA-Infrastrukturplattformen an [s. Rangan et al. 2005, 6]. Eine Studie der Gartner Group nennt u.a. IBM, BEA Systems, Microsoft, SAP oder Oracle als wichtige Anbieter sog. „integrated service environments“ [s. Plummer et al. 2006]. Sie weist aber auch darauf hin, dass sich die Plattformen noch in einem frühen Entwicklungsstadium befinden und die einzelnen Produktkomponenten der Plattformen oft erst mangelhaft integriert sind (s. auch [Natis et al. 2006], [Leser 2006, 181]). Abb. 3-11 führt Beispiele umfassender SOA-Integrationsplattformen von BEA Systems, IBM und SAP und ihre Produktkomponenten auf.

60

3 Prinzipien serviceorientierter Architekturen BEA AquaLogic

IBM WebSphere

SAP NetWeaver

Ebene Desktopintegration

AquaLogic User Interaction

WebSphere Portal

SAP Enterprise Portal

Ebene Workflowintegration

AquaLogic Business Service Interaction

WebSphere Process Server

SAP Business Workflow (Business Process Management)

AquaLogic Messaging Service Bus

WebSphere Message Broker

Ebene Services

Ebene Anwendungssystem

Service Registry

WebLogic Application Server

AquaLogic Data Services

WebSphere Enterprise Service Bus

SAP Exchange Infrastructure (Integration Broker)

WebSphere Application Server

SAP Web Application Server

WebSphere MQ

SAP Master Data Management

WebSphere Information Integrator

SAP Business Intelligence

Abb. 3-11: Beispiele für SOA-Integrationsplattformen (vgl. [BEA Systems 2006], [IBM 2006], [SAP 2006]) Ein weiterer Trend bei Herstellern von Anwendungssoftware besteht darin, ihre bisher hochintegrierten Softwarepakete stärker zu komponentisieren und Kunden Zugriff auf vordefinierte Services für eine einfachere Integration mit herstellerfremden Applikationen zu bieten (s. [Sprott 2004], [Whiting 2002]). Ein Beispiel ist SAPs mehrjähriges Enterprise Services Architecture (ESA)-Programm (s. [Bacheldor 2004], [Quack 2004b]). Bestandteil dieses Programms ist u.a. eine stärkere Komponentisierung der SAP R/3-Lösung und weiterer SAP-Produkte im Rahmen der MySAP Business Suite und die Kapselung ihrer Grundfunktionen als „Enterprise Services“ auf Basis der NetWeaver-Plattform. Diese Komponenten und Services bilden die Grundlage für Composite Applications in der mySAP Business Suite (z.B. branchenspezifische SAP-Lösungen) und für sog. xApps (Cross Applications), welche den Funktionsumfang der mySAP Business Suite unter Integration von Drittprodukten erweitern (s. Abb. 3-12). Die Entwicklung von xApps unterstützt das Composite Application Framework der NetWeaverPlattform, das Entwicklungsmethoden, Werkzeuge und eine Laufzeitumgebung bietet [s. SAP 2004a, 10]. Dadurch sind sowohl Kunden als auch SAP-Partnerfirmen in der Lage, SAP-Funktionalität einfacher in eigenen Lösungen zu verwenden, als dies beim bisherigen R/3-System der Fall war. SAP plant bis 2007 alle mySAP-Produkte NetWeaver- und Service-fähig zu machen. In einem Preview-System veröffentlichte das Unternehmen 2005 die ersten 500 Enterprise Services, welche zukünftig Kunden und Partnern zur Entwicklung eigener Composite Applications zur Verfügung stehen sollen [s. SAP 2005a].

3.6 Zusammenfassung

61

mySAP Business Suite

SAP xApps

Composites Verbraucherwerbung

Rechnungsprüfung

Composites …

…

SAP xEIC

SAPxPD

Drittprodukte

Generische Services

SAP NetWeaver Enterprise Services APO

ERP

CRM

Branchenkomponente

SAP-Komponenten

Abb. 3-12: Überblick über die SAP ESA [s. SAP 2004a, 14]

3.6

Zusammenfassung

Im Business Engineering Modell lässt sich eine SOA als Ansatz für die Strukturierung und Standardisierung der Integrations- und Applikationsarchitektur einordnen. Eine SOA verfolgt das Ziel, die anwendungsübergreifende Prozessintegration zu vereinfachen und die IT-Effizienz durch Wiederverwendung von Anwendungsfunktionalität und die Realisierung einer architekturweit standardisierten Schnittstellen- und Kommunikationsschicht zu verbessern. Das vorangegangene Kapitel charakterisierte eine SOA als Architekturstil für die Konstruktion von mehrschichtigen, verteilten Systemarchitekturen, die Teile von Applikationen unter Berücksichtigung einer Reihe von Designprinzipien als Services kapseln. Diese Designprinzipien lassen sich in die Kategorien Schnittstellenorientierung, Interoperabilität, Autonomie und Modularität sowie Bedarfsorientierung unterteilen, wobei einzelne Prinzipien je nach Anwendungskontext und Zielsetzung der SOA unterschiedlich wichtig sind. Die Serviceorientierung besitzt als Architekturstil gewisse Ähnlichkeiten zu früheren Ansätzen wie dem modularen Systemdesign, der Objekt- oder der Komponentenorientierung. Im Vergleich zu diesen weist sie aber eine grössere Entwurfsreichweite in der Applikationsarchitektur, ein höheres Abstraktionsniveau, einen stärkeren Fokus auf die prozessorientierte Komposition von IT-Funktionalität sowie eine stärkere Gewichtung der Unabhängigkeit und der lose gekoppelten Kommunikation zwischen Softwarebausteinen auf. Services stellen als geschäftsund prozessorientierte Abstraktion von IT-Funktionalität eine „Brücke“ zwischen fachlichen Prozessmodellen und technischen Anwendungsfunktionen dar. Wichtigste Neuerungen von SOA aus technischer Sicht sind die Konvergenz von Middlewarelösungen zu umfassenden und integrierten SOA-Plattformen sowie die Entwicklung der Web Service Standards und ihre breite Implementierung in Produkten vieler Hersteller. Web Services haben bei der Spezifikation von Diensten für eine serviceorientierte Integrationsplattform noch nicht den Reifegrad bestehender komponentenbasierter Ansätze wie z.B. CORBA oder J2EE erreicht. Zumindest die Kernstandards SOAP, WSDL und UDDI stossen aber in der Software-

62

3 Prinzipien serviceorientierter Architekturen

industrie auf eine herstellerübergreifende Akzeptanz und Unterstützung wie noch keiner der vorherigen Ansätze [s. Baker 2002, 623]. Dank der Standardisierungsaktivitäten von Industriekonsortien wie WS-I sind sie ein wertvolles Hilfsmittel für die Integration von auf verschiedenen Technologieplattformen implementierten Services.

4 Fallbeispiele zu SOA Fallstudien helfen bei der Identifikation von Treibern, Zielen, Potenzialen und Herausforderungen von SOA in der Praxis. Sie zeigen konkrete Ausprägungen des SOA-Ebenenmodells und der Designprinzipien aus Kap. 3.3 und geben Hinweise für Handlungsoptionen und Massnahmen zur Umsetzung einer SOA. Kap. 4.1 stellt die Auswahl der untersuchten Unternehmen sowie das verwendete Dokumentationsraster vor. Kap. 4.2 bis 4.5 beschreiben die Fallstudien detailliert. Kap. 4.6 gibt einen vergleichenden Überblick über ausgewählte Aspekte der Fallstudien.

4.1

Auswahl der Unternehmen und Übersicht

Zum Zeitpunkt der Fallstudienerhebung (Ende 2004 bis Ende 2005) waren in der Literatur erst wenige Beispiele umfassender, reifer SOA-Umsetzungen bekannt. Dieses Buch beschreibt vier Fallstudien aus unterschiedlichen Branchen und in verschiedenen Umsetzungsstadien. Die Beispiele Deutsche Post Brief und Credit Suisse werden in der Literatur als reife Umsetzungen einer unternehmensweiten SOA charakterisiert (s. [Krafzig et al. 2004], [Aier/Schönherr 2004a]). T-Com ist ein ehemaliges Partnerunternehmen des Forschungsprojekts CC BN3. Das Fallbeispiel befindet sich noch in einem frühen Umsetzungsstadium und konzentriert sich in einem ersten Schritt auf die Umsetzung einer SOA für den Prozessbereich Fulfillment. Das Beispiel Zuger Kantonalbank beschreibt nicht die unternehmensweite SOA-Einführung, sondern die servicebasierte Entwicklung eines integrierten Arbeitsplatzes. Es wurde in diese Publikation mit aufgenommen, weil es im Gegensatz zu den anderen Beispielen die Verwendung von Services in Workflows bzw. Taskflows illustriert. Die folgenden Abschnitte geben einen Überblick über die untersuchten Projekte zur Umsetzung einer SOA. Sie sind wie folgt strukturiert: •

Unternehmen: Beschreibt die Eckdaten der untersuchten Firma.

•

Ausgangslage: Stellt die Augangslage des Unternehmens und die Treiber dar, die zur Umsetzung einer SOA führten.

•

Umsetzung einer SOA: Erläutert die mit SOA verfolgten Ziele, getroffene Massnahmen und die realisierte Architektur. Der Abschnitt konzentriert sich auf die Ausprägung der in Kap. 3 hergeleiteten Architekturkomponenten und Designprinzipien. Detailliertere Beschreibungen zu einzelnen Architekturmanagement-Massnahmen und Vorgehensweisen bei der Umsetzung der SOA liefert Kap. 1.

•

Bisherige Erfahrungen: Diskutiert den bisherigen Aufwand und Nutzen der SOA, Herausforderungen und Erfolgsfaktoren bei der Umsetzung sowie geplante Weiterentwicklungen.

64

4.2

4 Fallbeispiele zu SOA

Deutsche Post Brief

4.2.1

Unternehmen

Mit 83 Briefzentren, 3'500 Auslieferungsstützpunkten und ca. 13'000 Filialen ist der Unternehmensbereich Brief von Deutsche Post World Net Europas grösster Briefdienstleister. Deutsche Post Brief verarbeitet täglich rund 72 Mio. Sendungen für 3 Mio. Geschäftskunden und 39 Mio. private Haushalte. Neben dem nationalen und internationalen Briefversand bietet der Unternehmensbereich briefbezogene Mehrwertdienstleistungen sowie Leistungen in den Bereichen Pressedistribution, Direkt Marketing und Philatelie an. Deutsche Post Brief Gründung

1924 Gründung der Deutschen Reichspost als selbständiges Unternehmen, 1989 Umwandlung von einem öffentlich-rechtlichen in ein privates Unternehmen

Firmensitz

Bonn, Deutschland

Branche

Logistik

Firmenstruktur

Eigenständiger Unternehmensbereich im Konzern Deutsche Post World Net

Geschäftsbereiche

Brief Kommunikation, Presse Distribution, Global Mail, Direkt Marketing, Philatelie

Umsatz

12.747 Mrd. EUR (2005)

Mitarbeiter

125'282 (2005)

Homepage

http://www.deutschepost.de

Tabelle 4-1: Kurzportrait Deutsche Post Brief 4.2.2

Ausgangslage

Die geringe Verfügbarkeit übergreifender Kerninformationen (Kunden, Kosten, Wettbewerberinformationen etc.) und zunehmend umfang- und risikoreichere ITProjekte führten dazu, dass Deutsche Post Brief neue Geschäftsanforderungen immer seltener in der geforderten Zeit umsetzen konnte: Das Unternehmen plante in der Vergangenheit seine IS-Architektur nicht zentral. Projekte aus den Fachbereichen wurden zwar in Zusammenarbeit mit einer zentralen IT umgesetzt, eine projektübergreifende Koordination und Planung fehlte jedoch. Die Folgen davon waren spezialisierte, isolierte Anwendungssysteme mit grossen Redundanzen in Applikationsfunktionen und Geschäftsdaten. Heterogene, für Einzelprojekte implementierte Systemschnittstellen mit vielen undokumentierten Abhängigkeiten führten bei neuen Projekten zu grossem Anpassungsaufwand sowie zu mangelhafter Wiederverwendung bestehender Funktionalität. Die gewachsene IS-Architektur war teuer im Unterhalt. Immer grössere Anteile des IT-Budgets flossen in den

4.2 Deutsche Post Brief

65

Betrieb und in die Wartung von Systemen, und nur ein geringer Teil stand für Neu- bzw. Weiterentwicklungen zur Verfügung [Herr/Brombach 2004, 1].

4.2.3

Umsetzung einer SOA

Ziele und Überblick 1999 initiierte Deutsche Post Brief ein strategisches Projekt zur zentralen, geschäftsorientierten Neugestaltung der Applikationsarchitektur. Ziel des Projektes war, eine logische Applikationsarchitektur als Generalbebauungsplan für eine redundanzfreie Implementierung von Anwendungsfunktionalität und eine konsistente Datenpflege zu entwickeln. Damit sollte eine bessere Wiederverwendbarkeit von Funktionen zur Unterstützung neuer Prozesse sowie ein gezielter und isolierter Ausbau um zusätzliche Funktionen erreicht werden. Die Ansiedlung des Projekts im Vorstand des Unternehmensbereichs Brief sorgte für die notwendige Managementunterstützung. Resultat des Projekts war eine fachliche SOA, bestehend aus voneinander abgegrenzten Anwendungsdomänen und Serviceschnittstellen für den Zugriff auf Funktionen und Daten in diesen Domänen. Das strategische Projekt führte zu einer Reihe von Implementierungsprojekten: Einerseits wurden verschiedene Fachprojekte für die Implementierung einzelner Domänen und Services (z.B. der Aufbau einer zentralen Kundendatenbank) angestossen. Andererseits entwickelte die IT-Abteilung den „Service Backbone“ (SBB), eine Integrationsplattform für die Kopplung von Serviceanbietern und Servicenutzern. Der SBB wurde Ende 2001 in einer ersten Version produktiv eingesetzt. Im Rahmen der Umstellung auf SOA bildete Deutsche Post Brief den zentralen IT-Bereich „Service Oriented Platform (SOP)-Group“, welcher die Weiterentwicklung des SBB und seine Verbreitung in den Unternehmensbereichen Brief sowie Express/Logistik (DHL) verantwortet. Entwicklung der fachlichen Applikationsarchitektur Ausgehend von einer Analyse der Kern-Geschäftsprozesse entwickelte Deutsche Post Brief eine fachliche Applikationsarchitektur, welche die fachlichen Funktionen und Daten prozessunabhängig und redundanzfrei in Applikationsdomänen abbildet (s. Abb. 4-1). Jeder Zugriff auf die in den Domänen gekapselte Geschäftslogik soll zukünftig über Serviceschnittstellen stattfinden. Teilweise kommunizieren auch Subdomänen innerhalb der Hauptdomänen über Services. 2005 boten die Domänen 20-30 Serviceschnittstellen, die jeweils mehrere Operationen unterstützten. Die identifizierten Services richten sich derzeit grösstenteils nach Geschäftsobjekten wie „Kunde“, „Rechnung“ oder „Vertrag“ und bieten datenbearbeitende Operationen wie „anlegen“, „suchen“ oder „löschen“. Wenige Services (z.B. Dublettenprüfung oder Adressvalidierung) kapseln komplexere Geschäftslogik, die sich an Prozessaktivitäten orientiert.

66

4 Fallbeispiele zu SOA

Kundendaten pflegen

Service Produkte

Datenanalyse

Service

Entwicklung DM-Kampagnen

Service

Ansprachekoordination

Service

Durchführung und Responseerfassung

Service

Auswertung

Service

Relationship

Kunde

Abrechnung

Leistungserbringung

Abb. 4-1: Applikationsdomänen und Zugriff über Services am Beispiel des Prozesses Kampagnenmanagement [s. Helbig 2005] Identifikation und Implementierung von Services Gemeinsam mit der Domänenbildung identifizierte Deutsche Post Brief auch pro Domäne die wichtigsten zu implementierenden Services. Die Hauptkriterien, nach denen Services gebildet wurden, waren: •

Generizität und Wiederverwendungspotenzial. Services sollten nicht für einen spezifischen Service-Nutzer ausgelegt, sondern in unterschiedlichen Prozessen und Applikationen nutzbar sein.

•

Fachlich sinnvolle und beschreibbare Dienstleistung. Die Services kapseln die fachliche Geschäftslogik, welche einen Geschäftsnutzen bietet, und sind aus fachlicher Sicht beschreibbar.

•

Langfristige Stabilität. Die Serviceschnittstellen sollten möglichst stabil sein. Dies hoffte das Projektteam aus fachlicher Sicht zu erreichen, indem es die Services entlang der grundlegenden stabilen Geschäftsfunktionen und Geschäftsobjekte definierte, die sich im Zeitverlauf wenig ändern. Aus technischer Sicht sollen Services eine stabile Abstraktionsschicht darstellen, die Serviceanbieter von den Servicenutzern trennt und eine schnelle und einfache Änderung der Serviceimplementierung erlaubt. Eine Massnahme zur Förderung der technischen Stabilität war die Verwendung breit akzeptierter Industriestandards (UML, XML, WSDL etc.) für die Servicespezifikation und -entwicklung. Bei der Serviceimplementierung legte das Unternehmen die Priorität auf Services, die zur Unterstützung neuerer Anwendungsbereiche mit hoher Dynamik (z.B. Customer Care, Call Center und Multi Channel Management) notwendig waren. Mit der Implementierung von Services ging teilweise auch eine Harmonisierung der Anwendungssystemlandschaft einher: Um Komplexität und Wartungs- bzw.

4.2 Deutsche Post Brief

67

Betriebsaufwände zu reduzieren, verfolgt die IT besonders bei Neuentwicklungen das Ziel, die Servicefunktionalität physisch möglichst in einem zentralen System (z.B. einer zentralen Kundendatenbank) zu realisieren. Dies ist jedoch nicht immer möglich, z.B. wenn für den Service benötigte Daten und Funktionen über mehrere Altanwendungen verteilt sind. Ein Beispiel für einen implementierten Service stellt der Service „Kundenmanagement“ dar. Dieser bietet Nutzern wie bspw. Call-Center-, Portal- oder CRMSystemen über die Operationen „seek“, „get“, „create“, „update“, „delete“, „getChildNodes“ und „checkAdress“ die Möglichkeit, Kundendaten zu suchen, erfassen, modifizieren und validieren. Die Servicenutzer bearbeiten die Entität Kunde über diese Operationen nicht auf Basis einzelner Attribute (Name, Vorname, Adresse etc.), wie dies bei einem Zugriff in Form von Objektmethoden typischerweise der Fall wäre, sondern erhalten und liefern jeweils eine strukturierte XMLNachricht, welche sämtliche Kundeninformationen (ca. 100 Attribute) enthält. Dadurch steigt zwar die bei der Servicenutzung ausgetauschte Datenmenge, die Anzahl Operationen bzw. Schnittstellen und die Häufigkeit der Interaktion zwischen Serviceanbieter und -nutzer wird aber niedrig gehalten. Abb. 4-2 zeigt schematisch die Anpassungen der bestehenden Anwendungssystemlandschaft bei der Umsetzung des Services: Existierten früher über 40 unterschiedliche Anwendungen mit lokaler Datenhaltung, wurde für den Service eine neue, zentrale Stammdatenbank implementiert. Diese setzt hauptsächlich Datenzugriffslogik um, mit nur geringem Anteil an Fachlogik bspw. für die Identifikation von Dubletten. Verschiedene bereits existierende Applikationen, besonders aber neue Applikationen, die Kundendaten verwenden, nutzen das Stammdatensystem über die Serviceschnittstelle. Derzeit existieren rund ein Dutzend Servicenutzer. Gewisse Applikationen (z.B. mobile Anwendungen ohne dauerhaften Online-Zugang) arbeiten noch mit lokalen Kundendaten, die sie aber regelmässig mit der zentralen Datenbank synchronisieren. Sie verwenden dazu spezielle, domäneninterne Serviceschnittstellen. Applikation 3 Applikation 1

Applikation 2

Applikation 3

Applikation 5 Applikation 6

Applikation 4

Einheitliche standardisierte Schnittstelle

Heterogene Schnittstellen Applikation 4

Applikation 2

Applikation 7

Applikation 1

Service

Applikation 5

Zentrale Stamm-DB Datensynchronisierung (domäneninterne Services) Schnittstelle

Applikation 7

Applikation 6

Applikationsfunktionalität Kundendaten

Abb. 4-2: Implementierung des Services "Kundenmanagement"

68

4 Fallbeispiele zu SOA

Der Hauptaufwand für die Implementierung des Services entstand in der Entwicklung des Datenmodells der Schnittstelle. Um den Service im Zeitablauf möglichst stabil und ausreichend generisch zu bilden, muss das Datenmodell alle von aktuellen und zukünftigen Servicenutzern geforderten Sichten auf die Entität „Kunde“ abbilden können. Das bedeutet, dass der Service bspw. sowohl für einen „Kampagnen-Kunden“ im Rahmen einer Marketing-Kampagne als auch für einen „Rechnungskunden“ im Rahmen der Auftragsabwicklung die benötigten Informationen (z.B. Kundentyp, Anschrift) in der notwendigen Granularität (z.B. Unterscheidung von Liefer- und Rechnungsanschrift) liefern können muss. Für jeden implementierten Service existiert eine fachliche Servicebeschreibung. Diese enthält die für den Serviceaufruf notwendigen bzw. die vom Service gelieferten Datenelemente (Nachrichten, fachliche Datentypen, Fachklassen, Fehlermeldungen, Geschäftsregeln) sowie die Beziehungen zwischen diesen Elementen (Assoziationen, Generalisierung, Komposition, Abhängigkeiten), notwendige Datentransformationen, das dynamische Verhalten des Services (Sequenzdiagramme), nichtfunktionale Eigenschaften (Servicequalität bzw. Verfügbarkeiten, Antwortzeiten etc.) sowie Beispiele für Daten und Serviceaufrufe. Um eine abteilungs- bzw. fachbereichsübergreifend konsistente Serviceentwicklung zu erreichen, definierte Deutsche Post Brief standardisierte Prozesse für das Servicedesign. Die Implementierung eines neuen Services umfasst folgende Schritte [s. Herr/Bath 2004, 4]: •

Identifikation aller potenzieller Servicenutzer

•

Spezifikation der Geschäftsfunktionalität unter Berücksichtigung der Anforderungen aller potenziellen Servicenutzer

•

Abgleich der Geschäftsfunktionalität mit den Applikationsdomänen und den bereits implementierten Services

•

Erstellung der Servicebeschreibung, der Service Level Agreements (SLAs) und des XML-Schemas zur Publikation des Services im Service Registry

•

Serviceimplementierung

•

Anbindung des Services an den Service Backbone

• Registrierung des Services im SBB User Directory Um einen neuen Servicenutzer anzubinden, sind zwei Schritte notwendig: •

Erfassung der Nutzerinformationen im SBB User Directory für die Authentifizierung und Autorisierung

•

Lokale Implementierung der Serviceschnittstelle bei der Nutzerapplikation

Entwicklung der Integrationsarchitektur (Service Backbone) Der sog. „Service Backbone“ (SBB) stellt den Kern der technischen Umsetzung der SOA bei Deutsche Post Brief dar und unterstützt als Kernfunktion die Kommunikation zwischen Serviceanbietern und -nutzern. Die Hauptkomponenten des SBB lassen sich in die in Abb. 4-3 dargestellten Bereiche der zentralen Infrastruktur (Core), der technischen Serviceteilnehmer (Technical Service Participants), der Schnittstellen (Interface) sowie der unterstüt-

4.2 Deutsche Post Brief

69

zenden Werkzeuge (Tools) für Anwendungsentwickler unterteilen (s. [Herr et al. 2004], [Herr/Sannemann 2004]). Tools

Interface

Service Editor

Programming Interface

Development Box

Legacy Integration System / eBIB

…

Technical Service Participants Transformation Services

Parsing and Validation

Security and User Management

…

Core Service Directory

Message Queuing

Abb. 4-3: Komponenten des SBB (in Weiterentwicklung) [s. Herr/Sannemann 2004, 3] Die Kerndienste des SBB umfassen die Komponenten Service Directory sowie Message Queuing. Das Service Directory dient als zentrales Verzeichnis für Services und ermöglicht in erster Linie das Registrieren und dynamische Binden von Services zur Laufzeit. Servicenutzer verwenden lediglich eine logische Adressierung von Diensten in Form eines Uniform Resource Locators (URL). Die Übersetzung in eine physische Adresse zur Laufzeit übernimmt der SBB. Neben der Funktion der logischen Adressierung ist das Service Directory zuständig für die Authentisierung und Autorisierung beim Zugriff auf Services unter Rückgriff auf Benutzer- und Berechtigungsinformationen. Darüber hinaus unterstützt es eine Versionierung von Services, d.h. Serviceanbieter können unterschiedliche Versionen von Diensten gleichzeitig zur Verfügung stellen. Die Implementierung basiert auf den Protokollen LDAP und HTTP, wobei Standard-Implementierungen von entsprechenden Servern eingesetzt werden. Die Kernfunktion der Komponente Message Queuing besteht in der Bereitstellung von Mechanismen zur Sicherstellung der reibungslosen Kommunikation zwischen Serviceanbieter und -nutzer während der Nutzung eines Dienstes. Insbesondere erlaubt die Komponente asynchrone und persistente Serviceaufrufe. Das Message Queuing basiert auf dem Standard Java Messaging Service (JMS) und unterstützt verschiedene Interaktionsstile (synchron, asynchron, publish / subscribe). Die Implementierung der Komponente beruht auf einem JMS-konformen Message Broker. Die technischen Serviceteilnehmer stellen Komponenten dar, die klar definierte Integrationsfunktionen über SBB-Schnittstellen anbieten. Beispiele sind die Komponenten Security and User Management (stellt Funktionen zur zentralen Administration von Benutzerdaten und Zugriffsberechtigungen zur Verfügung), Trans-

70

4 Fallbeispiele zu SOA

formation Service (stellt Routinen für die Transformation von Nachrichten und Daten bereit) oder Parsing and Validation (prüft die Gültigkeit der über den SBB ausgetauschten Nachrichten). Der Schnittstellen-Bereich des SBB stellt u.a. ein Java-basiertes Programming Interface (API) sowie ein Legacy Integration System für die Anbindung von Altsystemen bereit. Bei der Implementierung des SBB spielte für Deutsche Post Brief die Unabhängigkeit von einzelnen Softwareherstellern eine grosse Rolle. Das Unternehmen wählte deshalb einen Best-of-Breed Ansatz, der Infrastrukturkomponenten verschiedenster Anbieter, aber auch Eigenentwicklungen zusammenführt. So basiert die Plattform z.B. auf IBM WebSphere MQ, dem Sun One Directory Server, den Tomcat Apache Server oder den Produkten der Bea Weblogic Platform [s. Herr/Bath 2004, 233]. Die Implementierung setzt so weit wie möglich auf Industriestandards und versucht, herstellerspezifische Erweiterungen zu vermeiden. Die Plattform verwendet z.B. WebSphere MQ für das Message Handling, verzichtet aber auf die Nutzung proprietärer Erweiterungen und bindet das Produkt über den Java Messaging Service (JMS) ein. Von Web Service Standards erwartet Deutsche Post Brief einen wesentlichen Beitrag zur Anbieter- und Plattformunabhängigkeit der SOA. Sie erfüllen aber momentan nicht alle Anforderungen der SOA Infrastruktur und weisen z.B. Mängel in den Bereichen Versionierung, zuverlässige asynchrone Kommunikation oder Sicherheit (Authenthisierung und Autorisierung) auf [s. Herr/Brombach 2004]. Der Einsatz von WSDL und SOAP ist besonders für die zwischenbetriebliche Integration über einen Web Service Gateway geplant, der externen Partnern einen Zugriff mit reduziertem Leistungsumfang auf Services bietet. Ausserdem ist die Verwendung von UDDI für das momentan JNDI/LDAP-basierte Serviceverzeichnis geplant.

4.2.4

Bisherige Erfahrungen

Aufwand und Nutzen Das Teilprojekt zur Definition der Applikationsdomänen und der initialen Serviceidentifikation dauerte rund neun Monate. Davon wendete das Projektteam alleine für die Prozessanalyse ca. sechs Monate auf. Bei der Entwicklung eines wieder verwendbaren Services entstehen im Vergleich zur herkömmlichen Entwicklung Mehraufwände von einigen Tagen bis Wochen. Die initialen Implementierungskosten für den SBB sind mit den Kosten für eine gängige herstellerspezifische Komplettlösung wie der IBM WebSphere Plattform vergleichbar. Für Deutsche Post Brief ergeben sich aber aus dem Best-of-Breed Ansatz Vorteile: Neben der grösseren Herstellerunabhängigkeit und geringeren Betriebskosten (z.B. durch den Einsatz von Open-Source Produkten und die Einsparung von Lizenzkosten) profitiert das Unternehmen durch mehr internes Know-how und Kompetenz und eine bessere Abdeckung der eigenen Bedürfnisse.

4.2 Deutsche Post Brief

71

Tabelle 4-2 führt einige der bisher realisierten Nutzenpotenziale auf. Insgesamt rechnen die Projektverantwortlichen über fünf Jahre mit einem Nettobarwert in zweistelliger Millionenhöhe. Nutzen

Erläuterung

Wiederverwendung von Services und Vermeidung redundanter Softwareentwicklung

Die entwickelten Services werden durchschnittlich zwei bis drei mal wieder verwendet, wobei einzelne (z.B. der Service „Kundenmanagement“) von vielen, andere nur von einer Anwendung genutzt werden. Die mit der Wiederverwendung und gleichzeitigen Systemharmonisierung einhergehende Redundanzreduktion führte zu einer verbesserten Datenkonsistenz.

Kürzere Projektlaufzeiten und schnellere Time-tomarket

Bei Neuentwicklungen von Applikationen liessen sich durch Wiederverwendung bestehender Services sowie durch klar definierte Zuständigkeiten und Prozesse Projektlaufzeiten von einigen Monaten (inklusive Tests) auf Tage oder Wochen reduzieren. Allerdings kann bei der erstmaligen Implementierung eines wieder verwendbaren Services im Vergleich zur herkömmlichen Entwicklung ein Mehraufwand von einigen Tagen oder Wochen entstehen.

Niedrigere Wartungskosten

Mit der Domänenbildung und den besser kontrollierten Schnittstellen reduzieren sich Komplexität sowie Redundanzen in der Applikationsarchitektur. Dies führt zu niedrigeren Kosten für die Wartung und den Betrieb der IS-Architektur: Bei gleich bleibendem IT-Budget kann der Unternehmensbereich ca. 7% mehr für Neuentwicklungen ausgeben.

Dezentralisierung der Anwendungsentwicklung und bessere Reaktionsfähigkeit auf neue Geschäftsanforderungen

Die Domänen- und Servicearchitektur nimmt für Deutsche Post Brief eine Vermittlerrolle zwischen der Prozess- und Applikationsarchitektur ein: Sie beschreibt und strukturiert Daten und Funktionen der Applikationsarchitektur in der Begriffswelt des Business und erleichtert so die Kommunikation zwischen Fachbereichen und IT. Sie stellt gleichzeitig ein Gerüst für die Definition von Verantwortlichkeiten dar: Fachbereiche sind für Daten und Services einzelner Domänen verantwortlich und besitzen grössere Entwicklungskompetenzen. Der modulare Aufbau der Domänen, klare fachliche Verantwortlichkeiten, standardisierte Architekturrichtlinien und definierte Architekturprozesse erlauben kleinere, isoliertere IT-Projekte mit geringeren Risiken.

Tabelle 4-2: Mit SOA realisierte Nutzenpotenziale bei Deutsche Post Brief Herausforderungen und Erfolgsfaktoren Bisherige Erfahrungen zeigen, dass die zentralen Herausforderungen einer SOA nicht technischer Natur sind, sondern in der Abgrenzung und der Definition von Datenmodellen für Services liegen. Stabile und wieder verwendbare Services setzen voraus, dass die Anforderungen von (zur Entwicklungszeit) unbekannten Servicenutzern berücksichtigt und das Datenmodell bzw. die Servicesemantik so definiert wird, dass der Dienst in unterschiedlichen Geschäftsprozessen genutzt werden kann. Die Anforderungen zukünftiger Servicenutzer sind zum Entwick-

72

4 Fallbeispiele zu SOA

lungszeitpunkt i.d.R. aber nur beschränkt bekannt. Aufgrund dieser Unsicherheiten ist damit zu rechnen, dass Services für neue Projekte angepasst werden müssen, was Strukturen für ein kontrolliertes Versionsmanagement erfordert. Der Aufbau geeigneter organisatorischer Strukturen und Kompetenzen war eine weitere Herausforderung. Die Entwicklung fachbereichsübergreifend nutzbarer Services setzt eine intensive Kommunikation zwischen dem Bereich, der den Service entwickelt und besitzt, und den nutzenden Bereichen voraus. Einerseits muss das Interesse potenzieller Servicenutzer geweckt werden, andererseits ist darauf zu achten, dass die Anforderungen der nutzenden Fachbereiche die Entwicklungskosten für den implementierenden Bereich nicht zu stark erhöhen. Um dies zu erreichen, unterstützt die SOP-Group den Entwicklungsprozess und überwacht die Architekturkonformität des Projekts. Wichtige Erfolgsfaktoren aus Sicht der Architekturverantwortlichen von Deutsche Post Brief sind (s. [Herr/Bath 2004, 236f.], [Bath 2004, 22]): •

Eine geschäftsorientierte, aus fachlich-logischer Sicht startende Architekturentwicklung,

•

die Unterstützung und organisatorische Verankerung auf Top-Managementebene und

•

die Herstellerunabhängigkeit und Standardkonformität der Serviceinfrastruktur, um technologische Zukunftssicherheit und Flexibilität zu wahren.

Geplante Weiterentwicklung Aufgrund des Erfolgs der SOA plant Deutsche Post Brief, den Ansatz im Konzern und zu externen Geschäftspartnern hin weiter auszurollen. Im Rahmen der Bildung der SOP Group weitete Deutsche Post SOA bereits im Jahr 2004 auf den Unternehmensbereich Express/Logistik (DHL) aus. An der Schnittstelle zu externen Geschäftspartnern sollen in Zukunft vermehrt Web Services zum Einsatz kommen. Weiter ist eine bessere Unterstützung der prozessorientierten Serviceintegration vorgesehen. Der SBB besitzt momentan noch keine Workflow- bzw. BPMKomponente, welche das Herauslösen von serviceübergreifender Prozesslogik aus den nutzenden Applikationen und ein Performanzmanagement über End-zu-EndProzesse erlauben würde. Die Ablaufsteuerung und Koordination mehrerer Services in domänen- bzw. serviceübergreifenden Prozessen wird in den aufrufenden Applikationen (bzw. in Composite Services, die mehrere Services koordinieren und Nutzern über eine einzelne Schnittstelle zur Verfügung stellen), fest programmiert. Eine Erweiterung der Infrastruktur um eine BPM-Komponente ist für eine zukünftige Version von SBB geplant.

4.3 Credit Suisse

73

4.3

Credit Suisse

4.3.1

Unternehmen

Credit Suisse Group ist ein führendes, global tätiges FinanzdienstleistungsUnternehmen mit Hauptsitz in Zürich. Es bietet zum Zeitpunkt der Fallstudienerhebung Privatkunden sowie kleinen und mittelgrossen Firmen Finanzberatung, Bankprodukte sowie Vorsorge- und Versicherungslösungen der Winterthur an. Im Bereich Investment Banking unterstützt es globale Institutionen und Unternehmen, staatliche Körperschaften und Privatkunden als Finanzmarkt-Intermediär. Credit Suisse Group Gründung

1856

Firmensitz

Zürich, Schweiz

Branche

Finanzen und Versicherungen

Firmenstruktur

2005: Konzernstruktur mit den Geschäftseinheiten Credit Suisse, Credit Suisse First Boston sowie Winterthur

Geschäftsbereiche

Private Banking, Privatkunden in der Schweiz, Firmenkunden in der Schweiz, Globales Investment Banking, Winterthur: (Life & Pensions, Non-Life)

Reingewinn

5.85 Mrd. CHF (2005)

Mitarbeiter

63'000 (2005)

Homepage

http://www.credit-suisse.com

Tabelle 4-3: Kurzportrait Credit Suisse Group 4.3.2

Ausgangslage

Ende der 90er-Jahre besass die IS-Architektur von Credit Suisse eine Komplexität, die Anpassungen nur mit unverhältnismässig hohem Aufwand erlaubte [s. Hagen 2004, 68]: Alleine für das Schweizer Bankgeschäft befanden sich rund 600 in verschiedenen Technologien entwickelte Applikationen im Einsatz, die unterschiedliche Lebenszyklen aufwiesen, Funktionen und Daten redundant implementierten und viele unkontrollierte Abhängigkeiten bzw. spezialisierte Punkt-zuPunkt Schnittstellen untereinander aufwiesen. Mehrere Projekte scheiterten in dieser Zeit mit hohen Verlusten. So wurde bspw. ein Projekt zur Entwicklung eines neuen Buchungssystems nach rund zwei Jahren ergebnislos gestoppt. Wie bei anderen Grossunternehmen ist auch die IS-Architektur der Credit Suisse historisch gewachsen. Mit den in PL/I auf einem IBM Mainframe entwickelten terminalbasierten Systemen reichen die Wurzeln der heutigen Applikationslandschaft bis in die 70er-Jahre zurück. Daneben existieren u.a. in Smalltalk entwickelte Client/Server-Applikationen aus den späten 80er-Jahren und, mit der verstärkten Nutzung des Inter- und Intranets in den 90ern, Systeme mit Multitier-

74

4 Fallbeispiele zu SOA

Architekturen, z.B. auf Basis von Java. Wegen Zeit- und Kostendruck sowie fehlenden zentralen Designregeln und Reviewprozessen entstanden in der Vergangenheit viele Ad-hoc-Lösungen. Mit dem Aufkommen des E-Business zeichnete sich bei Credit Suisse eine umfangreichere Einführung intranet- und internetbasierter Applikationen ab. Die zentrale IS-Architektur unter der Verantwortung des CIO untersuchte verschiedene Optionen, um ein weiteres Komplexitätswachstum zu vermeiden, die ITSysteme wieder beherrschbarer zu machen und die notwendigen Modernisierungen durchführen zu können (s. Tabelle 4-4). Option

Diskussion

Kauf eines StandardSoftwarepakets

Da in der Schweiz nur eine weitere Bank mit ähnlichen Datenvolumen- bzw. Skalierbarkeitssanforderungen an eine Bankenplattform existierte, waren auf dem Markt keine passenden Angebote vorhanden. Internationalen Lösungen fehlte wesentliche Funktionalität.

Nutzung der Lösung einer anderen Bank

Wurde nur im Fall einer Fusion als realistisch angesehen und löste das Problem veralteter Technologien nicht, da die meisten Banken eine ähnliche Systemlandschaft besassen.

Komplette Neuentwicklung

Wurde aufgrund der Kosten (geschätzte 1 Mrd. CHF), der langen Entwicklungszeiten (5-7 Jahre) und wegen fehlenden Entwicklerkapazitäten verworfen.

Managed Evolution

Eine pragmatische, evolutionäre Anpassung und Erweiterung der Systemlandschaft (Anpassung bestehender Applikationen, Infrastrukturmodernisierung) mit strikten zentralen Steuerungsprozessen erlaubt die Nutzung der Stärken der bestehenden Systeme und des existierenden IT-Know-hows.

Tabelle 4-4: Architekturoptionen bei Credit Suisse [s. Koch/Murer 1999, 194] Credit Suisse entschied sich für einen Ansatz, den sie „Managed Evolution“ nennt. Dieser Ansatz sah vor, eine zentral gesteuerte Integrationsarchitektur nach den Prinzipien einer SOA schrittweise zu etablieren und Anpassungen bzw. Erweiterungen an bestehenden Applikationen einzelprojektgetrieben durchzuführen. Mit einer SOA sollten Strukturen geschaffen werden, die eine Entkopplung der verschiedenen Applikationen und fachlichen Applikationsgruppen und damit eine schnelle Anpassung und Erweiterung der Systemlandschaft erlauben und gleichzeitig die langfristige Kosteneffizienz sichern.

4.3.3

Umsetzung einer SOA

Ziele und Überblick Credit Suisse begann 1998 mit der Umsetzung der SOA. Die zentrale IT führte drei Teilprojekte durch: •

Die Entwicklung zentraler Architekturrichtlinien und Organisationsstrukturen definierte grundlegende Architekturziele sowie Standards, Methoden und

4.3 Credit Suisse

75

Prozesse für das Design, die Verwaltung und die Qualitätssicherung von Services. •

Mit der Definition von Applikationsdomänen wurden Applikationen nach fachlichen Gesichtspunkten gruppiert. Die Domänenarchitektur bildet das wichtigste Hilfsmittel für Kopplungsentscheidungen zwischen Applikationen und die Frage, in welchen Fällen über Services integriert werden soll und wann nicht.

•

Die Entwicklung einer zentralen Integrationsinfrastruktur schaffte die technische Basis für die domänenübergreifende, servicebasierte Applikationsintegration. Übereinstimmend mit der „Managed-Evolution-Strategie“ fand keine architekturweite Planung der Service-Landschaft statt. Services wurden projektgetrieben und je nach Geschäftsanforderungen identifiziert und dann gebaut, wenn eine ClientApplikation eine bestimmte Funktion benötigte. Das Unternehmen verfolgte mit der Umsetzung der SOA folgende Architekturziele [s. Hagen 2004, 73]: •

Eine Reduktion der Komplexität von Beziehungen zwischen Applikationen, die sich in Kostensenkungen bei Integrationsprojekten manifestiert,

•

eine geeignete Kopplung zwischen Applikationen und Applikationsteilen, die weder zu vielen Abhängigkeiten noch zu Performanzproblemen bei der Interaktion zur Laufzeit führt,

•

grösstmögliche Wiederverwendung und geringe Redundanz von Funktionen und Daten und

•

ein passendes Technologieportfolio, das so wenig Middleware-Produkte wie möglich umfasst, aber gleichzeitig alle Projektanforderungen unterstützt.

Entwicklung zentraler Architekturrichtlinien und Organisationsstrukturen Der evolutionäre, projektgetriebene Ansatz zur Entwicklung der Servicearchitektur birgt die Gefahr eines Service- und Technologiewildwuchses sowie von Redundanzen und Qualitätsmängeln in den entwickelten Lösungen. Um dies zu vermeiden, baute die zentrale IT Organisationsbereiche für die Entwicklung und den Betrieb der Integrationsinfrastruktur sowie für die Unterstützung und Qualitätssicherung von Fachprojekten auf. Sie legte ausserdem einen formalisierten, strikt durchgesetzten Projektmanagementprozess für fachliche Entwicklungsprojekte mit Qualitätschecks in verschiedenen Projektphasen fest. Daneben definierte sie verschiedene technische und fachliche Vorgaben für das Servicedesign. Sie umfassen z.B. Vorgaben, in welchen Fällen Services zu entwickeln bzw. zu integrieren sind, wann die zentrale Integrationsinfrastruktur zu benutzen ist, zu verwendende Notationen und Kataloge für die Servicebeschreibung, Standards für BasisDatentypen und eine Reihe weiterer Prinzipien für das fachliche Servicedesign (s. Tabelle 4-5).

76

4 Fallbeispiele zu SOA Prinzip

Erläuterung

Implementierungsunabhängige Beschreibung

Serviceschnittstellen sollten während der Designphase technologie- und implementierungsunabhängig beschrieben werden. Dazu sind z.B. nur serviceintern verwendete, für einen Servicenutzer irrelevante Daten zu verbergen und standardisierte anstatt technologiespezifische Datentypen zu verwenden.

Beschreibung aus Geschäftsperspektive

Schnittstellen sind in fachlicher Terminologie zu beschreiben (z.B. nicht „Operation X liest Tabelle Y in Datenbank Z“).

Einhaltung von Namenskonventionen

Operations-, Informationsobjekt- und Parameternamen sollten bestimmte Namenskonventionen befolgen: Sie sind möglichst konkret zu benennen (z.B. „creditor“ anstatt „customer“, „purchaseDate“ anstatt „date“), Repetitionen in hierarchischen Datenstrukturen sind zu vermeiden und die Namen von boolschen Variablen sind so zu wählen, dass die Semantik von „wahr“ und „falsch“ eindeutig ist (z.B. „hasAccount“ anstatt nur „Account“).

Servicegeneralisierung

Services sollten so generalisiert werden, dass sie für einen möglichst breiten Nutzerkreis wieder verwendbar sind. Dazu sollte ein Service z.B. mehr Attribute liefern, als dies die spezifische Applikation verlangt, für die er initial entwickelt wird.

Servicegranularität

Um Netzwerkaufrufe zu minimieren und eine statusbehaftete Interaktion zwischen Service und Nutzer zu vermeiden, sollten Services in der Regel grob granular sein, d.h. viel Funktionalität kapseln und möglichst alle benötigten Daten auf einmal liefern. Dabei sind je nach verwendetem Integrationsbus Beschränkungen bez. des ausgetauschten Datenvolumens zu beachten.

Redundanzfreie Input/ Output-Datenstrukturen

Abgesehen von Identifikationsschlüsseln sollte eine Wiederholung von Inputparametern in Output-Nachrichten vermieden werden.

Tabelle 4-5: Beispiele für Servicedesignprinzipien bei Credit Suisse Gegenwärtig definiert die Architektur 20 Prinzipien für das Servicedesign, spezifische Prinzipien für Events und Fileschnittstellen befinden sich in Entwicklung. Diese Richtlinien werden aus den Erfahrungen in den Fachprojekten und dem laufenden Betrieb kontinuierlich erweitert. So zeigte sich z.B. mit steigendem Servicewachstum, dass Fachprojekte aufgrund einer unzureichenden Kategorisierung zunehmend Schwierigkeiten haben, geeignete bestehende Services zu identifizieren. Als Konsequenz werden gegenwärtig pro Applikationsdomäne die wichtigsten Informationsobjekte identifiziert, die zukünftig eine bessere fachliche Einordnung von Services erlauben sollen. Die Definition einheitlicher Fehlercodes auf Serviceebene für eine einfachere Servicenutzung stellt einen weiteren aktuellen Ausbau dar. Zur laufenden Überwachung und Steuerung der SOA entwickelte die zentrale IT ausserdem eine Architektur-Scorecard, welche die Zielerreichung der SOA anhand von Architekturmetriken misst.

4.3 Credit Suisse

77

Abgrenzung von Applikationsdomänen Mit der Entwicklung einer Domänenarchitektur wollte die Credit Suisse die vielen hundert Applikationen verwaltbar machen und besser strukturieren. Eine Domäne fasst alle Applikationen und Daten zusammen, die zu einem bestimmten fachlichen Bereich gehören. Domänen bilden wichtige Anhaltspunkte für Kopplungsgrade in Integrationsprojekten: Während innerhalb von Domänen enge Kopplungsbeziehungen zwischen Applikationen und Applikationsbestandteilen zulässig sind (z.B. durch Verwendung einer gemeinsamen Datenbank), wird zwischen Domänen eine konsequente Kapselung über wohldefinierte und stabile Services, die alle Details ihrer Implementierung verbergen, umgesetzt. Eine lose Kopplung über Services erlaubt unabhängige Lebens- bzw. Entwicklungszyklen zwischen Domänen und stellt für Credit Suisse einen Haupterfolgsfaktor für die Wiederverwendung und längerfristige Wartbarkeit der Applikationslandschaft dar. Die Applikationsarchitektur unterscheidet heute rund 20 Domänen (s. Abb. 4-4). Ihre Strukturierung orientiert sich primär an Produkten und Kern-Bankenfunktionen (Payments, Credits, etc.), produktübergreifenden Funktionen und Daten (Customers, Financial Instruments, Basic Facilities), Supportfunktionen (Logistics, Accounting) sowie externen Kommunikationskanälen (Channels, Streetside Interfaces, Business Partner Interfaces).

Customers

Channels

External Systems

Streetside Interfaces

Business Partners

Exchanges

Business Partner Interfaces

Payments

Client Trading

Proprietary Trading

Credits

Securities Operations

Treasury Operations

Accounting Operations Control

Investment Management

Single Accounts

Documentation

Accounting

Data Warehouse / Internal Accounting

Financial Instruments

Customers, EAM, Front

Logistics

Basic Facilities Banking

Complementary Functions

External Relationships

Fundamentals

Abb. 4-4: Domänenarchitektur der Credit Suisse (Quelle: Credit Suisse) Die Domänenstruktur stellte ursprünglich eine rein konzeptionelle Zielarchitektur für Neuentwicklungen dar. Aus Kosten- und Zeitgründen wurden Schnittstellen zwischen bestehenden Applikationen nicht nachträglich als Services umgesetzt bzw. nur dann, wenn sie im Rahmen einer Plattform- bzw. Technologieablösung sowieso neu implementiert werden mussten. Funktionen und Daten bestehender Applikationen wurden ohne neue fachliche Anforderungen im Rahmen der Do-

78

4 Fallbeispiele zu SOA

mänenbildung auch nicht getrennt oder zusammengeführt. So wurden z.B. die auf dem Mainframe implementierten Applikationen bisher nicht entflochten, obwohl sie Funktionen und Daten, die fachlich in unterschiedliche Domänen gehören, eng koppeln. Eine Ausnahme bildet die Domäne „Data Warehouse“, die definiert wurde, um die Data Warehouse-Systeme der Credit Suisse zu konsolidieren. Sie wird nach Abschluss der Konsolidierung wieder in eine andere Domäne überführt. Die Domänenarchitektur ist nicht nur ein Entscheidungshilfsmittel dafür, wann serviceorientiert zu integrieren ist, sondern stellt für Credit Suisse auch ein wichtiges organisatorisches Konzept dar: Jede Domäne mit ihren Services besitzt einen verantwortlichen Architekten, die Architektur-Assessments werden pro Domäne durchgeführt und auch das IT-Budget wird auf Applikationsdomänen aufgeteilt. Entwicklung der technischen Infrastruktur Die zentrale Integrationsinfrastruktur standardisiert die zulässigen Integrationsmechanismen und -technologien zwischen Applikationen unterschiedlicher Domänen und stellt die technische Basis für die Implementierung und Nutzung von Services dar. Credit Suisse hat die Integrationsinfrastruktur phasenweise eingeführt und ausgebaut, angefangen von einem Integrationsbus für synchrone Serviceaufrufe (Credit Suissse Information Bus, CSIB) über die Entwicklung eines asynchronen Event-Busses (Credit Suissse Event Bus, CSEB) bis zur Ergänzung um einen Filetransfer-Bus für grosse Datenmengen (Bulk Transfer Infrastructure, BTI). Parallel zur Entwicklung der Middlewareinfrastruktur standardisierte die zentrale IT auch Applikations- und Entwicklungsplattformen. Sie verfolgte damit u.a. das Ziel, die Middlewaredienste, die Werkzeugunterstützung und den fachlichen Support für die Nutzung der Integrationsinfrastruktur auf eine beschränkte Anzahl Technologien zu konzentrieren. Unterstützt sind heute eine Host-, eine Java- und eine Microsoft-Plattform sowie je eine Plattform für ERP- und Data WarehouseSysteme. Abb. 4-5 gibt einen Überblick über die umgesetzte Integrationsinfrastruktur. Während der CSIB hauptsächlich als Plattformüberbrückungstechnologie für die domänenübergreifende Integration zwischen Backend- und Frontendsystemen (z.B. zwischen einer mainframebasierten Depotverwaltung und einer in Java implementierten Online-Banking Applikation) zum Einsatz kommt, dienen der CSEB und die BTI eher der Integration zwischen Backendsystemen, die auf unterschiedlichen Plattformen laufen. Die Bus-Integrationsinfrastruktur wird durch eine Workflow-Infrastruktur ergänzt, welche die prozessorientierte Applikationsintegration erlaubt.

FrontendApplikationen

4.3 Credit Suisse

79

Microsoft

Nicht-SAP

Java

Nicht-SAP

…

Nicht-SAP

BackendApplikationen

CSIB (CORBA-basiert)

Host

Nicht-SAP

ERP

Nicht-SAP

DWH

Nicht-SAP

CSEB (messagebasiert) BTI (Filetransfer) Integrationsbus

Serviceschnittstelle

Applikationsplattform

Applikation

Abb. 4-5: Credit Suisse Integrationsinfrastruktur Credit Suisse Information Bus (CSIB) Von Anfang 1998 bis 1999 entwickelte die zentrale IT der Credit Suisse einen CORBA-basierten Service-Integrationsbus, den CSIB. Der CSIB basiert im Kern auf Orbix von Iona Technologies und unterstützt synchrone Serviceaufrufe. Dieser Entwicklung ging eine Analyse voraus, die folgende Anforderungen ergab [s. Koch/Murer 1999]: •

Schnittstellendefinitionen müssen von Programmiersprachen und Plattformen unabhängig sein.

•

Die Lösung sollte auf dem Markt verfügbar sein und auf einem verbreiteten Industriestandard basieren, den Produkte unterschiedlicher Anbieter unterstützten.

•

Die Lösung muss mehrere Programmiersprachen (PL/I, Java, Smalltalk etc.) unterstützen und alle relevanten Plattformen (u.a. OS/390, UNIX, NT) integrieren können.

•

Sie muss einen Directory Service zur dynamischen Adressierung von Serviceaufrufen bieten, die Definition und Verteilung von Metadaten (z.B. Schnittstellendefinitionen) unterstützen und Systemmanagement-Dienste enthalten. Wichtige Gründe für den Entscheid einer Umsetzung mit CORBA waren u.a. die Plattform- und Programmiersprachenunabhängigkeit der Technologie und dass sich ein Hersteller finden liess, der eine CORBA-Implementierung für PL/I auf IBM-Mainframes erstellte.

80

4 Fallbeispiele zu SOA

Credit Suisse Event Bus (CSEB) Der CSIB stellte bald eine leistungsfähige und breit genutzte Infrastruktur dar. Bereits 1999 enthielt er rund 35 Services, die von fünf Frontend-Applikationen integriert wurden. Ende 2000 nutzten 21 Applikationen rund 170 Services. Bereits damals zeichnete sich jedoch ab, dass synchrone Funktionsaufrufe, wie sie der CSIB bot, nicht für alle Integrationsanforderungen ausreichten. Insbesondere bei der Integration zugekaufter Standardsoftware zeigten sich Grenzen. Diese Produkte setzten teilweise die Haltung eigener Daten voraus und besassen eigene interne Datenmodelle, was zu Datenredundanzen und dem Bedarf nach häufigen Datensynchronisationen und Datentransformationen führte. Der CSIB eignete sich schlecht für den Austausch so grosser Datenmengen. Er bot weder Unterstützung für lose Kopplungsmechanismen wie die asynchrone nachrichtenbasierte Kommunikation noch Dienste für die garantierte einmalige Zustellung von Nachrichten, regelbasiertes Routing oder Nachrichtentransformationen. Credit Suisse implementierte deshalb bis 2002 für einen eventbasierten, asynchronen Nachrichtenaustausch den CSEB. Events werden z.B. zu festgelegten Zeiten oder bei definierten Statusänderungen aufgrund eines Geschäftsereignisses (z.B. Registrierung eines neuen Kunden) ausgelöst. Die Kommunikation kann entweder zwischen zwei Parteien (Peer-to-Peer) oder nach dem Publish / Subscribe-Muster (mehrere Nutzer „abonnieren“ einen Service) stattfinden und reduziert im Vergleich zum Request / Reply-Kommunikationsmuster den Netzverkehr, da die Aufrufe durch Servicenutzer entfallen. Der CSEB basiert auf der IBM WebSphere-Produktfamilie mit WebSphere MQ als nachrichtenbasierte Middleware und dem WebSphere Business Integration Message Broker für regelbasiertes Routing und Nachrichtentransformationen. Die zentrale IT legte beim Aufbau des CSEB grossen Wert darauf, bezüglich der Methoden und Prozesse zur Serviceentwicklung nahe am bestehenden CSIB zu bleiben. So gelten z.B. für das Design von Events, wo sinnvoll, die gleichen Grundsätze wie für asynchrone CORBA-Services. Auch die Projektmanagement- und Qualitätssicherungsprozesse sind für beide Servicearten dieselben. Ausserdem verwenden beide Infrastrukturen ein gemeinsames, auf einer SQL-Datenbank basierendes zentrales Service-Repository. Bulk Transfer Infrastructure (BTI) Gegenwärtig befindet sich als dritter Integrationsbus die BTI im Aufbau. Sie soll den im Bankgeschäft intern und zwischenbetrieblich verbreiteten filebasierten Massendatentransfer im Batch-Modus unterstützen. Da die technische Infrastruktur dafür bereits vorhanden ist, konzentrieren sich die Anstrengungen momentan auf die Umsetzung des Konzepts der „gemanagten Schnittstelle“ und der dazugehörigen Prozesse für diesen Schnittstellentyp. Ausserdem werden das zentrale Servicerepository erweitert sowie ursprünglich projektspezifisch und bilateral vereinbarte Dateistrukturen vereinheitlicht. Identifikation und Implementierung von Services Da Credit Suisse 1999 verschiedene Intra- und Internet-Systeme entwickelte, konzentrierte sich die Serviceimplementierung in der Anfangsphase auf die Schnittstellen zwischen diesen Applikationen und den bestehenden Kernsystemen.

4.3 Credit Suisse

81

Bei der Serviceidentifikation und -entwicklung verfolgt Credit Suisse einen „bottom-up“-Ansatz: Services werden nicht zentral architekturweit geplant, sondern dann identifiziert, wenn ein Fachprojekt eine bestimmte Funktion benötigt. Um die organisatorisch verteilten Entwicklungsprojekte zu koordinieren und die Architekturkonformität der entstehenden Lösungen sicherzustellen, definierte die zentrale IT einen standardisierten Projektmanagement- und Reviewprozess mit drei Qualitätschecks. In diesen prüft sie, ob Projekte Services implementieren bzw. wieder verwenden müssen, ob die entwickelten Services die vorgeschriebenen Designprinzipien umsetzen und ob sie technisch korrekt spezifiziert sind. Dabei werden unabhängig vom verwendeten Bussystem bzw. Kommunikationsmechanismus die gleichen grundlegenden Prozesse, Methoden und Richtlinien angewendet. Im Laufe des Entwicklungsprozesses erstellen die Projektmitarbeiter schrittweise eine Servicespezifikation, die jeweils als Input für die einzelnen Qualitätschecks dient und im Anschluss an die Programmierung im zentralen Repository erfasst wird. Eine vollständige Servicespezifikation enthält folgende Elemente: •

Eine formale, maschinenlesbare Schnittstellenspezifikation mit Operationen und Input- / Outputparametern (in IDL oder XML),

•

eine knappe natürlichsprachliche Beschreibung der Servicefunktion, Operationen, Parameter und Effekte auf Daten,

•

Ausnahmen und Vor- / Nachbedingungen (natürlichsprachlich, da eine formale Beschreibung in OCL zu kompliziert ist),

•

angestrebte Servicelevels (Antwortzeitverhalten, Durchsatz, Reaktionszeiten im Fehlerfall),

•

Planungsangaben (Status, Daten für durchgeführte oder geplante Tests, Datum der Produktivsetzung),

•

Kontaktinformationen (Serviceentwickler, -betreiber und -nutzer),

•

Implementierungsinformationen (Plattformen, Applikationen, Datenbanken).

4.3.4

Bisherige Erfahrungen

Aufwand und Nutzen Credit Suisse benötigte für die Entwicklung der einzelnen Integrationsbusse jeweils 1.5 bis 2 Jahre mit geschätzten Kosten von 1 bis 2 Mio. CHF. In der zentralen IT sind heute 5 Personen im Bereich Integrationsarchitektur beschäftigt, 2 bis 3 Personen betreiben die Integrationsinfrastruktur und 5 Personen unterstützen Fachprojekte bei der Serviceentwicklung und der Nutzung der Integrationsinfrastruktur. Aufwände für Fachprojekte entstehen durch die Entwicklung wieder verwendbarer Services und die zentralen Reviewprozesse. In der Regel verlängern sich Projekte, die neue Services umsetzen oder bestehende erweitern, um einige Personentage. Die Fachbereiche müssen die anfallenden Kosten in den Projektbudgets einkalkulieren. Die zentrale IT geht allerdings davon aus, dass heute 80% bis 90% der von neuen Applikationen benötigten Services verfügbar sind.

82

4 Fallbeispiele zu SOA

Nutzen der SOA entsteht zum einen aus der Wiederverwendung von Services. Gegenwärtig werden die auf dem CSIB implementierten Services durchschnittlich 1.7-mal wieder verwendet, wobei einzelne Services (z.B. für das Lesen von Kundendaten) über 90 Nutzer aufweisen. Allerdings basiert diese Zahl auf einer freiwilligen Registrierung der Servicenutzer (die zentrale IT rechnet damit, dass effektiv rund 30% mehr Nutzer existieren) und bezieht sich auf die Wiederverwendung einzelner Operationen. Der Wiederverwendungsfaktor auf Ebene CORBA-Interface (umfasst im Schnitt rund 3 Operationen) beträgt 4.5. Credit Suisse rechnet damit, bis heute durch Wiederverwendung Entwicklungskosten von rund 30 Mio. CHF eingespart zu haben. Weiter entstanden Einsparungen im IT-Betrieb durch die Harmonisierung und Standardisierung von Integrations- und Entwicklungsplattformen sowie durch eine bessere Entkopplung der fachlichen Applikationsdomänen. Insgesamt sind die ITAufwände in den letzten 5 Jahren um rund 30% gesunken. Gleichzeitig ist die Produktivität, gemessen an der Implementierung neuer IT-Funktionen, gestiegen. Der Beitrag der SOA bzw. Integrationsarchitektur an dieser Kostenreduktion und Produktivitätserhöhung lässt sich nicht direkt bestimmen, dürfte aber signifikant sein. Daneben sieht die Credit Suisse verschiedene qualitative, schlecht quantifizierbare Vorteile. Dazu zählen etwa die verbesserte Kommunikation zwischen zentraler IT und Fachbereichen oder die höhere Flexibilität und kürzere Time-to-Market für neue Lösungen. Letztere wird für IT-Projekte seit einem Jahr erhoben, Nutzeneffekt der SOA lassen sich bisher nicht genau beziffern. Die zentrale IT geht jedoch von Verkürzungen der Projektlaufzeiten von bis zu einigen Wochen oder Monaten aus. Dies ist u.a. darauf zurückzuführen, dass sich bei einer Wiederverwendung existierender Services Projektverzögerungen durch personelle Ressourcenengpässe vermeiden lassen. Herausforderungen und Erfolgsfaktoren Die Herausforderungen bei der Umsetzung der SOA waren hauptsächlich technischer und organisatorischer Natur. Die Servicearchitektur nahm in kurzer Zeit eine so wichtige Rolle in Entwicklungsprojekten ein, dass es zu Performanzproblemen kam, die sich sofort negativ auf die Akzeptanz bei den Fachprojekten auswirkte. Neben solchen technisch bedingten Akzeptanzproblemen hatten die Architekten zu Beginn auch Mühe, die Fachbereiche vom Nutzen und der Notwendigkeit der neuen Architekturrichtlinien und Entwicklungsprozesse zu überzeugen. Die starke Unterstützung durch das Top-Management war wesentlich für ihre Durchsetzung. Eine weitere Herausforderung stellte die Auswahl der Architekturrichtlinien und -standards dar. Die im Laufe der Serviceentwicklung und -nutzung gesammelten Erfahrungen zeigten, dass zu Beginn z.B. die Standardisierung von Fehlercodes oder fachlichen Datenmodellen auf Serviceebene vernachlässigt wurde. Entsprechende Standards werden gegenwärtig entwickelt und nachträglich eingeführt. Wichtige Erfolgsfaktoren für die Umsetzung einer SOA sind für Credit Suisse: •

Die Konzentration auf die Definition sauberer, fachlich definierter und qualitätsgeprüfter Schnittstellen,

4.3 Credit Suisse

83

•

eine strikt durchgesetzte Projektkontrolle,

•

die Entscheidungsautorität der zentralen IT bei der Serviceentwicklung,

•

starke Unterstützung durch das Top-Management,

•

die personelle und werkzeugtechnisch in Entwicklungsplattformen integrierte Unterstützung der Fachprojekte (z.B. durch Codegeneratoren für die Serviceentwicklung),

•

eine solide technische Integrationsinfrastruktur und ihre laufende Weiterentwicklung sowie

•

ein kontinuierliches Architekturcontrolling über Metriken und Scorecards, um Entwicklungsbedarf zu erkennen und ggf. steuernd einzugreifen.

Geplante Weiterentwicklung Credit Suisse besitzt mit den zentralen Architekturrichtlinien und Organisationsstrukturen, der implementierten Integrationsinfrastruktur und den entwickelten Services eine leistungsfähige SOA. Momentan besteht jedoch noch Entwicklungsbedarf bei der nachträglichen Entkopplung der Applikationsarchitektur. Wegen des pragmatischen, projektgetriebenen Vorgehens bei der Serviceentwicklung existieren auch heute noch Redundanzen und unkontrollierte enge Kopplungsbeziehungen zwischen älteren Applikationen unterschiedlicher Domänen. besonders die Applikationen auf der Host-Plattform sind teilweise noch eng miteinander verflochten. Um in Zukunft einzelne Elemente der Applikationslandschaft möglichst unabhängig entwickeln und mit geringem Aufwand austauschen zu können, will Credit Suisse Applikationsdomänen und Applikationen nachträglich stärker in Komponenten zerlegen und konsequent kapseln sowie alle Schnittstellen und Abhängigkeiten von anderen Komponenten und das nach aussen sichtbare Verhalten genau spezifizieren. Herausforderungen entstehen dabei durch ein jahrzehntelang unkontrolliertes Wachstum der Applikationslandschaft und dabei teilweise verlorenes Wissen über die Semantik von Applikationen und ihrer Querbeziehungen. Daneben werden Architekturrichtlinien und Servicedesignprinzipien sowie die Integrationsarchitektur laufend weiterentwickelt und neuen technischen Möglichkeiten angepasst. CORBA ist als Technologie immer weniger verbreitet. Dadurch steigen für Anwender die Kosten für den Betrieb und das Risiko einer Verdrängung der Hersteller vom Markt. Credit Suisse führt deshalb laufend Potenzialanalysen für einen Technologiewechsel auf Web Services durch. Gegenwärtig können Web Services aber noch nicht alle Anforderungen an die Integrationsinfrastruktur erfüllen. Lücken bestehen z.B. in der Performanz und Skalierbarkeit von Web Service Lösungen sowie bezüglich Sicherheitsanforderungen. So fehlen z.B. geeignete Mechanismen für die Adressauflösung und das dynamische Routing von Serviceaufrufen, und Mechanismen für das Durchreichen der Identität eines Servicenutzers in die Backendsysteme sind noch nicht ausreichend standardisiert bzw. in den Produkten der Softwarehersteller implementiert.

84

4.4

4 Fallbeispiele zu SOA

T-Com

4.4.1

Unternehmen

T-Com ist eine Geschäftseinheit des Deutsche Telekom Konzerns. Mit der neuen Konzernstruktur seit dem 1. Januar 2005 wurde T-Com gemeinsam mit T-Online im strategischen Geschäftsfeld Breitband / Festnetz (BBFN) zusammengefasst. Dieses konzentriert sich auf die Betreuung der Privatkunden und der kleinen Geschäftskunden des Telekom Konzerns sowie auf das Wholesale-Geschäft, d.h. den Vertrieb von Produkten an Wiederverkäufer und Carrier, in Deutschland. T-Com ist ausserdem über Beteiligungen in Central Eastern Europe (CEE) aktiv und ist mit rund 41,2 Millionen Schmalbandanschlüssen und 7,9 Millionen Breitbandanschlüssen einer der grössten Festnetzanbieter Europas. Das Unternehmen ist in CEE nicht nur mit dem Festnetz, sondern auch mit ISP (Internet Service Provider) und Geschäftskunden vertreten. Festnetz-Basisinfrastrukturdienste bietet T-Com in Deutschland neben Privatkunden auch weiteren Bereichen des Deutsche Telekom Konzerns und anderen Telekommunikationsunternehmen an. T-Com AG Gründung

1999 (Gründung als eine von vier strategischen Geschäftseinheiten von Deutsche Telekom AG)

Firmensitz

Bonn, Deutschland

Branche

Telekommunikation

Firmenstruktur

Geschäftseinheit im Deutsche Telekom Konzern. Flächenorganisation (8 Regionen) in Deutschland, Beteiligungen in Central Eastern Europe (CEE).

Geschäftsbereiche

Breitband / Festnetz

Umsatz

24,7 Mia. EUR (2005)

Mitarbeiter

109'643 (2005)

Homepage

http://www.t-com.de

Tabelle 4-6: Kurzportrait T-Com 4.4.2

Ausgangslage

Einer der wichtigsten Trends im Telekommunikationsmarkt ist die Breitbandkommunikation in hochleistungsfähigen Netzen. Sie wird in den kommenden Jahren Anwendungen der Telekommunikation, Informationstechnik, Unterhaltungselektronik und Haustechnik zusammenführen. Im Massenmarkt werden kombinierte Sprach-, Internet- und TV-Angebote („Triple Play“) zukünftig ein wichtiges Wachstumsfeld darstellen. Ursprünglich war T-Com innerhalb des DTAG Konzerns für den Betrieb der Festnetzinfrastruktur sowie für die Fertigung und den Vertrieb von Produkten der fest-

4.4 T-Com

85

netzbasierten Sprach- und Datenkommunikation zuständig. In den letzten Jahren stand das Unternehmen zunehmend vor der Herausforderung, seine bisher vertikal integrierten Wertschöpfungsaktivitäten aufzubrechen. Je nach Geschäftsbereich und Kundensegment muss sich das Unternehmen heute mit unterschiedlichen Angeboten als Zulieferer von Teilleistungen an Vertriebspartner oder als Leistungsintegrator mit direktem Kundenkontakt positionieren. Abhängig vom Vertriebspartner und Produkttyp (Standardprodukte, komplexere Individualprodukte) muss es unterschiedliche Kooperationsprozesse unterstützen und Partnern dabei Zugriff auf bisher rein unternehmensintern verwendete Daten und Funktionen bieten. Wie bei vielen Unternehmen ist die IT-Architektur von T-Com historisch gewachsen und spiegelt die vollzogenen organisatorischen und technischen Entwicklungen wider. Ausgangspunkt bildete ein hostbasiertes Anwendungssystem für die Marktprodukte des traditionellen Kerngeschäfts (Netzzugangsleistungen, z.B. Telefon- und ISDN-Anschlüsse), das den kompletten Auftragserfassungs- und Produktionsprozess unterstützte und vertriebliche, vertragliche und technische Logik und Daten umfasste. Im Laufe der Jahre führten verschiedene Architekturtreiber zu Erweiterungen und wachsender Komplexität in der IT-Architektur (s. Tabelle 4-7). So entstanden etwa für den Vertrieb von Produkten an unterschiedliche Kundensegmente (Geschäftskunden, Massenmarkt, Reseller, andere Konzerneinheiten) und über unterschiedliche Kanäle (Call Center, Internet, T-Punkte) mehrere Vertriebssysteme, die Auftragsprüf- und Abwicklungslogik duplizierten und über fachlich und technisch verschiedene Schnittstellen auf die Produktionssysteme zugriffen. Architekturtreiber

Herausforderungen

Ausbau des Produktangebots, z.B. DSLProdukte

Monolithische Struktur des ursprünglichen Systems führt zu zusätzlichen Vertriebssystemen mit eigener Auftragsabwicklungs- und Produktionslogik und Schnittstellen für gemeinsame Produktkomponenten (z.B. Anschlussleitung).

Neue fachliche bzw. organisatorische Ziele

Neuausrichtungen der Architekturziele führen zu zunehmendem Integrationsbedarf und funktionalen Redundanzen: Vom effizienten Betrieb der Festnetzinfrastruktur über eine integrierte Produktion des erweiterten Marktangebots (möglichst durchgängige Beschaffung und Fertigung einzelner Produktgruppen) hin zur Ausrichtung an Kundensegmenten und Vertriebskanälen (bessere Zusammenarbeit mit Vertriebspartnern, umfassende Sicht auf Kundenbeziehungen etc.).

Neue Entwicklungsprinzipien und ITProdukte

Mit der Einführung neuer Technologien und Produkte wächst die technische Heterogenität in der IT-Architektur.

Tabelle 4-7: Beispiele für Architekturtreiber und Herausforderungen in der ITArchitektur Redundanzen, unkontrollierte Integrationsbeziehungen oder eine grosse technische Heterogenität erhöhen den Aufwand für den IT-Betrieb und können die unternehmerische Agilität reduzieren: Der Aufwand für die Anpassung von Prozes-

86

4 Fallbeispiele zu SOA

sen und die Time-to-Market für die Einführung neuer Produkte steigen und eine selektive Auslagerung von Aktivitäten an Vertriebspartner (z.B. die Geschäftskundenbetreuung durch eine andere Konzerneinheit) oder der automatisierte Zugriff von Geschäftspartnern auf Informationen zur Verbesserung des Kooperationsprozesses (z.B. Informationen über Produktverfügbarkeiten, Auftragsstatus, Netzzustände) werden erschwert. T-Com ist diesen Herausforderungen begegnet und hat bereits in der Vergangenheit Anstrengungen unternommen, verschiedenen Produkten und Prozessen gemeinsame vertriebliche, technische oder vertragliche Fachfunktionen aus den monolithischen Anwendungssystemen herauszulösen sowie Schnittstellen über eine EAI-Infrastruktur zu konsolidieren. Gewisse Herausforderungen blieben aber trotzdem bestehen: •

Wie die restliche Systemlandschaft ist auch die EAI-Infrastruktur über die Jahre gewachsen und basiert auf unterschiedlichen technischen Plattformen und Produkten mehrerer Hersteller (Sybase, Borland, IBM).

•

Die projektgetriebene Entwicklung von Application Server Diensten hatte zur Folge, dass sich Schnittstellen oft an den Anforderungen einzelner Integrationsprojekte orientierten. Es entstanden spezialisierte, feingranulare Dienste ohne gemeinsames fachliches Objekt- bzw. Datenmodell, die für eine Wiederverwendung in einem anderen Kontext nicht geeignet sind oder zu vielen Interaktionsschritten zwischen Serviceanbietern und -nutzern führten. Bspw. kam es zu Performance-Problemen, weil Schnittstellen des Kunden-Stammdatensystems zu feingranular definiert wurden und deshalb viele Funktionsaufrufe durch andere Applikationen verursachten. Durch die mittlerweile grosse Anzahl an Diensten auf den Application Servern sind die Systeme schwer zu warten und zu betreiben.

•

Momentan ist erst ein Teil der gemeinsamen Fachfunktionen aus den Altsystemen herausgelöst. Viel Fachlogik ist nach wie vor redundant in monolithischen Systemen vorhanden.

4.4.3

Umsetzung einer SOA

Ziele und Überblick Aufgrund der geschilderten Markt- und Geschäftstreiber sowie der aktuellen ITRestriktionen will T-Com eine serviceorientierte Architektur im FulfillmentBereich realisieren. Dieser umfasst die Prozesse und Applikationen für Vertriebsund Produktionsaktivitäten in der Auftragserstellung und Auftragsabwicklung. Damit verfolgt das Unternehmen primär drei Ziele: •

Qualitätserhöhung und technische Standardisierung von Schnittstellen. Die technische Integrationsinfrastruktur soll zukünftig vereinheitlicht und ein zentraler Enterprise Service Bus (ESB) umgesetzt werden. Die als Services auf dem ESB implementierten Schnittstellen sollen messbar (bez. ihrer Nutzung, Verfügbarkeit etc.) sowie besser managebar und skalierbar sein als die bisherigen Application Server Dienste.

4.4 T-Com

•

87

Entflechtung der fachlichen Funktionalität für eine flexiblere Prozessgestaltung. Eine bessere Modularisierung bisher eng verflochtener Fachlogik in abgegrenzte Anwendungsdomänen und ihre Kapselung hinter stabilen Serviceschnittstellen soll zukünftig die Auswirkungen neuer geschäftlicher Anforderungen (z.B. Umsetzung eines neuen Vertriebskanals oder Einführung eines neuen Produktbündels) stärker auf einen überschaubaren Bereich der ITArchitektur begrenzen. Neue Produkte und Prozesse sollen auf Basis stabiler Serviceschnittstellen schneller eingeführt und bestehende Altsysteme einfacher abgelöst werden können.

•

Kostenreduktion im Betrieb und in der Weiterentwicklung der IS-Architektur. T-Com strebt auch eine Konsolidierung und Harmonisierung der Applikations- und Integrationslandschaft an, wodurch das Unternehmen den Betriebsaufwand der IT-Architektur senken will. Der Ersatz von Punkt-zu-Punkt Schnittstellen durch fachlich standardisierte, wieder verwendbare Services soll längerfristig zu Kosteneinsparungen und Vermeidung von Redundanzen bei Neuentwicklungen führen. Zur Umsetzung der SOA führt T-Com momentan verschiedene Massnahmen durch. Der Aufbau einer SOA-Organisationsstruktur und die Definition technischer und fachlicher Architekturrichtlinien für das Servicedesign erlauben ein evolutionäres Vorgehen bei der Serviceimplementierung, indem sie die Konformität und Kompatibilität zeitlich und organisatorisch verteilter Projekte mit der Zielarchitektur sichern. Die Entwicklung einer standardisierten Integrationsarchitektur zielt auf eine Harmonisierung von Integrationsplattformen und -technologien und die Erhöhung der technischen Konnektivität zwischen Applikationen ab. Eine Entflechtung der Applikationsarchitektur und eine bessere fachliche Interoperabilität verfolgen die Modularisierung und Standardisierung fachlicher Logik und Daten und die Implementierung von Services für die Interaktion zwischen Anwendungsdomänen. Organisationsstrukturen und Architekturrichtlinien für das Servicedesign Um die SOA im Management und in den IT-Projekten zu verankern, ist T-Com gegenwärtig dabei, neue organisatorische Rollen, Aufgaben und Verantwortlichkeiten festzulegen. Vorgesehen ist inbs. die Bildung eines SOA-Ausschusses unter Leitung des CIO sowie ein SOA-Solution Center, das in der zentralen ISArchitektur angesiedelt ist. Der SOA-Ausschuss und das Solution Center definieren standardisierte Prozesse für die Serviceentwicklung und -nutzung in Fachprojekten. Diese beschreiben u.a., wie bei der Anforderungsanalyse, der Servicespezifikation, der Definition von SLAs, der Service-Zertifizierung und der Registrierung von Services im zentralen Repository vorzugehen ist. Daneben erarbeiten sie eine Reihe von Architekturrichtlinien und Service-Designprinzipien. Diese umfassen technische Eigenschaften von Services (z.B. kommunizieren Services ausschliesslich über den zentralen Servicebus), fachliche Eigenschaften (z.B. sollen Services autonom sein und einen Mehrwert aus fachlicher Sicht liefern) sowie die Servicedokumentation. Damit diese Richtlinien und Designprinzipien in den Projekten konsistent berücksichtigt

88

4 Fallbeispiele zu SOA

werden, entwickelt das SOA-Solution Center Templates, Werkzeuge und Methoden. Abb. 4-6 gibt z.B. einen Überblick über das einheitliche Servicebeschreibungs-Modell in einem zentralen Service-Repository. Service Definition

Service Template

Customization Info

Service Description

• Allg Info (Name, etc.) • Geschäftsprozess • Parameter

• • • •

• Verbale Beschreibung

contains Provider Service Profile

• Info über Provider • Ansprechpartner

Performance Version Daten Aktualität Add. Access Services accesses

Consumer Service Profile

• Info über Nutzer • Ansprechpartner

Abb. 4-6: Servicebeschreibung im zentralen Repository (Quelle: T-Com) Methodische Hilfe leistet das Solution Center u.a. bei der Bestimmung der Servicegranularität. Als Hilfsmittel für die Bestimmung einer geeigneten Servicegranularität setzen Entwickler Sequenzdiagramme ein, die Sequenzen zwischen Aufrufen von Serviceoperationen in unterschiedlichen Prozessen durch Servicenutzer zeigen. Von mehreren Nutzern in festen Sequenzen aufgerufene Operationen stellen Indizien für ein Zusammenfassen dieser Operationen dar. Entwicklung einer standardisierten Integrationsarchitektur T-Com unterscheidet in der serviceorientierten Zielarchitektur drei Arten von Systemen (s. Abb. 4-7): Frontend-Systeme (z.B. Internet-Vertriebsportale) realisieren die Schnittstellen zu Nutzern (Kunden, Call Center-Mitarbeitern etc.). Sie bieten kanal- und gerätespezifische Oberflächen für eine direkte Interaktion mit Endbenutzern bzw. Schnittstellen für die Interaktion mit T-Com-externen Anwendungssystemen (z.B. zur Kopplung von Auftragssystemen der WholesaleKunden). Frontend-Systeme unterstützen die End-zu-End-Steuerung der Fulfillmentprozesse von der Auftragsspezifikation bis zur Auftragsverfolgung in der Leistungserbringungsphase und treten als Service-Konsumenten auf. Backendbzw. Core-Systeme sind diejenigen Anwendungssysteme, welche die eigentlichen fachlichen Vertriebs- und Produktionsfunktionen implementieren und die dazu notwendigen Daten führen. Beispiele sind die Stammdatensysteme oder die Produktionssysteme zur Schaltung von Leitungen, für Telefonbucheinträge, Servicetechnikerdisposition etc. Die sog. Business-Logik- (BL) Systeme übernehmen eine

4.4 T-Com

89

Mittlerrolle zwischen Frontend- und Backend-Systemen. Sie abstrahieren Dienste der Core-Systeme fachlich und technisch und bündeln sie je nach Anforderungen der Frontend-Systeme zu Services. Um Performance- oder Verfügbarkeitsprobleme der Core-Systeme abzufangen, bieten sie teilweise auch Puffer-Mechanismen (z.B. eine Zwischenspeicherung zu produzierender Aufträge) und replizieren gewisse Daten. FrontendSysteme

BusinessLogikSysteme

Kundenportal

Call Center

Application Server (BL-System)

…

Application Server (BL-System)

Service Messaging Middleware, Adapter Integrationsinfrastruktur

CoreSysteme

CRM

…

Produktion

…

Abb. 4-7: Elemente der SOA-Integrationsinfrastruktur Die BL-Systeme sind auf Application Servern implementiert, welche zusammen mit einer nachrichtenbasierten Middleware wesentliche Bestandteile der Integrationsinfrastruktur darstellen. Die in dieser Integrationsinfrastruktur verwendeten Produkte und Technologien werden unternehmensweit standardisiert. Zum Einsatz kommt die IBM WebSphere Produktfamilie mit dem J2EE-basierten WebSphere Application Server und mit WebSphere MQ als nachrichtenbasierter Middleware. Letztere stellt eine asynchrone Kommunikationsinfrastruktur für die Interaktion zwischen Frontend- und BL-Systemen, BL- und Core-Systemen sowie zwischen BL-Systemen untereinander zur Verfügung. Neben asynchroner Kommunikation sind aus den Frontend-Systemen auch synchrone Serviceaufrufe über HTTP möglich. Als Dokumentenformat für den Nachrichtenaustausch auf Serviceebene wird XML verwendet. Serviceschnittstellen werden in einem zentralen Repository erfasst und sind formal beschrieben. Als Repository kommt ein Dokumentationstool zum Einsatz, das Templates für die Servicespezifikation definiert und über ein Web-Frontend im Intranet zugänglich macht. T-Com prüft den Einsatz von Web Service Standards (synchroner Austausch von XML-Nachrichten über SOAP / HTTP(s), Servicebeschreibung in WSDL) im zwischenbetrieblichen Bereich. Gegenwärtig werden sie aber im ESB nicht genutzt.

90

4 Fallbeispiele zu SOA

Modularisierung und Standardisierung fachlicher Logik und Daten Um den semantischen Integrationsaufwand zwischen Anwendungssystemen auf Datenebene zu reduzieren, d.h. die Übersetzung des Datenmodells einer Anwendung in dasjenige der anderen, entwickelt T-Com für rund 30 in den FulfillmentProzessen häufig verwendete Geschäftsobjekte (z.B. Kunde, Vertrag, Produkt oder Rufnummer) ein allen Services gemeinsames, applikationsübergreifendes Datenmodell (Business Object Model, BOM). Das Unternehmen evaluiert dazu auch Industriestandards wie das NGOSS Shared Information/Data Model des Telemanagement Forums.15 Ziel des standardisierten Datenmodells ist es, einen gemeinsamen, semantisch standardisierten „Datenbus“ zu definieren und spezifische Punkt-zu-Punkt Datentransformationen zwischen einzelnen Anwendungssystemen zu vermeiden. Dazu muss jede Anwendung für einen Serviceaufruf ihr internes Datenmodell in das entsprechende BOM und die Antwort aus dem BOM wieder in das intern verwendete Datenformat übersetzen. In der Abgrenzung von Anwendungsdomänen sieht T-Com drei wichtige Nutzenpotenziale: •

Vermeidung funktionaler Redundanzen und stärkere Wiederverwendung von IS-Bestandteilen, besonders durch eine klare Trennung der allen Vertriebsund Produktionsprozessen gemeinsamen Funktionen und Daten von prozessspezifischen.

•

„Lokalisierung“ der Auswirkungen absehbarer neuer Geschäftsanforderungen durch eine Trennung von Logik und Daten mit unterschiedlichen fachlichen Dynamiken bzw. Lebenszyklen.

• Klare Regelung der organisatorischen Verantwortung für Services und Daten. Servicesschnittstellen werden in domänenspezifischen BL-Systemen implementiert. Ein BL-System hat damit eine fachlich klar definierte Ausrichtung. Die aktuelle Zielarchitektur sieht für das Fulfillment fünf Domänen vor, zwischen denen zum Teil eine hierarchische Beziehung herrscht (s. Abb. 4-8): •

15

Die drei Domänen Endkundenkanal Internet (EKI), Wholesale Vertrieb (W) und Individuallösungen (INDIV) kapseln den Anteil an Vertriebslogik, der für einzelne Vertriebskanäle bzw. Kundensegmente und an sie vertriebene Produkte spezifisch ist. In diese Domänen fallen die Frontend-Systeme, welche die Endbenutzerschnittstellen („Presentation Layer“) implementieren und die vertriebskanalspezifischen BL-Systeme („Access Layer“), welche die eigentliche fachliche Vertriebslogik umsetzen. Diese BL-Systeme im Access Layer stellen „Automaten“ ohne eigene Präsentationslogik dar und bieten Services für die Frontend-Systeme. Sie kommen momentan für die Vertriebspartnerportale zum Einsatz, könnten aber auch zur Unterstützung webbasierter Call Center Lösungen genutzt oder mit Web Service Schnittstellen für eine direkte Kopplung mit Vertriebspartnersystemen versehen werden. Die vertriebskanalspezifischen BL-Systeme sind insbesondere für die Auftragssteuerungen zuständig. Sie bieten z.B. Services für die Kundenautorisierung, die Produktva-

s. http://www.tmforum.org/browse.asp?catID=1684

4.4 T-Com

91

lidierung (prüft, ob sich die im Auftrag enthaltenen Produkte im Portfolio des Kunden befinden und prinzipiell verfügbar sind), die Vertragsvalidierung (prüft, ob der Kunde für den Auftrag einen Vertrag besitzt), die Business Rules Validierung (validiert die Konstellationen zwischen den Auftragsbestandteilen auf Gültigkeit), die Order Completion (vervollständigt die Auftragsdaten mit evtl. notwendigen Bestandsdaten) oder das Auftragstracking (Rückgabe der Statuswerte des noch nicht abgeschlossenen Auftrags). • Die BL-Systeme der Access Ebene nutzen für die Umsetzung ihrer Logik Services der vertriebskanalneutralen Domänen Marketing / Vertrieb (MV) und Technik (T). Diese gruppieren den verschiedenen Vertriebsprozessen gemeinsame, vertriebskanalunabhängige Fachlogik und bilden den „Core Layer“. Sie kapseln Funktionen und Daten der unterstützenden Backend- bzw. Core-Systeme (z.B. Stammdatenserver, CRM-System, Produktionssysteme) als Services. Die Domäne MV bietet über ihre Services primär Zugriff auf Kunden- und Vertragsdaten für die Auftragsprüfung (z.B. zur Bonitätsprüfung) sowie Order Funktionen für die Erfassung produktionsreifer Aufträge und die Auftragsverfolgung. Die Domäne T umfasst technik- und produktspezifische Funktionen zur Prüfung von Verfügbarkeiten oder technischer Realisierbarkeit sowie zur Reservierung und Freigabe von Ressourcen (z.B. Montageterminen). Domäne EKI „Presentation Layer“

„Access Layer“

Portal EKI

Domäne W Portal W

…

BL EKI VertragsProduktvalidierung validierung Massenmarkt Massenmarkt …

…

Domäne INDIV Portal INDIV

BL W Vertragsvalidierung Wholesale …

…

BL INDIV Vertragsvalidierung Individual

Produktvalidierung Wholesale …

…

…

BL MV „Core Layer“

Bonitätsprüfung …

…

Kundenstamm

…

Domäne MV EKI: Endkundenkanal Internet W: Wholesales IDIV: Individuallösungen

…

…

BL T

Kundendaten bearbeiten …

Produktvalidierung Individual

Verfügbarkeitsprüfung …

Reservierung Montagetermin …

Produktion

…

…

Domäne T

MV: Marketing / Vertrieb T: Technik

Abb. 4-8: Fachliche Domänen- und Servicearchitektur (in Entwicklung) Neben einer klaren Zuordnung der fachlichen Verantwortung für Daten und Services und einer besseren Wiederverwendung gemeinsamer Funktionen trennt diese Domänenarchitektur auch Systembestandteile, die unterschiedliche fachliche Dynamiken bzw. Lebenszyklen aufweisen: Unterliegen Frontend-Systeme im Presentation Layer sehr häufig Änderungen (z.B. bei Anpassungen der Benutzeroberflächen, Logos oder Marketinginformationen), so bleibt die auf der „Zugangsebene“

92

4 Fallbeispiele zu SOA

enthaltene Vertriebslogik über Monate stabil und muss allenfalls für Verkaufsoffensiven oder die Vermarktung neuer Produktbündel (z.B. für die Umsetzung neuer Auftragsprüflogik) angepasst werden. Über eine noch höhere Stabilität verfügen die Domänen auf der Core-Ebene. Sie werden z.B. in den seltenen Fällen angepasst, in denen sich die technische Abwicklung der Produkte oder das Datenmodell der Kerngeschäftsobjekte ändern. Die in Abb. 4-8 aufgeführten groben Domänen der Zielarchitektur werden in weiteren Projekten detailliert, und zusätzliche Subdomänen werden abgegrenzt.

4.4.4

Bisherige Erfahrungen

Herausforderungen, mit denen sich T-Com gegenwärtig konfrontiert sieht, stellen die zeitliche Abstimmung der Architekturmassnahmen und das Change Management dar. Der Aufbau der notwendigen SOA-Organisationsstrukturen und der technischen Integrationsinfrastruktur dauert lange und ist mit Lernprozessen verbunden. Den Architekturverantwortlichen ist es aber wichtig, den SOA-Gedanken und das notwendige Wissen für die Entwicklung von Services schnell in die laufenden und zukünftigen Projekte einfliessen zu lassen. Das Bestimmen des richtigen Zeitpunkts für Informationen und Schulungen und der geeigneten Vorgehensweise ist jedoch schwierig: Um Akzeptanzprobleme und Frust bei den betroffenen Architekten und Entwicklern zu vermeiden, muss die organisatorische und technische Infrastruktur (Reviewgremien und -prozesse, Entwicklungswerkzeuge, Serviceverzeichnis etc.) zum Zeitpunkt der Schulungen einen Reifegrad erreichen, der eine reibungslose Umsetzung SOA-konformer Projekte möglich macht. Eine Überlegung von T-Com ist deshalb, ein Reifegrad-Modell zu formulieren, das aufeinander abgestimmte Stufen der technischen und organisatorischen Infrastruktur definiert und so einen schrittweisen Ausbau erlaubt. T-Com hat bereits viele Grundlagen für die Umsetzung der SOA geschaffen. Das SOA-Konzept ist beim T-Com IT-Management bekannt, und verantwortliche Personen sind bestimmt. Architekturrichtlinien für Services und Technik sind formuliert, das Business Object Modell erarbeitet, das Service-Repository aufgebaut und erste Informations- und Schulungsmassnahmen wurden durchgeführt. Ein Pilotprojekt hat auch bereits erste Services entwickelt. In den nächsten Monaten und Jahren stehen u.a. die Detaillierung der Domänenarchitektur, der Ausbau des SOA-Ausschusses und des SOA Solution Centers, die Einführung eines werkzeuggestützten Service-Designprozesses sowie die Etablierung weiterer Architekturprozesse (z.B. eines Service-Lebenszyklus-Managements) an. T-Com rechnet damit, in 3-4 Jahren zwischen 50 und 100 fachliche Services im Einsatz zu haben.

4.5 Zuger Kantonalbank

4.5

93

Zuger Kantonalbank

4.5.1

Unternehmen

Die Zuger Kantonalbank (ZGKB) ist eine regionale Universalbank, welche auf die Bedürfnisse der im Kanton Zug ansässigen Ziel-Kundengruppe eingeht. Geschäftsfelder neben Leistungen in den Bereichen Sparen und Zahlungsverkehr sind die Immobilienfinanzierung, kommerzielle Finanzierung sowie die Finanzund Anlageberatung. Zuger Kantonalbank AG (ZGKB) Gründung

1892

Firmensitz

Zug, Schweiz

Branche

Finanzdienstleistungen

Firmenstruktur

15 Geschäftsstellen im Kanton Zug

Geschäftsbereiche

Universalbank

Reingewinn

38.2 Mio. CHF (2005)

Mitarbeiter

396 (2005)

Homepage

http://www.zugerkb.ch

Tabelle 4-8: Kurzportrait Zuger Kantonalbank AG 4.5.2

Ausgangslage

Die ZGKB steht vor der Herausforderung, einer steigenden Kundenvolatilität und zunehmend heterogenen Kundenanforderungen gerecht zu werden, um im regionalen, nationalen und internationalen Wettbewerb zu bestehen. Gleichzeitig zwingen eine wachsende Wettbewerbsintensität, eine steigende Regulierungsdichte und anhaltender Druck auf Margen zu einer Effizienzsteigerung im Geschäftsbetrieb. Wichtige Erfolgsfaktoren des Unternehmens sind die Konzentration auf Kernkompetenzen und die Ausgliederung von Aktivitäten, die nicht zum Kerngeschäft gehören, die Steigerung der Geschwindigkeit und Qualität der Beratung von Kunden mit heterogenen Wünschen, die Automatisierung der Wertschöpfungskette sowie eine höhere Flexibilität bei der Neugestaltung von Prozessen. Die ZGKB hat 2002 die bisherige hostbasierte IT-Plattform durch die von CSC Switzerland GmbH betriebene Swiss Banking Platform (SBP) ersetzt. Die SBP stellt eine serviceorientierte, modular aufgebaute Gesamtlösung für den Bankbetrieb zur Verfügung, die verschiedene Geschäftsmodelle unterstützen soll. Banken, die ein umfassendes Marktangebot selbst produzieren und vertreiben, können die gesamte Funktionalität der Plattform nutzen. Sog. „Kooperationsbanken“ hingegen lagern gewisse Basisprozesse (z.B. das Wertschriftenmanagement, die Kontenbewirtschaftung etc.) an Partner aus, während „Tochterbanken“ nur Verkaufs- und Beratungsprozesse ausführen und die zentralen Management-, Un-

94

4 Fallbeispiele zu SOA

terstützungs- und Produktionsprozesse dem Stammhaus überlassen. Um solche flexiblen Verteilungsmodelle zu ermöglichen, definiert die SBP ausgehend von typischen Bankprozessen und -produkten eine fachliche Domänenarchitektur (s. Abb. 4-9). Auslagerungskandidaten sind vor allem Applikationsdomänen, die Produktionsprozesse unterstützen (z.B. Wertpapierabwicklung, Kontoführung, Zahlungsverkehr etc.), sowie produktübergreifende Unterstützungsprozesse und Aktivitäten (z.B. Archivierung). CSC will zukünftig für jede dieser Domänen Services definieren. Applikationen anderer Domänen sollen nur über die zentrale Integrationsinfrastruktur und die Serviceschnittstellen auf domäneninterne Funktionen und Daten zugreifen. Das Ersetzen oder die organisatorische Verlagerung der Anwendungssysteme einer Domäne haben dadurch weniger Auswirkungen auf domänenexterne Prozesse und Applikationen, solange die neuen Systeme die von der Plattform definierten Services zur Verfügung stellen.16

Supporting Systeme

Archivierung

Infrastruktur

Unterstützende Prozesse

Multi Channel

Call Center

Kundenmanagement

Geschäftsstelle

Beratung und Verkauf

Verkaufs- und Beratungsprozesse

Ausführende Basisprozesse

Basisdienste und -produkte

Unternehmenssupport

Unternehmensführung

Output

Zahlen

Anlegen

Finanzieren

Serviceintegrations-Layer (Enterprise Service Bibliothek und Steuerung / Koordination)

Zentrale Prozesse

Abb. 4-9: Domänenarchitektur der Swiss Banking Plattform (Quelle: CSC) Die SBP basiert auf dem CSC e4 Architekturframework und setzt sich im Kern aus der SAP NetWeaver-Plattform als Integrationsinfrastruktur, der Branchenlö-

16

Diese Serviceorientierung ist in der SBP gegenwärtig noch nicht vollständig umgesetzt. Services existieren bisher erst für einzelne Domänen. Sie kommunizieren noch nicht über plattformweit vereinheitlichte Kommunikationsprotokolle oder Nachrichtenformate, sondern bieten teilweise technologiespezifische Schnittstellen (z.B. ABAP-Objects- oder Java-Schnittstellen). Sie sind aber einheitlich beschrieben und die Servicebeschreibung ist zentral abgelegt.

4.5 Zuger Kantonalbank

95

sung SAP Banking, der CSC Lösung ADD für den Zahlungsverkehr und Legando für den Wertschriftenbereich zusammen. Mit der Einführung der SBP basierend auf SAP Banking löste die Zuger Kantonalbank u.a. ihre bisherige, von den Kundenberatern für die Kontoverwaltung genutzte Frontoffice-Applikation ab. Wie sich zeigte, wies die SAP Standardlösung für die meisten Frontoffice-Beratungsaktivitäten eine anspruchsvolle Benutzeroberfläche und eine nicht durchgängige Prozessführung auf: Ca. 80% der Kundenberatungen bestanden aus einfachen Aktivitäten wie dem Anlegen von Geschäftspartnern (Kunden), Konten und Dienstleistungen, und nur etwa 20% der Geschäftsfälle benötigten die vollständige SAP-Funktionalität. Gleichzeitig deckte SAP Banking nicht alle im Beratungsprozess benötigten Funktionen und Informationen ab. Z.B. waren Unterschriftenmuster zur Kundenauthentifizierung oder die Verwaltung von Konto- und Maestrokarten in separaten Anwendungssystemen enthalten, was zu schlecht integrierten Frontoffice-Prozessen führte.

4.5.3

Entwicklung eines servicebasierten Beraterarbeitsplatzes

Die ZGKB entwickelte gemeinsam mit CSC Switzerland GmbH und SAP AG einen integrierten Beraterarbeitsplatz (BAP). Das Projekt verfolgte primär zwei Ziele: •

Reduktion der Benutzeroberflächen- und Prozesskomplexität. Der BAP sollte den Kundenberatern eine auf ihre Bedürfnisse zugeschnittene, vereinfachte Benutzeroberfläche bieten und ihren administrativen Aufwand reduzieren. Komplexe Geschäftsvorfälle sollten einfach an das Backoffice delegiert werden können.

•

Flexible funktionale Erweiterung. Der Beraterprozess sollte unter einer einheitlichen Benutzeroberfläche besser integriert und – aus Sicht der Benutzerprozesse möglichst transparent – einfach erweitert werden können. Dies betraf einerseits die Erweiterung bestehender SAP-Funktionalität (z.B. um Dublettenchecks schon bei der Anlage von Partnergrunddaten durchführen zu können oder beim Speichern von Informationen automatisiert eine Prüfung gegen eine Personen-Risikoliste vorzunehmen), andererseits die Integration von nicht-SAP Funktionen (z.B. Unterschriftenkarte, Kontokarten), um Medienbrüche zu vermeiden und die Beratungs- und Datenqualität zu erhöhen. Der BAP wurde als Standardprodukt in die SBP integriert und wird heute von CSC und SAP weiterentwickelt. Leistungsumfang und Architektur des BAP Der BAP ist konzipiert als das Cockpit der ZGKB-Kundenberater. Er integriert verschiedene Bankanwendungen und bringt Expertenfunktionen zu den Kundenbetreuern, um die Frontoffice-Prozesse im Bereich Konto- und Kartenverwaltung für Geschäfts- und Privatkunden zu unterstützen. Der BAP fällt in die Applikationsdomäne „Beratung und Verkauf“ (s. Abb. 4-9) und nutzt primär Services der Domäne „Zahlen“ (Basisprozesse). Die aktuelle Version bietet die Leistungen:

96

4 Fallbeispiele zu SOA

•

Geführte Prozessablaufsteuerungen für die Neuanlage von Partnern (mit oder ohne Konten und Dienstleistungen wie Daueraufträge, Kontokarten etc.), für die Anlage von Konten und Dienstleistungen für bestehende Partner, für die Anlage von zusätzlichen Rollen für bestehende Partner (z.B. Wechsel von der Rolle „Interessent“ zur Rolle „Kunde) sowie für Bar-Saldierungen. Dokumente können personalisiert ausgegeben werden.

•

Die Modifikation von Partnern, Konten und Dienstleistungen.

•

Die Anzeige von Partnern, Konten, Kontaktinformationen, Unterschriftenkarten sowie Nachdruck von Dokumenten.

•

Das Absetzen von Meldungen zwischen Front- und Backoffice zur Delegation von Aufträgen, Formularbestellungen etc.

•

Das Kundenkontaktmanagement mit dem Anlegen, Bearbeiten und Auswerten von Kundenkontakten. Abb. 4-10 zeigt einen Screenshot der Benutzeroberfläche des BAP zum Anlegen eines neuen Geschäftspartners.

Abb. 4-10: Benutzeroberfläche des BAP (Quelle: CSC) Der BAP besteht im Kern aus einer Java-basierten Frontoffice-Applikation, welche eine eigene, aus SAP Banking herausgelöste Benutzeroberfläche und Prozesssteuerung bietet und Funktionen von SAP Banking, internen nicht-SAP Systemen sowie externen Anwendungssystemen von Partnern unter einer Oberfläche integriert. Abb. 4-11 zeigt die technische Umsetzung der BAP-Lösung auf den verschiedenen Integrationsebenen. Abb. 4-12 gibt einen Überblick über die BAPFunktionen und Integrationsbeziehungen am Beispiel der Berateraktivitäten „Partner anlegen“ und „Konto anlegen“.

4.5 Zuger Kantonalbank

97

Partner anlegen

Worksflowintegration

Desktopintegration

Anwendungsbezogene Sicht Konto anlegen

Anwendungsneutrale Sicht …

SAP Netweaver Enterprise Portal Guided Web Dynpro / Procedures J2EE

Backoffice-Kommunikation SAP Business Workflow

Services

SAP Banking ABAP Objects

Anwendungssysteme

dezidierte Middleware geplant

SAP BAPI SAP Nicht-SAP Banking

Nicht-SAP

ZGKB-extern

Abb. 4-11: Technische Implementierung des BAP Der Java-basierte BAP bietet auf Ebene Desktopintegration geführte, aus Beratersicht integrierte Benutzerprozesse (Guided Procedures) und übernimmt die Darstellung von Benutzeroberflächen in einem Web-Browser. Er stellt eine Composite Application dar, welche hauptsächlich Darstellungs- und (Benutzer-) Steuerungslogik in Form von Guided Procedures umfasst und selber keine persistenten Fachdaten hält. Lediglich Prozessstatusinformationen werden gespeichert und gewisse Hilfsdaten (z.B. Wertetabellen) aus Gründen der Performance ‚gecached’. Der BAP implementiert keine eigentlichen Fachdaten und -funktionen, sondern greift (zumindest im Fall von SAP-Funktionalität) über Remote Function Calls (RFCs) auf Funktionen zu, die in der Service-Ebene gekapselt und in (Backend-) Anwendungssystemen umgesetzt sind. Momentan nicht als Service gekapselte Funktionalität (alle nicht-SAP Funktionen und Daten) integriert er über alternative Technologien (z.B. das Java Messaging Service (JMS) Protokoll und einen WebSphere MQ-Adapter). Die auf Services basierenden Guided Procedures lassen sich durch berechtigte Prozessverantwortliche in einer portalbasierten, grafischen Design-time-Umgebung rekonfigurieren. Der BAP wurde auf einem SAP Web Application Server (Web AS) und dem SAP Enterprise Portal auf Basis der SAP Web Dynpro-Plattform implementiert. Frontoffice-Mitarbeiter können aus dem BAP über das Absetzen von Meldungen einen einfachen Workflow zur Kommunikation mit dem Backoffice anstossen. Der BAP definiert dazu Dokumentenvorlagen für verschiedene Meldungstypen und Listen mit möglichen Meldungsempfängern. Dieser (organisationseinheiten- bzw. benutzerrollenübergreifende) Prozess wurde auf Ebene Workflowintegration mit dem SAP Business Workflow umgesetzt. Die Ebene Anwendungssysteme enthält die eigentlichen Daten haltenden und Fachlogik implementierenden Applikationen, die ihre Funktionen über plattformspezifische Schnittstellen (im Fall von SAP über BAPI, Business Programming

98

4 Fallbeispiele zu SOA

Application Interfaces) zur Verfügung stellen. SAP Banking mit den Kernbestandteilen Konten (Banking Customer Accounts, BCA) und Geschäftspartner (Financial Services Business Partner, FS-BP) deckt den Grossteil des momentan vom BAP benötigten Funktionsumfangs ab. In BAP integrierte, unternehmenseigene nicht-SAP-Systeme umfassen z.B. eine Applikation zur Verwaltung von Unterschriftenkarten oder Microsoft Office für den Dokumentendruck. Für das Erfassen und Prüfen von Kontokarten-Anträgen wird eine externe, von Märki Baumann & Co. AG betriebene Applikation eingebunden. Die Service-Ebene schliesslich kapselt Funktionen der Applikationen auf Ebene Anwendungssystem. Services realisieren Funktionsschnittstellen mit dem Leistungsumfang bzw. in der Granularität, in der sie von den nutzenden Prozessen benötigt werden. Da die im BAP benötigten Funktionen grösstenteils in SAPBanking enthalten sind, beschlossen die Projektbeteiligten ursprünglich, keinen eigenen plattformunabhängigen Service-Layer zu implementieren. Stattdessen wurden die vorhandenen SAP-Schnittstellen (BAPIs) direkt auf dem Application Server von SAP Banking in Form von ABAP-Objects als Services umgesetzt. Diese Entscheidung wurde aus Kosten- und Performance-Überlegungen getroffen: Durch die Implementierung der Services auf dem Web AS von SAP Banking musste keine zusätzliche Middleware angeschafft werden und dank des Verzichts auf eine plattform- bzw. technologieübergreifend abstrahierende Serviceschicht (und der damit verbundenen Nachrichten- und Protokolltransformationen) konnten Performance-Engpässe in der Kommunikation zwischen BAP und Backend vermieden werden. Konsequenz dieses Entscheids ist allerdings, dass dem BAP und allfälligen weiteren Servicenutzern keine einheitlichen Schnittstellen auf die Backend-Systeme zur Verfügung stehen: Unternehmensinterne nicht-SAP Funktionen oder unternehmensexterne Funktionen werden über alternative Technologien direkt in den BAP eingebunden. Ein Beispiel ist die in Abb. 4-12 dargestellte Funktion zur Beauftragung von Kontokarten: Die durch den externen Partner Märki Baumann & Co. AG betriebene Applikation zur Verwaltung von Kontokarten bietet eine auf JMS und WebSphere MQ basierende Schnittstelle. Das Entwicklungsteam integrierte diese Schnittstelle direkt in den BAP und verzichtete darauf, die Funktion im Service Layer auf dem SAP AS in ABAP-Objects zu kapseln. Dadurch wurden zusätzlicher Entwicklungsaufwand und potenzielle Performance-Probleme vermieden. Sollten zukünftig weitere nicht-SAP Funktionen in den BAP eingebunden werden und auch weitere Applikationen auf die gleichen Backend-Systeme zugreifen, birgt diese Architekturentscheidung allerdings die Gefahr, dass im Laufe der Zeit eine wachsende Zahl technisch heterogener Schnittstellen und Punkt-zu-Punkt-Beziehungen zwischen den Applikationen entstehen. Aus diesem Grund strebt CSC bei steigender Komplexität der Architektur an, den Service Layer in eine dedizierte Middleware mit Prozessintegration zu verlagern.

4.5 Zuger Kantonalbank

Beratungsprozess

Kontoeröffnung Neukunde Partner anlegen

…

Konto anlegen

Services Anwendungssysteme

…

Partner anlegen Grunddaten erfassen

Personendaten u. Legitimation

Notizen erfassen

Konto anlegen

Daten kontrollieren

Workflowintegration

Desktopintegration

99

Partner sichern

Ggf. Backoffice Meldung erfassen

Karte anlegen

…

…

Backoffice-Kommunikation …

Partner anlegen

Dubletten prüfen

Gesch. Partner

Partner anlegen

Konten

SAP Banking

…

…

Karte anlegen

Textverarbeitung

…

Nicht SAP-Systeme

Kontokarten

…

ZGKB-externe Systeme

Abb. 4-12: BAP-Funktionen und Integrationsbeziehungen Die BAP-Architektur unterscheidet zwei Arten von Services: Sog. „PrepareServices“ dienen der Vorbereitung und dynamischen Generierung von Bildschirmmasken. Sie definieren die Feldattributierung (welche Felder sind zwingend, welche fakultativ, welche Wertebereiche sind erlaubt? etc.), belegen gewisse Felder mit Standardwerten oder laden Wertetabellen (z.B. eine Ländertabelle), die sie aus Backend-Systemen beziehen, in drop-down-Felder. „Execute-Services“ bearbeiten die eigentlichen Geschäftdaten bzw. kapseln Geschäftsfunktionen der Backend-Systeme. Abb. 4-12 zeigt beispielhaft die Verwendung der Services im Teilprozess „Partner anlegen“, den eine Guided Procedure mit mehreren Desktop-Masken unterstützt. Mit der Darstellung der ersten Maske zur Erfassung von Partnergrunddaten wird der „Partner anlegen“-Prepare-Service aufgerufen, der eine Feldattributierung vornimmt und (falls nicht bereits ‚gecached’) Wertelisten z.B. für die Partneranrede einliest. Mit Vervollständigung der Maske und dem Wechsel zur Maske für die Erfassung der Personendaten und Legitimationsunterlagen (Ausweispapiere) wird durch den Service „Dubletten prüfen“ eine erste Prüfung allfälliger bereits existierender Partnereinträge durchgeführt. Die weiteren Desktop-Aktivitäten (Notizen erfassen, Daten kontrollieren) finden nur im BAPFrontend ohne Aufruf von Services statt. Erst beim Sichern der erfassten Daten wird der „Partner anlegen“ Execute-Services aufgerufen, der eine Risikolistenprüfung und eine weitere Dublettenprüfung durchführt sowie die erfassten Personendaten und die Partnerrolle persistent in die SAP Banking Backend-Applikation schreibt. Momentan sind auf dem Service-Layer zwischen 20-30 Services implementiert. Rund 220 BAP-Nutzer tätigen mehrere zehntausend Serviceaufrufe täglich.

100

4 Fallbeispiele zu SOA

Vorgehen bei der Identifikation und Entwicklung von Services Das Projektteam wendete ein prozessorientiertes Vorgehen für die Identifikation und Abgrenzung von Services an. Ausgehend von den betroffenen Bankprodukten und typischen Geschäftsfällen modellierten die Prozessverantwortlichen der Zuger Kantonalbank die Beratungsprozesse unter der Annahme, dass ein integrierter Beraterarbeitsplatz existiert. Aufbauend darauf identifizierte das Projektteam in der Benutzeroberfläche ablaufende und durch das Backend zu unterstützende Prozesse und Aktivitäten und versuchte, letzteren existierende, durch die bestehenden Backend-Applikationen zur Verfügung gestellte Schnittstellen zuzuordnen. Diese wurden auf ihre Granularität und Performance-Aspekte untersucht und gegebenenfalls zusammengefasst, erweitert oder verfeinert. Beim Servicedesign berücksichtigten die Entwickler folgende Kriterien: •

Granularität und Performanz. Um die Anzahl der Systeminteraktionen gering zu halten, sollen Services aus funktionaler Sicht möglichst eine komplette Prozessaktivität unterstützen. Aus Datensicht sollen sie alle für den unterstützten Geschäftsprozess benötigten Informationen liefern. Wenn grosse Datenmengen zu Performance-Problemen führen, wird die Anzahl der mit einem Serviceaufruf übermittelten Attribute auf das Wesentliche reduziert.

•

Generalisierung und Erweiterbarkeit. Serviceschnittstellen kommunizieren mit Servicenutzern über XML-Nachrichten, welche generische Felder für zur Entwicklungszeit unbekannte Attribute enthalten. Diese können mit entsprechenden Werten gefüllt werden, wenn spätere Serviceversionen weitere Attribute neben den ursprünglich vorgesehenen verarbeiten sollen. Bestehende Servicenutzer ignorieren diese Felder und müssen keine Anpassungen vornehmen. Serviceentwickler verändern ausserdem nicht direkt die fachlichen Schnittstellen (BAPIs). Sie nehmen je nach Art der Erweiterung Anpassungen innerhalb der BAPIs nur an von SAP vordefinierten Stellen oder ausserhalb der BAPIs im Service Layer vor und versehen die Erweiterungen mit Logging- und Debugging-Möglichkeiten.

•

Kapselung von Transaktionen. Services interagieren mit ihren Nutzern statuslos und sind für ihre interne Transaktionssicherheit verantwortlich. Wenn sie mehrere Arbeitsschritte kapseln (z.B. neben dem Schreiben von Partnerstammdaten auch Partnerrollen anlegen), müssen sie bereits ausgeführte Aktionen rückgängig machen können, falls eine der Aktionen misslingt. Die als ABAP-Objects implementierten Services wurden meistens auf Basis bestehender BAPIs realisiert und – falls sie bezüglich ihres Leistungsumfangs nicht den Anforderungen der BAP-Prozesse entsprachen – folgendermassen angepasst: •

Zusammenfassung von zu feingranularen Schnittstellen. Für eine in sich geschlossene Prozessaktivität, die nicht vollständig durch ein bestehendes BAPI unterstützt wird, fasste das Projektteam mehrere BAPIs zusammen und erweiterte notfalls ihre Funktionalität. Ein Beispiel stellt die in Abb. 4-12 dargestellte Aktivität „Partner sichern“ dar: Das Anlegen eines neuen Geschäftspartners umfasst aus Prozesssicht einerseits das Erfassen der Partnergrunddaten und andererseits das Zuordnen einer Partnerrolle (Interessent, Kunde, Mitarbeiter etc.). Dazu bietet SAP Banking zwei BAPIs, die vom Service

4.5 Zuger Kantonalbank

101

„Partner anlegen“ gebündelt werden. Ausserdem erweitert der Service diese Funktionalität um eine Überprüfung der Risikoliste: Steht der anzulegende Geschäftspartner auf einer „Blacklist“, erhält der erfassende Kundenberater eine entsprechende Meldung. Durch diese Zusammenfassung mehrerer Schnittstellen sinkt die Anzahl Interaktionen zwischen Frontend (BAP) und den betroffenen Backend-Applikationen. Funktionserweiterungen wie zusätzliche Kundenprüfregeln lassen sich ausserdem implementieren, ohne dass die Beraterprozesse angepasst werden müssen. •

Verfeinerung von zu grobgranularen Schnittstellen. Gewisse BAPIs (etwa zur Anzeige von Kundeninformationen) stellen in ihrer generischen Form grosse Datenmengen zur Verfügung. Um die Grösse der zwischen BAP und Backend-Applikationen ausgetauschten Nachrichten zu reduzieren und dadurch die Systemperformance zu verbessern, wurden einige grobgranulare generische BAPIs zu spezialisierten Services „verfeinert“. Diese liefern nur die vom BAP im gerade unterstützten Prozess benötigten Daten (z.B. nur Werte für bestimmte Kundenattribute). Solche spezialisierten Services bergen die Gefahr, dass sie für andere Prozesse (z.B. im Marketing / Kampagnenmanagement) nicht alle benötigten Informationen zur Verfügung stellen können und deswegen in einem anderen als dem ursprünglich geplanten Kontext nicht wieder verwendbar sind. Um eine performante Lösung für die mit dem BAPProjekt angegangenen Probleme zu erhalten, wurde dies jedoch in Kauf genommen.

•

Entwicklung neuer Funktionalität. Gewisse funktionale Anforderungen des BAP gingen über die vorhandenen SAP-Funktionen hinaus, bzw. das SAPSystem erfüllte nicht immer die Performance-Anforderungen des BAP. In diesen Fällen wurde das SAP-System um zusätzliche Funktionen erweitert. Ein Beispiel ist die Ähnlichkeitssuche nach Partnern, welche phonetisch gleiche Namen mit unterschiedlichen Schreibweisen liefert (z.B. Meier und Meyer). Dazu wurden eine Standardsoftware für SAP installiert und eine entsprechende Schnittstelle als Service implementiert.

4.5.4

Bisherige Erfahrungen

Aufwand und Nutzen Die Entwicklung und Einführung des BAP dauerte gut ein Jahr und lief von September 2003 bis Oktober 2004. Während der neunmonatigen Kernprojektphase waren für die Entwicklung der Backend-Services drei bis vier, in der Frontendentwicklung rund sieben Personen beschäftigt. Während den restlichen drei Monaten testeten ca. sechs Personen den BAP und bereiteten seine Inbetriebnahme vor. An der Entwicklung waren Mitarbeiter der ZGKB, CSC und SAP beteiligt, wobei die Gesamtprojektleitung bei CSC lag. Projektnutzen für die ZGKB entstand in folgenden Bereichen: •

Prozessverbesserung. Aufgrund von Messungen der Ausgangslage und erster Schätzungen rechnet die Zuger Kantonalbank mit einer Prozessbeschleuni-

102

4 Fallbeispiele zu SOA

gung von 25-75% beim Anlegen von Partnern und Konten durch FrontBerater, mit einer Beschleunigung der Backoffice-Kontrolle um 75% durch bessere Datenqualität und dem Wegfall bestimmter manueller Aktivitäten und mit einer Beschleunigung der Partnersuche um 25%. Der hohe Automatisierungsgrad der Lösung erlaubte ausserdem die Reduktion von Personalaufwand, und die geringere Komplexität der Benutzeroberfläche spart Schulungskosten für neue Mitarbeiter. •

Mitarbeiterzufriedenheit und Beratungsqualität. Der BAP ermöglicht es Front-Beratern, sich stärker auf das Kundengespräch und den Verkauf zu fokussieren und liefert Informationen in einer besseren Datenqualität.

•

Flexibilität und Erweiterbarkeit. Die Architektur des BAP erlaubt es, servicebasierte Front-Prozesse und Guided Procedures schneller als bisher anzupassen und aus Sicht der Benutzerprozesse transparent um zusätzliche Funktionen (z.B. zusätzliche Kundenprüfregeln) zu erweitern. Einzelne für den BAP entwickelte Services werden mittlerweile auch von der Schalterapplikation bei der ZGKB verwendet.

Herausforderungen und Erfolgsfaktoren Eine Herausforderung bei der Umsetzung des BAP stellte die zu Projektbeginn noch unreife Integrationsinfrastruktur dar. Die eingesetzte SAP NetWeaverPlattform war erst im ersten Quartal 2004 allgemein am Markt verfügbar, weshalb das Projekt im letzten Quartal 2003 mit einer Ramp-up-Version starten musste. Eine fachliche Herausforderung bestand in der Definition möglichst stabiler Services. Das Projektteam musste dazu die Anforderungen abgleichen, welche die unterschiedlichen zu unterstützenden Prozesse an die Service-Funktionen und Service-Datenmodelle stellten. Eine prozessorientierte Serviceidentifikation und die Verwendung erweiterbarer XML-Nachrichten für die Kommunikation stellten hier wichtige Erfolgsfaktoren dar. Ein weiterer wichtiger Faktor für das Gelingen des Projekts war die genaue Bedürfnisabklärung durch die ZGKB und die enge Zusammenarbeit zwischen den Projektbeteiligten. Geplante Weiterentwicklungen Der nächste grössere, mittelfristig geplante Entwicklungsschritt betrifft den Weiterausbau des BAP für zusätzliche Produkte und die Umsetzung einer umfassenden Sicht auf einen Kunden und seine Produkte. Momentan stellt der BAP die Cockpit-Anwendung für den Basisprozess dar (Partner, Konten, Karten, Zahlungsverkehr, Vertrags- und Beziehungsmanagement inkl. Compliance). Neben dem BAP existieren weiter je eine Applikation für die Anlage- und die Kreditberatung. Die Zuger Kantonalbank untersucht gemeinsam mit CSC die Möglichkeit, alle Beratungsprodukte unter einem einheitlichen Arbeitsplatz mit rollenspezifischen Sichten zu integrieren und um weitere Funktionen für das Kundenkontaktmanagement zu ergänzen. Dabei würde es Sinn machen, den aktuellen BAPService-Layer aus dem SAP Banking herauszulösen und in eine eigenständige, applikationsübergreifende Service-Schicht zu überführen. Das Unternehmen prüft in diesem Zusammenhang auch eine plattformunabhängigere Umsetzung der Ser-

4.6 Erkenntnisse aus den Fallstudien

103

viceschicht. Zur Diskussion steht dabei die Verwendung von Web Service Standards (SOAP / XML und WSDL).

4.6

Erkenntnisse aus den Fallstudien

4.6.1

Treiber und Leidensdruck

In den untersuchten Fallstudien waren wichtige Auslöser für die Einführung einer SOA mangelhaft integrierte Geschäftsprozesse, lange und risikoreiche Projekte beim Umsetzen neuer Geschäftsanforderungen, hohe Kosten des IT-Betriebs und Probleme bei notwendigen technischen Modernisierungen in der IS-Architektur: •

Für Deutsche Post Brief (DPB) stellten schlecht verfügbare Kerninformationen (Kunden, Wettbewerbsinformationen etc.), ungenügend integrierte Geschäftsprozesse, hohe Wartungs- und Betriebskosten der IS-Architektur sowie zunehmend umfang- und risikoreichere IT-Projekte Treiber für eine SOA dar.

•

Der jahrelange, oft unter Zeitdruck erfolgte Ausbau der Applikationslandschaft führte bei Credit Suisse (CS) zu einer IS-Architektur, welche bspw. den Aufbau von Internet-Kundenkanälen oder die Ablösung des MainframeBuchungssystems durch eine objektorientierte Lösung mit vertretbarem Aufwand verunmöglichte.

•

Wiederholte organisatorische Anpassungen, steigender Bedarf nach unternehmensübergreifend integrierten Kooperationsprozessen mit Vertriebspartnern und ein umfangreicher Ausbau des Produkt- bzw. Leistungsangebots waren Startpunkte der SOA-Überlegungen bei T-Com. Sie führten v.a. in der Auftragsabwicklung und der Produktion zu Herausforderungen durch Redundanzen, technische Heterogenität und enge Abhängigkeiten der unterstützenden Informationssysteme.

•

Auslöser des Projekts bei der Zuger Kantonalbank (ZGKB) war eine unzureichende Unterstützung der Kundenberatungsprozesse durch eine neu eingeführte Standardsoftware. Benutzeroberfläche und Prozessführung waren für die Kundenberater ungeeignet. Ausserdem deckte die neue Lösung nicht alle benötigten Funktionen und Daten ab. Tabelle 4-9 konsolidiert die wichtigsten der in den Fallstudien genannten Treiber in den bestehenden IS-Architekturen.

CS

T-Com

ZGKB

4 Fallbeispiele zu SOA

DPB

104

Paralleler Einsatz verschiedener Technologien und Plattformen in der Applikationsarchitektur





Vielfalt an Integrationstechnologien mit mangelhafter Interoperabilität





Schlecht kontrollierte Applikationsschnittstellen und enge logische Abhängigkeiten zwischen Systemen







Fachfunktionen mehrfach in unterschiedlichen Anwendungen implementiert







Wichtige Geschäftsdaten mehrfach in Applikationen verwaltet







Enge Verknüpfung von Präsentations-, Ablaufsteuerungs- und Fachlogik in monolithischen Systemen







Mangelhafte Fähigkeit, externe Funktionen einzubinden bzw. externen Partnern Zugriff auf interne Funktionen zu geben







Architekturtreiber für SOA

 wichtiger Treiber kein wichtiger Treiber

Tabelle 4-9: Architekturtreiber für SOA 4.6.2

Einsatzreichweite und Ziele

Die SOA-Projekte von Credit Suisse und Deutsche Post Brief umfassten von Beginn weg die unternehmensweite Applikationsarchitektur bzw. alle Kerngeschäftsprozesse, wobei die eigentliche Implementierung von Services nach aktuellen Geschäftsanforderungen und laufenden Projekten priorisiert wurde. Die Architekturentwicklung von T-Com konzentriert sich in einem ersten Schritt auf den Fulfillment-Bereich, mit Schwerpunkt Auftragserstellung und -abwicklung. Das Unternehmen will die SOA erst in einem nächsten Schritt auf weitere Prozesse und Anwendungsdomänen ausdehnen. Mit der Entwicklung eines integrierten Arbeitsplatzes für die Kundenberatung im Bereich Konten und Kontokarten war das BAP-Projekt von Zuger Kantonalbank auf einen sehr kleinen Teil der Unternehmensprozesse und der Applikationsarchitektur ausgelegt. Auch mit der geplanten Ausweitung auf Beraterprozesse zu weiteren Produkten treten erst wenige Anwendungen als Anbieter und Nutzer von Services auf. Die durchgeführten Projekte konzentrierten sich zuerst auf die Entwicklung unternehmensintern genutzter Services. Die Integration externer Geschäftspartner für durchgängige unternehmensübergreifende Prozesse stellte i.d.R. einen zweiten, auf den internen Services aufbauenden Schritt dar. Nur für T-Com besassen Services für externe Nutzer eine hohe Priorität. Das Unternehmen will früh Services

4.6 Erkenntnisse aus den Fallstudien

105

wie bspw. eine produktübergreifende Verfügbarkeitsprüfung entwickeln, die sowohl interne Vertriebskanäle als auch Vertriebspartner nutzen können. Im Vergleich der Fallstudien zeichnen sich drei grobe Einsatzziele für SOA ab (s. Tabelle 4-10): •

Als standardisierte Integrationsinfrastruktur erhöht eine SOA die technische Konnektivität heterogener Applikationen, reduziert die Vielfalt der Schnittstellentechnologien und verringert damit Integrations- und Wartungskosten. Angesichts einer wachsenden Anzahl heterogener Applikationsplattformen, Betriebssysteme, Integrationsinfrastrukturen und Entwicklungswerkzeuge verfolgen Deutsche Post Brief, Credit Suisse und T-Com das Ziel, die Integration bestehender Anwendungssysteme zu standardisieren und dazu eine plattformübergreifende Integrationsinfrastruktur aufzubauen. Dies ist vergleichbar mit typischen EAI-Zielen.

•

Der Einsatz von SOA zur Entkopplung von Applikationssdomänen zielt auf eine Reduktion von Abhängigkeiten und Redundanzen zwischen Applikationen. Credit Suisse, Deutsche Post Brief und T-Com senken Projektrisiken sowie Kosten für die Neu- bzw. Weiterentwicklung von Anwendungen und den IT-Betrieb, indem sie ihre Applikationslandschaft in redundanzfreie, fachlich abgegrenzte Domänen unterteilen. Diese bieten wieder verwendbare Services und werden eigenständig verantwortet und weiterentwickelt. Die Entkopplung von Domänen ist beim Fallbeispiel ZGKB nicht so stark ausgeprägt bzw. besitzt wegen der Beschränkung auf einen kleinen Teilbereich der Applikationsarchitektur nicht den gleichen Stellenwert wie bei den übrigen Unternehmen. Mit der Entwicklung von Serviceschnittstellen für SAPBanking wurde aber ein erster Schritt zur Trennung der Domänen „Beratung und Verkauf“ und „Zahlen“ im Rahmen der Bankenplattform realisiert.

•

Eine einfachere und schnellere Anpassung bzw. Neuentwicklung anwendungsübergreifender Prozesse strebt die flexible Benutzer- bzw. Geschäftsprozessintegration an. Alle untersuchten Unternehmen integrieren Services in Portalen, um Benutzerprozesse besser zu unterstützen. Eine Externalisierung von Ablauf- und Steuerungslogik in Form von Workflows bzw. Taskflows stellte zum Zeitpunkt der Fallstudienerhebung aber nur bei Zuger Kantonalbank ein zentrales Ziel der SOA dar. Die restlichen Unternehmen programmierten Prozesslogik zur Servicenutzung i.d.R. fest in den nutzenden Anwendungen ein. Zwar waren auch bei Credit Suisse, Deutsche Post Brief und TCom Workflowsysteme im Einsatz bzw. geplant. Die Serviceorchestrierung auf Basis von Workflows war dort aber eine Massnahme, die erst in Zukunft stärker gewichtet werden soll.

CS

T-Com

ZGKB

4 Fallbeispiele zu SOA

DPB

106

SOA als standardisierte Integrationsinfrastruktur







SOA für die Entkopplung von Applikationsdomänen









SOA für eine flexible Benutzer- bzw. Geschäftsprozessintegration









Primäre Einsatzziele der SOA

 angestrebt teilweise angestrebt nicht angestrebt

Tabelle 4-10: Primäre Einsatzziele der SOA Während das erste Einsatzziel primär die IT-Effizienz erhöhen soll (dank einfacherer technischer Integration, einer Beschränkung von Technologien, Knowhow-Konsolidierung etc.), zielen die beiden weiteren stärker auf ein verbessertes IT-Business-Alignment durch eine Strukturierung des IS nach den Konzepten und der Begriffswelt des Geschäfts ab. Eine umfassende SOA deckt idealerweise alle Einsatzziele ab. Die dargestellten Fallbeispiele sowie weitere Praxisberichte zeigen aber, dass sich Unternehmen je nach Ausgangslage und Problemstellung auf einzelne Bereiche konzentrieren: So unternahmen Credit Suisse und Deutsche Post Brief ihre Hauptanstrengungen bisher in den Bereichen Integrationsinfrastruktur und Domänen-Entkopplung. Im Projekt der ZGKB lag der Fokus auf der Benutzerintegration. Weitere dokumentierte SOA-Praxisbeispiele zeigen Projekte, die sich fast ausschliesslich auf die Entwicklung einer technisch standardisierten Integrationsschicht konzentrierten. So beschreiben etwa [Zimmermann et al. 2004b] die Umsetzung einer SOA bei Sparkassen Informatik, welche eine Reduktion der Schnittstellentechnologien und der Integrationslösungen durch eine einheitliche Kapselung bestehender Anwendungsschnittstellen mit Web Service Technologien verfolgte. Tabelle 4-11 detailliert die in den Fallstudien beobachteten Ziele und Treiber. Architekturziel

Typische Treiber

SOA als standardisierte Integrationsinfrastruktur Dokumentierte und gemanagte Schnittstellen

• Mangelhafter Überblick über Schnittstellen in der Applikationsarchitektur

Plattformübergreifende Integration und Technologiereduktion

• Paralleler Einsatz technisch inkompatibler Applikationsplattformen

• Schlechte / uneinheitliche Dokumentationsqualität von Schnittstellen

• Vielfalt an Integrationstechnologien mit mangelhafter Interoperabilität

4.6 Erkenntnisse aus den Fallstudien Architekturziel

107 Typische Treiber

SOA für die Entkopplung von Applikationsdomänen Lokale Begrenzung von Anpassungen in der Applikationsarchitektur

• Viele Abhängigkeiten zwischen logisch / fachlich verschiedenen Funktionen

Hohe Wiederverwendung und Redundanzreduktion

• Hoher Betriebs- / Anpassungsaufwand und mangelhafte Datenqualität durch redundante Funktionen und Daten in der Applikationsarchitektur

• Wiederkehrende Änderungen, die nur einen kleinen Architekturbereich betreffen, führen zu umfangreichen und komplexen Projekten

• Einzelprojektspezifische Funktions- / Schnittstellenentwicklung • Unklare organisatorische Zuständigkeit für Daten / Funktionen SOA für eine flexible Benutzer- bzw. Geschäftsprozessintegration Ausrichtung von ITFunktionen an Geschäftsprozessen

• Von Anwendungen zur Verfügung gestellte Funktionen / Daten / Masken entsprechen nicht den Anforderungen der Nutzer (Granularität, Terminologie etc.) • Fachliche Geschäfts- bzw. Benutzerprozess-Modelle lassen sich schwer auf Funktionsschnittstellen in der Applikationsarchitektur abbilden

Entkopplung von Prozess- und Systemanpassungen

• Enge Verknüpfung von Präsentations-, Ablaufsteuerungsund Fachlogik • Unterschiedliche Lebenszyklen von Prozessen und unterstützenden Anwendungen

Tabelle 4-11: SOA-Ziele und Treiber Die Literatur beschreibt den Entwurf und die teilweise automatisierte Umsetzung servicebasierter Prozesse über Prozessmodellierungs-Werkzeuge [s. Newcomer/ Lomow 2004, 222] oder die dynamische Identifikation und Integration von Services [s. Hepp et al. 2005] oft als wichtige Ziele einer SOA. In den untersuchten Fallbeispielen besassen sie zum Zeitpunkt der Erhebung noch keine grosse Bedeutung. Auch andere Studien zeigen, dass sie für viele Unternehmen erst Zukunftsthemen darstellen (vgl. [Fontanella 2005, 14], [Wilhelmi et al. 2005, 30f]).

4.6.3

Einordnung der Fallbeispiele im SOA-Ebenenmodell

Die Beispiele zeigen, dass die Umsetzung von SOA erst in den Anfängen steckt. Keines der Unternehmen realisiert sämtliche Architekturebenen des Modells aus Kap. 3.2 vollständig (s. Abb. 4-13). Deutsche Post Brief, Credit Suisse und T-Com legten das Hauptgewicht auf die Entwicklung einer Domänenarchitektur sowie die Umsetzung standardisierter, gemanagter Serviceschnittstellen auf einer zentralen Integrationsinfrastruktur. Sie bewegen sich damit primär auf der Anwendungssys-

108

4 Fallbeispiele zu SOA

tem- und der Serviceebene. Die Logik zur Komposition von Services wird überwiegend direkt in die nutzenden Applikationen programmiert; eine Umsetzung von aus den Applikationen herausgelösten übergreifenden Work- bzw. Taskflows steht momentan nicht im Vordergrund. Bei der Zuger Kantonalbank bildete die Externalisierung von Prozesslogik aus bestehenden Applikationen und die Komposition von Services in Taskflows den Schwerpunkt. Zwar wurden auch hier bestehende Applikationsfunktionen als Services gekapselt und in einem zentralen Verzeichnis beschrieben, auf die Implementierung einer plattformunabhängigen Serviceschicht mit standardisierten Schnittstellentechnologien verzichtete das Unternehmen aber vorerst. Da ein Grossteil der Services durch eine Applikation (SAP Banking) implementiert wird, spielte auch die Definition von Applikationsdomänen eine untergeordnete Rolle. Ebene Desktopintegration

führt aus

cn

1 besteht aus n Task

Rolle

c unterstützt 1

1

implen mentiert 1 Portal- / CAplattform

n

stösst an cn

1

Ebene Workflowintegration

c

Manuelle Aktivität

nutzt

n

Ebene Service

Workflow ist1 ist 1

Automatisierte Aktivität

Aktivität

n

steuert

n

implementiert

1

1 Workflow Management System n nutzt

c

nutzt

c n

Prozessportal

führt aus

cn

Nachricht

1

n

Taskflow

c

kommuniziert über n

cn

n

n

1

n Middlewaredienst

nutzt 1

Service

beschreibt

1

1

Servicespezifikation n

Ebene Anwendungssystem

enthält

n

Serviceverzeichnis

nutzt

Serviceschnittstelle

n

1 besitzt

implementiert / nutzt

n

n

gruppiert

Applikation

n Funktion

1

1

nutzt

cn nutzt cn

n

führt aus

Gestaltungsbereiche aller Fallbeispiele

n n

bietet

1 Applikationsdomäne

nutzt

1 bietet an

greift zu auf n

cn

Applikationsschnittstelle

n

Informationsobjekte

Gestaltungsbereiche Deutsche Post Brief, Credit Suisse, T-Com

Gestaltungsbereiche Zuger Kantonalbank

Abb. 4-13: Hauptgestaltungsbereiche in den Fallstudien Tabelle 4-12 gibt einen Überblick über die Ausprägung der Architekturebenen in den Fallstudien zum Zeitpunkt ihrer Erhebung.

4.6 Erkenntnisse aus den Fallstudien

Ebene Services

Workflow

Desktopintegration

DPB

CS

109 T-Com

ZGKB

U.a. Verwendung von Services in Mitarbeiter-, Kunden- oder Vertriebspartnerportalen, in Fallstudien nicht im Detail untersucht

Unterstützung der Kundenberatungsprozesse (Kontenanlage, Kontaktmanagement etc.) auf Basis SAP Enterprise Portal und Composite Application Framework

Zum Zeitpunkt der Fallstudienerhebung keine workflowbasierte Servicekomposition

Unterstützung der Front- / Backoffice-Kommunikation auf Basis SAP Business Workflow

• 20-30 Services (ca. 100 geplant) in 13 Domänen • Zentrale, standardisierte Integrationsinfrastruktur auf Basis J2EE und Best-ofBreed-Produkte • Einheitliche Servicespezifikation in zentralem Serviceverzeichnis

• Ca. 300 Services (ca. 900 Serviceoperationen) in 20 Applikationsdomänen

• Ca. 50-100 Services geplant, 5 Applikationsdomänen (nur für Fulfillment)

• Ca. 20 Services, grossteils direkt auf SAP Banking Application Server implementiert

• Zentrale, standardisierte Integrationsinfrastruktur auf Basis CORBA und IBM WebSpherePlattform

• Zentrale, standardisierte Integrationsinfrastruktur auf Basis IBM WebSpherePlattform

• Keine zentrale Integrationsinfrastruktur, verschiedene Schnittstellentechnologien (ABAP Objects / SAP RFC, Java RMI)

• Einheitliche Servicespezifikation in zentralem Serviceverzeichnis

• Einheitliche Servicespezifikation in zentralem Serviceverzeichnis

• Einheitliche Servicespezifikation, Dokumente auf Serververzeichnis abgelegt

Tabelle 4-12: Ausprägung der Architekturebenen 4.6.4

Anwendung der SOA-Designprinzipien

Tabelle 4-13 gibt einen Überblick über die in den Fallstudien angewendeten SOADesignprinzipien. Detailliertere Informationen zur Ausprägung der Prinzpien in den einzelnen Fallstudien gibt Anhang C.

110

4 Fallbeispiele zu SOA

Bedarfsorientierung

Autonomie, Modularität

Interoperabilität

Schnittstellenorientierung

Designprinzip

DPB

CS

T-Com

ZGKB

Abstraktion von der Serviceimplementierung









Umfassende Servicespezifikation









Stabile, gemanagte Servicekontrakte









Technische Schnittstellenstandardisierung









Fachliche Schnittstellenstandardisierung









Verwendung offener und verbreiteter Industriestandards









Hohe Servicekohäsion und schwache logische Kopplung









Lose gekoppelte Kommunikation









An Geschäftskonzepten orientierte Servicegranularität









Generalisierung der Serviceleistung









 angewendet teilweise angewendet nicht angewendet

Tabelle 4-13: Angewendete Designprinzipien In der Berücksichtigung der Designprinzipien zeigen sich die Unterschiede in der Anwendungsreichweite und den Einsatzzielen der SOA. Im Gegensatz zu den restlichen Fallbeispielen setzte Zuger Kantonalbank die SOA für einen kleinen und homogenen Teilbereich der Applikationsarchitektur um. Hauptziel war die flexible Anpassbarkeit und bessere Integration der Arbeitsabläufe von Kundenberatern durch Herauslösen der Benutzerprozess- und Präsentationslogik aus dem SAP-Banking-System. Sowohl der Beraterarbeitsplatz als Servicenutzer als auch das Banking-System, das den überwiegenden Teil der genutzten Services implementierte, basierten auf der SAP-Produktfamilie, und die Anzahl entwickelter Services war gering. Entsprechend besassen hier die Abstraktion von der technischen und fachlichen Serviceimplementierung, das Management der Servicekontrakte sowie die technische und semantische Schnittstellenstandardisierung keine bzw. eine untergeordnete Bedeutung. Die Unternehmen, die SOA für einen grösseren Bereich der Applikationsarchitektur umsetzen, wendeten diese Prinzipien stärker an. Obwohl in der Literatur selten erwähnt (s. Kap. 3.3.5), erachten sie

4.6 Erkenntnisse aus den Fallstudien

111

auch eine fachlich-semantische Standardisierung der Serviceschnittstellen als wichtig. Die Verwendung von Industriestandards ist in keinem der Fallbeispiele umfassend ausgeprägt. Grund dafür ist, dass hersteller- und technologieplattformübergreifende Standards momentan fehlen bzw. nicht reif genug sind. Im Bezug auf technische Standards geht Deutsche Post Brief am weitesten: Das Unternehmen achtet darauf, in der Integrationsinfrastruktur nur J2EE-Standards zu verwenden und herstellerspezifische Erweiterungen zu vermeiden, um sich möglichst wenig an einen bestimmten Softwareanbieter zu binden. Die anderen Unternehmen verfolgen zumindest in Teilbereichen der Integrationsinfrastruktur die Strategie, die Integrationsplattform von einem Hersteller zu beziehen und auch herstellerspezifische Erweiterungen zu nutzen. Auch die lose gekoppelte Kommunikation zwischen Services ist in keiner Fallstudie durchgängig für alle Services umgesetzt. Zwar streben alle Unternehmen eine dynamische Serviceadressierung und eine statuslose Serviceinteraktion an, Service und Servicenutzer kommunizieren aber aus Performanzgründen häufig über synchrone Mechanismen.

4.6.5

Nutzenpotenziale und Herausforderungen

DPB

CS

T-Com

ZGKB

Tabelle 4-14 fasst die von den untersuchten Unternehmen mit SOA verfolgten Nutzenpotenziale zusammen. Wegen der fortgeschrittenen Umsetzung der SOA konnten Deutsche Post Brief, Credit Suisse und Zuger Kantonalbank die Nutzenpotenziale bereits im täglichen IT-Betrieb und in einzelnen Entwicklungsprojekten beobachten und dazu quantitative oder qualitative Aussagen machen. T-Com hingegen befindet sich noch in einem frühen Umsetzungsstadium, und die angestrebten Nutzenpotenziale sind noch nicht verifizierbar.

Reduzierte Betriebskosten durch Harmonisierung von Plattformen und Technologien sowie Konzentration der technischen Fähigkeiten









Senkung der Kosten für die Systemintegration durch technische und fachliche Schnittstellenstandardisierung







Senkung von Entwicklungs- und Betriebskosten durch Wiederverwendung und Redundanzreduktion









Kosten

SOA-Nutzenpotenziale

CS

T-Com

ZGKB

4 Fallbeispiele zu SOA

DPB

112

Verkürzung von Projektlaufzeiten und bessere Time-to-Market durch stärkere Wiederverwendung









Schnellere Entwicklung rollen- und zugangskanalspezifischer Benutzerschnittstellen









Schnellere Prozessanpassungen durch Trennung stabiler Geschäftslogik von dynamischer Prozesslogik







Bessere Transparenz über Abhängigkeiten bzw. Schnittstellen in der Applikationsarchitektur







Integrierte Prozesse und Investitionsschutz für bestehende Systeme durch plattformübergreifende Nutzung existierender Funktionen









Besser beherrschbare bzw. besser isolierte ITProjekte durch Domänen-Entkopplung







Klar geregelte Verantwortlichkeiten für Fachfunktionen und Daten







Bessere Kommunikation zwischen IT- und Fachbereichen dank einheitlicher Terminologie und einfachere Abbildung fachlicher Prozessmodelle in die Applikationsarchitektur









Qualität

Zeit

SOA-Nutzenpotenziale

 realisiert angestrebt gegenwärtig nicht angestrebt

Tabelle 4-14: Realisierte bzw. angestrebte Nutzenpotenziale Tabelle 4-15 ordnet die beobachteten Nutzenpotenziale den SOA-Zielen der Fallbeispiele zu (s. Kap. 4.6.2)

4.6 Erkenntnisse aus den Fallstudien Architekturziel

113 Verfolgte Nutzenpotenziale

SOA als standardisierte Integrationsinfrastruktur Dokumentierte und gemanagte Schnittstellen

• Bessere Transparenz über Abhängigkeiten bzw. Schnittstellen in der Applikationsarchitektur

Plattformübergreifende Integration und Technologiereduktion

• Senkung der Kosten für die Systemintegration durch technische und fachliche Schnittstellenstandardisierung

• Besseres Schnittstellenverständnis durch einheitliche Beschreibung

• Integrierte Prozesse und Investitionsschutz für bestehende Systeme durch plattformübergreifende Nutzung existierender Funktionen

SOA für die Entkopplung von Applikationsdomänen Lokale Begrenzung von Anpassungen in der Applikationsarchitektur

• Besser beherrschbare bzw. besser isolierte IT-Projekte durch Domänen-Entkopplung, Reduktion von Projektrisiken und Projektaufwänden

Hohe Wiederverwendung und Redundanzreduktion

• Senkung von Entwicklungs- und Betriebskosten durch Wiederverwendung und Redundanzreduktion

• Klar geregelte Verantwortlichkeiten für Fachfunktionen und Daten

• Verkürzung von Projektlaufzeiten und bessere Time-toMarket durch stärkere Wiederverwendung

SOA für eine flexible Benutzer- bzw. Geschäftsprozessintegration Ausrichtung von ITFunktionen an Geschäftsprozessen

• Bessere Kommunikation zwischen IT- und Fachbereichen dank einheitlicher Terminologie und einfachere Abbildung fachlicher Prozessmodelle in die Applikationsarchitektur • Schnellere Entwicklung rollen- und zugangskanalspezifischer Benutzerschnittstellen

Entkopplung von Prozess- und Systemanpassungen

• Schnellere Prozessanpassungen durch Trennung stabiler Geschäftslogik von dynamischer Prozesslogik: Änderungen an Geschäftsprozessen wirken sich weniger auf Services implementierende Applikationen aus und umgekehrt

Tabelle 4-15: SOA-Ziele und damit verfolgte Nutzenpotenziale Den Nutzenpotenzialen stehen erhebliche Mehraufwände gegenüber. Diese bestehen u.a. in Anfangsinvestitionen für die Definition und Durchsetzung neuer Governance-Strukturen, Prozesse und Standards oder in der Implementierung der technischen Integrationsinfrastruktur. Auch im laufenden Betrieb und in Entwicklungsprojekten entstehen Zusatzaufwände, etwa durch die Entwicklung wieder verwendbarer Services und zentrale Projekt-Reviews. Neben den dadurch anfallenden Kosten bestehen auch verschiedene organisatorische und technische Herausforderungen. Tabelle 4-16 fasst die in den Fallstudien beobachteten Herausforderungen und Erfolgsfaktoren bei der Umsetzung einer SOA zusammen.

114

4 Fallbeispiele zu SOA Herausforderungen

Erfolgsfaktoren

Identifikation und Design stabiler, wieder verwendbarer Services

• An Geschäftsstrategie und Geschäftsprozessen orientierte Abgrenzung fachlicher Applikationsdomänen und Konzentration auf domänenübergreifende Schnittstellen • Auf Prozessanalysen basierende Serviceidentifikation, Berücksichtigung der Anforderungen mehrerer potenzieller Service-Nutzer

Definition von Standards und Designprinzipien

• Beschränkung auf wesentliche Standards und Prinzipien und regelmässige Anpassung bzw. Erweiterung aufgrund von Projekterfahrungen • Definition von Messgrössen zur Bewertung der Architektur- und Service-qualität und kontinuierliche Überwachung

Aufbau notwendiger Governance-Strukturen und Durchsetzung von Standards und Designprinzipien in IT- und Fachbereichen

• Unterstützung der Massnahmen durch das TopManagement bzw. organisatorische Verankerung der SOA-Verantwortung auf Ebene Unternehmensleitung • Aufbau einer Support-Organisation zur Projektunterstützung • Frühzeitige, transparente Kommunikation von Zielen und strikte Projektkontrolle

Zeitliche Koordination organisatorischer und technischer Massnahmen bei der Einführung einer SOA

• Definition von aufeinander abgestimmten Entwicklungsstufen der Organisations- und Architekturentwicklung • Frühzeitiger Aufbau einer leistungsfähigen Entwicklungs- und Integrationsinfrastruktur

Tabelle 4-16: Herausforderungen und Erfolgsfaktoren einer SOA-Umsetzung 4.6.6

Massnahmen zur Einführung einer SOA

Die untersuchten Unternehmen haben ihre SOA schrittweise in mehreren Teilprojekten geplant und eingeführt. Dazu setzten sie organisatorische Massnahmen sowie Massnahmen im Architekturmanagement und der IS-Entwicklung um (s. Tabelle 4-17):

CS

T-Com

ZGKB

115

DPB

4.6 Erkenntnisse aus den Fallstudien







SOA-Ziele definieren









SOA überwachen und steuern







SOA-Architekturprinzipien formulieren









Domänenarchitektur entwickeln









Technische Integrationsarchitektur entwickeln







SOA-Prinzipien in Fachprojekten kommunizieren







Projektunterstützung und -review







Zentrale Integrations- und Entwicklungsinfrastruktur entwickeln







Services identifizieren









Services entwickeln und nutzen









Aktivitäten bei der Einführung der SOA

Organisation Neue Architekturrollen und Verantwortlichkeiten festlegen Architekturmanagement Architekturführung

Architekturentwicklung

Architekturkommunikation und -vertretung

IS-Entwicklung

 ausgeführt teilweise ausgeführt nicht ausgeführt

Tabelle 4-17: Massnahmen zur Einführung der SOA •

In einem ersten Schritt verankerten die Unternehmen die Umsetzung der SOA in der IT-Organisation. Sie definierten dazu neue Architekturrollen und Verantwortlichkeiten, bzw. erweiterten die Aufgaben und Kompetenzen bestehender Rollen. Deutsche Post Brief bildete dazu den zentralen Bereich SOPGroup, T-Com einen ESB- / SOA-Ausschuss und ein SOA Solution Center. Auch Credit Suisse definierte Verantwortliche für die Projektunterstützung oder die Entwicklung und den Betrieb der Integrationsinfrastruktur im zentralen IT-Bereich.

•

Aufgrund von Situations- und Potenzialanalysen bestimmten die Architekturverantwortlichen anschliessend die Ziele und Einsatzbereiche der SOA (s. Kap. 4.6.2).

116

4 Fallbeispiele zu SOA

•

Die laufende Überwachung und Steuerung der SOA anhand von Kennzahlen war besonders im Fallbeispiel Credit Suisse ausgeprägt. Auch Deutsche Post Brief erhob gewisse Metriken (z.B. Änderungshäufigkeit von Schnittstellen oder Wiederverwendungsgrad) zur Messung der Architekturqualität. Bei ZGKB existierte keine projektübergreifende SOA-spezifische Architekturüberwachung, bei T-Com befand sich diese zum Zeitpunkt der Fallstudienerhebung noch im Aufbau.

•

SOA-Ziele bildeten die Grundlage zur Formulierung von SOA-Architekturprinzipien. Diese machen zentrale fachliche und technische Vorgaben für die Entwicklung und Nutzung von Services und der Integrationsinfrastruktur (s. Kap. 4.6.4). Beispiele umfassen Namenskonventionen bei Servicebeschreibung, standardisierte Datenmodelle oder Vorgaben für die Verwendung der technischen Integrationsinfrastruktur.

•

Mit der Entwicklung einer Domänenarchitektur strukturierten die Unternehmen die Applikationsarchitektur aus fachlicher Sicht und unterstützten damit Zuständigkeits- und Kopplungsentscheidungen: Domänengrenzen bestimmen, wo Applikationen lose gekoppelt über Services zu integrieren sind und wo alternative Kopplungsmechanismen zulässig sind. Die Entwicklung einer Domänenarchitektur war bei ZGKB zwar nicht Bestandteil des beschriebenen Projekts, es baute aber auf der bestehenden Domänenarchitektur der Bankenplattform auf.

•

Bis auf ZGKB implementierten alle Unternehmen eine zentrale technische Integrationsinfrastruktur auf Service-Ebene. Diese vereinheitlicht Serviceschnittstellen, bietet zentrale Integrationsdienste (Verzeichnisdienst, MessageBus etc.) und bildet damit die Grundlage für eine einfache plattformunabhängige Nutzung von Services. Im Rahmen der Entwicklung der technischen Integrationsarchitektur trafen sie dabei Entscheidungen bezüglich der zu unterstützenden Middleware- und Entwicklungsdienste sowie der einzusetzenden Plattformen, Produkte und Standards. Während Unternehmen die früh mit der SOA-Umsetzung begonnen haben in der Vergangenheit ihre Integrationsinfrastruktur aus Produkten mehrerer Hersteller zusammenstellten, geht der Trend heute stärker in Richtung Verwendung einer umfassenden SOAPlattform eines Herstellers (z.B. IBM WebSphere, SAP NetWeaver).

•

Wegen des geringen Projektumfangs und des kleinen Projektteams führte die Zuger Kantonalbank keine speziellen SOA-spezifischen Schulungs- und Projektreview-Massnahmen durch. In den anderen Unternehmen kommunizierten Vertreter aus der zentralen Architektur die SOA-Architekturprinzipien in Fachprojekten und bildeten Projektbeteiligte in der Nutzung der technischen SOA-Infrastruktur aus. Formalisierte Reviewprozesse stellen sicher, dass ISProjekte, welche Services entwickeln oder nutzen, die SOA-Architekturprinzipien korrekt anwenden.

•

Vorgaben der technischen Integrationsarchitektur setzten Deutsche Post Brief, Credit Suisse und T-Com in IS-Projekten zur Entwicklung einer zentralen Integrations- Entwicklungsinfrastruktur für Services um. Zuger Kantonalbank führte dazu kein spezifisches Projekt durch, sondern verwendete die vorhan-

4.7 Zusammenfassung

117

denen Middlewaredienste der Swiss Banking Plattform für die Serviceentwicklung und Serviceintegration. •

Alle Fallbeispiele entwickelten und nutzten Services in fachlich getriebenen Applikationsentwicklungs- und Integrationsprojekten. Die Unternehmen sind aber bei der initialen Identifikation von zu entwickelnden Services unterschiedlich vorgegangen: Während Credit Suisse und ZGKB pro (domänenübergreifendem) Fachprojekt bestimmten, ob eine Schnittstelle als Service umgesetzt werden soll oder nicht, identifizierten Deutsche Post Brief oder TCom die Services vorausplanend pro Applikationsdomäne. Wie bspw. das Fallbeispiel Credit Suisse gut zeigt, bestehen zwischen den Aktivitäten im projektübergreifenden Architekturmanagement und der projektspezifischen Serviceentwicklung Abhängigkeiten: Das Architekturmanagement macht u.a. mittels Designprinzipien Vorgaben für das Servicedesign; umgekehrt sollten diese Designprinzipien aufgrund der Erfahrungen aus den Entwicklungsprojekten periodisch angepasst werden.

4.7

Zusammenfassung

Die Fallstudien zeigten die drei Einsatzziele standardisierte Integrationsinfrastruktur, Entkopplung von Appliktionsdomänen und flexible Benutzer- bzw. Geschäftsprozessintegration. Die Unternehmen gewichten die SOA-Ebenen und die Designprinzipien je nach Ausgangslage und Zielsetzung unterschiedlich. Obwohl einige der untersuchten Unternehmen bereits seit mehreren Jahren an der Umsetzung der SOA arbeiten, hat keines sämtliche Ebenen ausgeprägt und alle Nutzenpotenziale realisiert. Insbesondere die flexible Komposition und Orchestrierung von Services auf Ebene Workflow- und Desktopintegration – in der Literatur oft als eines der Hauptpotenziale von SOA aufgeführt – wollen die meisten Unternehmen erst in Zukunft angehen. Die Fallstudien liefern auch Hinweise dafür, welche Massnahmen für die Umsetzung einer SOA zu treffen sind, was die Herausforderungen sind und welche Handlungsoptionen bestehen. Das folgende Kapitel vertieft diese Inhalte.

5 Architekturmanagement und Servicedesign Auf Basis der Fallstudien von Kap. 4 sowie anhand zusätzlicher Quellen aus der Literatur erläutert das folgende Kapitel verschiedene der identifizierten Massnahmen zur Einführung einer SOA. Der Fokus liegt auf den Bereichen des Architekturmanagements und der IS-Anwendungsentwicklung, in denen SOA-spezifische Neuerungen einzuführen sind. Ziel ist, Handlungsanweisungen für ihre Umsetzung zu liefern, die auf bestehenden Methoden bzw. Techniken aufsetzen und diese erweitern. Abb. 5-1 gibt einen Überblick über die diskutierten Massnahmen und ihre Zusammenhänge. Kap. 5.1 behandelt die SOA-Zieldefinition, das Fomulieren von Architekturprinzipien und die SOA-Steuerung. Es konzentriert sich dabei auf die zielspezifische Gewichtung der SOA-Designprinzipien und formuliert Metriken bzw. Qualitätsindikatoren für ihre Messung. Kap. 5.2 diskutiert Ansätze und Kriterien für die Entwicklung einer Domänenarchitektur. Kap. 5.3 beschreibt Ansätze für die Identifikation und das Design von Services im Rahmen der Anwendungsentwicklung. Schliesslich geht Kap. 5.4 auf neue Architekturrollen und ihre Aufgaben bei der SOA-Einführung ein. Prozessarchitektur als Grundlage für die Domänenarchitektur

Prozessentwurf

Architekturmanagement SOA-Ziele, Architekturprinzipien und Architektursteuerung (Kap. 5.1)

IS-Entwicklung Vorgaben für das Servicedesign Messwerte und Umsetzungserfahrungen

Serviceidentifikation und Servicedesign (Kap. 5.3)

Vorgaben für die Domänenabgrenzung

Entwicklung der Domänenarchitektur (Kap. 5.2)

Prozessmodelle als Grundlage für die Serviceidentifikation

Vorgaben für die Serviceidentifikation

Verantwortung für Aktivitäten

Architekturrollen und Verantwortlichkeiten (Kap. 5.4)

Organisation

Abb. 5-1: Behandelte Massnahmen und ihre Zusammenhänge Die beschriebenen Massnahmen orientieren sich an einen geschäftsgetriebenen, von der Unternehmensstrategie und den Geschäftsprozessen ausgehenden Vorgehen, wie es das Business Engineering Modell (s. Kap. 2.2) vorsieht. Dabei stellt besonders der Prozessentwurf [s. Österle 1995, 35ff.] eine wichtige Voraussetzung dar. Er liefert mit der unternehmensweiten Prozessarchitektur eine Grundlage für die Entwicklung der Domänenarchitektur und mit detaillierten fachlichen

120

5 Architekturmanagement und Servicedesign

Prozessmodellen eine Grundlage für die Identifikation von Services in der Anwendungsentwicklung.

5.1

SOA-Ziele, Architekturprinzipien und Architektursteuerung

Wichtige Aufgaben beim Einführen einer SOA sind das Formulieren von Architekturprinzipien und das Überwachen ihrer Einhaltung in Applikationsentwicklungs- und Integrationsprojekten. Architekturprinzipien stellen Leitkriterien für die Entwicklung und Implementierung des IS dar und stellen sicher, dass in dezentralen Projekten entwickelte Services architekturkonform sind und die erwünschte Qualität aufweisen (s. [Schwinn 2006a, 161], [Richter et al. 2005, 415]). Im Vordergrund dieses Kapitels stehen die Designprinzipien zur Gestaltung von SOA und Services, wie sie Kap. 3.3 herleitete. Die Fallbeispiele in Kap. 4 zeigten, dass nicht alle Prinzipien für jeden Einsatzzweck einer SOA zwingend sind und einzelne Prinzipien sogar gewissen Zielen entgegen wirken.17 Ausserdem erhöhen zu viele Prinzipien den Aufwand für das Entwickeln und Testen von Services. Die Architekturverantwortlichen sollten deshalb nur Designprinzipen formulieren, die einen klaren Bezug zu den SOA-Zielen haben und diese gemäss den spezifischen Anforderungen des Unternehmens priorisieren (s. [Bieberstein et al. 2005a, 70], [Hafner 2005, 214]). Die Designprinzipien sind ausserdem mit konkreten Metriken bzw. Qualitätsindikatoren zu operationalisieren, so dass sie die Bewertung einzelner Services und der SOA insgesamt im Rahmen von Projekt- und Architekturreviews zu unterstützen [s. Schwinn 2006a, 185]. Zur Messung der Qualitätseigenschaften von Informationssystemen sind im Informationsmanagement Factor-Criteria-Metrics-Modelle (FCM) verbreitet, die aus Qualitätszielen Merkmale (factors) ableiten, in Teilmerkmale (criterias) verfeinern und über Qualitätsindikatoren (metrics) messbar machen (s. [Balzert 1998, 257ff.], [Heinrich/Lehner 2005, 500]). Während verschiedene generische Qualitätsmodelle für die Bewertung der Software- oder IS-Architekturqualität existieren, sind spezifisch für SOA ausgeprägte Modelle in der Literatur bisher kaum vorhanden. Die folgenden Abschnitte beschreiben bestehende Qualitätsmodelle zur Bewertung einer SOA (Kap. 5.1.1) und machen anschliessend einen am FCM-Modell orientierten Vorschlag zur Priorisierung von SOA-Designprinzipien und ihrer Operationalisierung für die Architektursteuerung und -überwachung (s. Abb. 5-2):

17

Bspw. kann eine lose gekoppelte, asynchrone Kommunikation zu langen Antwortzeiten führen (s. Kap. 3.3.3) oder eine grobe Servicegranularität die Wiederverwendbarkeit und Stabilität eines Services reduzieren (s. Kap. 3.3.4).

5.1 SOA-Ziele, Architekturprinzipien und Architektursteuerung

SOA-Ziele

Qualitätsmerkmale (Designprinzipien)

Indikatoren / Metriken

Plattformübergreifende Integration

...

Qualitativ, z.B. Kommunikationsart (Schnittstellenkopplung / Datenkopplung)

121

Hohe Wiederverwendung / Redundanzreduktion

Abstraktion von der Serviceimplementierung

Quantitativ, z.B. Anzahl öffentlicher Operationen einer Serviceschnittstelle

Stabile, gemanagte Servicekontrakte

Qualitativ, z.B. Existenz von SLAs mit Angaben zu Releasezyklen

…

...

Quantitativ, z.B. Änderungshäufigkeit einer Serviceschnittstelle

Abb. 5-2: SOA-Ziele, Designprinzipien und Qualitätsindikatoren Ausgangspunkt bildet eine Potenzialanalyse zum Bestimmen der mit SOA verfolgten Architekturziele, anhand derer die zu berücksichtigenden Designprinzipien priorisiert werden (Kap. 5.1.2). Diese Designprinzipien dienen als Architekturqualitätsmerkmale. Qualitätsindikatoren (Kap. 5.1.3) erlauben es, die Einhaltung der Designprinzipien in Projekt- und Architekturreviews zu überprüfen (Kap. 5.1.4). Sie konzentrieren sich dabei auf SOA-spezifische Merkmale; für eine umfassende Architekturbewertung sind zusätzlich allgemeine Indikatoren für die Systemqualität (Sicherheit, Verfügbarkeit, Performanz etc., [s. O'Brien et al. 2005]) und Kennzahlen zur Messung weiterer, übergeordneter Architekturziele [s. z.B. Schwinn/ Winter 2005] zu berücksichtigen.

5.1.1

Bestehende Qualitätsmodelle zur Bewertung von SOA

Es existiert eine Reihe generischer Qualitätsmodelle für die Bewertung der Software- oder IS-Architekturqualität. Beispiele sind etwa die DIN ISO/IEC 9126Norm, welche die sechs Qualitätskriterien „Funktionalität“, „Zuverlässigkeit“, „Benutzbarkeit“, „Effizienz“, „Änderbarkeit“ und „Übertragbarkeit“ definiert [s. Balzert 1998, 259f.], oder Qualitätsmerkmale und Kennzahlen, wie sie die Control Objectives for Information and Related Technology (CobiT, [s. ITGI 2005]) oder das Capability Maturity Model (CMM, [s. Paulk et al. 1993]) formulieren. Sie beschreiben zwar Qualitätseigenschaften, die auch in einer SOA zu berücksichtigen sind, liefern aber keine spezifischen Merkmale und Masse, die eine Prüfung der Qualität konkreter Services oder Domänenarchitekturen unterstützen würden. [O'Brien et al. 2005] definieren eine Reihe von Architekturqualitätsmerkmalen und untersuchen ihre Ausprägung für eine SOA. Sie nennen allerdings kaum konkrete Qualitätsindikatoren und nehmen eine Bewertung von SOA als Architekturstil insgesamt vor. Der Vorschlag eignet sich nur beschränkt zur Bewertung alternativer Ausprägungen von SOA und Services. Eine Grundlage für die Formulierung von Qualitätsmerkmalen je nach Ziel einer SOA bildet der Beitrag von [Dietzsch/Goetz 2005]. Die Autoren definieren anhand von typischen SOA-Zielen sechs aufeinander aufbauende Nutzenstufen der

122

5 Architekturmanagement und Servicedesign

Serviceentwicklung.18 Für jede Nutzenstufe beschreiben sie Anforderungen an das Servicedesign, mögliche Einschränkungen und Freiheitsgrade sowie Beispiele für Entwurfsmuster. Sie formulieren allerdings keine konkreten Messgrössen zur Bewertung der Ausprägung der Designprinzipien. [Schwinn/Winter 2005] entwickeln ein Qualitätsmodell zur Steuerung der Applikationsintegration, das sich auf die Bewertung einer SOA auf Ebene Gesamtsystem, also zur Bewertung der Domänenarchitektur und der Integrationsinfrastruktur, übertragen lässt. Anhand der strategischen Oberziele „optimale Integration von Applikationen“ und „Agilität des Informationssystems“ leiten sie fünf Teilziele der Applikationsintegration ab und definieren mögliche Messgrössen. Die Prinzipien des serviceorientierten Systemdesigns weisen Ähnlichkeiten mit Designprinzipien der objekt- und besonders der komponentenorientierten Systementwicklung auf. Aus diesem Grund können zur Bewertung von Services gewisse Messgrössen dieser Entwurfsmethoden übernommen werden [s. Vinoski 2005, 72]. Bspw. machen [Perepletchikov et al. 2005] Vorschläge für die Anpassung der Metriken für objektorientierte Systeme von [Chidamber/Kemerer 1994] auf die Bewertung von Services. Schwierigkeiten bei der Übertragung objektorientierter Qualitätsmodelle entstehen bei Messgrössen, die auf Konzepten basieren, welche kein Äquivalent im serviceorientierten Design besitzen (z.B. Vererbung zwischen Klassen). Weiter setzen viele Messgrössen für objekt- und komponentenorientierte Systeme einen Einblick in den Quellcode der Softwareimplementierung voraus. Dies ist bei Services, die eingekaufte Standardsoftware oder monolithische Altsysteme kapseln können, nicht immer möglich. Kennzahlensysteme aus der objektund komponentenorientierten Systementwicklung lassen sich deshalb nur beschränkt auf SOA übertragen.

5.1.2

Priorisieren der Designprinzipien anhand der SOA-Ziele

Um SOA-Designprinzipien sinnvoll priorisieren zu können, müssen die Architekturverantwortlichen in einem ersten Schritt die mit SOA zu erreichenden Ziele definieren. Ausgangslage dafür ist eine Potenzialanalyse. Sie hilft beim Bestimmen von Bereichen der Prozess- und Systemarchitektur, die am stärksten von einer SOA profitieren, und identifiziert den Beitrag von SOA zur Erreichung der übergeordneten Unternehmens- und IT-Ziele. Ein Hilfsmittel für eine Potenzialanalyse sind Heuristiken, die Anhaltspunkte dafür geben, in welchen Situationen eine SOA Nutzen stiften kann und unter welchen Umständen Services nicht angebracht sind. Aufgrund der Erfahrungen bei der Einführung einer SOA nennen bspw. [Dietzsch/Goetz 2005] und [SAP 2005b] generische Prozess- und Applikationsindikatoren, die auf Potenziale einer serviceorientierten Systementwicklung bzw. Applikationsintegration hinweisen. Andererseits nennen [Adams 2005] oder [Bloomberg 2004b] Indikatoren, die gegen eine SOA sprechen (s. Tabelle 5-1). Weitere Indikatoren für SOA-Potenziale liefern 18

Die definierten Nutzenstufen sind „Qualität“, „Integration“, „Evolution“, „Standardisierung“, „Flexibilität“ und „Wiederverwendbarkeit“.

5.1 SOA-Ziele, Architekturprinzipien und Architektursteuerung

123

die Treiber und Nutzenpotenziale einer SOA-Einführung aus den Fallstudien (s. Kap. 4.6.2 und 4.6.5). Architekturverantwortliche können solche Indikatoren im Rahmen der Analyse bestehender Prozesse und Systeme verwenden. Indikatoren für Potenziale einer SOA (vgl. [Dietzsch/Goetz 2005], [SAP 2005b,]) • Häufig ausgeführte Prozesse mit hohen Durchlaufzeiten oder Ausführungskosten: Sollten auf Potenziale für eine stärkere Automatisierung durch Serviceschnittstellen untersucht werden. • Ein Geschäftsprozess kann nicht so weit standardisiert werden, dass er den Grossteil der Geschäftsfälle abdeckt, oder es existieren mehrere Prozessvarianten mit gemeinsamen stabilen Elementen: Services können stabile Funktionen und Daten kapseln und eine flexible Orchestrierung unterstützen. • Ein Geschäftsprozess greift auf viele Applikationen zu: Services können Schnittstellen vereinheitlichen und eine standardisierte Sicht auf Geschäftsentitäten realisieren. • Von Nutzern benötigte Informationen sind in mehreren Applikationen verteilt bzw. Informationen werden manuell transformiert: Services können die Benutzerproduktivität durch Entwicklung rollenspezifischer, integrierter Arbeitsoberflächen erhöhen. • Prozesse verwenden unternehmensexterne Datenquellen: Services können die Transformation und Vereinheitlichung interner und externer Datenformate unterstützen. • Standardsoftware ist stark angepasst bzw. durch eigenen Code erweitert: Services bieten Potenzial, Erweiterungen als Composite Application zu implementieren. • Applikationen sind im Unternehmen redundant implementiert und tauschen untereinander Daten aus: Services erleichtern eine Wiederverwendung und bieten Potenziale für die Entwicklung einer gemeinsamen Lösung (Shared Service). Indikatoren gegen Potenziale einer SOA (vgl. [Adams 2005], [Bloomberg 2004b]) • Geschäftsprozesse sind überwiegend stabil und es besteht nur geringes Potenzial für eine weitere Automatisierung. • Die Applikationsarchitektur ist technisch und fachlich überwiegend homogen: Die Applikationsentwicklung erfolgt auf einer einheitlichen Plattform und nach einem einheitlichen Programmiermodell bzw. Prozesse werden durch Applikationen eines oder weniger Anbieter unterstützt. • Kosten für die Systemintegration machen einen kleinen Anteil des IT-Budgets aus. • Geschäftsprozesse verlangen hochvolumige, synchrone Echtzeit-Transaktionen: Services können durch höhere Netzwerkbelastung und Daten- und Protokolltransformationen zu Performanzproblemen führen. • Das Know-how und die Ressourcen für den Aufbau und Betrieb einer SOAIntegrationsinfrastruktur sind im Unternehmen nicht vorhanden. • Die notwendige Managementunterstützung zur Einführung einer SOA fehlt.

Tabelle 5-1: Indikatoren für oder gegen Potenziale einer SOA Die in der Potenzialanalyse definierten Architekturziele bilden die Grundlage für das unternehmensindividuelle Priorisieren der SOA-Designprinzipien. Tabelle 5-2 zeigt eine entsprechende Priorisierung für die in den Fallstudien identifizierten Ziele.

+

Ausrichtung von IT-Funktionen an Geschäftsprozessen

Entkopplung von Prozess- und Systemanpassungen

Abstraktion von der Serviceimplementierung Umfassende, einheitliche Servicespezifikation Stabile, gemanagte Servicekontrakte Technische Schnittstellenstandardisierung Fachliche Schnittstellenstandardisierung Verwendung offener und verbreiteter Industriestandards Hohe Servicekohäsion und schwache logische Kopplung Lose gekoppelte Kommunikation An Geschäftskonzepten orientierte, grobe Servicegranularität

Wiederverwendung und Redundanzreduktion

Designprinzip

Begrenzung von Anpassungen in der Applikationsarchitektur

Ziel

Plattformübergreifende Integration und Technologiereduktion

5 Architekturmanagement und Servicedesign

Dokumentierte und gemanagte Schnittstellen

124

+

+

+

+

+

+

+

+ +

+

+

+

+ + +

+

+ +

+

+ +

+

+

+

+ -/+19

+

+

Legende: + = unterstützender Einfluss, - = schwächender Einfluss, leer = wenig Einfluss

Tabelle 5-2: SOA-Ziele und unterstützende Designprinzipien Dokumentierte und gemanagte Schnittstellen Typische Treiber für dieses Ziel sind ein mangelhafter Überblick über Schnittstellen in der Applikationsarchitektur oder eine schlechte Dokumentationsqualität von Schnittstellen. Von Bedeutung sind hier besonders Designprinzipien, die zu einer einheitlichen Mindestqualität von Schnittstellenspezifikationen führen [s. Dietzsch/Goetz 2005, 1526]. Erreicht wird dies durch eine konsequente technische und fachliche Servicespezifikation und durch ihre Dokumentation in einem zentralen Serviceverzeichnis über klar definierte Publikationsprozesse.

19

Wie in Kap. 3.3.4 beschrieben, müssen hier zwei Granularitätsmasse unterschieden werden: Während eine grobe Funktionsgranularität zu höherer Servicespezifität und dadurch geringerer Wiederverwendbarkeit führen kann, fördert eine grobe Schnittstellengranularität die potenzielle Wiederverwendbarkeit eines Services.

5.1 SOA-Ziele, Architekturprinzipien und Architektursteuerung

125

Plattformübergreifende Integration und Technologiereduktion Der parallele Einsatz technisch inkompatibler Plattformen oder eine Vielfalt an Integrationstechnologien können Treiber für dieses Ziel sein. Im Vordergrund steht hier die Einführung einer zentralen Integrationsinfastruktur für eine einfachere plattformübergreifende Integration und eine Technologieharmonisierung. Wesentliche SOA-Designprinzipien sind die Abstraktion von internen Aspekten der Serviceimplementierung, eine einheitliche plattform- und middlewareneutrale Schnittstellenbeschreibung sowie die technische Schnittstellenstandardisierung (s. [Dietzsch/Goetz 2005, 1527], [Dodd 2005d, 12]). Die Verwendung verbreiteter technischer Industriestandards wie Web Services erhöht ausserdem die Interoperabilität zwischen Plattformen unterschiedlicher Anbieter (s. [Newcomer/Lomow 2004], [O'Brien et al. 2005, 8]). Begrenzung von Anpassungen in der Applikationsarchitektur Treiber für dieses SOA-Ziel sind Abhängigkeiten zwischen logisch bzw. fachlich verschiedenen Funktionen in der Applikationsarchitektur. Wiederkehrende Änderungen, die nur einen kleinen Architekturbereich betreffen, lösen umfangreiche und komplexe Projekte aus. Die sinnvolle Modularisierung von Fachlogik und Daten durch die Definition von Applikationsdomänen und Services mit hoher Kohäsion, schwacher logischer Kopplung und stabilen Schnittstellen ist die wichtigste Massnahme dafür, dass sich fachlich getriebene Anpassungen nur in begrenzten Bereichen der Applikationsarchitektur auswirken (s. [O'Brien et al. 2005, 21], [Newcomer/Lomow 2004, 80], [Schlamann 2004, 7]). Auch die Abstraktion von der Serviceimplementierung zur Reduktion der Abhängigkeiten zwischen Services und Servicenutzern auf Schnittstellenebene unterstützt dieses Ziel [s. Newcomer/Lomow 2004, 75]. Eine lose gekoppelte Kommunikation mit dynamischer Service-Adressierung kann Anpassungen bei Servicenutzern verhindern, wenn ein identischer Service durch einen anderen Serviceanbieter erbracht werden soll [s. O'Brien et al. 2005, 18]. Wiederverwendung und Redundanzreduktion Eine höhere Wiederverwendung von Funktionen und Daten durch SOA streben Unternehmen an, wenn Redundanzen in der Applikationsarchitektur zu hohem Betriebs- oder Anpassungsaufwand, mangelhafter Datenqualität oder unklaren organisatorischen Zuständigkeiten für gemeinsame Daten und Funktionen führen. Zentral sind hier die Generalisierung und geringe Prozessspezifität der Serviceleistung, eine hohe Schnittstellenstabilität sowie Massnahmen, welche die Integration und Verwendung von Services durch potenzielle Nutzer so weit als möglich vereinfachen (s. [Schwinn/Winter 2005, 596], [Newcomer/Lomow 2004, 89]). Die Nutzung wird dann vereinfacht, wenn Services klar definierte Aufgaben übernehmen (hohe Servicekohäsion), einheitlich beschrieben sowie technisch und fachlich standardisiert sind und möglichst stark von ihrer Implementierung abstrahieren (s. [Dietzsch/Goetz 2005, 1531], [Erl 2005, 312], [Newcomer/Lomow 2004, 88f.]). Die Verwendung etablierter Industriestandards vergrössert den potenziellen Nutzerkreis insbesondere im zwischenbetrieblichen Bereich (s. [Dodd 2005c, 29], [Newcomer/Lomow 2004, 78]). Eine grobe Funktionsgranularität reduziert die

126

5 Architekturmanagement und Servicedesign

Wiederverwendbarkeit eines Services tendenziell, während eine grobe Schnittstellengranularität die Anzahl möglicher Nutzer erhöht. Ausrichtung von IT-Funktionen an Geschäftsprozessen Eine bessere Ausrichtung von IT-Funktionen an Prozessanforderungen und eine einfachere Kommunikation zwischen Fachbereichen und IT verfolgen Unternehmen, wenn die von Anwendungen zur Verfügung gestellten Funktionen, Daten oder Bildschirmmasken nicht den Anforderungen der Nutzer entsprechen bzw. wenn sich fachliche Prozessmodelle nur schwer auf Funktionsschnittstellen in der Applikationsarchitektur abbilden lassen. Dieses Ziel unterstützen u.a. eine umfassende Servicebeschreibung, die Abstraktion von der technischen Serviceimplementierung und die Verwendung einer einheitlichen fachlichen Terminologie. Wenn sich Serviceleistungen an Geschäftskonzepten, d.h. Aktivitäten aus Geschäftsprozessen und Geschäftsentitäten, orientieren, vereinfacht dies ausserdem die Abbildung fachlich modellierter Prozesse auf Services [Newcomer/Lomow 2004, 77]. Entkopplung von Prozess- und Systemanpassungen Eine enge Verknüpfung von Präsentations-, Ablaufsteuerungs- und Fachlogik in monolithischen Applikationen und unterschiedliche Lebenszyklen von Prozessen und unterstützenden Anwendungen sind typische Treiber für dieses Ziel. Eine flexible Anpassung von Geschäfts- bzw. Benutzerprozessen wird durch Massnahmen gefördert, welche die Komposition von Services zu Geschäftsprozessen vereinfachen. Diese Massnahmen umfassen die Abstraktion von der Serviceimplementierung, die klare Spezifikation von Abhängigkeiten zwischen Services und von SLA-Eigenschaften in der Servicebeschreibung sowie die Definition von technischen und semantischen Standards für die Servicekommunikation [s. Dietzsch/Goetz 2005, 1534]. Die prozessorientierte Komposition wird weiter vereinfacht durch eine an Geschäftskonzepten orientierte Servicegranularität, eine starke Servicekohäsion bzw. schwache logische Kopplung sowie durch statuslos interagierende Services, die komplette Transaktionen kapseln und kompensierende Transaktionen bieten (s. [Erl 2005, 317], [O'Brien et al. 2005, 21]).

5.1.3

Indikatoren für die Architekturqualität

Nach der Definition der SOA-Ziele und der Priorisierung von SOADesignprinzipien müssen die Architekturverantwortlichen Messgrössen definieren, welche sie zur Bewertung der Umsetzung der Designprinzipien verwenden können. Im Folgenden werden Vorschläge für mögliche Qualitätsindikatoren aufgeführt. Diese bauen auf Erfahrungen aus den Fallstudien und Ansätzen aus der Literatur (s. Kap. 5.1.1) auf. Als Überblick zeigt Tabelle 5-3 eine Zuordnung der Indikatoren zu den Designprinzipien.

5.1 SOA-Ziele, Architekturprinzipien und Architektursteuerung Nr.

Designprinzip / Qualitätsmerkmal

127 Qualitätsindikatoren

1

Abstraktion von der Serviceimplementierung

EZ: S1 NZ: S2, S5, G1

2

Umfassende, einheitliche Servicespezifikation

EZ: S3 NZ: S4

3

Stabile, gemanagte Servicekontrakte

NZ: S2, S5, G2

4

Technische Schnittstellenstandardisierung

EZ: G3, G4 NZ: G5

5

Fachliche Schnittstellenstandardisierung

EZ: G6 NZ: G7

6

Verwendung offener, verbreiteter Industriestandards

EZ: G8

7

Hohe Servicekohäsion, schwache logische Kopplung

EZ: S6, S7, S8, G9, G10, G11 NZ: S5, G1

8

Lose gekoppelte Kommunikation

NZ: G12

9

An Geschäftskonzepten orientierte Servicegranularität

EZ: S9, S10 NZ: S11, S12, G13

10

Generalisierung der Serviceleistung

EZ: S5, S13 NZ: S12, G13, G14

EZ: Erhebung zur Entwicklungszeit, NZ: Erhebung zur Nutzungs- bzw. Betriebszeit S: Indikatoren zur Bewertung einzelner Services, G: Indikatoren auf Ebene Gesamtarchitektur

Tabelle 5-3: Überblick über Qualitätsindikatoren der SOA-Designprinzipien Tabelle 5-4 beschreibt Indikatoren auf Ebene Einzelservice (S), die Aussagen zur Qualität des Designs einzelner Services erlauben. Sie unterstützen die Qualitätssicherung bei einzelnen Serviceentwicklungsprojekten. Tabelle 5-5 nennt Indikatoren auf Ebene Gesamtarchitektur (G) zur Bewertung der Qualität der Gesamtheit aller Services, der Domänenarchitektur oder der Integrationsinfrastruktur in der SOA. Sie können in periodischen Architekturreviews erhoben werden. Die Tabellen enthalten zu den Indikatoren jeweils eine kurze Erläuterung und, wo möglich, Zielwerte. Dabei ist zu beachten, dass sich komplexe Eigenschaften wie z.B. die Kohäsion eines Services nicht immer in quantitativen Grössen ausdrücken und berechnen lassen [s. Balzert 1998, 478]. Selbst wenn sich ein Qualitätsmerkmal quantitativ erfassen lässt, fehlen häufig Erfahrungswerte für die Interpretation der Messgrösse [s. Schwinn/Winter 2005, 596]: So lässt sich z.B. die Stabilität einer Serviceschnittstelle anhand der Anzahl Anpassungen pro Zeitperiode oder die Eignung der Servicegranularität und -generalisierung über die Gesamtzahl der publizierten Services bestimmen, es existieren aber bisher keine allgemeinen Erkenntnisse über Idealwerte für diese Grössen. Vergleiche von Werten über mehrere Services oder über Benchmarking-Studien mit anderen Unternehmen können in solchen Fällen Anhaltspunkte liefern, ob ein Wert „gut“ oder „schlecht“ ist.

128

5 Architekturmanagement und Servicedesign

Indikator Ebene Einzelservice

Erläuterung und Zielwerte

S1

Kommunikationsart

Ein Servicenutzer sollte einem Service möglichst nur Daten übergeben (Datenkopplung), keine Steuerungsinformationen, die Kenntnisse über interne Datenstrukturen bzw. Algorithmen des Services voraussetzen (Steuerungskopplung) [s. Balzert 1998, 524].

S2

Änderungshäufigkeit der Serviceschnittstelle bei Änderungen an der Serviceimplementierung

Eine hohe Anzahl Schnittstellenanpassungen bei Änderungen an der Serviceimplementierung deutet auf eine mangelhafte Schnittstellenabstraktion hin. Es sind keine allgemeinen Richtwerte für dieses Mass bekannt. Eine Bewertung kann durch Benchmarking erfolgen.

S3

Vollständigkeit der Servicespezifikation

Bewertung der Vollständigkeit anhand der Elemente einer umfassenden Servicespezifikation: Services sollten auf der Schnittstellenebene, der Verhaltens- und Informationsebene, der Abstimmungsebene, der Aufgaben- und Terminologieebene, der Qualitätsebene sowie der Vermarktungsebene beschrieben sein (s. Kap. 3.3.1).

S4

Anzahl Rückfragen durch Servicenutzer

Häufige Rückfragen durch Servicenutzer bei Serviceverantwortlichen im Rahmen der Wiederverwendung von Services in Entwicklungsprojekten können auf eine mangelhafte Spezifikation hinweisen (Benchmarking).

S5

Durchschnittliche Lebensdauer einer Serviceversion

Sollte möglichst hoch sein. Kurze Releasezyklen können auf eine mangelhafte Abstraktion, eine mangelhafte Kohäsion, eine zu grosse Funktionsgranularität oder eine mangelhafte Servicegeneralisierung hinweisen (Benchmarking).

S6

Kohäsionsgrad

Bestimmung des Kohäsionsgrades anhand der Merkmale in Kap. 3.3.3. Geeignete Kohäsionsgrade für Services sind eine funktionale, eine kommunikative oder eine sequenzielle Kohäsion [s. Vinoski 2005, 74].

S7

Anzahl Serviceoperationen

Eine grosse Anzahl Serviceoperationen kann auf einen zu breiten Leistungsumfang des Services hinweisen (Benchmarking).

S8

„Response For a Class (RFC)“

[Perepletchikov et al. 2005] übertragen zur Bestimmung der Kopplungsintensität zwischen Services das entsprechende Mass von [Chidamber/Kemerer 1994, 487]. Es berechnet die Menge aller Operationen, die potenziell mit dem Senden einer Nachricht an einen Service aufgerufen werden können. Sie setzt sich zusammen aus der Anzahl der vom Service angebotenen Operationen plus aller von diesen aufgerufenen Operationen anderer Services. Hohe Werte deuten auf eine enge Kopplung hin (Benchmarking).

5.1 SOA-Ziele, Architekturprinzipien und Architektursteuerung

129

S9

Nachrichtengrösse und erwartete Antwortzeiten

Anhand der Nachrichtengrösse für einen Serviceaufruf und der Performanz der Integrationsinfrastruktur lassen sich Antwortzeiten für Servicenutzer schätzen. Bei zu grossen Nachrichten sollte die Schnittstellengranularität reduziert werden.

S10

Kapselung eines geschäftlichen Konzepts

Der Leistungsumfang bzw. das Abstraktionsniveau eines Services sollte einem geschäftlichen Konzept entsprechen (Prozess, abgeschlossene Prozessaktivität, Geschäftsentität bzw. Geschäftsdokument).

S11

InteraktionsOverhead

Von mehreren Nutzern in gleichen Sequenzen aufgerufene Operationen eines oder mehrerer Services sind ein Hinweis dafür, dass die Operationen durch einen gröber granularen Service gekapselt werden könnten.

S12

Geschätzte bzw. tatsächliche Wiederverwendungshäufigkeit

Eine geringe Wiederverwendungshäufigkeit kann auf eine zu geringe Service-Generalisierung hinweisen. Im Kontext der Komponentenentwicklung geht [Griffel 1998, 47] davon aus, dass eine 3-5-fache Wiederverwendung nötig ist, um den zusätzlichen Aufwand der Entwicklung und des Betriebs einer wieder verwendbaren Komponente zu rechtfertigen. Nach [Poulin/Carlson 2003, 4] reicht eine 2-fache Wiederverwendung.

S13

Geschätzte Wiederverwendungsrentabilität

Die Wiederverwendungs-Rentabilität kann durch Multiplikation der erwarteten Wiederverwendungshäufigkeit mit dem geschätzten Wiederverwendungsnutzen (Kosteneinsparungen bei Wiederverwendung) abzüglich der Mehrkosten einer Entwicklung für Wiederverwendung errechnet werden (s. [Jacobson et al. 1997, 387ff.], [LogicLibrary 2003]). Schätzwerte in der KomponentenLiteratur gehen von Kosteneinsparungen bei Wiederverwendung von 75-80% und von 1.5- bis 3-fachen Entwicklungskosten aus (s. [Griffel 1998, 47f.], [Poulin/Carlson 2003]).

Tabelle 5-4: Indikatoren zur Bewertung einzelner Services

130

5 Architekturmanagement und Servicedesign

Indikator Ebene Gesamtarchitektur

Erläuterung und Zielwerte

G1

Gleichzeitige Änderungen an Serviceimplementierungen oder Applikationen verschiedener Domänen über mehrere Releasezyklen

Gleichzeitige Änderungen über mehrere Releasezyklen sind Hinweise für eine mangelhafte Schnittstellenabstraktion oder eine enge logische Kopplung zwischen Services bzw. Domänen [Gall et al. 1998, 193].

G2

Einhaltung der in den SLA vereinbarten Releasezyklen

Genutzte Serviceschnittstellen sollten, wenn überhaupt, nur in zuvor vereinbarten Releasezyklen angepasst werden. Mehrere SLA-Verletzungen deuten auf mangelhafte Planungsprozesse oder Mängel in der Serviceentwicklung hin.

G3

Technischer Standardisierungsumfang

Bewertung des technischen Standardisierungsumfangs der SOA: Existieren Schnittstellen- und Kommunikationsstandards für die Servicespezifikation und -nutzung, sind die notwendigen zentralen Middlewaredienste der Integrationsinfrastruktur implementiert (s. Kap. 3.3.2)?

G4

Anzahl eingesetzter Middlewarekomponenten und technischer Standards

Viele verschiedene Middlewarekomponenten und alternative Standards für die technische Integrationsinfrastruktur verursachen Lizenz- und Personalkosten und Aufwand in Projekten. Ihre Anzahl sollte möglichst gering gehalten werden (unter Berücksichtigung ihrer Durchdringung in Projekten, s. G5 unten) [s. Schwinn 2006a, 186].

G5

Durchdringung der standardisierten Infrastruktur in Projekten

Werden Middlewarekomponenten und Standards der Integrationsinfrastruktur in Projekten selten verwendet, kann das auf ein mangelhaftes Middlewareportfolio oder mangelhaft durchgesetzte Entwicklungsprozesse und Richtlinien hindeuten [s. Schwinn 2006a, 189].

G6

Fachlich-semantischer Standardisierungsumfang

Bewertung des fachlich-semantischen Standardisierungsumfangs der SOA anhand einer Checkliste (Terminologie der fachlichen Servicebeschreibung, einheitliche Datenmodelle und Datenwerte etc., s. Kap. 3.3.2).

G7

Semantischer Integrationsaufwand der ServiceWiederverwendung

Messung bzw. Schätzung des Aufwandes, der entsteht, weil Servicenutzer mehrere Services wieder verwenden, die unterschiedliche Datenmodelle und Werte für gleiche Geschäftsentitäten nutzen. Wo hohe Aufwände anfallen, sollte die Entwicklung eines standardisierten Datenmodells in Betracht gezogen werden.

G8

Offenheit, Reife und Verbreitung der Standards

Qualitative Bewertung der verwendeten Standards bez. Offenheit, Reife und Marktverbreitung.

5.1 SOA-Ziele, Architekturprinzipien und Architektursteuerung

131

G9

Kohäsionsverhältnis

Das Kohäsionsverhältnis in der Servicearchitektur (Anzahl Services mit funktionaler, kommunikativer oder sequenzieller Kohäsion im Verhältnis zur gesamten Anzahl Services [vgl. Balzert 1998, 479]) sollte möglichst hoch sein (Benchmarking).

G10

Verhältnis servicebasierter Schnittstellen zu Schnittstellen zwischen Applikationsdomänen insgesamt

Ein niedriger Wert deutet auf eine schlechte Entkopplung der Domänenarchitektur hin (schlechter Grad der Desintegration [s. Schwinn 2006a, 189], Benchmarking).

G11

Verhältnis domänenexterner Schnittstellen zu Applikationsschnittstellen einer Domäne insgesamt

Hohe Werte können auf eine schlechte Domänenkohäsion hinweisen. Allerdings können auch spezialisierte Domänen mit monolithischen Applikationen (z.B. Stammdatensystem für das KundendatenManagement) zu hohen Werten führen (Benchmarking).

G12

Verhältnis Laufzeitkosten für Middleware zu Laufzeitkosten gesamt

Vergleich der Laufzeitkosten für Middlewarekomponenten mit den Laufzeitkosten für die Erbringung der eigentlichen Funktionalität [s. Schwinn 2006a, 188]. Hohe Middleware-Laufzeitkosten können ein Hinweis für eine zu lose Kommunikationskopplung sein (Benchmarking).

G13

Anzahl publizierter bzw. geplanter Services

Eine sehr hohe Anzahl publizierter bzw. geplanter Services kann darauf hinweisen, dass Services zu feingranular sind oder in Projekten nicht wieder verwendet werden (Benchmarking).

G14

Wachstum der Anzahl Services im Zeitverlauf

Ein exponentielles oder lineares Wachstum der Anzahl publizierter Services über längere Zeit kann darauf hinweisen, dass Services nicht wieder verwendet werden [s. Schwinn 2006a, 187]. In den Anfangsphasen der SOA-Umsetzung ist allerdings mit einem starken Wachstum zu rechnen.

Tabelle 5-5: Indikatoren zur Bewertung auf Ebene Gesamtarchitektur 5.1.4

Architekturreviews

Die Einhaltung der formulierten Designprinzipien ist in Architekturreviews laufend zu kontrollieren. Neben periodischen Bewertungen der Gesamtarchitektur bspw. auf Basis einer Architektur-Scorecard sollten Unternehmen einen zentralen Reviewprozess für Projekte definieren, die Services entwickeln oder nutzen. Dieser Reviewprozess ist in das allgemeine Projektmanagement zu integrieren. Erkenntnisse aus den Architekturreviews und aus der Anwendung der Designprinzipien in Entwicklungsprojekten sollten in die periodische Überarbeitung und Anpassung der SOA-Ziele und Architekturprinzipien zurückfliessen.

132

5 Architekturmanagement und Servicedesign

Abgeleitet aus den Architekturzielen definierte Credit Suisse eine ArchitekturScorecard. Darin erhebt das Unternehmen regelmässig eine Reihe von Messgrössen zur Überwachung der Qualität der SOA auf Ebene Gesamtarchitektur: •

Resistance to change: Vergleich von Projektkosten im Zeitverlauf, mit einer Normierung der Projektkomplexität anhand von Use Case Points20

•

Time to Market: Entwicklungszeiten pro Use Case Point

•

Wiederverwendungsfaktor von Services

•

Entwicklung der Anzahl Services im Zeitverlauf

•

Anzahl Serviceaufrufe bzw. Messages pro Zeitintervall (Monat, Tag)

• Durch einzelne Domänen bearbeitete Serviceaufrufe pro Zeitintervall Für das Projektcontrolling definierte das Unternehmen einen dreistufigen Reviewprozess, den jedes Fachprojekt durchlaufen muss (s. Abb. 5-3). Project Idea

Initialization

Service Development Request

Service Change Request

1. Quality Check

Design

2. Quality Check

Implementation

IDL Specification 3. Quality Check

Extended Design for reuse

Basic Request

Private service

Completion Service Definition

Generation Service Documentation

Abb. 5-3: Projektreviewprozess (Quelle: Credit Suisse) Qualitätscheck 1 Der Entwicklungs- und Reviewprozess beginnt damit, dass ein Fachprojekt im Rahmen einer Anforderungsanalyse aus Geschäftssicht die benötigten Funktionen der zu entwickelnden Lösung und ihre Effekte auf Daten beschreibt. Im Rahmen des Qualitätschecks 1 überprüft ein zentrales Architekturteam anhand des Servicerepository, ob bestehende Services wieder verwendet werden können, ob sie ggf. angepasst werden müssen oder ob die Funktionalität durch einen neuen Service zur Verfügung gestellt werden muss. In diesem Qualitätscheck fällt aufgrund der Domänenzugehörigkeiten und der technischen Plattformen von Servicenutzer und

20

Use Case Points sind, ähnlich wie Function Points, Grössen zur normierten Messung des funktionalen Umfangs und der Komplexität von Applikationen (s. [Cohn 2005, 3ff.]).

5.2 Entwicklung der Domänenarchitektur

133

Serviceanbieter auch die Entscheidung darüber, ob neue Services als Public oder Private Services zu entwickeln sind und welchen Integrationsbus sie verwenden (s. dazu Kap. 5.3.3). Qualitätscheck 2 Den Qualitätscheck 2 führt das zentrale Architekturteam nur für Public Services durch. Er basiert auf einer detaillierteren Servicespezifikation, die eine Beschreibung der unterstützten Operationen und ihrer Effekte auf Daten, Input- und Outputdatenstrukturen, Ausnahmen sowie Vor- und Nachbedingungen der Servicenutzung enthält. Das Architekturteam prüft, ob das Servicedesign die vorgegebenen Designprinzipien erfüllt (z.B. Einhaltung von Namenskonventionen, Generalisierung der Serviceleistung). Es protokolliert die Ergebnisse des Qualitätschecks und entscheidet über die Projektfortführung in die Implementierungsphase oder eine Überarbeitung des Designs. Qualitätscheck 3 Qualitätscheck 3 wird in der Implementierungsphase für alle Schnittstellen durchgeführt, welche eine der zentralen Integrationsinfrastrukturen nutzen (Public und Private Services). Middlewarespezialisten der zentralen IT überprüfen die korrekte Übersetzung der fachlichen Schnittstellenspezifikation in eine formale technische Schnittstellenbeschreibung (CORBA IDL im Falle von CORBA-Services, optional XML für Events) sowie die Performanzeigenschaften des Services unter Berücksichtigung der gewählten Integrationsinfrastruktur.

5.2

Entwicklung der Domänenarchitektur

Applikationsdomänen stellen in den untersuchten Fallstudien zentrale Instrumente für die Entscheidung dar, wo Services zu entwickeln sind und wer sie verantwortet. Voraussetzung dafür, dass eine Domänenarchitektur als Rahmen für solche Kopplungs- und Verantwortungsentscheidungen dienen kann, ist die Domänenabgrenzung anhand geeigneter Kriterien. Die folgenden Abschnitte erläutern die Notwendigkeit und Zielsetzung einer Domänenarchitektur (Kap. 5.2.1), gehen auf verschiedene Ansätze zur Domänenabgrenzung ein (Kap. 5.2.2) und konsolidieren schliesslich Kriterien zur Domänenbildung (Kap. 5.2.3).

5.2.1

Ziele der Domänenabgrenzung

Die Entwicklung und der Betrieb von Services verursachen im Vergleich zu alternativen Kopplungsmechanismen Mehrkosten (s. [Dietzsch/Goetz 2005, 1527f.], [Schwinn/Winter 2005, 596]). Ausserdem sind XML-basierte, plattformübergreifende Service-Kommunikationsprotokolle oft ineffizienter als plattformspezifische Technologien [s. McGovern et al. 2003, 51]. Weiter erhöht eine sehr grosse An-

134

5 Architekturmanagement und Servicedesign

zahl Services den Aufwand der Identifikation existierender Services in Fachprojekten und reduziert damit ihre Wiederverwendung [s. Stiemerling 2002, 437]. Services sind deshalb selektiv an klar definierten Stellen der Applikationsarchitektur zu entwickeln. Applikationsdomänen bieten in einer SOA einen Rahmen für die Entscheidung, wann Applikationen über Services zu integrieren sind und wann nicht: Services bieten domänenexternen Applikationen einen standardisierten, lose gekoppelten Zugriff auf die in einer Domäne gekapselten Funktionalität, während innerhalb von Domänen eine enge Kopplung zwischen Applikationen bzw. die Verwendung effizienterer, plattformspezifischer Integrationsmechanismen zulässig ist. Neben solchen Kopplungsentscheidungen besitzt eine Domänenarchitektur in einer SOA weitere Funktionen: •

Fachliche Strukturierung der Applikationsarchitektur. Domänen nehmen eine fachliche, geschäftsorientierte Strukturierung der in der Applikationsarchitektur verfügbaren Funktionen und Daten vor und erleichtern es potenziellen Servicenutzern, die von ihnen benötigten Funktionen und die dafür verantwortlichen Stellen zu identifizieren. Sie fördern dadurch die Wiederverwendung und verhindern ein unkontrolliertes Wachstum redundanter Funktionen.

•

Klare Verantwortungsbereiche und Autonomie. Die Kopplung über Services erhöht die Autonomie und Unabhängigkeit von Domänen und unterstützt damit eine schrittweise, isolierte Migration der Applikationsarchitektur. Domänenverantwortliche können eigenständige Entscheidungen über die interne Domänenarchitektur, einzusetzende Produkte und Plattformen treffen, solange diese Entscheidungen die mittels Services definierten Domänenschnittstellen nicht beeinflussen. Die Domänenarchitektur kann dabei in mehreren hierarchischen Stufen verfeinert werden (s. [Dodd 2005a, 23], [Richter et al. 2005, 415]): Innerhalb einer Anwendungsdomäne lassen sich weitere Subdomänen definieren, die Services bieten, welche nicht unternehmensweit, sondern domänenintern verwendet werden (s. Abb. 5-4). Entsprechend lassen sich auch unterschiedliche Verantwortlichkeitsstufen festlegen, wie dies bspw. Credit Suisse macht (s. Kap. 5.3.3): Während Richtlinien und Infrastrukturen für unternehmensweit eingesetzte „Public Services“ durch zentrale Architekten bestimmt und kontrolliert werden, können die Domänenverantwortlichen für domäneninterne „Private Services“, wo sinnvoll und notwendig, eigene Infrastrukturen und Architekturvorgaben definieren. Falls Services über die Unternehmensgrenze hinaus angeboten werden sollen, können die Domänen „Unternehmen“ und „Geschäftsnetzwerk“ eine weitere, übergeordnete Hierarchiestufe darstellen.

5.2 Entwicklung der Domänenarchitektur

135

Domäne

Domäne

Subdomäne

Subdomäne Subdomäne

Subdomäne

Subdomäne Subdomäne

Zentral koordinierte (Public) Services und Infrastruktur Dezentral, durch Domänenverantwortliche koordinierte (Private) Services und Infrastruktur

Abb. 5-4: Unterschiedliche Verantwortlichkeitsstufen in einer Domänenarchitektur •

Komplexitätsbeherrschung. Die Kapselung von Domänen über Services reduziert Abhängigkeiten in der Applikationslandschaft und macht bestehende Abhängigkeiten besser sichtbar. Bei Anpassungen an Applikationen oder bei ihrem Ersatz müssen nur die Auswirkungen auf die Domänenservices und auf allfällige nicht über Services gekoppelte Applikationen innerhalb der gleichen Domäne berücksichtigt werden [s. Schlamann 2004, 7]. In den Fallstudien bilden Domänen ausserdem einen Rahmen für die Entwicklung unternehmensweit standardisierter Daten- und Funktionsmodelle. In den 80er-Jahren unternahmen verschiedene Unternehmen den Versuch, ihre Datenmodelle zu harmonisieren und ein einheitliches Unternehmensdatenmodell zu entwickeln. Die Projekte scheiterten an politischen Hindernissen und am Umfang und der Komplexität der Aufgabe: Bei der grossen Geschäftsdynamik waren unternehmensweite Datenmodelle i.d.R. veraltet, bevor sie fertig modelliert werden konnten [s. Krafzig et al. 2004, 9]. Anstatt zu versuchen, einheitliche Datenmodelle für sämtliche Geschäftsentitäten in der Applikationsarchitektur zu entwickeln, konzentrieren sich z.B. Deutsche Post Brief oder T-Com bei der semantischen Standardisierung auf die wichtigsten domänenübergreifend genutzten Entitäten und Attribute sowie ihre Beziehungen untereinander. Diese Datenmodelle werden dabei nicht zwingend in Applikationen bzw. Datenbanken implementiert, sondern dienen als einheitliche semantische Modelle für Servicenachrichten. Sie verringern damit den semantischen Integrationsaufwand, d.h. die Übersetzung unterschiedlicher Datenmodelle, für Applikationen, die mehrere Services nutzen [s. Newcomer/Lomow 2004, 119].

136

5.2.2

5 Architekturmanagement und Servicedesign

Vorgehensansätze für die Domänenabgrenzung

Damit eine Domänenarchitektur im Rahmen einer SOA die beschriebenen Funktionen erfüllt, muss sie die fachlichen Applikationen bzw. Funktionen und Daten der Applikationsarchitektur in Bereiche unterteilen, die sinnvollerweise lose gekoppelt über Services interagieren. Obwohl die Fallstudien aus Kapitel 4 den Nutzen einer Domänenarchitektur belegen, behandelt die Literatur die Domänenabgrenzung im Zusammenhang mit SOA bisher wenig [s. Gallas 2004, 243]. Es existieren aber in der Literatur verschiedene Partitionierungs- bzw. Clusterungstechniken für betriebliche Informationssysteme, die sich zumindest teilweise auf die Abgrenzung von Applikationsdomänen für eine SOA übertragen lassen. Sie orientieren sich oft an Modularisierungskonzepten aus der Organisations-21 und der Produktentwicklung.22 Tabelle 5-6 gibt einen Überblick über die Ziele, Clusterungsobjekte und Clusterungskriterien einiger Ansätze. Auswahlkriterien für die Ansätze waren, dass sie eine möglichst redundanzfreie Clusterung grösserer Bereiche der Applikationsarchitektur eines Unternehmens verfolgen, auf eine hohe Autonomie (lose Kopplung) zwischen Clustern und eine hohe Kohäsion bzw. Zusammengehörigkeit innerhalb der Cluster abzielen und dabei fachliche Kriterien anwenden, die sich an der Geschäftsstrategie und / oder der Aufbau- und Ablauforganisation des Unternehmens orientieren. Ansatz und Ziel

Clusterungsobjekte

Business Systems Planning (BSP): Unternehmensweite Zusammenfassung von Prozessen und Datenklassen zu langlebigen Informationssystemen [s. IBM 1984].

Gruppierung von Geschäftsprozessen und Datenklassen zu Applikationen.

Ähnlichkeit der Datenverwendung durch Prozesse.

Architecture Model for Application Integration: Wahl geeigneter Integrationsgrade bei der Kopplung von Softwareartefakten für eine ausgewogene Inter- und Intra-Applikationskomplexität und zur Minimierung der Gesamtintegrationskosten in der Applikationsarchitektur [s. Winter 2003a].

Gruppierung von Softwareartefakten (Module, Datenstrukturen, Komponenten) zu Applikationen.

Gruppierung anhand fachlicher Eigenschaften:

21

22

Clusterungskriterien

• Unterstützung spezifischer Prozesse einzelner Geschäftseinheiten bzw. Produktlinien. • Durch mehrere Geschäftseinheiten verwendete Querschnittsfunktionen. • Durch mehrere Geschäftseinheiten und Querschnittsfunktionen verwendete Datenstrukturen.

Kriterien für eine Modularisierung der Aufbau- und Ablauforganisation von Unternehmen liefern z.B. [Picot et al. 2001, 227ff.] oder [Aier/Schönherr 2004b, 28ff.] Einen Überblick über Ansätze zur Modularisierung von Sachgütern findet sich z.B. in [Holmqvist/Persson 2003]

5.2 Entwicklung der Domänenarchitektur Ansatz und Ziel

Clusterungsobjekte

Methode zur Verteilung von Informationssystemen in globalen Unternehmensarchitekturen: Unterstützung von Verteilungs- und Integrationsentscheidungen in Applikationsarchitekturen globaler Unternehmen durch Bildung geschäftlicher und applikatorischer Integrationsbereiche [s. Pohland 2000].

Gruppierung betrieblicher Standardsoftwaremodule (umfassen Fachfunktionen und Datensammlungen) zu Applikationsclustern.

Component Business Modeling (CBM): Redundanzfreie Komponentisierung der Hauptgeschäftsaktivitäten eines Unternehmens zur Unterstützung strategischer Investitions- und Sourcingentscheidungen sowie zur Serviceidentifikation und Planung der Applikationsarchitektur [s. Latimore/Robinson 2004].

Gruppierung von Geschäftsaktivitäten und unterstützende Ressourcen zu autonomen „Geschäftskomponenten“.

137 Clusterungskriterien Gruppierung von Geschäftsprozessen in Geschäftscluster anhand geschäftlicher bzw. organisatorischer Clusterungsdimensionen wie Produktsparten, Verantwortungsbereichen, Know-how etc. Gruppierung der Softwaremodule in an Geschäftsclustern angelehnte Applikationscluster, evtl. Umgruppierung aufgrund applikatorischer Restriktionen. Primäre Gruppierung anhand von Geschäftskompotenzen bzw. Funktionsbereichen und Verantwortlichkeitsstufen. Feinere Unterteilung anhand der Kriterien • Erstellung einer wertschöpfenden Leistung, • Verwendung gleicher Ressourcen (Know-how, Prozesse, Informationssysteme), • eigenständige Verantwortbarkeit und Betreibbarkeit.

Methode für das Service Engineering: Entwicklung einer modularen Produkt- bzw. Servicearchitektur für IT-Dienstleistungen [s. Böhmann 2004].

Gruppierung von Basisfunktionen bzw. funktionalen Merkmalen von IT-Dienstleistungen zu kombinierbaren und wieder verwendbaren Dienstleistungsmodulen.

Gruppierung nach Art der Funktionen (Fachfunktionen, technische / unterstützende Funktionen, Funktionen zur Leistungserbringung) und gemeinsamer Abhängigkeiten von Treibern für Leistungsvarianten.

Tabelle 5-6: Überblick über Clusterungsansätze Business System Planning Einen der ältesten Clusterungsansätze für den Entwurf von Applikationsarchitekturen enthält IBMs Business Systems Planning (BSP)-Methode [s. IBM 1984]. Ziele des BSP umfassen u.a. die Überführung der Geschäftsstrategie in eine ISStrategie, die Priorisierung von Informationssystemen und die unternehmensweite Planung langlebiger Informationssysteme, basierend auf stabilen Geschäftsprozessen [s. Lee 1999, 354]. Die Methode enthält die Technik „Definition der Informationssystem-Architektur“, welche Unternehmensprozesse und Datenklassen zu

138

5 Architekturmanagement und Servicedesign

Personnel

Costs

Orders

Sales segmentation

Sales plans

Bills of work

Accounts payable

Capacity utilization

Facilities

Machines

Inventories

Suppliers

Bills of material

Parts catalog

Products

Appl. A

Appl. B

Appl. C

Appl. D

Appl. F

Appl. E

Corporate planning Organizational analysis Planning review Financial planning Finance Research Forecasting Product development Product specification Supply management Deliveries Inventory control Scheduling Capacity planning Materials planning Production Sales Aerea management Sales support Order processing Distribution Financial accounting Budgeting Human resource mgt. Recruiting … … …

Financials

Business Process

Planning

Data Cluster

Production program

grösseren Systembereichen zusammenfasst. Dazu werden die Prozesse und Datenklassen an den Achsen einer Matrix angeordnet und Prozessgruppen mit ähnlicher Datenverwendung identifiziert. Die ähnliche Verwendung gleicher Daten deutet auf eine hohe fachliche Kohäsion der entsprechenden Prozesse hin. Die auf diese Weise gruppierten Prozesse und Daten bilden die Basis für langfristig stabile Applikationen und sollen zu einer Applikationsarchitektur mit geringer Komplexität führen [s. Pohland 2000, 64].

Abb. 5-5: Applikations-Clusterungsansatz nach BSP [vgl. IBM 1984, 41] Architecture Model for Application Integration [Winter 2003a] baut in seinem Architecture Model for Application Integration auf dem Clusterungsansatz des BSP auf. Er entwickelt für die Clusterung von „Softwareartefakten“ (Module, Datenstrukturen, Komponenten) ein Modell mit den drei Dimensionen „Geschäftsbereich / Produktlinie“, „Funktionscluster“ und „Informationssubjekt“ bzw. Datenklasse. Ziel des Modells ist es, anhand der Abhängigkeiten zwischen diesen Dimensionen geeignete Integrationsgrade bei der Kopplung von Softwareartefakten zu wählen und dadurch eine ausgewogene Inter- und Intra-Applikationskomplexität sowie minimale Integrationskosten in der

5.2 Entwicklung der Domänenarchitektur

139

Applikationsarchitektur zu erreichen. Dazu werden Softwareartefakte in Applikationen zusammengefasst, die spezifische Prozesse einzelner Geschäftseinheiten oder Produktlinien unterstützen (z.B. Zahlungsverkehrs- oder Kreditfinanzierungsapplikationen), in Applikationen, die Querschnittsfunktionen bieten, welche über mehrere Geschäftseinheiten und Geschäftsentitäten generisch wieder verwendet werden können (z.B. Call-Center, Portal), und in Applikationen, die über mehrere Geschäftseinheiten und Funktionscluster hinweg benötigte Kerndaten zur Verfügung stellen (z.B. Kunden- oder Vertragsdaten). Abb. 5-6 zeigt eine „ideale Applikationsarchitektur“ mit organisations- bzw. produktzentrierten, kerninformationszentrierten und querschnittsfunktionszentrierten Applikationen.

Abb. 5-6: "Ideale Applikationsarchitektur" nach [Winter 2003a] Verteilung von Informationssystemen in globalen Unternehmensarchitekturen Einen weiteren Ansatz für die Partitionierung von Applikationsarchitekturen liefert [Pohland 2000] in seiner Methode zur Verteilung von Informationssystemen in globalen Unternehmensarchitekturen. Die Methode sieht in einem ersten Schritt die Definition von „Geschäftsclustern“ vor, die in einem zweiten Schritt in „Applikationscluster“ überführt werden. Ein Geschäftscluster ist ein betriebswirtschaftlicher Integrationsbereich, der durch eine starke Verflechtung der Geschäftsprozesse charakterisiert ist, während Applikationscluster Bereiche der Applikationsarchitektur mit engen internen Integrationsbeziehungen darstellen [s. Pohland 2000, 81f.]. Für die Abgrenzung von Geschäftsclustern führt die Methode verschiedene organisatorische Clusterungsdimensionen23 auf, die anhand des Or23

[Pohland 2000, 117f.] unterscheidet ablauf- und aufbauorientierte Clusterungsdimensionen. Erstere umfassen bspw. Absatzregionen, Produktsparten, Vertriebswege, benötigte Ressourcen oder Knowhow, letztere Verantwortungsbereiche, Standorte oder organisatorische bzw. rechtliche Einheiten.

140

5 Architekturmanagement und Servicedesign

ganisationsprofils, der Prozessarchitektur und der unternehmensspezifischen Architekturtreiber priorisiert werden. Das Organisationsprofil beschreibt dabei organisatorische und kulturelle Eigenschaften des Unternehmens, die Prozessarchitektur ordnet Prozesse zentralen und dezentralen organisatorischen Einheiten zu, und die Architekturtreiberliste identifiziert aktuelle und zukünftige Anforderungen an die Applikationsarchitektur. Anhand der Gruppierung von Geschäftsprozessen in Geschäftsclustern bestimmt die Methode die Verteilung von Funktionen und Daten im Unternehmen und fasst sie zu Applikationsclustern zusammen. Die Methode konzentriert sich auf Verteilungsarchitekturen für betriebliche Standardsoftware, weshalb einzelne Standardsoftwaremodule die primären Clusterungsobjekte auf Applikationsebene darstellen. Im Idealfall werden Geschäftscluster eins zu eins in Applikationsclustern abgebildet, die Methode sieht aber auch ein Zusammenfassen mehrerer Geschäftscluster zu einem Applikationscluster oder das Zerteilen eines Geschäftsclusters in mehrere Applikationscluster aufgrund applikatorischer Restriktionen der Standardsoftware vor [s. Pohland 2000, 162]. Die Methode beschreibt typische Architekturmuster für Applikationsarchitekturen globaler Unternehmen, die sich in der Praxis bewährt haben (s. Abb. 5-7). Sie unterscheidet die primären Clusterungsdimensionen Unternehmensbereich (z.B. Produktbereiche) und Verantwortungsbereich (z.B. Landesgesellschaften) und bündelt Applikationen hauptsächlich in unternehmensbereichsspezifischen Clustern. Weiter bilden unternehmensbereichsübergreifende, verantwortungsbereichsspezifische Funktionen (z.B. landesspezifische Finanz- oder Human ResourceSysteme) und zentrale, unternehmensbereichs- und gesellschaftsübergreifende Funktionen (z.B. zentraler Konzerneinkauf) eigene Applikationscluster. Unternehmensbereiche (z.B. Produktbereiche) Produktbereich 1

Produktbereich 2

Produktbereich 3

Verantwortungsbereichsübergreifend

Verantwortungsbereiche (z.B. Gesellschaften)

Gesellschaft 1

Gesellschaft 2

Gesellschaft 3

Unternehmensbereichsübergreifend

Gesellschaftsspezifische Funktionen (z.B. Finanzen) Weltweite Kernprozesse Produktbereich 1

Weltweite Kernprozesse Produktbereich 2

Weltweite Kernprozesse Produktbereich 3

Gesellschaftsspezifische Funktionen (z.B. Finanzen) Gesellschaftsspezifische Funktionen (z.B. Finanzen)

Konzernweite Funktionen (z.B. Einkauf)

Abb. 5-7: Typische Applikationscluster für globale Unternehmen in Anlehnung an [Pohland 2000, 156ff.]

5.2 Entwicklung der Domänenarchitektur

141

Component Business Modeling Der Ansatz des Component Business Modeling (CBM) wurde von IBM im Rahmen der „on demand“-Initiative entwickelt (s. [Latimore/Robinson 2004], [Cherbakov et al. 2005]).24 Ziel ist es, die Gesamtheit der Geschäftsaktivitäten und der sie unterstützenden Ressourcen eines Unternehmens so in Geschäftskomponenten (Business Components) zu unterteilen, dass diese möglichst redundanzfrei im Unternehmen implementiert sind, flexibel zur Unterstützung neuer Marktleistungen kombinierbar sind und bei entsprechendem Angebot auf einem externen Markt bezogen werden können. Unter einer Geschäftskomponente versteht IBM eine autonom gemanagte Gruppe zusammengehöriger Geschäftsaktivitäten, die auf einem gemeinsamen Set an Know-how, Prozessen, Informationssystemen, Organisations- bzw. Verantwortlichkeitsstrukturen und Erfolgsmetriken basieren. Jede Komponente erbringt eine wertschöpfende Geschäftsleistung und besitzt definierte Prozess- und Systemschnittstellen. CBM gruppiert Geschäftsaktivitäten anhand der zwei Dimensionen Geschäftskompetenzen bzw. Funktionsbereiche (Business Competencies, z.B. Kundenbeziehungsmanagement, Fulfillment) und Verantwortlichkeitsstufe (Accountability Level) (s. Abb. 5-8). Während der Ansatz bez. der Verantwortlichkeitsstufen die drei generischen Ausprägungen „directing“ (strategische Planungsaktivitäten), „controlling“ (Überwachungs- und Steuerungsaktivitäten) und „executing“ (operative Ausführung) unterscheidet, werden die Geschäftskompetenzen anhand der Hauptwertschöpfungsbereiche des Unternehmens unternehmensspezifisch bestimmt. Auf Basis von Prozess- und Organisationsmodellen, Stellenbeschreibungen etc. werden Geschäftskomponenten primär innerhalb der einzelnen Geschäftskompetenzen und sekundär anhand der Verantwortlichkeitsstufen abgegrenzt. Eine weitere Verfeinerung der Geschäftskomponenten nimmt die Methode anhand der Kriterien Verwendung gleicher Ressourcen (Know-how, Prozesse, Informationssysteme), eigenständige Verantwortbarkeit und Betreibbarkeit sowie Erstellung einer wertschöpfenden Leistung vor. Die so entwickelte „Business Component Map“ dient sowohl als Grundlage für Investitions- oder Spezialisierungsentscheidungen auf Ebene Geschäftsstrategie als auch als zukünftiger Bebauungsplan für die Applikationsarchitektur und als Ausgangslage für die Serviceidentifikation (s. [McCall 2004, 11f.], [Cherbakov et al. 2005, 665]).

24

[Latimore/Robinson 2004, 1] definieren „on demand business“ wie folgt: „An on demand business is an enterprise whose business processes – integrated end-to-end across the company and with key partners, suppliers and customers – can respond with flexibility and speed to virtually any customer demand, market opportunity or external threat.”

142

5 Architekturmanagement und Servicedesign Business Competencies

Accountability Level

Directing

Controlling

Business Administration

New Business Development

Relationship Management

Servicing & Sales

Product Fulfillment

Financial Control and Accounting

Business Planning

Sector Planning

Account Planning

Sales Planning

Fulfillment Planning

Portfolio Planning

Business Unit Tracking

Sector Management

Relationship Management

Staff Appraisals

Product Management

Credit Assessment

Sales Management

Fulfillment Planning

Staff Administration

Product Directory

Product Administration

Marketing Campaigns

Reconciliation

Sales

Credit Administration

Executing

Compliance

Product Fulfillment

Customer Accounts

Document Management

General Ledger

Customer Dialogue Contact Routing

Abb. 5-8: Business Component Map [Cherbakov et al. 2005, 665] Methode für das IT-Service Engineering Die Methode für das Service Engineering von [Böhmann 2004] überträgt Ansätze für das Design modularer Sachgüter und Dienstleistungen auf das Design von ITDienstleistungen wie z.B. gehostete Applikationsdienste. Sie will eine modulare Servicearchitektur entwerfen, die es IT-Dienstleistern erlaubt, Kunden ein flexibles Leistungsportfolio auf Basis semistandardisierter, stabiler Module mit begrenzter Abhängigkeit voneinander anzubieten. Der Ansatz befasst sich damit nicht mit der Modularisierung einer unternehmensweiten Applikationsarchitektur, die Grundidee des Vorgehens lässt sich aber prinzipiell darauf übertragen. Diese besteht darin, die zur Erbringung einer IT-Leistung benötigten Funktionen anhand gemeinsamer Abhängigkeiten von Treibern für Leistungsvarianten zu gruppieren. Die Methode erstellt in einem ersten Schritt eine Liste mit Basisfunktionen, welche für eine anzubietende IT-Leistung benötigt werden. Dies können die von Kunden in ihren Prozessen verwendeten Fachfunktionen (z.B. Zahlungseingang erfassen, Rechnung prüfen etc.), unterstützende Funktionen (z.B. Nachrichtentransformation) oder auch die im Leistungserbringungsprozess des Anbieters benötigten Funktionen (z.B. Backup- oder Recovery-Funktionen) sein. In einem zweiten Schritt analysiert das Designteam Treiber, die zu Varianten in den zu erbringenden Leistungen führen. Beispiele sind unterschiedliche technische Systemlandschaften bei Kunden, in welche die eigene Leistung integriert werden muss, unterschiedliche Nutzerzahlen bei Kunden oder unterschiedliche Anforderungen an Fachfunktionen aufgrund branchen- oder ortspezifischer gesetzlicher Vorschriften. Anhand einer Matrix untersucht das Designteam anschliessend, wie sich die einzelnen Treiber auf die verschiedenen Funktionen auswirken. Treiber, die sich in ähnlicher Weise auf mehrere Funktionen auswirken, deuten auf Abhängigkeiten zwischen diesen Funktionen hin und sind ein Hinweis dafür, sie in einem Modul zusammenzufassen.

5.2 Entwicklung der Domänenarchitektur

5.2.3

143

Kriterien für die Domänenabgrenzung

Aus den betrachteten Clusterungsansätzen lassen sich verschiedene Kriterien für eine Domänenabgrenzung ableiten. Die untersuchten Fallstudien sowie die Architekturmuster von [Winter 2003a], [Pohland 2000] oder [Cherbakov et al. 2005] zeigen drei Hauptdimensionen für eine erste, unternehmensweite Domänenbildung: •

Unternehmensbereichsspezifische Domänen gruppieren Funktionen und Daten, die spezifische Geschäftsprozesse einzelner Geschäftseinheiten oder Produktlinien unterstützen. Sie orientieren sich an den wesentlichen Geschäftsleistungen, Kundensegmenten oder Marktkompetenzen des Unternehmens und berücksichtigen notwendiges spezielles Know-how sowie den Bedarf nach unterschiedlichen Geschäfts- und IT-Strategien von Unternehmensbereichen. Beispiele sind die Domänen „Payments“ oder „Credits“ bei Credit Suisse oder die kundensegmentspezifischen Domänen bei T-Com.

•

An Kerngeschäftsentitäten orientierte Domänen gruppieren Kerndaten, die in mehreren Unternehmensbereichen und Prozessen verwendet werden. Typische Beispiele sind die Domänen für Kunden-, Vertrags-, Organisations- oder Produktstammdaten.

•

Eine weitere Gruppe von Domänen bietet bereichs- und prozessübergreifende Querschnittsfunktionen. Diese können sowohl fachlicher (z.B. Finanzfunktionen) als auch technischer Natur sein (z.B. Sicherheitsfunktionen). Die Prozessarchitektur eines Unternehmens liefert damit wichtige Hinweise für eine erste Partitionierung der Applikationsarchitektur, indem sie die Strategie, die Geschäftsmodelle und die Machtverhältnisse in der Organisation des Unternehmens reflektiert [s. Kagermann/Österle 2006, 223]. Die aus der Prozessarchitektur abgeleitete erste Clusterung lässt sich in einem nächsten Schritt durch Prüfen einer Reihe von Merkmalen verfeinern (s. Abb. 5-9):

144

5 Architekturmanagement und Servicedesign

Verfeinerung

Datenaustauschbeziehungen

Daten- / Funktionsredundanzen

Grobpartitionierung

Übergreifende Kerndaten Übergreifende Querschnittsfunktionen

Unternehmensbereichsspezifische Funktionen und Daten Lebenszyklen / Anpassungstreiber

Kooperations- / Sourcing-Strategien

Abb. 5-9: Kriterien für die Domänenabgrenzung •

Daten- und Funktionsredundanzen. Um eindeutige Zuständigkeiten für Services definieren zu können, sollten Fachfunktionen und Geschäftsentitäten den Applikationsdomänen möglichst redundanzfrei zugeordnet sein. Allfällige Redundanzen sollten geschäftlich motiviert sein (z.B. spezielle Anforderungen an die Bonitätsprüfung oder an Kundendaten in einem Geschäftsbereich). Eine Einordnung der existierenden Applikationen in die logische Domänenarchitektur hilft, Doppelspurigkeiten oder eine zu grosse funktionale Abdeckung einzelner Applikationen zu identifizieren und zu entscheiden, wo mittelfristig Anwendungen konsolidiert oder zerteilt werden sollen.

•

Datenaustauschbeziehungen. Einen weiteren Hinweis auf die Eignung der Domänenabgrenzung gibt die Analyse von Datenaustauschbeziehungen bzw. Schnittstellen innerhalb und zwischen Domänen. Besonders für unternehmensbereichsspezifische Domänen gilt, dass Fachfunktionen, die unterschiedlichen Domänen angehören, untereinander wenige und einfache Datenaustauschbeziehungen aufweisen sollten. Insgesamt sollten bereichsspezifische Domänen dadurch im Vergleich zur Anzahl interner Applikationsschnittstellen wenige Schnittstellen untereinander besitzen. Das Verhältnis domäneninterner zu domänenexternen Schnittstellen kann niedriger sein bei bereichsübergreifenden Domänen, die wenige Applikationen mit sehr oft wieder verwendbaren Funktionen und Daten kapseln (z.B. ein Kundenstammdatensystem).

5.2 Entwicklung der Domänenarchitektur

145

Zur Domänenabgrenzung analysierte bei Deutsche Post Brief ein Projektteam, bestehend aus Prozessverantwortlichen der Fachbereiche sowie Mitarbeitern aus der Fach-IT, die Kern-Geschäftsprozesse. Im Rahmen dieser Analyse fand in verschiedenen Fällen auch ein Prozessredesign statt. Das Projektteam zerlegte die Geschäftsprozesse in ihre betriebswirtschaftlichen funktionalen Bestandteile und bestimmte die generischen Geschäftsfunktionen und Datenflüsse, aus denen sich die Prozesse zusammensetzen. Im Anschluss untersuchte es, welche der identifizierten Geschäftsfunktionen in mehreren Prozessen vorkommen. Die Geschäftsfunktionen mit Bedarf an IT-Unterstützung wurden anhand ihrer wechselseitigen Abhängigkeiten geclustert und fachlichen Applikationsdomänen zugeordnet. Als Cluster-Kriterium zur Abgrenzung der Domänen dienten Datenströme (Input-Output-Beziehungen) zwischen den einzelnen Geschäftsfunktionen: Gruppen von Funktionen mit vielen und komplexen Austauschbeziehungen untereinander wurden jeweils in eigenen Domänen zusammengefasst, wobei die Domänen untereinander möglichst wenige Schnittstellen aufweisen sollten. Credit Suisse ging bei der Abgrenzung der Applikationsdomänen von der bestehenden Applikationslandschaft aus. Die zentrale IT erstellte einen Katalog mit den existierenden Applikationen und gruppierte sie nach ihrer fachlichen Zusammengehörigkeit. Die Interaktionshäufigkeit zwischen Applikationen diente dabei als wichtiger Anhaltspunkt. •

Lebenszyklen und Anpassungstreiber. Lose gekoppelte Domänen sollen die Auswirkungen fachlicher Anpassungen in der Applikationsarchitektur lokal begrenzen. Unterschiedliche Lebenszyklen von Fachfunktion und Daten bzw. unterschiedliche Treiber, die zu Anpassungen führen, geben deshalb ebenfalls Hinweise für die Domänenverfeinerung. Bspw. schlagen [Ratzinger et al. 2005] vor, Systemrelease-Zyklen bestehender Applikationen zu vergleichen und die Zusammenfassung von Funktionen zu prüfen, die wiederholt gleichzeitig geändert wurden. Eine in den Fallbeispielen oft beobachtete, u.a. auf unterschiedliche Lebenszyklen zurückzuführende Massnahme ist die Abgrenzung von „Frontoffice“- und „Backoffice“-Domänen. Erstere umfassen kunden-, vertriebspartner- oder mitarbeiternahe Vertriebsapplikationen, während letztere primär Produktions- und Stammdatensysteme enthalten. Weiter kann eine Aufteilung in dispositive und operative Systeme oder in Prozessintegrationssysteme und Systeme zur Informationsverwaltung sinnvoll sein [s. Richter et al. 2005, 415]. Grundlage für die Domänenabgrenzung bei T-Com bildeten einerseits Erfahrungen bez. der Datenflüsse zwischen Fachfunktionen und ihrer Verwendung zentraler Geschäftsobjekte in der bestehenden Applikationsarchitektur. Andererseits analysierten die Architekturverantwortlichen Treiber, die für Varianten und Anpassungen in den Fulfillmentprozessen verantwortlich sind. Wie diese Untersuchungen zeigten, entstehen Prozessvarianten hauptsächlich für unterschiedliche Vertriebspartner bzw. Kundensegmente (Massenmarkt, Wholesale-Kunden, andere Konzerneinheiten) sowie für unterschiedliche Produkttypen („Sell-from-Stock“ Standardprodukte, „Make-to-Order“ Individualprodukte, „Engineer-to-Order“ Individuallösungen). Die Prozessvari-

146

5 Architekturmanagement und Servicedesign

anten unterscheiden sich einerseits bezüglich der Auftragsvolumina, andererseits aber auch in ihren Abläufen und fachlichen Aktivitäten. So finden z.B. bei der Auftragsabwicklung im Massenmarkt Bonitätsprüfungen statt, während im Wholesale-Geschäft Rahmenverträge geprüft werden. Die beiden Prozessvarianten weisen aber in Bezug auf die Aktivitäten in der Produktion (z.B. Verfügbarkeitsprüfungen, Reservierung von Montageterminen etc.) und gewisse Vertriebsaktivitäten (z.B. das Erfassen oder Abfragen von Kundenoder Vertragsinformationen) Gemeinsamkeiten auf. Die Unterscheidung von „Frontend-„ und „Core-Domänen“ spiegelt die unterschiedlichen Lebenszyklen der Prozessteile wider (s. Kap. 4.4.3). •

Kooperations- bzw. Sourcingstrategien. Ein weiteres Kriterium für die Gruppierung von Geschäftsfunktionen in separaten Domänen können SourcingEntscheidungen sein. Eine Fremdvergabe (Outtasking [s. Österle/Reichmayr 2003, 565]) oder Zentralisierung von Geschäftsaktivitäten (Shared Services [s. Kagelmann 2001, 3]) verfolgt i.d.R. das Ziel, auch die zur Unterstützung der Aktivität notwendigen Applikationen auszulagern oder an zentraler Stelle zu konsolidieren. Unternehmen sollten deshalb Aktivitäten, die sie zukünftig evtl. fremd vergeben oder zentralisieren wollen, in der Applikationsarchitektur möglichst in eigenen Domänen abbilden und hinter Services kapseln. Die Domänenarchitektur der von der Zuger Kantonalbank verwendeten Bankenplattform wurde massgeblich von möglichen Sourcing-Optionen beeinflusst. Ziel ist, durch eine selektive Kombination von Prozess- und Applikationsdomänen flexibel unterschiedliche kooperative Banken-Geschäftsmodelle zu unterstützen (s. Kap. 4.5.2). Über die geeignete Granularität der Clusterung von Applikationen zu Anwendungsdomänen gibt es in der Literatur keine Untersuchungen. Die Erfahrungen aus den in Kap. 4 beschriebenen Praxisbeispielen deuten darauf hin, dass auch in grösseren Unternehmen eine grobe Strukturierung der Applikationsarchitektur in ein bis zwei Dutzend Hauptdomänen zu ausreichend autonomen Clustern und längerfristig zu einer beherrschbaren Anzahl Services führt. Deutsche Post Brief unterscheidet 13, Credit Suisse rund 20 Hauptdomänen. Die Bankenplattform, innerhalb welcher der BAP für Zuger Kantonalbank realisiert wurde, sieht 15 Domänen vor. T-Com segmentiert die Applikationslandschaft in 5 Domänen, welche allerdings nur den Teilbereich „Fulfillment“ abdecken. Anhand der oben genannten Prinzipien gebildete Domänen können zu einer Domänenarchitektur führen, die stark von der aktuellen Applikationsarchitektur abweicht. Typische Abweichungen sind Überlappungen innerhalb einer Domäne durch Applikationen, die redundante Funktionen und Daten implementieren, oder umfangreiche Host- oder Standardsoftware-Applikationen, die mehreren fachlichen Domänen zugeordnet sind. Die Domänenarchitektur hilft, solche Diskrepanzen sichtbar zu machen. Sie stellt eine längerfristige Zielarchitektur dar. Architekturverantwortliche müssen aufgrund von Aufwand- und Nutzenbetrachtungen fallweise entscheiden, welche redundanten Systeme sie längerfristig konsolidieren bzw. welche Applikationen sie modularisieren wollen und wo sie auf eine konsequente Umsetzung der Domänenarchitektur verzichten können.

5.3 Serviceidentifikation und -design

5.3

147

Serviceidentifikation und -design

Eine Domänenarchitektur stellt ein Grundgerüst dar, das bei der Entscheidung hilft, welche Applikationen mittels Services miteinander kommunizieren. Die eigentliche Identifikation und Entwicklung konkreter fachlicher Services findet in einem nächsten Schritt statt und ergibt sich aus dem Integrationsbedarf der domänenübergreifenden Geschäftsprozesse. Die systematische Identifikation, Entwicklung und Nutzung von Services in ISProjekten ist ein zentraler Erfolgsfaktor bei der Umsetzung einer SOA [s. Endrei et al. 2004, 80]. Die folgenden Abschnitte diskutieren grundlegende Ansätze der Serviceidentifikation (Kap. 5.3.1) und beschreiben Methoden für das Servicedesign (Kap. 5.3.2). Der Fokus liegt dabei auf einer Untersuchung der methodischen Unterstützung der SOA-Designprinzipien. Kap. 5.3.3 zeigt Ansatzpunkte für eine Servicetypologie zur Unterstützung der Serviceentwicklung.

5.3.1

Projektgetriebene und vorausplanende Identifikation von Services

Die Fallstudien zeigen zwei grundsätzliche Vorgehensweisen bei der Serviceidentifikation: Eine fallweise Identifikation pro Fachprojekt und eine domänenbezogene, vorausplanende Serviceidentifikation. Bei der projektgetriebenen Identifikation findet keine architekturweite, vorausschauende Planung des Serviceportfolios durch die zentrale IS-Architektur oder die Domänenverantwortlichen statt. Stattdessen formuliert die zentrale IS-Architektur klare Richtlinien, unter welchen Bedingungen im Rahmen von Applikationsentwicklungsprojekten Services entwickelt und genutzt werden müssen und überwacht ihre Einhaltung in einem Projektreview-Prozess. Credit Suisse identifiziert und entwickelt Services dann, wenn ein Fachprojekt eine bestimmte Funktion benötigt. Die Projekte beschreiben im Rahmen einer Anforderungsanalyse die benötigten Funktionen der zu entwickelnden Lösung und ihre Effekte auf Daten. Anhand der Domänenzugehörigkeiten einzelner Funktion und Daten entscheidet die zentrale Architektur, ob bestehende Services wieder verwendet oder ob neue Services entwickelt werden müssen (s. Kap. 5.3.3). Je nachdem, auf welchen technischen Plattformen Serviceanbieter und -nutzer implementiert sind und welche nichtfunktionalen Anforderungen an ihre Kommunikation bestehen, bestimmt sie ausserdem den zu entwickelnden Servicetyp (Private oder Public) und den zu verwendenden Integrationsbus. Diese Entscheidungen werden im Rahmen des Review-Prozesses getroffen, den jedes Fachprojekt durchlaufen muss (Qualitätscheck 1, s. Kap. 5.1.4). Bei der vorausplanenden Serviceidentifikation bestimmen die zentrale IS-Architektur und einzelne Domänenverantwortliche gemeinsam, welche Services eine Domäne übergreifenden Geschäftsprozessen zur Verfügung stellen soll. Das Serviceportfolio einer Applikationsdomäne wird damit aus Serviceanbieter-Sicht geplant, bevor konkrete Fachprojekte die Services in ihre Lösungen integrieren.

148

5 Architekturmanagement und Servicedesign

Ein Service kann im Voraus oder gemeinsam mit dem ersten nutzenden Fachprojekt implementiert werden. Deutsche Post Brief identifizierte Services vorausplanend pro Applikationsdomäne. Das Vorgehen orientierte sich dabei an der objektorientierten Systementwicklung. Grundlage bildeten Fachklassenmodelle, welche die wesentlichen Geschäftsentitäten einer Domäne sowie ihre Beziehungen zueinander (auch domänenübergreifend) beschrieben. Die Fachklassen stellten Kandidaten für mögliche Services wie z.B. „CustomerManagement“ dar. Anhand der Basisoperationen Create, Read, Update, Delete (CRUD) auf den Fachklassen und deren wichtigsten Attributen wurden Serviceoperationen wie bspw. „createCustomer“ oder „readCustomer“ definiert. In einem nächsten Schritt fand eine Eliminierung überflüssiger Services durch eine Analyse der domänenübergreifenden Prozesse statt. Aus diesen leiteten die Servicearchitekten Anwendungsfälle (Use Cases) und Domänenbeziehungen ab. Sie verwarfen Servicekandidaten bzw. Serviceoperationen, die nur in einem Use Case genutzt wurden und kein Wiederverwendungspotenzial hatten bzw. nur innerhalb einer Domäne Verwendung fanden. Beide Ansätze weisen Vor- und Nachteile auf (s. Tabelle 5-7). Die projektgetriebene Serviceidentifikation erlaubt einen pragmatischen Aufbau der Servicearchitektur. Zum einen entstehen keine zusätzlichen Projektaufwände durch eine architekturweite Prozess- und Domänenanalyse, und Services werden schnell entwickelt und genutzt. Weiter werden Services nach den Prioritäten der Fachbereiche umgesetzt. Die Serviceentwicklung ist damit in das bestehende Projektportfoliomanagement eingebunden. Fachprojekte in der Rolle von Servicekonsumenten sind die Auftraggeber für die Serviceentwicklung und haben ein inhärentes Interesse, sich am Servicedesign, der Entwicklung und dem Testen zu beteiligen. Nachteil dieses Ansatzes ist, dass die domänenorientierte, projekt- und serviceübergreifende Sicht verloren geht: Domäneninterne Verbesserungs- und Wiederverwendungspotenziale, die z.B. aus einer Applikationskonsolidierung bzw. einer alternativen Modularisierung in Subdomänen entstehen, zeigen sich u.U. erst spät, nach der Abwicklung mehrerer Projekte. Die Serviceidentifikation und -entwicklung findet ausserdem primär aus der Sicht eines Servicekonsumenten statt, wodurch die Wiederverwendbarkeit der Services für andere Nutzer leiden kann. Das Vorgehen erschwert es Domänenverantwortlichen ausserdem, das Service-Portfolio längerfristig zu planen und z.B. Sourcing- oder Kommerzialisierungsstrategien zu entwickeln oder eine Kapazitätsplanung zu machen. Diese Planbarkeit ist ein Vorteil der vorausplanenden Serviceidentifikation. Domänenverantwortliche haben eine bessere Übersicht über die Anforderungen mehrerer Servicenutzer und können Wiederverwendungspotenziale, Kapazitäts- und Ressourcenanforderungen etc. besser abschätzen. Sie können die interne Domänenarchitektur und die Serviceleistungen daran ausrichten. Nachteile der vorausplanenden Serviceidentifikation sind die zusätzlich notwendigen Anfangsinvestitionen und u.U. eine mangelhafte Beteiligung der Servicenutzer: Der zukünftige Bedarf an Services lässt sich nur bei guter Kenntnis der Anforderungen aller potenziellen Nutzer und der domänenenübergreifenden Prozesse planen. Die notwendigen Anforderungsanalysen stellen einen von Fachprojekten losgelösten, initialen Aufwand dar, der keinen kurzfristigen Geschäftsnutzen generiert. Die

5.3 Serviceidentifikation und -design

149

Nachteile

Vorteile

Serviceidentifikation wird von den Domänenverantwortlichen als Serviceanbieter getrieben und die Fachbereiche haben evtl. wenig Interesse, sich daran zu beteiligen. Besonders wenn Services auch im Voraus und unabhängig von Fachprojekten implementiert werden, besteht die Gefahr, dass sie nicht den tatsächlichen Anforderungen der Servicenutzer entsprechen und nachträglich angepasst werden müssen. Projektgetriebene Serviceidentifikation

Vorausplanende, domänenorientierte Serviceidentifiaktion

• Geringere initiale Aufwände für die Serviceidentifikation.

• Umfassende Erhebung der Anforderung mehrerer Servicenutzer an mehrere Services einer Domäne.

• Schnelle, schrittweise Entwicklung von Services. • Gute Beteiligung der Servicenutzer und Fachbereichsmitarbeiter an der Serviceidentifikation und Entwicklung. • Projekt- und serviceübergreifende Sicht fehlt; Gefahr, dass domäneninterne Verbesserungspotenziale nicht beachtet werden und entwickelte Services mangelhaft wieder verwendbar sind. • Schlechte Planbarkeit für Domänen- / Serviceverantwortliche, strategisches Management des Serviceportfolios schwierig.

• Gute Planbarkeit für Domänen- / Serviceverantwortliche.

• Initialer, fachprojektunabhängiger Aufwand für die Serviceidentifikation. • Ggf. schlechte Beteiligung der potenziellen Servicenutzer, da durch Serviceanbieter getrieben und unabhängig von konkreten Fachprojekten. • Gefahr, dass überflüssige Services entwickelt werden oder Services nicht den tatsächlichen Bedürfnissen der Nutzer entsprechen.

Tabelle 5-7: Vor- und Nachteile der Ansätze zur Serviceidentifikation Aufgrund der Vor- und Nachteile einer rein projektgetriebenen und einer rein vorausplanenden Serviceidentifikation empfiehlt sich eine Kombination der beiden Ansätze. Die vorausplanende Identifikation bietet sich besonders für die Domänen an, die Funktionalität mit hoher strategischer Bedeutung oder hohem Wiederverwendungs-, Auslagerungs- oder Kommerzialisierungspotenzial umfassen [vgl. Dodd 2005c]. Sie werden im Rahmen der Potenzialanalyse (s. Kap. 5.1.2) und der Domänenabgrenzung (s. Kap. 5.2.3) bestimmt. Ergänzend sollte die zentrale Architektur Reviewprozesse und Kriterien formulieren, welche eine kontinuierliche, projektgetriebene Serviceidentifikation sicherstellen.

5.3.2

Methoden für das Servicedesign

Unabhängig davon, wie ein Unternehmen Services identifiziert, sind Methoden notwendig, die eine Umsetzung der SOA-Standards und Designprinzipien in der Softwareentwicklung unterstützen. Als Kandidaten dafür werden in der Literatur

150

5 Architekturmanagement und Servicedesign

Methoden aus der komponentenorientierten Systementwicklung und aus der Geschäftsprozess- bzw. Workflowmodellierung diskutiert (s. [Stojanovic 2005], [Kotonya et al. 2005], [Zimmermann et al. 2004a]). Eignung bestehender Methoden Komponentenorientierte Entwicklungsmethoden25 geben nützliche Hinweise für die Dekomposition und Komposition von Softwaresystemen unter Berücksichtigung von Designprinzipien wie Schnittstellenorientierung, geeignete Bindung (Kohäsion und Kopplung) oder Wiederverwendung (s. [Zimmermann et al. 2004a], [Kotonya et al. 2005, 156]). Komponententechnologien werden generell auch als ein geeigneter Ansatz für die Implementierung von Services betrachtet ([Stojanovic 2005 105], [Veryard 2003, 15]). Herkömmliche komponentenorientierte Entwurfsmethoden weisen für das Servicedesign aber Mängel auf: •

Gestaltungsobjekte sind i.d.R. einzelne Applikationen; eine architekturweite Sicht fehlt [s. Zimmermann et al. 2004a]. Es mangelt auch an geeigneten Hilfsmitteln, um Funktionen zu Services und Services zu Applikationsdomänen zu gruppieren [s. Kotonya et al. 2005, 157].

•

Die Methoden bewegen sich auf einer sehr feinen Granularitäts- bzw. Abstraktionsebene. Die resultierenden Services sind zu feingranular und zu entitätsorientiert, um sich als Wiederverwendungsobjekte in grösseren Systemarchitekturen oder für eine Geschäftsprozessmodellierung zu eignen (s. [Zimmermann et al. 2004a], [Stojanovic 2005, 163f.]).

•

Sie basieren oft auf objektorientierten Designprinzipien und verwenden Konzepte wie bspw. Vererbung, die für einen serviceorientierten Entwurf nicht geeignet sind (s. [Zimmermann et al. 2004a], [Stojanovic 2005, 163f.]). Die Gestaltungsobjekte prozessorientierter Ansätze aus der Prozess- und Workflowmodellierung bewegen sich eher auf einer servicegerechten Abstraktionsebene. Sie leiten applikationsübergreifenden Integrationsbedarf auf Basis von fachlich modellierten Aktivitäten, Abläufen und Datenflüssen ab, die besser dem anzustrebenden Leistungsumfang von Services entsprechen (s. [Zimmermann et al. 2004a], [Stojanovic 2005, 161]). Auch sie weisen aber Mängel auf: •

Sie zielen meist auf die Verbesserung einzelner Prozesse bzw. Prozessgruppen ab und vernachlässigen die Sicht auf die Gesamtarchitektur. Sie berücksichtigen ähnliche, über verschiedene Prozesse verteilte Aktivitäten zu wenig und bieten kaum Hilfsmittel zur Identifikation wieder verwendbarer Funktionen oder zur geeigneten Modularisierung der Applikationsarchitektur (s. [Latimore/Robinson 2004, 3], [Zimmermann et al. 2004a]).

•

Zwischen der Modellierung von Prozessen und ihrer systemtechnischen Implementierung kommt es zu einem Bruch, da die Methoden die Übersetzung von Prozessmodellen in Modelle für die Applikationsentwicklung schlecht unterstützen [s. Zimmermann et al. 2004a].

25

Eine ausführliche Diskussion der Eignung verschiedener komponentenorientierter Entwurfsmethoden findet sich in [Stojanovic 2005, 50ff.].

5.3 Serviceidentifikation und -design

151

Heute verbreitete Methoden für die Systementwicklung eignen sich damit nur beschränkt für das Servicedesign. Deshalb beschreiben die folgenden Abschnitte fünf Methodenvorschläge für die Identifikation und das Design von Services in einer SOA. SOA-spezifische Methoden Methoden, die explizit das Servicedesign zum Inhalt haben, werden in der Literatur erst seit kurzem behandelt und sind in der Praxis noch nicht verbreitet. Ausschlaggebend für die Auswahl einer Methode war daher nicht die Häufigkeit ihrer Anwendung in der Praxis, sondern eine hinreichende Dokumentation in der Literatur. Ausserdem sollten ein breites Spektrum an Vorgehensansätzen (prozess-, komponenten- oder datenorientiert) und unterschiedliche Institutionen bzw. Herkünfte berücksichtigt werden. Tabelle 5-8 gibt eine Übersicht. Methode

Kurzcharakterisierung

Herkunft

SOAD – Serviceoriented architecture and design [Endrei et al. 2004]

Serviceidentifikation durch Domänenzerlegung in funktionale Bestandteile. Baut auf Techniken der komponentenorientierten Systementwicklung auf.

Analyst / Softwareanbieter

Practical service specification and design [Dodd 2005a]

Serviceidentifikation und Design sowohl projektgetrieben über Prozesszerlegung als auch Entwicklung einer unternehmensweiten Domänenarchitektur und vorausplanende Serviceidentifikation über funktionale Zerlegung einer Applikationsdomäne. Baut auf Techniken der Prozessmodellierung und Komponentenorientierung auf.

Analyst

A method for component-based and service-oriented systems engineering [Stojanovic 2005]

Eher vorausplanende Serviceidentifikation, allerdings nicht domänenweit, sondern für ein einzelnes Anwendungssystem (Komponentisierung einer Applikation und Identifikation der von ihr zur Verfügung gestellten Services). Baut auf bestehenden komponentenorientierten Methoden auf.

Wissenschaft

Design of service interfaces for e-business applications using data normalization techniques [Feuerlicht 2005]

Identifikation und Design industriespezifischer zwischenbetrieblicher Web Services auf Basis von Dokumenten- und Prozess-Industriestandards.

Wissenschaft

A business model for deploying web services: A data-centric approach based on factual dependencies [Baghdadi 2005]

Unternehmensweites datenorientiertes Vorgehen für die Identifikation und das Design von Services; Analyse der Auswirkungen von Geschäftsereignissen auf Geschäftsentitäten.

Wissenschaft

Tabelle 5-8: Kurzcharakterisierung der untersuchten Methoden

152

5 Architekturmanagement und Servicedesign

Im Vordergrund der Methodenbeschreibung stehen die Fragen, wie die Ansätze Services identifizieren und wie sie die SOA-Designprinzipien unterstützen. Die untersuchten Methoden behandeln hautpsächlich das fachliche Design von Services. Die technische Serviceimplementierung oder die Entwicklung der technischen Integrationsinfrastruktur sind i.d.R. keine Methodenbestandteile. Aus diesem Grund betrachtet der Methodenvergleich nur Aspekte der SOA-Designprinzipien, die bereits in der Phase der fachlichen Anforderungsanalyse und des fachlichen Designs berücksichtigt werden sollten. Sie sind in Tabelle 5-9 aufgeführt.

Bedarfsorientierung

Autonomie und Modularität

Interoperabilität

Schnittstellenorientierung

Designprinzip

Kriterien bei der Methodenuntersuchung

Abstraktion von der Serviceimplementierung

Werden Services in der Analyse- / Entwurfsphase plattform- und technologieneutral modelliert und beschrieben?

Umfassende Servicespezifikation

Enthält die Methode eine umfassende Servicespezifikation und definiert sie die zu beschreibenden Elemente?

Stabile, gemanagte Servicekontrakte

Sieht die Methode die Definition verbindlicher Schnittstellenkontrakte und SLAs vor?

Technische Schnittstellenstandardisierung

Nicht berücksichtigt, da hauptsächlich in der Phase der Serviceimplementierung relevant.

Fachliche Schnittstellenstandardisierung

Sieht die Methode die Berücksichtigung fachlich-semantischer Standards (einheitliche Datenmodelle, Namenskonventionen, einheitliche Fehlercodes etc.) für das Servicedesign vor?

Verwendung offener und verbreiteter Industriestandards

Sieht die Methode eine Prüfung fachlicher Industriestandards vor?

Hohe Servicekohäsion und schwache logische Kopplung

Untersucht die Methode Kohäsions- und Kopplungsbeziehungen auf Domänen- und / oder Serviceebene?

Lose gekoppelte Kommunikation

Untersucht die Methode nicht-funktionale Anforderungen an das Kommunikationsverhalten von Services (Zeitanforderungen, Datenvolumen, Zustandsbehaftung)?

An Geschäftskonzepten orientierte Servicegranularität

Modelliert die Methode Services auf einer geeigneten Granularitätsebene? Überprüft sie die Servicegranularitäten anhand Eigenschaften wie Stabilität, Wiederverwendbarkeit oder Performanz?

Generalisierung der Serviceleistung

Liefert die Methode Techniken bzw. Hilfsmittel für eine Generalisierung von Services mit dem Ziel der besseren Wiederverwendung?

Tabelle 5-9: Berücksichtigte Designprinzipien bei der Methodenuntersuchung

5.3 Serviceidentifikation und -design

153

SOAD – Service-oriented Architecture and Design Der Consultingbereich von IBM entwickelte SOAD als Bestandteil des SOABeratungsangebotes. Verschiedene Publikationen beschreiben die Methode (s. [Levi/Arsanjani 2002], [Arsanjani 2004], [Endrei et al. 2004], [Zimmermann et al. 2004a]). Ihr Ziel ist „to uncover the business aligned services, their dependencies and their large grained components“ [Endrei et al. 2004, 80]. Sie baut auf bestehenden objekt- und komponentenorientierten Methoden auf (hauptsächlich dem Unified Rational Process, RUP) und erweitert diese um Aktivitäten für eine geschäftsprozessorientierte Domänendekomposition (Domain Decomposition) und eine Identifikation von Services anhand von Geschäftszielen (Goal-Service Model Creation). [Endrei et al. 2004] ergänzen die Methode zusätzlich um einen schrittweisen Entwurf der notwendigen Laufzeit- und Integrationsinfrastruktur anhand der „IBM Patterns for e-business“ [s. Adams et al. 2002]. Das Vorgehensmodell der Methode ist in die drei Phasen Identifikation, Spezifikation und Realisierung unterteilt und umfasst sieben Hauptaktivitäten.26 Abb. 5-10 zeigt das Vorgehensmodell und Tabelle 5-10 führt die Hauptergebnisse bzw. Inputdokumente der Aktivitäten auf. Identification Domain decomposition

Specification

Goal-service model creation

Subsystem analysis 2

3

Service classification and allocation 4

Realization Component specification and structuring 5

Service realization mapping

1 Existing asset analysis 6

Abb. 5-10: Hauptaktivitäten und Ergebnisfluss Nr.

26

Ergebnisdokumente

1

„Enterprise Components“ als fachliche Domänen, Geschäfts-Anwendungsfälle („Business Use Case“-Modell) als Servicekandidaten

2

„Goal Service“-Modell (zusätzliche Servicekandidaten)

3

Geschäftsobjekt-Modell, „Business Components“ (Subsysteme) und ihre Abhängigkeiten (Datenflüsse), System-Anwendungsfälle

4

Zuordnung von Services zu „Business Components“

Die Anzahl Aktivitäten und ihre Bezeichnungen variieren je nach Quelle. Aktivitäten mit gestricheltem Rahmen werden in den verwendeten Publikationen zwar genannt, aber nicht beschrieben.

154

5 Architekturmanagement und Servicedesign

Nr.

Ergebnisdokumente

5

Komponenten- und Servicespezifikation

6

Schnittstellen, Transaktionen und Module existierender Alt- / StandardsoftwareApplikationen

Tabelle 5-10: Hauptergebnisse Tabelle 5-11 beschreibt die Aktivitäten der Methode und gibt einen Überblick über die unterstützenden Techniken. Aktivität / Vorgehensschritte

Techniken / Entscheidungshilfen

Domain decomposition Untersuchte Geschäftsdomäne in Funktionsbereiche bzw. „Enterprise Components“ zerlegen (z.B. „Warehouse“, „Manufacturer“).

Nur grobe Kriterien zur Domänendekomposition: „Based on department boundaries, business process boundaries, and value chains”.

Pro Enterprise Component Teilprozesse bzw. “Geschäfts-Anwendungsfälle” („highlevel, coarse-grained use cases like purchase goods”) ableiten (stellen Servicekandidaten dar). Datenflüsse zwischen Anwendungsfällen beschreiben.

-

Enterprise Components und Datenflüsse für das schrittweise Design der Integrationsinfrastruktur auf „Business“ und „Application Integration Patterns“ abbilden.

IBM Patterns for e-business.

Goal-service model creation Zusätzliche funktionale Anforderungen aus Geschäftszielen ableiten, liefert weitere Servicekandidaten.

Vorgehen und Vorlage zur Dokumentation.

Subsystem analysis Geschäfts-Anwendungsfall-Modell mit Servicekandidaten aus dem Goal-serviceModell erweitern.

-

Innerhalb einer Enterprise Component die zu unterstützenden SystemAnwendungsfälle entwickeln und Enterprise Component in „Business Components“ (z.B. Kunde, Produkt) zerlegen.

Grobes Vorgehen für Verfeinerung der Geschäfts-Anwendungsfälle (Prozesszerlegung in elementare Schritte).

Komponentenmodell auf „Application Patterns“ abbilden.

IBM Patterns for e-business.

5.3 Serviceidentifikation und -design

155

Aktivität / Vorgehensschritte

Techniken / Entscheidungshilfen

Service classification and allocation Servicehierarchie entwickeln: Services Ebene Enterprise Component in feingranularere Services auf Ebene Business Components zerlegen.

-

Bisher identifizierte Services Komponenten zuordnen.

-

Component specification and structuring Komponenten beschreiben / spezifizieren.

Grobe Vorlage mit zu beschreibenden Elementen.

Komponenten auf „Runtime Patterns“ abbilden, um benötigte Middlewarekomponenten zu identifizieren.

IBM Patterns for e-business.

Service realization mapping Entscheid über Art der Serviceimplementierung (existierendes System vs. Neuentwicklung).

Nennung von Implementierungsoptionen, ohne Diskussion.

Identifizierte Middlewarekomponenten anhand „Product Mapping Patterns“ auf IBM-Produkte abbilden.

IBM Patterns for e-business.

Tabelle 5-11: Aktivitäten und Techniken der Methode Die Methode identifiziert Services, indem sie einen grösseren Funktionsbereich (z.B. Kooperationsprozesse Beschaffung und Vertrieb) in seine groben funktionalen Bestandteile zerlegt und in Domänen gruppiert (Enterprise Components, z.B. Lager, Produzent etc.). Domänenübergreifende Geschäftsprozesse liefern erste Servicekandidaten. Eine weitere Zerlegung der Enterprise Components in Teilprozesse, Geschäftsobjekte und Anwendungsfälle (Use Cases) mit herkömmlichen Techniken der komponentenorientierten Systementwicklung detailliert diese. Das Ableiten funktionaler Anforderungen aus den Geschäftszielen des Funktionsbereichs hilft beim Identifizieren zusätzlicher Services. Bspw. bestimmen [Endrei et al. 2004, 91] aus dem Ziel der besseren Kundenunterstützung durch schrittweises Verfeinern Services wie „Get Catalog“ oder „Manage Shopping Cart“. Die Methode erwähnt im Verlauf des Servicedesignprozesses viele der SOADesignprinzipien, unterstützt ihre Umsetzung aber kaum durch konkrete Techniken und Entscheidungshilfen. Tabelle 5-12 gibt einen Überblick über die methodische Unterstützung der Designprinzipien.

156

5 Architekturmanagement und Servicedesign

Designprinzip

Berücksichtigung

Erläuterung

Abstraktion von der Serviceimplementierung



Implementierungsneutrale Servicemodellierung, keine konkreten Angaben bez. Notationssprachen.

Umfassende Servicespezifikation



Detaillierte Servicespezifikation in Aktivität „component specification and structuring“ vorgesehen, keine konkrete Vorlage.

Stabile, gemanagte Servicekontrakte



-

Fachliche Schnittstellenstandardisierung



Verwendung offener und verbreiteter Industriestandards



Hohe Servicekohäsion und schwache logische Kopplung Lose gekoppelte Kommunikation

An Geschäftskonzepten orientierte Servicegranularität Generalisierung der Serviceleistung

Als übergeordnete Governance-Massnahme erwähnt.

-



Auf Domänenebene im Rahmen der „domain decomposition“ behandelt. Nur vage Abgrenzungskriterien, keine detaillierten Entscheidungshilfen („decompopsition based on department boundaries, business process boundaries, and value chains”).



Untersuchung nichtfunktionaler Anforderungen an die Kommunikation von Services in den Aktivitäten „subsystem analysis“ und „component specification and structuring“ erwähnt, keine detaillierte Entscheidungshilfen.



An Geschäftskonzepten orientierte Granularität durch Identifikation der Services aus Geschäftszielen, Prozessaktivitäten und Geschäftsentitäten. Überprüfung der Servicegranularität in „service classification and allocation“ diskutiert, keine detaillierte Entscheidungshilfen.



Variantenanalyse in den Aktivitäten „domain decomposition“, „subsystem analysis“ und „component specification and structuring“ erwähnt, keine Anleitungen.

 Explizit berücksichtigt, Anleitungen vorhanden Explizit oder implizit berücksichtigt, keine detaillierten Anleitungen Nicht berücksichtigt

Tabelle 5-12: Methodische Unterstützung der Designprinzipien

5.3 Serviceidentifikation und -design

157

Practical Service Specification and Design Das Analysten-Unternehmen CBDI Forum entwickelte diese Methode und veröffentlichte sie in einer Artikelserie (s. [Dodd 2005a], [Dodd 2005b], [Dodd 2005c], [Dodd 2005d], [Dodd 2005e]). Ziel der Methode ist “to provide guidance on how to develop software services for long-term value while addressing the needs of current projects” [s. Dodd 2005a, 22]. Sie umfasst die Identifikation und das fachliche Design von Services bis hin zur detaillierten Servicespezifikation und dem Treffen von Implementierungsentscheidungen. Die Methode baut auf Ansätzen der Prozessmodellierung, der komponentenorientierten Systementwicklung und des „Domain Engineering“ [s. Kang et al. 1990] auf. Die Methode unterscheidet in Anlehnung an unterschiedliche Projekttypen im Umfeld des Servicedesigns vier Phasen mit jeweils einer Hauptaktivität (s. Abb. 5-11). Tabelle 5-13 führt die wichtigsten Ergebnisse auf. Service portfolio planning Service planning and architecture

Business process Software solution improvement delivery Business process design

1

Refining service requirements (consumer) 4

3

Service provisioning Refining service requirements (provider) 6

Service implementation

5 2

Abb. 5-11: Hauptaktivitäten und Ergebnisfluss Nr.

Ergebnisdokumente

1

Geschäfts- und IS-Ziele, grobe Prozess- und Geschäftsobjekt-Modelle, Designrichtlinien der technischen Infrastruktur

2

Geschäftsziele, Prozessprioritäten

3

Prozessflüsse und Funktions- und Datenbedarf in Form von SystemAnwendungsfällen

4

Grobe Servicespezifikation aus Nutzer- / Prozesssicht

5

Servicedesign- und Entwicklungsrichtlinien

6

Detaillierte Servicespezifikation und Implementierungs- bzw. Anbieterentscheidung

Tabelle 5-13: Hauptergebnisse Tabelle 5-14 beschreibt die Aktivitäten der Methode und gibt einen Überblick über die unterstützenden Techniken.

158

5 Architekturmanagement und Servicedesign Aktivität / Vorgehensschritte

Techniken / Entscheidungshilfen

Service planning and architecture Servicedomänen definieren.

Grobes Template für Domänenbeschreibung, keine Hilfsmittel für die Domänendekomposition.

SOA-Architekturrichtlinien definieren.

Checkliste mit zu definierenden technischen, fachlichen und organisatorischen Richtlinien.

Services pro Domäne grob identifizieren.

-

Architekturentwicklung planen (technische Infrastruktur, projektunabhängig zu entwickelnde Services).

-

Business Process Design Soll-Geschäftsprozess in Prozessflussdiagramm modellieren.

UML-Template (Aktivitätsdiagramm).

Refining service requirements (comsumer) System-Anwendungsfälle aus elementaren Prozessaktivitäten ableiten und bestehende, anzupassende oder neu zu entwickelnde Anwendungsfälle identifizieren.

UML-Template (Anwendungsfalldiagramm), keine Hinweise für Ableitung von Use Cases aus Prozessaktivitäten.

Neu zu entwickelnde / anzupassende Anwendungsfälle in elementare Schritte verfeinern und Serviceoperationen bestimmen.

UML-Templates (Anwendungsfalldiagramm), keine Hinweise, wie geeignete Serviceoperationen aus Anwendungsfällen abgeleitet oder wie Serviceoperationen zu Services gruppiert werden sollen.

Durch Anwendungsfälle abgebildete Teilprozesse in einem Sequenzdiagramm modellieren und ggf. zusätzliche Serviceoperationen identifizieren.

UML-Template (Sequenzdiagramm).

Refining service requirements (provider) Ggf. Services innerhalb einer Domäne projektunabhängig und vorausplanend entwickeln, durch funktionale Domänendekomposition oder Prozessflussanalyse.

Grobe Heuristiken und Vorgehensmodelle für eine proaktive Serviceentwicklung.

Serviceanforderungen generalisieren.

Liste mit möglichen Massnahmen zur Servicegeneralisierung.

Sourcing-Optionen und Vermarktungspotenzial des Services prüfen.

Grobe Vorlage für Analyse, grobe Checkliste mit Kriterien für Servicevermarktung.

5.3 Serviceidentifikation und -design

159

Aktivität / Vorgehensschritte

Techniken / Entscheidungshilfen

Detaillierte Servicespezifikation erstellen.

Vorlage für Servicespezifikation, Vorschlag für Notationsformen.

Serviceanbieter auswählen.

Abgrenzung und grobe Diskussion der Vorund Nachteile von 12 Sourcing- bzw. Implementierungsoptionen.

Tabelle 5-14: Aktivitäten und Techniken der Methode Die Methode geht davon aus, dass Services primär im Rahmen von Projekten zur Prozessverbesserung identifiziert werden. Sie leitet Services aus elementaren Prozessaktivitäten in Prozessflussdiagrammen ab. Obwohl die Methode die Entwicklung einer Domänenarchitektur in der Aktivität „service planning and architecture“ als übergeordnete Massnahme vorsieht, bezieht sie Domänengrenzen bei der Serviceidentifikation nicht mit ein: Unabhängig von der Domänenzugehörigkeit von Funktionen und Daten geht sie davon aus, dass jede Prozessaktivität als Service implementiert wird. Als Ergänzung der projektgetriebenen Serviceidentifikation skizziert die Methode Ansätze für eine vorausplanende, domänenorientierte Serviceidentifikation. Sie behandelt die meisten SOA-Designprinzipien und liefert auch verschiedene Vorlagen und Techniken bzw. Entscheidungshilfen, z.B. für die Servicespezifikation oder die Servicegeneralisierung (s. Tabelle 5-15). Nicht explizit berücksichtigt wird das Designprinzip der hohen Domänen- oder Servicekohäsion und ihrer schwachen Kopplung: Die Methode gibt keine Hinweise darauf, wie Serviceoperationen zu gruppieren und wie in der Applikationsarchitektur Domänen zu bilden sind. Designprinzip

Berücksichtigung

Erläuterung

Abstraktion von der Serviceimplementierung



Implementierungsneutrale Servicemodellierung in UML.

Umfassende Servicespezifikation



Detaillierte Servicespezifikation in „refining service requirements (provider)“ anhand Vorlage.

Stabile, gemanagte Servicekontrakte



SLA-Formulierung im Rahmen der Servicespezifikation vorgesehen.

Fachliche Schnittstellenstandardisierung



Definition domänenweit standardisierter Daten- bzw. Informationsmodelle, einheitliche fachliche Servicebeschreibung mit standardisierter Terminologie etc. in „service planning and architecture“ und „refining service requirements (provider)“ vorgesehen.

Verwendung offener und verbreiteter Industriestandards



Prüfung von Industriestandards in „service planning and architecture“ vorgesehen, keine Entscheidungshilfen für Auswahl.

160

5 Architekturmanagement und Servicedesign

Designprinzip

Hohe Servicekohäsion und schwache logische Kopplung Lose gekoppelte Kommunikation

An Geschäftskonzepten orientierte Servicegranularität Generalisierung der Serviceleistung

Berücksichtigung

Erläuterung



„Zusammengehörigkeit“ von Funktionen und Daten im Rahmen der Domänenidentifikation erwähnt ,aber keine konkreten Kriterien für die Domänendekomposition genannt. Domänenkonzept wird bei der prozessorientierten Serviceidentifikation nicht berücksichtigt.



Entwicklung von Entscheidungsgrundlagen für das Kommunikationsverhalten von Services in „service planning and architecture“ vorgesehen, keine Entscheidungshilfen.



An Geschäftskonzepten orientierte Granularität durch Identifikation von Services aus Prozessaktivitäten. Keine explizite Überprüfung der Servicegranularität.



Behandelt im Rahmen einer domänenorientierten Anforderungsanalyse in „refining service requirements (provider)“, Massnahmen zur Servicegeneralisierung aufgeführt.

 Explizit berücksichtigt, Anleitungen vorhanden Explizit oder implizit berücksichtigt, keine detaillierten Anleitungen Nicht berücksichtigt

Tabelle 5-15: Methodische Unterstützung der Designprinzipien Method for Component-Based and Service-Oriented Systems Engineering [Stojanovic 2005] beschreibt in seiner Dissertation eine Methode für eine komponenten- und serviceorientierte Systementwicklung. Schwerpunkte der Methode sind die Analyse- und Designphase der Anwendungsentwicklung mit der Identifikation von Services anhand gegebener Geschäftsanforderungen, ihrer Zuordnung zu grobgranularen Geschäftskomponenten („business components“) und der feineren Zerlegung der Geschäftskomponenten in Applikationskomponenten („application components“). Die Methode baut auf bewährten Techniken aus der objektund komponentenorientierten Systementwicklung auf und verwendet das ISO standard Reference Model of Open Distributed Processing (RM-ODP) und ModelDriven Architecture (MDA, [s. OMG 2004]) zur Herleitung der Methodenkonstrukte. Sie zeichnet sich im Vergleich zu bestehenden komponentenorientierten Ansätzen u.a. dadurch aus, dass sie Komponentenkonzepte wie Kapselung, hohe

5.3 Serviceidentifikation und -design

161

Kohäsion und schwache Kopplung auf einer servicegerechten Abstraktions- bzw. Granularitätsebene27 anwendet [s. Stojanovic 2005, 209f.]. Das Vorgehensmodell der Methode orientiert sich an den Modellierungsebenen der MDA.28 Es beschreibt hauptsächlich drei Aktivitäten zur Entwicklung eines plattformunabhängigen Komponentenmodells und eine Aktivität zur Entwicklung eines plattformspezifischen Modells (s. Abb. 5-12). Tabelle 5-16 führt die Hauptergebnisse auf. Computation independent Business Model

Platform independent Model Business Component Model

Business Domain Model

4

Application Component Model

2 1

Implementation specific model

7 Implementation Component 8 Model

5

Component Refactoring 3

Platform specific model

Implementation and deployment

6

Abb. 5-12: Hauptaktivitäten und Ergebnisfluss Nr.

27

28

Ergebnisdokumente

1

Geschäftsziele, Prozesse, Geschäftsobjekte / Fachklassen und Geschäftsvorfälle im Anwendungsbereich des zu entwickelnden Systems („Business Domain Model“)

2

Grobes Business Component-Modell mit angebotenen Services und deren Kopplung untereinander

3

Überarbeitetes, auf Redundanzen, Kohäsion und Kopplung geprüftes Business Component-Modell

4

Vollständig spezifiziertes Business Component-Modell für neu zu entwickelnde Business Components

5

Grobes Application Component-Modell mit Schnittstellen und Kopplungsbeziehungen

Die Methode unterscheidet vier Granularitätsebenen von Komponenten [s. Stojanovic 2005, 102ff.]. „Enterprise Components“ stellen für sich alleine stehende Anwendungssysteme innerhalb einer Domäne dar. Sie können sich aus „Business Components“ zusammensetzen. Diese stellen Services zur Verfügung, die einen aus Geschäftssicht sinnvollen und messbaren Wert bieten und einzelne automatisierbare Schritte von Geschäftsprozessen unterstützen. Sie können wiederum in Form von „Application Components“ implementiert sein, die Funktionsbausteine ohne unmittelbaren Geschäftsbezug darstellen und typischerweise abgegrenzte Aufgaben innerhalb einer bestimmten Anwendungsschicht (Präsentation/Benutzerinteraktion, Geschäftslogik, Datenzugriff) übernehmen. Unter „Program Components“ werden typische Klassen bzw. Objekte aus der objektorientierten Systementwicklung verstanden. Die MDA unterscheidet vier Modelle auf unterschiedlichen Abstraktionsebenen: Das Computation independent Model (CIM), das Platform Independent Model (PIM), das Platform Specific Model (PMS) und das Implementations Specific Model (ISM) [s. OMG 2004].

162

5 Architekturmanagement und Servicedesign

Nr.

Ergebnisdokumente

6

Überarbeitetes, auf Redundanzen, Kohäsion und Kopplung geprüftes Application Component-Modell

7

Vollständig spezifiziertes Application Component-Modell für neu zu entwickelnde Application Components

8

Technologiespezifisches Komponentenmodell

Tabelle 5-16: Hauptergebnisse Tabelle 5-17 beschreibt die Aktivitäten der Methode und gibt einen Überblick über die unterstützenden Techniken. Aktivität / Vorgehensschritte

Techniken / Entscheidungshilfen

Business domain model Geschäftsdomäne als Grundlage für die Anforderungsanalyse IS-unabhängig beschreiben.

Durch Methode nicht abgedeckt.

Business Component model Geschäftsanforderungen an das Anwendungssystem analysieren: IS-unterstützte Geschäftsprozesse in „business goal“Anwendungsfälle zerlegen, dynamische Abhängigkeiten zwischen Anwendungsfällen modellieren, Domänen-Fachklassenmodell entwickeln, Anwendungsfälle auf bestehende bzw. neu zu entwickelnde Applikationen abbilden.

Detaillierte Vorgehensbeschreibung, diverse Vorlagen für die Dokumentation (UMLDiagramme).

Business Components identifizieren: Zeitliche Abhängigkeiten und Spezialisierungs- / Generalisierungsbeziehungen zwischen Anwendungsfällen analysieren, Nutzung von Geschäftsobjekten / Fachklassen durch Anwendungsfälle untersuchen, Anwendungsfälle auf Business Components verteilen.

Kriterien zur Abgrenzung von Business Components mit hoher Kohäsion und schwacher Kopplung anhand der Anwendungsfälle, Vorlagen für die Dokumentation (UML-Diagramme).

Identifizierte Business Components spezifizieren.

Beschreibungsvorlage, Vorschläge für Notationsformen.

Application Component model Anhand der Komponentenspezifikationen Implementierungsmöglichkeiten der Business Components im bestehenden IS bewerten.

Implementierungsalternativen.

5.3 Serviceidentifikation und -design

163

Aktivität / Vorgehensschritte

Techniken / Entscheidungshilfen

Application Components und Schichtenarchitektur für neu zu entwickelnde Business Components modellieren und spezifizieren.

Muster-Schichtenarchitektur und Komponententypen, Vorlagen für die Dokumentation (UML-Diagramme).

Component refactoring Business Components bzw. Application Components auf Kopplungs- / Interaktionsaspekte reduzieren und Kopplungsbeziehungen zwischen jeweils zwei Komponenten analysieren.

„9-interaction matrix“ mit Heuristiken zur Analyse von Kopplungsbeziehungen und für die Zerlegung oder Zusammenfassung von Komponenten.

Implementation component model Application Component-Modell auf plattformspezifisches Komponentenmodell transformieren.

Exemplarische Tabelle für eine Abbildung von Application Component-Typen auf EJB-Konstrukte.

Implementation and deployment Komponenten programmieren und verteilen.

Durch Methode nicht abgedeckt.

Tabelle 5-17: Aktivitäten und Techniken der Methode Wichtigstes Methodenkonstrukt aus SOA-Sicht ist das Business Component Model, welches den Anwendungsbereich des zu entwickelnden Systems (bspw. eine Geoinformations- und Routenplanungssystem) in seine Haupt-Funktionsbestandteile zerlegt. Die Methode modelliert hier Services auf einer für SOA geeigneten Granularitätsebene, indem sie Services aus „business goal“-Anwendungsfällen ableitet, die elementare Prozessschritte repräsentieren (bspw. „registrieren“, „Standort abfragen“, „Route berechnen“ etc.). Die Methode berücksichtigt besonders die Designprinzipien der plattformunabhängigen Modellierung, der geschäftskonzeptorientierten Servicegranularität und der hohen Kohäsion und schwachen Kopplung (s. Tabelle 5-18). Eine zentrale Technik ist die „9-interaction matrix“ für das „component refactoring“ [s. Stojanovic 2005, 170ff]: Sie analysiert die Kopplung zwischen Komponenten und liefert Heuristiken für ihre Zerlegung oder Zusammenfassung, um eine redundanzfreie Verteilung von Services auf Komponenten und eine Verbesserung des Kopplungs- und Kohäsionsgrades zu erreichen. Sie lässt sich sowohl auf Ebene „business components“ als auch auf Ebene „application components“ anwenden. Die Methode beinhaltet keine Standardisierungsmassnahmen zur Verbesserung der fachlichen Interoperabilität zwischen Services. Ausserdem ist der primäre Gestaltungsbereich der Methode ein einzelnes Anwendungssystem; sie behandelt weder die Abgrenzung von Applikationsdomänen noch ein domänenweites, applikationsübergreifendes Servicedesign.

164

5 Architekturmanagement und Servicedesign

Designprinzip

Berücksichtigung

Erläuterung

Abstraktion von der Serviceimplementierung



Implementierungsneutrale Servicemodellierung in UML.

Umfassende Servicespezifikation



Detaillierte Servicespezifikation in „Business Component Model“ und „Application Component Model“ anhand einer Vorlage.

Stabile, gemanagte Servicekontrakte



SLA-Formulierung im Rahmen der Komponentenspezifikation behandelt.

Fachliche Schnittstellenstandardisierung



Verwendung offener und verbreiteter Industriestandards



Hohe Servicekohäsion und schwache logische Kopplung



Detailliert behandelt bei der Identifikation von Business Components („Business Component model“) und bei der Überprüfung der Komponentenmodelle im „component refactoring“.



Kommunikationsanforderungen im Rahmen der Anwendungsfall-Analyse („Business Component model“) erhoben, beim Servicedesign aber nicht explizit berücksichtigt.



An Geschäftskonzepten orientierte Granularität durch Identifikation von Services aus „business goal“Anwendungsfällen, die elementare Prozessaktivitäten unterstützen. Kriterien zur Bewertung der Granularität werden diskutiert (Anzahl Aufrufe, NetzwerkOverhead, Verständlichkeit aus Geschäftssicht etc.).



Erwähnt im Rahmen der Anforderungsanalyse, aber nicht explizit behandelt. Betrachtet Wiederverwendbarkeit von Services bzw. Komponenten nicht als wesentliches Gestaltungsziel.

Lose gekoppelte Kommunikation

An Geschäftskonzepten orientierte Servicegranularität Generalisierung der Serviceleistung

-

-

 Explizit berücksichtigt, Anleitungen vorhanden Explizit oder implizit berücksichtigt, keine detaillierten Anleitungen Nicht berücksichtigt

Tabelle 5-18: Methodische Unterstützung der Designprinzipien Design of service interfaces for e-business applications [Feuerlicht 2005] und [Feuerlicht/Meesathit 2004] entwickeln eine Methode für den Entwurf industriespezifischer, zwischenbetrieblicher Serviceschnittstellen durch Anwendung von Datennormalisierungs-Techniken auf Geschäftsdokumen-

5.3 Serviceidentifikation und -design

165

ten- und Geschäftsprozessstandard (z.B. RosettaNet) . Resultat der Methode soll eine Menge redundanzfreier Serviceschnittstellen mit hoher Kohäsion und schwacher Kopplung für den zu unterstützenden zwischenbetrieblichen Prozess sein. Sie deckt nur die Spezifikation von Serviceschnittstellen ab; eine Analyse von Geschäftsanforderungen oder die Modellierung der Serviceimplementierung behandelt sie nicht. Die Methode umfasst drei Schritte für den Entwurf von Serviceschnittstellen (s. Abb. 5-13). Tabelle 5-19 führt die Ergebnisse auf. Design of service interfaces

1

Identification of candidate operations

Refining interface design 2

3

Adjusting granularity of operations

4

Abb. 5-13: Aktivitäten und Ergebnisfluss Nr.

Ergebnisdokumente

1

Industriestandard mit Prozess- / Dokumentenspezifikation

2

Kandidaten für Serviceoperationen mit Input- / Outputparametern

3

Normalisierte Serviceschnittstellen (redundanzfrei, hohe Kohäsion, schwache Kopplung)

4

Aggregierte Serviceschnittstellen (geeignete Granularität)

Tabelle 5-19: Ergebnisse Tabelle 5-20 beschreibt die Aktivitäten der Methode und gibt einen Überblick über die unterstützenden Techniken. Aktivität / Vorgehensschritte

Techniken / Entscheidungshilfen

Identification of candidate operations Prozesse bzw. Geschäftsfunktion in elementare Aktivitäten zerlegen (anhand der Prozessspezifikation des Industriestandards).

-

Serviceoperationen und Input- / Outputparameter pro Aktivität definieren (anhand der Prozessspezifikation des Industriestandards).

-

166

5 Architekturmanagement und Servicedesign Aktivität / Vorgehensschritte

Techniken / Entscheidungshilfen

Refining interface design Serviceschnittstellen normalisieren, ggf. um zusätzliche Operationen ergänzen.

Regeln zur Schnittstellennormalisierung (minimale Anzahl Attribute in Input- und Outputnachrichten, nur funktional von Input abhängige Outputparameter für Abfrageoperationen).

Adjusting granularity of operations Operationen zur Reduktion der Anzahl Aufrufe im Prozess zusammenfassen.

Hinweise für das Zusammenfassen von Operationen, ohne ihre Kohäsion stark zu verschlechtern.

Tabelle 5-20: Aktivitäten und Techniken der Methode Die Methode zerlegt die im Industriestandard29 spezifizierten Prozesse in ihre Basisfunktionen (z.B. Fluganfrage, Sitzplatzanfrage, Preisanfrage etc.) und identifiziert anhand der ausgetauschten Geschäftsdokumente Serviceoperationen, Inputund Outputparameter. Indem sie Regeln zur Datennormalisierung anwendet (minimale Anzahl Attribute in Input- und Outputnachrichten, nur von Inputparametern abhängige Outputparameter), versucht sie die Kohäsion einer Serviceoperation zu erhöhen und ihre Kopplung mit anderen Operationen zu reduzieren. Sie passt anschliessend die Servicegranularität an, indem sie Operationen zusammenfasst, die ähnliche Datenparameter austauschen. Tabelle 5-21 zeigt die methodische Unterstüzung der SOA-Designprinzipien. Designprinzip

Berücksichtigung

Erläuterung

Abstraktion von der Serviceimplementierung



Rein fachlicher, implementierungsneutraler Schnittstellenentwurf.

Umfassende Servicespezifikation



Servicespezifikation auf grobe Servicefunktion und Auflistung von Input- / Outputparametern beschränkt.

Stabile, gemanagte Servicekontrakte



-

Fachliche Schnittstellenstandardisierung



Abstützung auf übergreifendes, standardisiertes Daten- und Prozessmodell; nur Funktionen und Fachdaten berücksichtigt.

Verwendung offener und verbreiteter Industriestandards



Abstützung auf vorhandene Industriestandards.

29

[Feuerlicht 2005] verwendet als Beispiel die Spezifikation der Open Travel Alliance (OTA, s. http://www.opentravel.org).

5.3 Serviceidentifikation und -design

Designprinzip

167

Berücksichtigung

Erläuterung

Hohe Servicekohäsion und schwache logische Kopplung



Verfolgt mit Daten-Normalisierungstechniken. Beschränkt auf Service-Schnittstellen/ Nachrichtenebene.

Lose gekoppelte Kommunikation



Nachrichtenbasierte, statuslose Kommunikation über Web Services vorausgesetzt.

An Geschäftskonzepten orientierte Servicegranularität



Serviceoperationen und unterstützen elementare Prozessaktivitäten, Identifikation aus Geschäftsprozessen und -dokumenten.



Implizit durch Verwendung von Industriestandards und Anpassung der Servicegranularität; auf von einem Standard abgedeckte Prozesse und Dokumente beschränkt.

Generalisierung der Serviceleistung

 Explizit berücksichtigt, Anleitungen vorhanden Explizit oder implizit berücksichtigt, keine detaillierten Anleitungen Nicht berücksichtigt

Tabelle 5-21: Methodische Unterstützung der Designprinzipien A Business model for deploying Web services Der in [Baghdadi 2004] und [Baghdadi 2005] beschriebene Ansatz verfolgt das Ziel, unternehmensweit Services ausgehend von der Geschäfts- und Prozessarchitektur zu identifizieren und entwerfen. Der Autor skizziert ein grobes Vorgehen für die Identifikation, den Entwurf, die Implementierung und Publikation von Services sowie ihre Komposition zu Geschäftsprozessen. Eigentlicher Kern des Methodenvorschlags ist aber nur die Identifikation und der Entwurf von Serviceschnittstellen. Abb. 5-14 gibt einen Überblick über die von der Methode unterstützten Hauptaktivitäten. Tabelle 5-22 führt die Hauptergebnisse auf. Turning data into web services Identification and description of business objects and coordination artifacts

Identification of business events 2

Identification and design of service interfaces 3

Service implementation and registration

1

Abb. 5-14: Hauptaktivitäten und Ergebnisfluss

168

5 Architekturmanagement und Servicedesign

Nr.

Ergebnisdokumente

1

Geschäftsobjekte, Koordinationsartefakte und Attribute

2

Liste mit Geschäftsereignissen

3

Serviceschnittstellen (Operationen, Input- und Outputparameter)

Tabelle 5-22: Hauptergebnisse Tabelle 5-23 beschreibt die Aktivitäten der Methode und gibt einen Überblick über die unterstützenden Techniken. Aktivität / Vorgehensschritte

Techniken / Entscheidungshilfen

Identification and description of business objects and coordination artifacts Geschäftsobjekte, Koordinationsartefakte und ihre Hauptattribute aus Geschäfts- bzw. Prozessmodellen identifizieren.

-

Identification of business events Geschäftsereignisse identifizieren.

-

Identification and design of service interfaces Auswirkungen der Geschäftsereignisse auf Attribute beschreiben.

-

Faktische Abhängigkeiten (gemeinsame Abhängigkeiten von Geschäftsereignissen) zwischen Attributen identifizieren und Attribute hinter Schnittstellen aggregieren.

Regeln zur Zusammenfassung von Attributen in Schnittstellen.

Definition einer oder mehrerer Serviceoperationen mit Input- / Outputparametern pro Geschäftsereignis.

-

Service implementation and registration Services implementieren und im Serviceverzeichnis registrieren.

-

Tabelle 5-23: Aktivitäten und Techniken der Methode Die Methode orientiert sich für die Serviceidentifikation an den grundlegenden und stabilen Geschäftsentitäten und „Koordinationsartefakten“30 des Unternehmens und setzt ein entsprechendes „Unternehmensdatenmodell“ voraus. Sie untersucht die Abhängigkeiten einzelner Datenattribute (z.B. Kundennummer, Name, Rechnungsadresse) untereinander anhand von „Geschäftsereignissen“ (z.B. „neuer Kunde“, „neuer Auftrag“, „Auslieferung“): Attribute, deren Werte von den glei-

30

Unter „Koordinationsartefakten“ versteht [Baghdadi 2005, 156] Elemente, die den Status von Geschäftsprozessen repräsentieren. Im Gegensatz zu den Geschäftsentitäten, die Geschäftsprozessen Stammdaten zur Verfügung stellen, enthalten sie die zur Prozesskoordination benötigten Bewegungsdaten. Ein Koordinationsartefakt ist z.B. die Datensammlung „offene Aufträge“.

5.3 Serviceidentifikation und -design

169

chen Geschäftsereignissen erfasst, gelesen, modifiziert oder gelöscht werden, fasst die Methode unter Anwendung von Datennormalisierungs-Techniken hinter einer Serviceschnittstelle mit einer Basisoperation (create, read, update oder delete) zusammen. Die entstehenden Services sind dementsprechend hauptsächlich datenorientiert und eher feingranular (z.B. „update billing adress“, „update shipping adress“). Die Kerntechnik der Methode (identification and design of service interfaces) konzentriert sich auf den Entwurf „idealer“ Schnittstellen im Hinblick auf eine hohe Kohäsion und Redundanzfreiheit der Attribute ausgetauschter Nachrichten; weitere Designprinzipien werden kaum thematisiert (s. Tabelle 5-24). Designprinzip

Berücksichtigung

Erläuterung

Abstraktion von der Serviceimplementierung



Rein fachlicher, implementierungsneutraler Schnittstellenentwurf.

Umfassende Servicespezifikation



-

Stabile, gemanagte Servicekontrakte



-



Implizit, durch Entwicklung eines unternehmensweiten Datenmodells (Haupt-Geschäftsobjekte und Koordinationsartefakte) als Basis für Nachrichtenattribute der Services.

Fachliche Schnittstellenstandardisierung Verwendung offener und verbreiteter Industriestandards

-



Hohe Servicekohäsion und schwache logische Kopplung



Verfolgt mit Daten-Normalisierungstechniken. Beschränkt auf Service-Schnittstellen- / Nachrichtenebene.

Lose gekoppelte Kommunikation



Nachrichtenbasierte, statuslose Kommunikation über Web Services vorausgesetzt.

An Geschäftskonzepten orientierte Servicegranularität



Serviceoperationen werden pro „Geschäftsereignis“ definiert, die Methode macht keine Angaben, wie diese zu identifizieren sind. Es entstehen feingranulare, datenorientierte Services.

Generalisierung der Serviceleistung



-

 Explizit berücksichtigt, Anleitungen vorhanden Explizit oder implizit berücksichtigt, keine detaillierten Anleitungen Nicht berücksichtigt

Tabelle 5-24: Methodische Unterstützung der Designprinzipien

170

5 Architekturmanagement und Servicedesign

Practical Service Specification and Design

A Business model for deploying Web services

Service-oriented Architecture and Design

Designprinzip

Component-Based and ServiceOriented Systems Engineering Design of service interfaces for ebusiness applications

Bewertung der Methoden Der Vergleich der Methoden für die Identifikation und das Design von Services zeigt, dass keine Methode sämtliche SOA-Designprinzipien berücksichtigt (s. Tabelle 5-25). Die verschiedenen Techniken der Methoden ergänzen sich aber insgesamt gut. Da sich die Methoden i.d.R. als Erweiterungen bzw. Ergänzungen bestehender Ansätze aus der komponentenorientierten Systementwicklung oder der Prozessmodellierung verstehen, lassen sich auch ihre Techniken einigermassen isoliert nutzen und in vorhandene Entwicklungsmethoden integrieren.

Abstraktion von der Serviceimplementierung











Umfassende Servicespezifikation











Stabile, gemanagte Servicekontrakte











Fachliche Schnittstellenstandardisierung











Verwendung offener und verbreiteter Industriestandards











Hohe Servicekohäsion und schwache logische Kopplung











Lose gekoppelte Kommunikation











An Geschäftskonzepten orientierte Servicegranularität











Generalisierung der Serviceleistung











 Explizit berücksichtigt, Anleitungen vorhanden Explizit oder implizit berücksichtigt, keine detaillierten Anleitungen Nicht berücksichtigt

Tabelle 5-25: Berücksichtigung der Designprinzipien in den Methoden Die meisten Designprinzipien deckt die Methode von [Dodd 2005a] ab. Sie unterstützt insbesondere ein von Fachprojekten zur Prozessverbesserung getriebenes,

5.3 Serviceidentifikation und -design

171

von Prozessmodellen ausgehendes Servicedesign. Um Lücken dieser Methode bezüglich der Servicekohäsion und -kopplung oder der Servicegranularität zu schliessen, kann sie im Rahmen der prozess- und projektübergreifenden Aktivität „refining service requirements (provider)“ mit den Techniken zur Kopplungsanalyse von [Stojanovic 2005] oder mit Techniken zur Normalisierung der Datenstrukturen ausgetauschter Nachrichten (s. [Feuerlicht 2005] und [Baghdadi 2005]) ergänzt werden. Die Methoden von [Endrei et al. 2004] und [Stojanovic 2005] sind eher als Ansätze für das domänenorientierte Design von Services durch funktionale Zerlegung einer Applikationsdomäne geeignet. Die Methode von [Stojanovic 2005] beschreibt dazu die umfassenderen Techniken. Obwohl sie sich auf die Identifikation und das Design von Services für ein einzelnes Anwendungssystem konzentriert, lassen sich ihre Techniken (z.B. die Kopplungsanalyse) auch auf die Funktionalität einer ganzen Applikationsdomäne anwenden. Die Methode berücksichtigt beim Servicedesign allerdings die Verwendung fachlicher Architekturstandards und die Generalisierung der Serviceleistungen wenig. Die Methoden von [Feuerlicht 2005] und [Baghdadi 2005] sind weniger umfassend. Ihre Ansätze für die Serviceabgrenzung und das Schnittstellendesign mittels Datennormalisierungs-Techniken lassen sich aber in den restlichen Methoden sinnvoll integrieren. Als Ansatz für eine initiale Serviceidentifikation eignen sie sich nur beschränkt: [Feuerlicht 2005] geht von einem ausgereiften Prozess- und Datenindustriestandard aus und identifiziert lediglich zwischenbetriebliche Services. [Baghdadi 2005] sieht zwar eine unternehmensweite Serviceidentifikation vor, setzt als Grundlage aber ein unternehmensweites Datenmodell und eine Auflistung aller Geschäftsereignisse, die diese Daten bearbeiten, voraus. Sie dürfte in der Praxis zu einem sehr hohen Analyseaufwand und einer zu grossen Servicezahl mit feingranularen Operationen führen. Generell beziehen die Methoden das Konzept der Domänenarchitektur (s. Kap. 5.2) bei der Serviceidentifikation wenig mit ein. Der Ansatz von [Baghdadi 2005] nimmt gar keine Strukturierung von Services in Domänen vor, die Ansätze von [Endrei et al. 2004], [Stojanovic 2005] und [Feuerlicht 2005] grenzen Domänen projektspezifisch bzw. für einen zwischenbetrieblichen Kooperationsprozess und nicht unternehmensweit ab. Die Methode von [Dodd 2005a] sieht zwar eine initiale, unternehmensweite Domänenabgrenzung vor. Sie berücksichtigt diese aber bei der Serviceidentifikation nicht, sondern bildet ausgehend von einem Prozessmodell jede Prozessaktivität als Service ab. Dadurch besteht die Gefahr, dass die Serviceentwicklung unternehmensweit mangelhaft koordiniert ist und mit der Zeit sehr viele und redundante Services entstehen. Wie die Fallbeispiele Credit Suisse oder Deutsche Post zeigen, könnte eine stärkere Berücksichtigung des Domänenkonzepts die Methoden sinnvoll ergänzen (s. Kap. 5.3.1). So liesse sich bspw. der Ansatz von [Dodd 2005a] dadurch erweitern, dass nicht jede Prozessaktivität als Service umgesetzt wird, sondern nur die Aktivitäten, die in domänenübergreifenden Prozessen genutzt werden. Auch die Analyse der Auswirkungen von Geschäftsereignissen auf das Unternehmensdatenmodell bei [Baghdadi 2005] liesse sich auf die domänenübergreifend genutzten Geschäftsobjekte beschränken.

172

5.3.3

5 Architekturmanagement und Servicedesign

Servicetypologie

Wie Kap. 5.1 zeigte, gelten nicht für jeden Service die gleichen Designanforderungen – bspw. sind einzelne Designprinzipien je nach Einsatzziel verschieden zu gewichten. Eine Servicetypologie bildet Klassen von Services mit gemeinsamen Designprinzipien, Entwicklungsmethoden oder Entwicklungsverantwortlichkeiten und kann als Grundlage für Entwurfsmuster dienen, welche Lösungen für ähnliche bzw. sich wiederholende Designprobleme beschreiben (s. [SAP 2005b, 18], [Dietzsch/Goetz 2005, 1526]). Servicetypen lassen sich anhand verschiedener Dimensionen abgrenzen. Tabelle 5-26 gibt einen Überblick über mögliche Unterscheidungsdimensionen, ihre Ausprägungen und die Konsequenzen für die Serviceentwicklung.

Typisierungsdimensionen

Ausprägungen

ServiceZiel

Gemanagte Schnittstellen

Geltungsbereich

Domänenintern (Private)

Beschaffungsstrategie

Interne Erstellung / Kooperation

Art der Funktion

Technisch / Infrastruktur

Geschäftlich

Unterschiedliche Entwicklungsund Betriebsverantwortung

Fachliche Granularität

Querschnittsfunktion

Prozessaktivität

Unterschiedliche Designprinzipien und Entwicklungsmethoden

Komposition Interaktionsstil

Technologiereduktion

Konsequenzen für die Serviceentwicklung

Wiederverwendung

Domänenübergreifend (Public)

Übergang

Entität / Geschäftsobjekt

…

Unternehmensübergreifend

Externer Bezug (OutTasking)

Kommerzialisierung

Geschäftsprozess

Unterschiedliche Bedeutung der SOA-Designprinzipien Unterschiedliche Designprinzipien und Governancestrukturen Unterschiedliche Entwicklungsund Betriebsverantwortung

Atomarer Service (Application-Service)

KompositionsServices (EnterpriseService)

Unterschiedliche Designprinzipien und Entwicklungsmethoden

Synchron

Request / Response

Unterschiedliche Anforderungen an die Integrationsinfrastruktur

Asynchron

Notification

Tabelle 5-26: Dimensionen einer Servicetypisierung

5.3 Serviceidentifikation und -design

173

Eine mögliche Dimension zur Definition von Servicetypen stellen mit der Entwicklung verfolgte Ziele dar (s. Kap. 5.1.2). Diese Form der Typisierung hilft bei der Auswahl von Designprinzipien aufgrund bestimmter Problemstellungen in der Prozess- und IS-Architektur [s. Dietzsch/Goetz 2005]: Die Schweizerische Mobiliar bestimmte anhand unterschiedlicher SOA-Ziele sechs Nutzenstufen von Services. Diese reichen von der Stufe „Qualität“ (einheitliche Mindestqualität von Services) bis hin zur Stufe „Wiederverwendbarkeit“ (mehrfache Verwendung fachlicher Lösungen). Jeder Servicetyp unterstützt eine bestimmte Nutzenstufe und formuliert gewisse Anforderungen an das Servicedesign sowie zu berücksichtigende Einschränkungen (s. Tabelle 5-27). Servicetyp Nutzenstufe „Qualität“ Ziel und Nutzen

Mindestqualität von Schnittstellenspezifikationen. Spezifikation kann implementierungsunabhängig durch Prüfung der Schnittstelle getestet werden.

Anforderungen an das Design

Einheitliche Beschreibung von Schnittstellen (Operationen, Inputund Outputtypen, Vor- und Nachbedingungen, Invarianten und Ausnahmen).

Einschränkungen

Erhöhte Kosten der Schnittstellenentwicklung.

Tabelle 5-27: Servicetyp Nutzenstufe "Qualität" (in Anlehnung an [Dietzsch/Goetz 2005, 1526f.]) Die Schweizerische Mobiliar definiert auf Basis dieser Servicetypen Heuristiken bzw. Muster für die Identifikation und das Design von Services (vgl. Kap. 5.1). Diese Heuristiken beschreiben bestimmte Problemstellungen in der Prozess- und Applikationsarchitektur (z.B. häufige Änderungen eines Produktes, nicht standardisierbare Prozesse, Unterstützung eines Prozesses durch mehrere Applikationen) und geben Hinweise darauf, welche Art Services in diesen Situationen entwickelt werden sollten. Einen anderen Ansatz der Servicetypisierung zeigt das Fallbeispiel Credit Suisse (s. Kap. 4.3). Das Unternehmen grenzt Servicetypen nicht nach Zielsetzungen ab, sondern anhand ihres organisatorischen Geltungsbereichs bzw. der Verantwortlichkeitsstufe (Private und Public Services) sowie anhand ihres Interaktionsstils. Credit Suisse unterscheidet mit „Public Services“ und „Private Services“ zwei prinzipielle Servicetypen, die unterschiedliche Entwicklungs- und Reviewprozesse durchlaufen und unterschiedliche Designrichtlinien einhalten müssen. „Public Services“ besitzen zentral gemanagte Spezifikationen, sind im zentralen Servicerepository registriert und durchlaufen einen mehrstufigen Reviewprozess mit Qualitätschecks. Sie werden dann entwickelt, wenn die Servicenutzer-Applikation Funktionen oder Daten benötigt, die sich in einer anderen fachlichen Domäne befinden (Schnittstellentypen 1 und 2 in Abb. 5-15). Falls Servicenutzer und Serviceanbieter dabei auf unterschiedlichen Applikationsplattformen implementiert sind (Typ 1), ist für die technische Integration zwingend die zentrale Integrationsinfrastruktur mit einem der drei Integrationsbusse zu verwenden. Falls sich Servicenutzer und Serviceanbieter in unterschiedlichen fachlichen Domänen befinden, jedoch auf derselben Applikationsplattform implementiert sind (Typ 2), müssen sie

174

5 Architekturmanagement und Servicedesign

nicht unbedingt über einen Bus kommunizieren, sondern können plattformspezifische Mechanismen (z.B. JMS für Java-Applikationen) verwenden. Sie müssen aber die für Public Services vorgeschriebenen Designprinzipien einhalten und sich bei Bedarf schnell an einen Integrationsbus anbinden lassen. Befinden sich sowohl die servicenutzende als auch die serviceanbietende Applikation in derselben fachlichen Domäne, laufen aber auf unterschiedlichen Applikationsplattformen (Typ 3, z.B. Java-basiertes Benutzerfrontend für Datawarehouse-Systeme), spricht die Credit Suisse von einem „Private Service“. Private Services werden nicht im zentralen Repository aufgeführt und verwaltet, unterliegen einem weniger strikten Reviewprozess und müssen nur technische Designvorgaben einhalten, die aufgrund der Nutzung eines Integrationsbusses vorgegeben sind. Applikationsplattform

Applikationsplattform Applikationsdomäne

Applikationsplattform

3

2 Applikationsdomäne

Applikationsdomäne

Serviceanbieter

1

Servicenutzer

Abb. 5-15: Entscheidungsgrundlagen für die Serviceentwicklung bei Credit Suise (Quelle: Credit Suisse) Eine weitere Unterscheidung von Servicetypen trifft Credit Suisse anhand des Kommunikations- bzw. Interaktionsstils, der über die zu vewendende Integrationsinfrastruktur entscheidet. Je nachdem wird ein Service als synchroner CORBAService, als Event, als Fileschnittstelle oder mit einem gemischten Muster implementiert. Um ein gemischtes Muster handelt es sich z.B., wenn ein Event bei einem Ereignis nur einen Schlüssel liefert und die Client-Applikation die benötigten Daten bei Bedarf über einen synchronen Serviceaufruf bezieht. Die zentrale IT ist momentan dabei, Heuristiken für die Wahl eines Kommunikationsmechanismus zu formalisieren. Wichtige Entscheidungsgrundlagen sind Zeitanforderungen (benötigt ein Servicenutzer die Daten sofort oder ist eine zeitlich verzögerte Verarbeitung möglich?) und das zu übermittelnde Datenvolumen. Eine andere, in der Literatur häufig aufgeführte Unterscheidungsdimension ist die Art der Servicefunktionalität. So grenzen z.B. [Keen et al. 2004, 28] aufgrund der für die Entwicklung notwendigen Kompetenzen fachliche (Business-Services, z.B. Bonitätsprüfung) von technischen Services (Integration- und Infrastructure-Servi-

5.3 Serviceidentifikation und -design

175

ces, z.B. Benutzerauthentisierung) ab. Während erstere in enger Zusammenarbeit mit Fachbereichen entwickelt werden, liegen letztere im Verantwortungsbereich der Infrastrukturverantwortlichen bzw. werden von externen Middlewareplattform-Anbietern entwickelt. Eine ähnliche Unterscheidung nimmt [Reichmayr 2003, 120f.] vor, der die Typen Business-Process-Services, Content- und Transaction-Services, Integration-Services und IT-Operation-Services aufführt. Anhand der Unternehmensspezifität einer Serviceleistung, ihrer strategischen Bedeutung für das Unternehmen, ihrer Verfügbarkeit (intern oder am Markt) sowie ihrer Verrechenbarkeit beschreibt [Reichmayr 2003, 106] Beschaffungsstrategien für Services, welche sich auf ihren Entwicklungsprozess und ihren Lebenszyklus auswirken (s. Abb. 5-16): Die Strategie „intern / Kooperation“ wird auf Services angewendet, die sowohl eine hohe Spezifität als auch eine hohe Bedeutung für das Unternehmen besitzen. Sie sind intern aufzubauen und zu betreiben. Services mit niedriger Spezifität und strategischer Bedeutung sind Kandidaten für eine Auslagerung („Out-tasking“). Hier sind potenzielle externe Serviceanbieter zu identifizieren und zu beurteilen. Für Services mit geringer strategischer Bedeutung und sehr unternehmensspezifischer Leistung, die nicht auf dem Markt bezogen werden kann, gilt eine „Übergangs“-Strategie. Hier ist zu überprüfen, ob die Serviceleistung längerfristig generalisiert und dadurch ausgelagert werden kann. Für Services mit hoher strategischer Bedeutung und geringer Spezifität sollte geprüft werden, ob sie kommerzialisiert und extern auf dem Markt angeboten werden können („WebService“-Strategie). Spezifität

hoch Übergang (überprüfen, kurzfristig intern ausführen, langfristig auslagern oder Kooperation aufbauen)

Intern / Kooperation (langfristig Kompetenzen aufrechterhalten)

Out-tasking

WebService (verkaufen oder als WebService anbieten, Haltbarkeitsdauer überprüfen)

mittel

niedrig

niedrig

mittel

hoch

Strategische Bedeutung

Abb. 5-16: Beschaffungsstrategien für Services [s. Reichmayr 2003, 106] Verschiedene Autoren differenzieren Services auch anhand ihrer fachlichen Granularität und formulieren daraus Anforderungen an ihre Stabilität bzw. Flexibilität und Wiederverwendbarkeit. [Sims 2003] etwa unterscheidet „Utility Services“ (unterstützen generische Querschnittsfunktionen, z.B. Authentisierung), „Entity

176

5 Architekturmanagement und Servicedesign

Servics“ (bieten Operationen zum Lesen und Bearbeiten einer Geschäftsentität, z.B. Kunde), „Core Process Services“ (bieten eine prozessspezifische Leistung, z.B. Verfügbarkeitsprüfung) und „Process Services“ (kapseln einen umfangreicheren Geschäftsprozess, z.B. Auftragsannahme und -validierung). Die ersten beiden Typen sind i.d.R. über längere Zeit stabil und möglichst generisch, in vielen Prozessen wieder verwendbar zu entwickeln. Bei Core-Process- und besonders Process-Services hingegen ist mit häufigeren Anpassungen zu rechnen und die Services sollten entsprechend schnell erweiterbar sein. Eine ähnliche Unterteilung nimmt [SAP 2005b, 18] mit der Unterscheidung von „Utility Services“, „Entity / Engine Services“ und „Process Services“ vor. Eine weitere Unterscheidung machen z.B. [Karch et al. 2004] oder [Krafzig et al. 2004, 74] mit der Abgrenzung von atomaren Services („Application-“ bzw. „Intermediary/Services“) und Kompositions-Services („Enterprise-“ bzw. „BusinessServices“). Bei ersteren handelt es sich um Services, die bestehende Applikationsfunktionalität als Adapter kapseln und auf der Serviceebene verfügbar machen. Zwischen Softwarekomponente und kapselnden Adapterservices besteht eine 1zu-1 Beziehung. Der Entwurf von Application Services ist eher bottom-up, ausgehend von bestehenden Applikationsschnittstellen motiviert. Im Gegensatz dazu erfolgt die Identifikation von Kompositions-Services aus den Anforderungen des Geschäftsprozesses. Sie können geschäftsorientierte und technische Services kombinieren (etwa einen Service zur Abfrage von Informationen mit einem Zugriffskontrollservice) und bieten einen Mehrwert aus Geschäftssicht.

5.4

Architekturrollen und Verantwortlichkeiten

Die verschiedenen SOA-spezifischen Architekturmanagement- und IS-Entwicklungsaufgaben müssen in organisatorischen Strukturen, d.h. Ausschüssen und Stellen, verankert werden. Diese regeln die Zusammenarbeit zwischen Fachbereichen, zentralen und dezentralen IT-Abteilungen sowie Serviceanbietern und Servicenutzern und sorgen dafür, dass IS-Projekte die Architekturrichtlinien und Standards einhalten [s. Richter et al. 2005, 415]. T-Com unterscheidet die drei Haupt-Aufgabenbereiche „Governance“, „Guidance“ und „Delivery“. Governance-Aufgaben liegen in der Verantwortung eines „ESB- / SOA-Ausschusses“, in dem neben dem CIO auch Vertreter der Geschäftsbzw. Prozessbereiche und Mitglieder des übergreifenden Architektur-Ausschusses mitwirken. Der Ausschuss bestimmt strategische Ziele, Regeln, Prozesse und Rollen für die SOA-Einführung, überwacht die Einhaltung der Vorgaben und die Zielerreichung und ist Eskalationsinstanz. Die Verantwortung über die Architektur-Guidance übernehmen Vertreter des zentralen IS-Architekturbereichs. Sie bauen ein „SOA Solution Center“ auf, in welchem sie gemeinsam mit Vertretern der Geschäftsbereiche das einheitliche Business Object Model entwickeln, die fachliche (Domänen-) und die technische Integrations-Architektur definieren sowie Informationen und Know-how für die an der SOA-Einführung Beteiligten bereitstellen. Das SOA Solution Center betreibt ausserdem die technische Infrastruktur und misst die Einhaltung von Service Level Agreements (SLAs) im laufen-

5.4 Architekturrollen und Verantwortlichkeiten

177

den Betrieb. Die Delivery-Verantwortung liegt bei den Fachprojekten. Die Projektverantwortlichen sind für die Abdeckung fachlicher Anforderungen durch geeignete Entwicklungsprojekte und die Einhaltung der SOA-Richtlinien im Rahmen der Projektarbeit zuständig. Credit Suisse unterscheidet im Kontext der SOA drei wichtige Architekturrollen: „Zentrale Integrationsarchitekten“ sind für die Entwicklung der fachlichen Domänenarchitektur, die technische Integrationsinfrastruktur sowie das Formulieren und Überprüfen von Service-Designprinzipien zuständig. Sie arbeiten zu mindestens 30% an IS-Entwicklungsprojekten mit. „Domänenarchitekten“ sind für jeweils eine fachliche Applikationsdomäne zuständig. Sie wirken zu je ca. 50% an domäneninternen Projekten und zentralen Architekturfragestellungen mit. „Lead Engineers“ (Middlewarespezialisten) sind für jeweils eine technische Domäne (Technologieplattform) zuständig. Auch sie beteiligen sich neben den domänenspezifischen an zentralen, technischen Architekturaufgaben. Die Definition von SOA-Zielen und Architekturprinzipien, das Überwachen und Steuern der Servicearchitektur oder die Entwicklung der notwendigen Integrationsinfrastruktur sind nur Teilaufgaben einer übergreifenden IS-Architekturentwicklung und Architektursteuerung. Ebenso sind das Entwickeln oder Integrieren von Services nur Teilaufgaben in Applikationsentwicklungs- und Integrationsprojekten. Im Folgenden werden deshalb nur die Rollen beschrieben, die SOAspezifische Aufgaben übernehmen und in ein umfassendes Architekturmanagement bzw. eine umfassende IS-Entwicklungsorganisation einzubinden sind. Dabei müssen Unternehmen nicht unbedingt neue Stellen schaffen, sondern können ggf. den Aufgabenbereich bestehender Rollen weiter ausbauen.

5.4.1

SOA-Rollen in der Literatur

Tabelle 5-28 gibt einen Überblick über SOA-Rollen bzw. -Gremien im Architekturmanagement und der IS-Entwicklung aus der Literatur. 31 Dabei handelt es sich zum Teil um SOA-spezifische, zum Teil um erweiterte bestehende Rollen.

31

Die Quellen nehmen zum Teil keine organisatorische Einordnung der SOA-Rollen vor oder weisen den Rollen sowohl Aufgaben aus dem Architekturmanagement als auch aus der IS-Entwicklung zu. Tabelle 5-28 ordnet die Rolle in dem Bereich ein, wo ihr Aufgabenschwerpunkt liegt.

178

5 Architekturmanagement und Servicedesign SOA-Rollen im Architekturmanagement

SOA-Rollen in der IS-Entwicklung

[Balzer 2004]

Architecture Management Board, Architecture Review Team

Project Team (Domain Owner, Domain Service-Oriented Business Analyst, Line of Business Representative, Service Developer and Maintainer, Service Tester)

[Bieberstein et al. 2005a 79ff.]

Service Governor, SOAArchitect, Interoperability Tester

Service Modeler or Designer, Process Flow Designer, Service Developer, Integration Specialist, UDDI Administrator, UDDI Designer

[Schwinn 2006a 235]

Integrationsarchitekt, Middleware-Architekt

Applikationsarchitekt, Middlewarespezialist, Vertreter Fachbereich

[van de Loo 2004]

Enterprise Service Architect

Enterprise Service Developer, Application Service Developer, Interaction Component Developer

Tabelle 5-28: SOA-Rollen und Gremien aus der Literatur [Balzer 2004] nennt im Rahmen eines SOA-Governancemodells ein Gremium für die Architekturführung (Architecture Management Board) und ein Gremium mit Aufgaben aus den Bereichen Architekturentwicklung, -kommunikation und -vertretung (Architecture Group). IS-Entwicklungsaufgaben übernehmen IS-Entwicklungsteams. Im Fall von Anwendungsentwicklungsprojekten unterstehen diese Domänenverantwortlichen (Domain Owners) und setzen sich aus verschiedenen spezialisierten Rollen zusammen. [Bieberstein et al. 2005a, 79ff.] sehen mit dem Service Governor für Architekturführungsaufgaben, dem SOA-Architect und dem Interoperability Tester für Architekturentwicklungs- und Architekturvertretungsaufgaben primär drei neue SOAspezifische Rollen im Architekturmanagement. Sie detaillieren eine Reihe von Rollen, die neue bzw. erweiterte Aufgaben in der Anwendungs- und Infrastrukturentwicklung übernehmen. [Schwinn 2006a, 235] formuliert in seiner Methode zur Gestaltung von Integrationsarchitekturen ein generisches Rollenmodell für das Integrationsarchitekturmanagement und für IS-Integrationsprojekte, das verschiedene Aufgaben der SOA-Einführung abdeckt. Integrations- und Middlewarearchitekten formulieren Architekturprinzipien, grenzen Domänen ab, entwickeln die technische Integrationsarchitektur und übernehmen die Architektursteuerung. Applikationsarchitekten sind zusammen mit Fachbereichsvertretern für die Identifikation von Integrationsbedarf und für das Design von Services zuständig, Middlewarexperten setzen einzelne Infrastrukturkomponenten um. [van de Loo 2004] definiert eine neue Rolle für die entwicklungsprojektübergreifende Serviceidentifikation (Enterprise Service Architect) sowie spezialisierte Rollen für die Implementierung von Services (Enterprise Service Developer, Application Service Developer) und Service-Benutzerschnittstellen (Interaction Component Developer).

5.4 Architekturrollen und Verantwortlichkeiten

5.4.2

179

Konsolidierung der Rollen

B

B

SOA überwachen und steuern

V

B

B

SOA-Architekturprinzipien formulieren

B

V

V

Domänenarchitektur entwickeln

B

V

Technische Integrationsarchitektur entwickeln

B

Serviceentwickler

Technische SOAArchitekten

V

Domänenarchitekten

Fachliche SOAArchitekten

SOA-Ziele definieren

Aktivitäten bei der Einführung der SOA

Infrastrukturspezialisten

SOA-Lenkungsausschuss

Tabelle 5-29 konsolidiert die in den Fallstudien und der Literatur vorgefundenen Rollen für die Aufgaben einer SOA-Einführung in einem Funktionendiagramm.

Architekturmanagement Architekturführung

B

Architekturentwicklung B

B B

V

B

Architekturkommunikation und -vertretung SOA-Prinzipien in Fachprojekten kommunizieren

V

V

B

B

Projektunterstützung und -review

V

V

B

B

IS-Entwicklung Services identifizieren Services entwickeln und nutzen Zentrale Infrastruktur entwickeln

V/B B

V B

B

B

V

B

V

Legende: V = verantwortlich, B = beteiligt (Unterstützung / Kontrolle)

Tabelle 5-29: Überblick über SOA-Rollen und Aufgaben •

SOA-Lenkungsausschuss. Der SOA-Lenkungsausschuss setzt sich aus IT- und Fachverantwortlichen zusammen und kann Teil eines IT-Strategiegremiums sein. Er entwickelt im Rahmen der allgemeinen Geschäfts- und IT-Strategie eine SOA-Strategie, legt die Ziele und Massnahmen der SOA-Umsetzung fest und kontrolliert die Zielerreichung in regelmässigen Abständen. Darüber hinaus verabschiedet der SOA-Ausschuss die SOA-Architekturprinzipien, die Domänenarchitektur und die technische Integrationsarchitektur.

180

5 Architekturmanagement und Servicedesign

•

Fachliche SOA-Architekten. Hauptaufgabe der fachlichen SOA-Architekten ist es, in Abstimmung mit den Fachbereichen und Domänenarchitekten eine fachliche Zielarchitektur mit Domänen, Services und übergreifenden Datenmodellen zu entwickeln. Sie definieren ausserdem fachliche Standards und Designprinzipien für Services, kommunizieren diese in Applikationsentwicklungsprojekten und überprüfen die Projekte auf ihre Architekturkonformität. Weiter unterstützen sie die SOA-Strategieentwicklung und erheben und verwerten Führungsgrössen für die Architektursteuerung.

•

Technische SOA-Architekten. Technische SOA-Architekten sind für das Entwickeln der technischen SOA-Integrationsarchitektur verantwortlich. Sie definieren technische Designrichtlinien und Standards, steuern die Entwicklung der SOA-Infrastruktur und unterstützen und kontrollieren Applikationsentwicklungsprojekte bei der Infrastrukturnutzung.

•

Infrastrukturspezialisten. Infrastrukturspezialisten entwickeln und betreiben eine oder mehrere Komponenten der zentralen Infrastruktur (z.B. ein ServiceVerzeichnis oder einzelne Middlewareplattformen). Sie unterstützen Applikationsentwicklungsprojekte bei der Infrastrukturnutzung und überwachen diese im Betrieb.

•

Domänenarchitekten. Domänenarchitekten besitzen die Entwicklungs- und Betriebsverantwortung für die domäneninterne IS-Architektur und die von der Domäne angebotenen Services. Sie setzen Fachanforderungen in konkrete Applikationen und Services um und arbeiten dabei eng mit den Fachbereichen zusammen. Sie wirken ausserdem bei der Entwicklung der Domänenarchitektur und der Definition von Servicerichtlinien und Standards mit und planen und kontrollieren Entwicklungsprojekte zur Implementierung der Domänenarchitektur. Weiter liefern sie domänenspezifische Qualitätsindikatoren bzw. Kennzahlen zur Architekturüberwachung. Um die Beteiligung der Fachbereiche an der Serviceentwicklung und das IT-Business-Alignment zu sichern, empfehlen [Bieberstein et al. 2005b, 693] und [Scherdin 2006, 12], die fachliche und finanzielle Verantwortung über eine Domäne einzelnen Fach- bzw. Unternehmensbereichsleitern zu übertragen.

•

Serviceentwickler. Serviceentwickler entwerfen und implementieren neue bzw. integrieren bestehende Services in IS-Entwicklungsprojekten. Serviceentwickler können mit traditionellen Applikations- oder Infrastrukturentwicklern identisch sein oder mit diesen zusammenarbeiten und müssen die Richtlinien und Methoden für das Servicedesign sowie die Nutzung der SOAInfrastruktur beherrschen. Für spezifische Aufgaben und Fachkompetenzen in der Serviceentwicklung kann diese Rolle weiter unterteilt werden in Funktionen wie Fachbereichsvertreter, Schnittstellenmodellierer, Prozessflussmodellierer etc. (s. [Balzer 2004], [Bieberstein et al. 2005a, 79ff.]).

5.5 Zusammenfassung

5.5

181

Zusammenfassung

Zur Einführung einer SOA sind im Rahmen des Architekturmanagements Architekturziele und -prinzipien zu formulieren, die IS-Entwicklungsprojekten Leitlinien für eine architekturkonforme Serviceentwicklung und -nutzung setzen. Für eine wirkungsvolle Architektursteuerung sind ausserdem Metriken notwendig, welche die Zielerreichung und die Einhaltung der Architekturprinzipien mess- und bewertbar machen. Das vorangegangene Kapitel entwickelte einen Vorschlag für die zielspezifische Priorisierung der SOA-Designprinzipien und für ihre Operationalisierung in Form von Qualitätsindikatoren. Diese unterstützen die Bewertung einzelner Services im Rahmen von IS-Entwicklungsprojekten und die Bewertung der SOA insgesamt. Das Strukturieren der Applikationsarchitektur in Domänen ist ein weiterer wichtiger Bestandteil des SOA-Architekturmanagements. Domänen unterstützen die Identifikation von Services, indem sie eine Entscheidungsgrundlage dafür liefern, in welchen Fällen Applikationsschnittstellen als Services auszuprägen sind. Sie sind ausserdem ein Hilfsmittel für die Zuordnung fachlicher Verantwortlichkeiten in der Servicentwicklung und im Servicebetrieb. Das Kapitel untersuchte verschiedene Ansätze für eine Domänenabgrenzung und leitete daraus Kriterien und Empfehlungen für die Domänenbildung ab. Die eigentliche Identifikation und das Design von Services finden im Rahmen der IS-Entwicklung statt. Dabei sollten Unternehmen potenzielle Services sowohl projektübergreifend, aus Sicht einer Applikationsdomäne, als auch projektgetrieben in Applikationsentwicklungsprojekten identifizieren. Die im Servicedesign eingesetzten Entwurfsmethoden müssen die Servicedesignprinzipien unterstützen. Herkömmliche Softwareentwicklungsmethoden erfüllen dies nur beschränkt und müssen um SOA-spezifische Entwurfstechniken erweitert werden. Eine Reihe neuerer Methoden liefern dazu nützliche Ansätze. Da sich das Vorgehen in der Serviceentwicklung, Entwicklungsverantwortlichkeiten und zu berücksichtigende Designprinzipien für unterschiedliche Arten von Services unterscheiden können, vereinfacht eine Servicetypologie den Serviceentwicklungsprozess. Abschluss des Kapitels bildete ein Funktionendiagramm, das die besprochenen Architekturmassnahmen einzelnen Rollen im Architekturmanagement und der ISEntwicklung zuordnete.

6 Zusammenfassung und Ausblick Bei steigendem Bedarf nach integrierter Abwicklung von Geschäftsprozessen und nach Flexibilität des Informationssystems ist eine SOA ein Ansatz, Geschwindigkeit und Qualität der unternehmensweiten Applikationsentwicklung und -integration zu erhöhen und ihre Komplexität und Kosten zu senken. Eine SOA unterstützt die schnelle und wirtschaftliche Umsetzung von Innovationen des Geschäftsmodells im Informationssystem und steigert dadurch die unternehmerische Agilität. Ziel des Buches war, den Architekturansatz SOA zu charakterisieren, seine Nutzenpotenziale zu untersuchen und Unternehmen Handlungsempfehlungen für seine Umsetzung zu geben. Es konzentrierte sich dabei auf die Ebene IS-Architektur und die Entwicklung und Steuerung einer SOA aus fachlicher Sicht. Die folgenden Abschnitte fassen die Kernerkenntnisse zusammen und geben einen Ausblick auf zukünftige Entwicklungen im Umfeld von SOA.

6.1

Zusammenfassung

Architekturmodell Eine SOA ist eine mehrschichtige Integrationsarchitektur, welche die fachliche Prozessarchitektur mit der Applikationsarchitektur verbindet. Ein Literaturvergleich identifizierte wesentliche SOA-Designprinzipien. Sie lassen sich in die Kategorien Schnittstellenorientierung, Interoperabilität, Autonomie und Modularität sowie Bedarfsorientierung einordnen. Eine SOA stellt eine Weiterentwicklung verschiedener bestehender Ansätze dar, die sowohl aus entwurfsmethodischer als auch aus technischer Sicht Neuerungen einführt: Im Vergleich zu Ansätzen wie dem modularen, objektorientierten oder komponentenorientierten Systemdesign betrachtet sie grössere Bereiche der IS-Architektur anstelle einzelner Applikationen oder Applikationsfamilien und legt mehr Gewicht auf die prozessorientierte Komposition und die lose Kopplung von IT-Funktionalität. Aus technischer Sicht stellen Web Service Standards sowie die Konvergenz von Middlewarelösungen zu umfassenden und integrierten SOA-Plattformen wichtige Neuerungen dar. Fallstudien Am Beispiel der Unternehmen Deutsche Post Brief, Credit Suisse, T-Com und Zuger Kantonalbank wird die Umsetzung von SOA und die Ausprägung der Architekturkomponenten und Designprinzipien in der Praxis gezeigt. Wichtige Treiber für eine SOA sind schlecht integrierte Geschäftsprozesse, mangelhafte Flexibilität beim Umsetzen neuer Geschäftsanforderungen, hohe Kosten des IS-Betriebs und Probleme bei notwendigen technischen Modernisierungen in der IS-Architektur. Ursachen in der IS-Architektur sind u.a. der parallele Einsatz verschiedener Technologien und Plattformen, viele schlecht kontrollierte Applikationsschnittstellen, die zu Abhängigkeiten zwischen Applikationen führen, die

184

6 Zusammenfassung und Ausblick

mehrfache Implementierung zentraler Geschäftsdaten und -funktionen oder eine enge Verknüpfung von Präsentations-, Prozess- und Fachlogik in Altsystemen. Aus den Fallbeispielen lassn sich drei typische SOA-Ziele identifizieren: SOA als standardisierte Integrationsinfrastruktur, SOA zur besseren Entkopplung von Applikationsdomänen und SOA für eine flexiblere Benutzer- und Geschäftsprozessintegration. Die Beispiele zeigen, dass die Unternehmen bezüglich des letzten Ziels mit der Umsetzung von Prozesslogik zur Orchestrierung von Services in Form von Workflows oder Taskflows erst in den Anfängen stehen. Keines der Unternehmen setzt SOA vollumfänglich um. Die Beispiele Deutsche Post Brief, Credit Suisse und T-Com bewegen sich mit den Hauptzielen der unternehmensweit standardisierten Integrationsinfrastruktur und Entkopplung von Applikationsdomänen schwerpunktmässig auf der Serviceebene des Architekturmodells. Das Beispiel Zuger Kantonalbank, das SOA in einem ersten Schritt nur für einen integrierten Arbeitsplatz zur Kundenbetreuung umsetzt, konzentriert sich dagegen in den Ebenen Workflow- und Desktopintegration auf das Herauslösen von Prozess- und Präsentationslogik aus einer SAP Standardsoftware. Die Unternehmen realisieren mit SOA verschiedene Nutzenpotenziale. U.a. rechnet Credit Suisse mit Entwicklungseinsparungen durch Wiederverwendung von 30 Mio. CHF in fünf Jahren, Deutsche Post Brief reduzierte Projektlaufzeiten von einigen Monaten auf einige Wochen oder Tage und beide Unternehmen konnten Wartungs- und Betriebskosten senken. Architekturmassnahmen zur Umsetzung einer SOA Massnahmen zur Einführung einer SOA lassen sich in Architekturmanagement-, IS-Entwicklungs- und organisatorische Aufgaben unterteilen. Das Architekturmanagement formuliert mit Architekturprinzipien Leitkriterien für die Entwicklung und Implementierung des IS. Es stellt sicher, dass in dezentralen Projekten entwickelte Services architekturkonform sind und die erwünschte Qualität aufweisen. Das Buch macht hier einen Vorschlag für die zielabhängige Gewichtung der SOA-Designprinzipien und für ihre Operationalisierung in Form von Qualitätsindikatoren. Diese unterstützen regelmässige Projekt- und Architekturreviews. Weiter entwickelt es Kriterien und Handlungsempfehlungen für das Abgrenzen von Applikationsdomänen. Die Domänenarchitektur ist ein wichtiges Instrument für das Identifizieren von Services und für das Zuordnen von Verantwortlichkeiten für Services. Im Rahmen der IS-Entwicklung setzen Applikationsentwicklungsprojekte fachliche Services um. Mit der fachprojektgetriebenen, domänenübergreifenden und der domänenorientierten, vorausplanenden Serviceidentifikation existieren zwei prinzipielle Ansätze, wie Unternehmen die Serviceentwicklung angehen können. Methodenvorschläge für die Servicentwicklung zeigen Techniken und Handlungsanleitungen für die Berücksichtigung der SOA-Designprinzipien im Serviceentwurf. Unternehmen müssen die verschiedenen SOA-spezifischen Aufgaben des Architekturmanagements und der IS-Entwicklung in ihrer IT-Organisation verankern. Das Buch liefert dazu ein Funktionendiagramm, das die Aufgaben verschiedenen IT-Rollen zuordnet.

6.2 Ausblick

6.2

185

Ausblick

Die folgenden Abschnitte geben einen Ausblick auf zukünftige, momentan in der Praxis noch wenig umgesetzte SOA-Themen. Services als vermarktbare ITProdukte versprechen, die Netzwerkfähigkeit von Unternehmen und ihre Flexibilität bei der organisatorischen Verteilung von Wertschöpfungsaktivitäten zu verbessern und neue Formen der Zusammenarbeit zwischen internen IT- und Fachbereichen zu unterstützen. Die modellbasierte, dynamische Servicekomposition verfolgt eine stärkere Automatisierung der Applikationsentwicklung. Sie soll zukünftig Fachbereiche in die Lage versetzen, Prozesse und Applikationen teilweise selbständig anzupassen. Services als vermarktbare IT-Produkte Ein bisher wenig ausgeschöpftes Potenzial von SOA ist das stärkere Erbringen und Beziehen von IT-Leistungen über Marktmechanismen. Unternehmen versuchen heute vermehrt, ihre IT-Bereiche als eigenverantwortliche interne Dienstleistungserbringer zu positionieren und ein kunden- und produktorientiertes Informationsmanagement einzuführen [s. Scheeg 2004, 36]. Sie verrechnen z.B. ITLeistungen nicht über festgelegte Kostenschlüssel, sondern über Produktpreise und versuchen, proaktiv IT-Leistungsportfolios mit hohen internen und externen Absatzchancen zu entwickeln. Sie bewegen sich dabei weg von ressourcen- oder lösungsorientierten IT-Produkten (z.B. CPU-Zeit, Speicherplatz, Bereitstellung einer Applikation für die Textverarbeitung) und hin zu einer service- und prozessorientierten Leistungsdefinition (z.B. „Schadensvorgang anlegen“, „Kundeninformationen anlegen“) und zu eigenständig vermarktbaren, vollständig ITbasierten Produkten bzw. Online-Services (z.B. netzbasierter Anrufbeantworter, Adressvalidierung) (s. [Zarnekow 2004, 44], [Kagermann/Österle 2006, 188]). Die Nutzung von Spezialisierungs- und Skaleneffekten in der Leistungserbringung ist dabei ein logischer nächster Schritt: Unternehmen bündeln standardisierte, von mehreren Einheiten gemeinsam verwendete Ressourcen zu zentral zur Verfügung gestellten Shared Services [s. von Glahn/Schomann 2003, 78], beziehen einzelne Prozessleistungen gegen Bezahlung als Online-Services von externen Spezialisten (Outtasking [s. Österle/Reichmayr 2003, 565]) oder bieten eigene Online-Services in einem externen Markt an. Diese Möglichkeiten verstärken den Trend zur Vernetzung von Unternehmen. Es entstehen Geschäftsnetzwerke bzw. Ecosysteme von Spezialisten, in denen sich Unternehmen einerseits auf die interne Produktion derjenigen Leistungen konzentrieren, für die sie spezielle Kompetenzen besitzen (Spezialisierung), andererseits trotzdem die Prozesse ihrer Kunden umfassend unterstützen, indem sie komplementäre Leistungen Dritter integrieren (Aggregation) [s. Kagermann/Österle 2006, 180]. Eine SOA erhöht diese Form der Netzwerkfähigkeit von Unternehmen durch folgende Eigenschaften: •

Services stellen mit ihrem fachlich klar abgegrenzten, an Wertschöpfungsaktivitäten eines Unternehmens orientierten Leistungsumfang geeignete verrechen- und vermarktbare Einheiten dar.

•

Sie besitzen stabile, in geschäftlicher Terminologie beschriebene und kontrollierbare Schnittstellenvereinbarungen. Sie erleichtern damit die Identifikation,

186

6 Zusammenfassung und Ausblick

Integration und Nutzung von IT-basierten Leistungen auf einer geschäftlichen Ebene. •

Servicebasierte Prozessaktivitäten sind, sofern sie in der implementierenden Applikationsarchitektur ausreichend modular abgebildet sind, durch Verwendung von plattformunabhängigen Industriestandards physisch verteilbar. Sie können aus technischer Sicht einfach zentralisiert und unternehmensextern bezogen oder angeboten werden. Der Online-Service-Markt mit Diensten für z.B. das Electronic Bill Presentment und Payment, Bonitätsprüfungen, Adressvalidierungen, die Navigation, den unternehmensübergreifenden Stammdatenabgleich etc. wächst gegenwärtig stark. Analysten prognostizieren jährliche Wachtumsraten von bis zu 26 Prozent [s. Rangan et al. 2005, 9]. Viele Unternehmen müssen aber erst noch die technischen und organisatorischen Voraussetzungen für ein service- und produktorientiertes Informationsmanagement und das Anbieten und Nutzen von Online-Services schaffen. So sind bspw. „Marktregeln“ zu formulieren, die Bezugspflichten von Fachbereichen bei der internen IT oder Möglichkeiten des externen Leistungsbezugs definieren und ggf. neue Prozesse für das Service-Lieferanten- und -Kundenmanagement zu entwickeln [Zarnekow et al. 2005, 74ff.]. Ausserdem entstehen beim Bezug von Services im noch jungen Markt für Online-Services u.a. Risiken aus der Unerfahrenheit und Instabilität der Anbieter (z.B. durch unsichere Geschäftsmodelle), aus der Unerfahrenheit der Abnehmer bei der Vertragsgestaltung oder aus technischen Gefahren einer Servicenutzung über das Internet (z.B. Sicherheitslücken, mangelnde Verfügbarkeit, hohe Antwortzeiten, s. [Kern et al. 2002, 118], [Samtani 2002, 35]). Modellbasierte, dynamische Servicekomposition Eine SOA soll Business Engineers oder Fachbereichsmitarbeiter in Zukunft in die Lage versetzen, ohne vertiefte Informatikkenntnisse mit einfachen Modellierungswerkzeuge fachliche Prozessmodelle anzupassen und weitgehend automatisiert ausführbare Workflows bzw. neue Composite Applications zu generieren (s. [Newcomer/Lomow 2004, 222], [Kagermann/Österle 2006, 237]). Die Verantwortung für die Prozessentwicklung soll damit stärker von der IT-Abteilung zu den Business Engineers in den Geschäftsbereichen verlagert werden. Verschiedene Anbieter von WFMS- bzw. BPMS-Lösungen gehen in diese Richtung, indem sie aufbauend auf einem Repository mit existierenden Services Werkzeuge für die fachliche Prozessmodellierung (z.B. in der Modellierungssprache Business Process Modeling Notation, BPMN) und deren automatische Übersetzung in durch WFMS ausführbare Sprachen (z.B. BPEL) zur Verfügung stellen. Ein Beispiel ist die Kooperation zwischen IDS Scheer und SAP, welche eine Integration des Prozessmodellierungswerkzeugs ARIS in die NetWeaver-Plattform vorsieht [s. IDS 2005]. Anwender modellieren damit bspw. in Form ereignisgesteuerter Prozessketten (EPKs) einen Prozess aus betriebswirtschaftlicher Sicht und ohne technischen Bezug. In einem Prozesskonfigurationsmodell werden anschliessend automatisierbare Prozessteile mit den unterstützenden Applikationen bzw. Services verknüpft. Dies soll zukünftig auf Basis des SAP Enterprise Services Repository erfolgen, welches vordefinierte, konfigurierbare Referenzprozesse

6.2 Ausblick

187

und Serviceschnittstellen enthält. Die so modellierten Prozessflüsse werden dann in ein ausführbares Prozessmodell in BPEL übersetzt, welches von der Laufzeitumgebung der SAP Exchange Infrastructure, dem SAP Integration Server, zur Workflowsteuerung verwendet wird. Das Service-Repository von SAP NetWeaver speichert und verknüpft zentral sämtliche Metadaten auf allen Modellierungsebenen, von den fachlichen Prozessmodellen bis hin zu den ausführbaren Workflowmodellen und Serviceschnittstellen. Damit unterstützt es eine durchgängige und konsistente Softwareentwicklung und erleichtert die Kommunikation zwischen Fach- und Informatikspezialisten. Die Automatisierung gewisser Arbeitsschritte (bspw. das Übersetzen von Prozesskonfigurationsmodellen in BPEL-Prozesse) und die Wiederverwendung bestehender, als Service gekapselter Funktionen erhöhen ausserdem die Entwicklerproduktivität. Eine vollständig automatisierte Umsetzung von Anpassungen an fachlichen Prozessmodellen in Workflows und Composite Applications würde aber u.a. erfordern, dass: •

alle von der neuen Lösung benötigten Aktivitäten bzw. Funktionen als Service in einem Repository zur Verfügung stehen und semantische Verknüpfungen zwischen fachlichen Prozessaktivitäten und Serviceoperationen definiert sind (z.B. Aktivität „Partner anlegen“ entspricht standardisierter Serviceoperation „createPartner“),

•

die miteinander zu verknüpfenden Services auf einheitlichen fachlichen Daten- und Funktionsmodellen basieren (z.B. Verwendung einheitlicher Feldbezeichnungen und Werte für Kunden- oder Produktnummern) oder sämtliche notwendigen Datentransformationen zwischen beliebigen Services vordefiniert sind,

•

Geschäftsregeln zur Servicenutzung (Vor- / Nachbedingungen der Servicenutzung, Abhängigkeiten eines Services zu anderen im Prozessablauf) spezifiziert sind und während der Modellierung überprüft werden und

•

die Services in der Granularität vorliegen, die der neue bzw. geänderte Prozess vorsieht. Bspw. kann ein Business Engineer keinen Prozess modellieren, der das Anlegen von Kundendaten ohne Risikoprüfung vorsieht, wenn auf Serviceebene die Kundendatenerfassung immer mit einer Risikoprüfung verbunden ist. Umgekehrt kann er in seinem Prozessmodell nicht die Basisaktivität „Partner anlegen“ verwenden, wenn auf Serviceebene „Partnergrunddaten anlegen“ und „Partnerrollen anlegen“ als einzelne Operationen definiert sind. Noch einen Schritt weiter in der Automatisierung der Applikationsentwicklung geht die Vision einer regelbasierten, dynamischen Servicekomposition. Dies ist das Fernziel des Semantic Webs [s. W3C 2001a] bzw. von Semantic Web Services [s. Fensel/Bussler 2002] und Semantic Web Business Process Management [s. Hepp et al. 2005]. Die Idee ist hier, dass z.B. ein WFMS anhand eines geschäftlichen Ziels (bspw. Umsetzung eines Rechnungsstellungsprozesses mit einer Durchlaufzeit von 0.3 Sekunden und Kosten von 0.50 CHF pro Transaktion) selbständig interne und externe Serviceverzeichnisse durchsucht, geeignete Services identifiziert, aus der Servicespezifikation erkennt, wie es mit den Services interagieren muss, und schliesslich die Services ohne manuelle Eingriffe nutzt (s. [Alonso et al. 2003, 300], [Hepp et al. 2005]). Damit liessen sich z.B. selbstheilende oder sich selbst verbessernde Prozesse realisieren, die beim Ausfall eines

188

6 Zusammenfassung und Ausblick

Services einen geeigneten Alternativservice integrieren oder den Serviceanbieter wechseln, wenn ein neuer Service die definierten Qualitätskriterien (z.B. Antwortzeit, Ausfallsicherheit, Preis) besser erfüllt (s. [Papazoglou et al. 2006, 14], [Berbner et al. 2005, 275]). Ein solcher Grad an Autonomie und Automatisierung stellt allerdings noch höhere Anforderungen an die semantische Standardisierung von Begriffssystemen, Geschäftsregeln und Services sowie an die Beschreibung von Serviceigenschaften über maschinenlesbare Metadaten [s. Hepp et al. 2005]. Ausserdem sind standardisierte, rechtsgültige Geschäftsvereinbarungen sowie umfassende Tests der Qualitätseigenschaften der Services notwendig, damit ein Unternehmen überhaupt in Erwägung ziehen kann, sie ohne manuelle Kontrolle in geschäftskritische Prozesse einzubinden (s. [Berbner et al. 2005, 271f.], [Alt 2004, 269]). Es ist nicht zu erwarten, dass sich dieser Automatisierungsgrad der Servicekomposition in absehbarer Zukunft ausserhalb geschlossener, semantisch stark standardisierter Bereiche realisieren lässt. Dies wäre allenfalls innerhalb einer homogenen Softwareplattform vorstellbar oder in Anwendungsbereichen, für die umfassende fachliche und technische Industriestandards definiert sowie in rechtsgültigen Verträgen und konkreten Softwaresystemen implementiert sind.

Anhang A Definition der Metaentitätstypen Metaentitätstyp

Beschreibung

Aktivität

Beschreibung: Eine Aktivität ist eine in sich geschlossene Verrichtungseinheit in einem Prozess, die logisch und fachlich zusammengehörende Arbeitsschritte in einem aus Sicht des Benutzers sinnvollen Arbeitspaket zusammenfasst (vgl. [WFMC 1999, 13], [Vogler 2004, 89f.]). Aktivitäten können vollständig automatisch (automatisierte Aktivität) oder im Dialog mit dem Benutzer (manuelle Aktivität) ablaufen. Beziehungen: Ein Workflow umfasst mehrere Aktivitäten. Eine Aktivität bündelt einen oder mehrere Tasks.

Applikation

Beschreibung: Eine Applikation bzw. eine Anwendung ist Software, die Funktionen und Daten zur Unterstützung betrieblicher Aufgaben zur Verfügung stellt (s. [Mertens et al. 1997, 37], [Vogler 2004, 41]). Beziehungen: Eine Applikation kann eine Service-Implementierung enthalten. Eine Applikation kann Services nutzen. Eine Applikation besitzt Funktionalität und Daten.

Applikationsdomäne

Beschreibung: Applikationsdomänen sind ein Konzept zur Strukturierung der Applikationslandschaft. Sie kapseln eng voneinander abhängige Anwendungen oder Funktionen und Informationsobjekte aufgrund von fachlichen Kopplungsanalysen (z.B. gemeinsam genutzte Informationsobjekte, verwandte Funktionalität, gemeinsame Ownership) und bieten Anwendungen anderer Domänen über definierte Schnittstellen (i.d.R. Services) Zugriff auf die gekapselte Funktionalität (vgl. [Winter/Schelp 2005, 49], [Schlamann 2004, 60]). Beziehungen: Eine Applikationsdomäne gruppiert mehrere Applikationen. Eine Applikationsdomäne bietet mehrere Services.

Applikationsschnittstelle

Beschreibung: Eine Applikationsschnittstelle ist Bestandteil einer Applikation und bietet Zugriff auf Teile seiner Funktionen oder Daten. Applikationsschnittstellen sind implementierungsspezifisch in der Technologie der Applikation umgesetzt und entsprechen i.d.R. nicht den anwendungsübergreifenden Standards auf Serviceebene. Beispiele sind EJBInterfaces, Standardsoftware-APIs oder Message Queue Nachrichten (vgl. [Vogler 2004, 91], [Cheesman/Ntinolazos 2004, 15]). Beziehungen: Eine Applikation kann keine, eine oder mehrere Schnittstellen bieten.

Funktion

Beschreibung: Eine Applikationsfunktion realisiert eine (Geschäfts-)Funktion und ist Bestandteil einer Applikation [s. Schwinn 2006b, 34].

190

Anhang A Beziehungen: Mehrere auf den gleichen Informationsobjekten operierende Funktionen werden zu einer Applikation zusammengefasst.

Geschäftsprozess

Beschreibung: Ein Geschäftsprozess fasst eine Menge von Aufgaben, die in einer vorgegebenen Ablauffolge zu erledigen sind, und ggf. durch Applikationen unterstützt werden, als Einheit zusammen (vgl. [Hess 1996, 124ff.], [Vogler 2004, 96]). Seine Wertschöpfung besteht aus Leistungen an andere Prozesse innerhalb und ausserhalb des eigenen Unternehmens. Beziehungen: Ein Prozess setzt sich aus mehreren Aufgaben zusammen. Ein Prozess kann im Informationssystem als Workflow implementiert sein.

Informationsobjekt

Beschreibung: Informationsobjekte bzw. Datensammlungen stellen auf Dauer gespeicherte Informationen dar, auf die wiederholt zugegriffen wird [s. Schwinn 2006b, 34]. Eine oder mehrere Applikationsfunktionen erzeugen, verändern oder löschen Informationen in Datensammlungen. Die Datensammlung entspricht im relationalen Datenmodell einer Datenbank, kann aber bspw. auch aus einer Sammlung von Dokumenten (Word-Dokumente, HTML-Pages etc.) bestehen [s. Vogler 2004, 93]. Beziehungen: Eine Applikation operiert auf einer gemeinsamen Menge von Informationsobjekten.

Middlewaredienst

Beschreibung: Ein Middlewaredienst bzw. Integrationsmechanismus umfasst Basiskomponenten, welche Dienste und Protokolle für die transparente Kommunikation verteilter heterogener Anwendungen bereitstellen (vgl. [Vogler 2004, 95], [Mantel et al. 2004, 4]). Abhängig von einer gewählten Integrationsebene und der damit verbundenen Teilsicht der Systemintegration lassen sich verschiedene Integrationsmechanismen unterscheiden (s. Kap. 2.3). Beziehungen: Elemente der anwendungsneutralen Sicht wie Portal- / CA-Plattformen, Workflowsysteme, Service- und Applikationsschnittstellen nutzen Middlewaredienste.

Nachricht

Beschreibung: Nachrichten dienen der standardisierten Kommunikation zwischen Services und Servicenutzern. Sie enthalten die Daten, die Service und Servicenutzer zur Ausführung der von einer Serviceoperation unterstützten Arbeitseinheit austauschen müssen [s. Erl 2005, 288]. Sie werden durch den Schnittstellenkontrakt definiert und setzen sich aus einem Header- und einem Payload-Teil zusammen [s. Krafzig et al. 2004, 34]. Beziehungen: Eine Nachricht kann von mehreren Services zur Kommunikation mit anderen Services eingesetzt werden.

Anhang A Definition der Metaentitätstypen

191

Portal- / CAPlattform

Beschreibung: Portal- oder Composite Application (CA)-Plattformen bieten Entwicklungs- bzw. Integrations- und Laufzeitdienste für die Realisierung von desktopintegrierten Anwendungssystemen (s. [Vogler 2004, 55], [Puschmann 2003 74ff.], [Woods 2003, 4]). Beziehungen: Eine Portal- / CA-Plattform ist für die Implementierung von Prozessportalen zuständig. Eine Portal- / CA-Plattform nutzt verschiedene Middlewaredienste.

Prozessportal

Beschreibung: Ein Portal ist eine webbasierte Anwendung, die Inhalte, Dienste und Funktionen benutzerspezifisch integriert [s. Schelp/Winter 2002]. Beziehungen: Zur Umsetzung eines Prozessportals wird eine Portalplattform benötigt. Über ein Prozessportal greift eine Benutzerrolle auf die von ihr auszuführenden Taskflows zu.

Rolle

Beschreibung: Rollen sind Klassifikationen von Mitarbeitern, die sich aus den Fähigkeiten, den Aufgaben und dem Verantwortungsbereich ableiten lassen [vgl. Puschmann 2004, 53]. Beziehungen: Eine Rolle führt einen oder mehrere Taskflows aus.

Service

Beschreibung: Ein Service stellt ein abstraktes Software-Element bzw. eine Schnittstelle dar, die anderen Applikationen über ein Netzwerk einen standardisierten Zugriff auf Anwendungsfunktionalität anbietet. Beziehungen: Services werden genutzt von Applikationen, automatisierten Aktivitäten in Workflows, automatisierten Tasks in Taskflows oder von anderen Services (Composite Services).

Serviceschnittstelle

Beschreibung: Eine Serviceschnittstelle stellt die softwaretechnische Realisierung einer Servicespezifikation dar [s. Alonso et al. 2003, 161]. Beziehungen: Eine Serviceschnittstelle realisiert eine Servicespezifikation. Sie nutzt über Applikationsschnittstellen die (Fach-) Funktionalität von bestehenden Applikationen.

Servicespezifikation

Beschreibung: Eine Servicespezifikation enthält sämtliche Informationen, die ein Servicenutzer benötigt, ohne die interne Realisierung des Services zu kennen [Stojanovic 2005]. Inhalte umfassen die Schnittstellen-, die Verhaltens-, die Aufgaben-, die Qualitäts-, die Terminologie-, die Aufgabensowie die Vermarktungsebene eines Services [Turowski et al. 2002]. Beziehungen: Eine Servicespezifikation beschreibt einen Service. Mehrere Servicespezifikationen werden in einem Serviceverzeichnis hinterlegt.

192

Anhang A

Serviceverzeichnis

Beschreibung: In einem Serviceverzeichnis werden die verfügbaren Services registriert und ihre Servicespezifikation abgelegt. Es kategorisiert Services und bietet Servicenutzern Schnittstellen für eine automatisierte oder eine manuelle Suche nach Diensten [s. Dostal et al. 2005, 15]. Beziehungen: Ein Serviceverzeichnis speichert mehrere Servicespezifikationen.

Task

Beschreibung: Ein Task bzw. ein Arbeitsschritt ist eine atomare Verrichtungseinheit in einem Prozess, d.h. er lässt sich nicht weiter zerlegen [s. Vogler 2004, 98]. Ein Task ist entweder manuell, d.h. er wird von einem Benutzer ausgeführt oder automatisiert, d.h. er läuft IT-unterstützt ab. Beziehungen: Eine Aktivität bündelt einen oder mehrere Tasks. Ein automatisierter Task kann einen oder mehrere Services nutzen. Ein Task kann einen oder mehrere Workflows anstossen.

Taskflow

Beschreibung: Ein Taskflow implementiert den Steuer- und Datenfluss zwischen Tasks innerhalb einer Benutzeraktivität [s. Vogler 2004, 55]. Beziehungen: Ein Taskflow setzt sich aus mehreren manuellen oder automatisierten Tasks zusammen.

Workflow

Beschreibung: Ein Workflow ist die Automatisierung eines (Teil-)Prozesses. Er steuert die koordinierte Ausführung von Aktivitäten durch Applikationen bzw. Benutzer unter Rückgriff auf ein Workflow-Management-System (vgl. [WFMC 1999, 8], [Zur Muehlen 2004, 39]). Beziehungen: Ein Workflow implementiert einen Ausschnitt aus einem Prozess. Ein Workflow besteht aus mehreren Aktivitäten.

Workflow Management System

Beschreibung: Ein Workflow Management System bietet Entwicklungs-, Integrationsund Laufzeitdienste für die Realisierung automatisierter Abläufe (Workflows) zur anwendungsübergreifenden Integration von Geschäftsprozessen. Beziehungen: ein Workflow Management System steuert die Workflowausführung. Ein Workflow Management System nutzt Middlewaredienste.

Anhang B SOA-Charakterisierungen Quelle [Baskerville et al. 2005]

Charakterisierung SOA is characterized by the following fundamental features: • It is based on services that can be readily integrated, •

it is based on standards,

•

it is available on multiple platforms,

•

it provides self-contained (hence, loosely coupled) services, and

•

it incorporates and presupposes a contract that specifies the functionalities offered and at the same time, guarantees that they are replicable.

[Brown et al. 2002, 4f.]

Key characteristics for effective use of services: • Coarse-grained – Operations on services are frequently implemented to encompass more functionality and operate on larger data sets, compared with component-interface design. • Interface-based design – Services implement separately defined interfaces. The benefit of this is that multiple services can implement a common interface and a service can implement multiple interfaces. • Discoverable – Services need to be found at both design time and run time, not only by unique identity but also by interface identity and by service kind. • Single instance – Unlike component-based development, which instantiates components as needed, each service is a single, always running instance that a number of clients communicate with. • Loosely coupled – Services are connected to other services and clients using standard, dependency-reducing, decoupled messagebased methods such as XML document exchanges. • Asynchronous – In general, services use an asynchronous message passing approach; however, this is not required. In fact, many services will use synchronous message passing at times.

[Erl 2005, 291f.]

There are a common set of principles most associated with serviceorientation: • Services are reusable. • Services share a formal contract. • Services are loosely coupled. • Services abstract underlying logic. • Services are composable. • Services are autonomous. • Services are stateless. • Services are discoverable. Of these eight, autonomy, loose coupling, abstraction, and the need for a formal contract can be considered the core principles.

194 [Fritz 2004]

Anhang B Enterprise Services Architecture (ESA) is a set of principles that guides the evolution of a service-oriented IT architecture for increased business value and adaptive business solutions. [Its key principles are] • • • • •

[Klesse et al. 2005, 262ff.]

Abstraction – hiding confusing details, modularity – breaking down complexity, resulting in reusable pieces, standardized connectivity – enabling flexible composition of services to create bigger processes and scenarios, loose coupling – allowing for separate evolution of the various components without breaking any points of integration, incremental design – enabling changes to composition and configuration without affecting the interior of components, and vice versa.

Unter dem Stichwort Service-orientierte Architektur werden folgende Gestaltungsgrundsätze diskutiert: • • • • •

Trennung von Präsentations-, Geschäfts- und Datenzugriffslogik. Partitionierung der Logik in unabhängige Module bzw. Services. Explizite Spezifikation und Dokumentation der Schnittstellen. Externalisierung bzw. Kapselung der Steuerungslogik über mehrere Applikationen (Workflowmanagement). Lose Kopplung der Applikationen.

[McGovern et al. 2003, 40f.]

Service-oriented software architecture has these characteristics:

[Newcomer/ Lomow 2004, 72f.]

[The most important SOA principles and guidelines are:]

• • • • • • • • • • •

• •

•

Services are discoverable and dynamically bound. Services are self-contained and modular. Services stress interoperability. Services are loosely coupled. Services have a network-addressable interface. Services have coarse-grained interfaces. Services are location-transparent. Services are composable. Service-oriented architecture supports self-healing. Services are the central organizing concept of an SOA. Every service is defined by a formal contract that clearly separates the functionality being provided from technical implementation. Services should only interact with other Services through their well-defined public interfaces. Services should be accessible through standardized technologies that are available across a wide range of environments. This also implies that the invocation mechanisms (protocols, transports, discovery mechanisms, and service descriptions) should comply with widely accepted industry standards. […] Services should be defined at a level of abstraction that corre-

Anhang B SOA-Charakterisierungen

•

• •

•

•

[Papazoglou 2003, 3]

sponds to real world business activities and recognizable business functions so as to better align business needs and technical capabilities. Services should be meaningful to service requester. Avoid letting legacy systems and implementation details dictate services and service contracts. Services should be loosely coupled. Collections of related services should use the same XML document types to facilitate information exchange among related services, and the structure and semantics of the documents must be agreed to and well understood. Services should perform discrete tasks and provide simple interfaces to access their functionality to encourage reuse and loose coupling. Services should provide metadata that defines their capabilities and constraints, and this metadata should be available in a repository, which itself can be accessed through services. […]

Services are self-describing, platform-agnostic computational elements that support rapid, low-cost composition of distributed applications. [They] should be: •

• •

[W3C 2004a]

195

Technology neutral: they must be invocable through standardized lowest common denominator technologies that are available to almost all IT environments. This implies that the invocation mechanisms (protocols, descriptions and discovery mechanisms) should comply with widely accepted standards. Loosely coupled: they must not require knowledge or any internal structures or conventions (context) at the client or service side. Support location transparency: services should have their definitions and location information stored in a repository such as UDDI and be accessible by a variety of clients that can locate and invoke the services irrespective of their location.

[A SOA] is typically characterized by the following properties: •

•

• • • •

Logical view: The service is an abstracted, logical view of actual programs, databases, business processes etc., defined in terms of what it does, typically carrying out a business-level operation. Message orientation: The service is formally defined in terms of the messages exchanged between provider agents and requester agents, and not the properties of the agents themselves. […] Description orientation: A service is described by machineprocessable meta data. […] Granularity: Services tend to use a small number of operations with relatively large and complex messages. Network orientation: Services tend to be oriented toward use over a network […]. Platform neutral: Messages are sent in a platform-neutral, standardized format delivered through the interfaces. XML is the most obvious format that meets this constraint.

Anhang C Ausprägung der Designprinzipien Die folgenden Abschnitte beschreiben die Ausprägungen der SOA-Designprinzipien in den untersuchten Fallstudien. Ausprägung der Designprinzipien bei Deutsche Post Brief Designprinzip

Ausprägung

Abstraktion von der Serviceimplementierung

•

Parameterbasierter Zugriff auf Servicefunktionalität.

•

Plattformneutrale Beschreibung der Serviceschnittstellen (UML, XML, WSDL, natürlichsprachlich, …).

Umfassende Servicespezifikation

Servicespezifikationen enthalten technische Schnittstelleninformationen (logische Adresse etc.), Beschreibungen der Serviceoperationen und Nachrichtenstrukturen, das dynamische Verhalten des Services (Sequenzdiagramme), nichtfunktionale Eigenschaften etc.

Stabile, gemanagte Servicekontrakte

•

Zentrales Repository, SLAs.

•

Definierte Prozesse für die Serviceentwicklung und -weiterentwicklung.

Technische Schnittstellenstandardisierung

Zentrale technische Integrationsinfrastruktur (SBB) mit vereinheitlichten Schnittstellen und Kommunikationsstandards (J2EE, Web Service Standards für zwischenbetriebliche Integration), einheitlicher Servicebeschreibung, zentralem Repository, zentralen Transformations- und Sicherheitsdiensten etc.

Fachliche Schnittstellenstandardisierung

Fachklassenmodelle mit standardisierter Semantik pro fachlicher Domäne.

Verwendung offener und verbreiteter Industriestandards

Hohe Servicekohäsion und schwache logische Kopplung

•

Hersteller- und Produktunabhängigkeit wichtiges Ziel bei der Entwicklung der technischen Integrationsinfrastruktur.

•

Auf Serviceebene Verwendung des auf Java Plattformen ausgelegten J2EE-Frameworks für innerbetrieblichen Bereich, Web Service Standards für zwischenbetrieblichen Bereich.

•

Verwendung herstellerspezifischer Erweiterungen in konkreten Produkten (z.B. WebSphere MQ) vermieden.

•

Keine Verwendung von auf Industriestandards basierenden fachlichen Standards.

•

Kohäsions- / Kopplungsüberlegungen bei der Prozesszerlegung und Strukturierung der Applikationslandschaft auf Ebene Anwendungsdomänen.

•

Services realisieren möglichst abgeschlossene Funktionen bzw. kapseln einzelne Geschäftsobjekte.

198

Lose gekoppelte Kommunikation

An Geschäftskonzepten orientierte Servicegranularität

Generalisierung der Serviceleistung

Anhang C •

Dynamische Adressierung über Directory Service der Integrationsinfrastruktur.

•

Synchrone und asynchrone Kommunikation unterstützt, Serviceaufruf über Austausch von XML-Nachrichten.

•

Statuslose Serviceinteraktion angestrebt.

Prozess- und geschäftsobjektorientierte Serviceidentifikation, Services kapseln aus fachlicher Sicht sinnvolle und beschreibbare Geschäftslogik und bearbeiten möglichst komplette Geschäftsentitäten. •

Entwicklung der Servicefunktionalität über Analyse verschiedener nutzender Geschäftsprozesse.

•

Servicegeneralisierung mit Zielsetzung Wiederverwendung und längerfristiger Stabilität angestrebt, v.a. über grobe Schnittstellengranularität und generischen, mit mehreren Nutzern abgestimmten Schnittstellen-Datenmodellen.

Ausprägung der Designprinzipien bei Credit Suisse Designprinzip Abstraktion von der Serviceimplementierung

Umfassende Servicespezifikation

Stabile, gemanagte Servicekontrakte

Technische Schnittstellenstandardisierung

Fachliche Schnittstellenstandardisierung

Ausprägung •

Parameterbasierter Zugriff auf Servicefunktionalität.

•

Plattformneutrale Beschreibung der Serviceschnittstellen (OMG-IDL, XML, natürlichsprachlich, …).

Servicespezifikationen enthalten formale Schnittstellenspezifikation mit Operationen und Input- / Outputparametern, natürlichsprachliche Beschreibung der Servicefunktion, Ausnahmen und Vor- / Nachbedingungen, angestrebte Servicelevels, Planungsangaben (Status, Daten für durchgeführte oder geplante Tests, Datum der Produktivsetzung), Kontaktinformationen, Implementierungsinformationen. •

Zentrales Repository (SQL-DB), SLAs.

•

Gesteuerte Prozesse und Qualitätschecks für Serviceentwicklung, -nutzung und -anpassungen, Versionsmanagement.

•

Drei technische Integrationsinfrastrukturen mit jeweils eigenen, durch Architekturvorgaben definierte Schnittstellen- und Kommunikationsstandards für technische Konnektivität.

•

Standardisierte Datentypen, einheitliche Servicebeschreibung, zentrales Repository.

•

Standardisierte Anwendungs-bzw. Entwicklungsplattformen.

Vorgaben für Namenskonventionen, übergreifende Datenmodelle und einheitliche Fehlercodes sind in Entwicklung.

Anhang C Ausprägung der Designprinzipien

Verwendung offener und verbreiteter Industriestandards

Hohe Servicekohäsion und schwache logische Kopplung

Lose gekoppelte Kommunikation

An Geschäftskonzepten orientierte Servicegranularität Generalisierung der Serviceleistung

199

•

Unterstützung von bzw. Interoperabilität zwischen verschiedenen Technologieplattformen wichtiger als Herstellerunabhängigkeit und Offenheit der verwendeten Technologien.

•

Verwendung des OMG-Standards CORBA für synchronen Bus, IBM-Technologien für asynchronen Bus. Keine vorgeschriebene Verwendung fachlicher Industriestandards.

•

Einsatz von Web Service Standards regelmässig geprüft, momentan nicht geplant.

Kohäsion und Kopplung eher als Prinzip zur Strukturierung auf Ebene Anwendungsdomäne, weniger auf Ebene Einzelservices verwendet. •

Dynamische Serviceadressierung und möglichst statuslose Interaktion als Designprinzipien verfolgt.

•

Asynchrone Kommunikation nicht zwingend, aus Performanzgründen häufig synchrone Kommunikation über CORBA-Bus zwischen Backend- und Frontendsystemen. Serviceaufruf über Austausch von XML-Nachrichten und binäre Nachrichtenformate (CORBA-Services).

Grobe Granularität angestrebt mit den Zielen, den Netzwerkverkehr zu minimieren und Services statuslos interagieren zu lassen. •

Servicegeneralisierung mit Zielsetzung Wiederverwendung angestrebt, v.a. über grobe Schnittstellengranularität.

•

Keine explizite Identifikation und Analyse zusätzlicher potenzieller Servicenutzer im Rahmen der Serviceentwicklung.

Ausprägung der Designprinzipien bei T-Com Designprinzip Abstraktion von der Serviceimplementierung

Umfassende Servicespezifikation

Stabile, gemanagte Servicekontrakte

Ausprägung •

Parameterbasierter Zugriff auf Servicefunktionalität.

•

Plattformneutrale Beschreibung der Serviceschnittstellen (XML, natürlichsprachlich).

Servicespezifikationen enthalten technische Schnittstelleninformationen, Nachrichten-Datenmodelle in XML, natürlichsprachliche Beschreibungen der Operationen und Parameter, organisatorische Informationen (Name, Nummer, Version, Ansprechpartner etc.), Service-Level-Informationen (Performanzinformationen, Releasezyklen etc.). •

Zentrales Repository, SLAs.

•

Definierte Prozesse für die Serviceentwicklung und -weiterentwicklung.

200

Anhang C

Technische Schnittstellenstandardisierung

Technischer Rahmenplan definiert zentrale technische Integrationsinfrastruktur mit vereinheitlichten Schnittstellen und Kommunikationsstandards, einheitlicher Servicebeschreibung, zentralem Repository, zentralen Transformations- und Sicherheitsdiensten etc.

Fachliche Schnittstellenstandardisierung

Business Object Model mit standardisierten Datenmodellen für wichtige anwendungsübergreifende Geschäftsentitäten.

Verwendung offener und verbreiteter Industriestandards

Hohe Servicekohäsion und schwache logische Kopplung

Lose gekoppelte Kommunikation

An Geschäftskonzepten orientierte Servicegranularität

Generalisierung der Serviceleistung

•

Hersteller-Plattformstrategie für Integrationsinfrastruktur.

•

Auf Serviceebene Verwendung der durch die WebSpherePlattform spezifizierten Kommunikations- und Schnittstellentechnologien.

•

Verwendung von Web Service Standards für zwischenbetrieblichen Bereich und Industriestandards für semantische Datenmodelle gegenwärtig geprüft.

•

Kohäsions- / Kopplungsüberlegungen bei der Prozesszerlegung und der Strukturierung der Applikationslandschaft auf Ebene Anwendungsdomänen.

•

Serviceautonomie als Designprinzip formuliert.

•

Dynamische Serviceadressierung.

•

Synchrone und asynchrone Kommunikation unterstützt, Serviceaufruf über Austausch von XML-Nachrichten.

•

Statuslose und statusbehaftete Services.

•

An Prozessaktivitäten und zentralen Geschäftsobjekten orientierte Serviceidentifikation.

•

Services bearbeiten möglichst komplette Geschäftsentitäten (wo aus Performanzgründen möglich).

•

Funktionsgranularität unter Abwägung der Wiederverwendbarkeit (höher bei feiner Funktionsgranularität) und Netzwerkaufrufen (weniger bei grober Funktionsgranularität).

•

Entwicklung der Servicefunktionalität anhand Analyse verschiedener nutzender Geschäftsprozesse.

•

Servicegeneralisierung mit Zielsetzung Wiederverwendung angestrebt, v.a. über generische, standardisierte Datenmodelle mit grober Schnittstellengranularität und generischer, aus Prozessvarianten identifizierter Funktionalität.

Anhang C Ausprägung der Designprinzipien

201

Ausprägung der Designprinzipien bei Zuger Kantonalbank Designprinzip Abstraktion von der Serviceimplementierung Umfassende Servicespezifikation Stabile, gemanagte Servicekontrakte

Ausprägung • •

Parameterbasierter Zugriff auf Servicefunktionalität. Nur SAP-basierende Schnittstellen sind im Service Layer definiert. • Plattformunabhängige Beschreibung.

Servicespezifikationen enthalten technische Schnittstelleninformationen, Fehlerbehandlung, Erweiterbarkeit, Funktionalität, Aussagen zu Datenvolumen, Performanz, Datenschutz, Datensicherheit etc. •

Zentrales Wartungs- und Entwicklungsteam innerhalb der Betriebsabteilung bei CSC. • Keine definierten Prozesse für die Weiterentwicklung bzw. das Versionsmanagement.

• Technische Schnittstellenstandardisierung

Momentan keine zentrale technische Integrationsinfrastruktur für Zugriff auf alle vom BAP integrierten Funktionen. • Bis auf Bankkartenfunktionen alle Funktionen zentral und mit homogenem Zugriff (Datenformate, Kommunikationsprotokoll) in SAP-Banking Application Server implementiert.

Fachliche Schnittstellenstandardisierung

Nicht berücksichtigt (anwendungsspezifische Datenmodelle, Fehlercodes etc. der Services implementierenden Backendsysteme).

Verwendung offener und verbreiteter Industriestandards

Nicht berücksichtigt.

Hohe Servicekohäsion und schwache logische Kopplung

Lose gekoppelte Kommunikation

•

Kohäsions- / Kopplungsüberlegungen bei der Serviceidentifikation durch Prozesszerlegung. • Services realisieren möglichst abgeschlossene Funktionen bzw. kapseln einzelne Geschäftsobjekte.

• •

Dynamische Serviceadressierung über logische Adressen. Serviceaufrufe aus BAP i.d.R. synchron (kurze Antwortzeiten, Performanz wichtig), Serviceaufrufe zu (ABAP-) Service Layer über SAP RFC-Protokoll, zu Kartenlösung via binäres Datenformat (Java RMI). • Statuslose Services, kapseln komplette Transaktionen.

202

Anhang C •

An Geschäftskonzepten orientierte Servicegranularität

Generalisierung der Serviceleistung

An Prozessaktivitäten und zentralen Geschäftsobjekten orientierte Serviceidentifikation. • Services bearbeiten möglichst komplette Geschäftsentitäten – wo aus Performanzgründen möglich und sinnvoll – und bündeln bzw. erweitern Funktionen mehrerer BackendSchnittstellen.

•

Entwicklung der Servicefunktionalität aufgrund Analyse verschiedener nutzender Kundenberatungsprozesse. • Erweiterbarkeit der Servicefunktionalität über generische Felder in den ausgetauschten XML-Nachrichten.

Abkürzungen ACID ADSI API ASAP BPEL(4WS) BPM BPMN BPR CA CCM CIDL CMM CMMI CobiT COM CORBA CRUD DCOM EJB EPK ERP ESB ETL FTP GIOP GUI HTTP IDL IETF IIOP IS IT J2EE JAAS JAX-RPC

Atomicity, Consistency, Isolation, Durability Active Directory Service Interfaces Application Programming Interface Asynchronous Service Access Protocol Business Process Execution Language (for Web Services) Business Process Management Business Process Modeling Notation Business Process Reengineering Composite Application CORBA Component Model Component Implementation Definition Language Capability Maturity Model Capability Maturity Model Integration Control Objectives for Information and Related Technology Component Object Model Common Object Request Broker Architecture Create, read, update, delete Distributed Component Object Model Enterprise Java Bean Ereignisgesteuerte Prozesskette Enterprise Resource Planning Enterprise Service Bus Extraction-Transformation-Load File Transfer Protocol General Inter-ORB Protocol Graphical User Interface, grafische Benutzerschnittstelle HyperText Transfer Protocol Interface Definition Language Internet Engineering Task Force Internet Inter-Orb Protocol Informationssystem Informations (und Kommunikations)-technologie Java 2 Enterprise Edition Java Authentication and Authorization Service Java API for XML-based RPC

204

JDBC JMS JNDI JTA MDA MIDL MOM MTOM OASIS ODBC OMA OMG RM-ODP ROI RPC SMTP SOA SOAP SQL SWOT TP UDDI UML UN/CEFACT URI URL W3C WFMS WS WS-CAF WS-CDL WSDL WSRM WSRP XML

Abkürzungen

Java DataBase Connectivity Java Messaging Service Java Naming and Directory Interface Java Transaction API Model Driven Architecture Microsoft Interface Definition Language Message Oriented Middleware Message Transmission Optimization Mechanism Organization for the Advancement of Structured Information Standards Open DataBase Connectivity Object Management Architecture Object Management Group Reference Model of Open Distributed Processing Return on investment Remote Procedure Call Simple Mail Transport Protocol Serviceorientierte Architektur(en) Ehemals „simple object access protocol“, seit v1.2 nicht mehr als Akronym verwendet Structured Query Language Strengths, Weaknesses, Opportunities, Threats Transaction Processing Universal Description Discovery and Integration Unified Modeling Language United Nations / Centre for Trade Facilitation and Electronic Business Unified Resource Identifier Unified Resource Locator World Wide Web Consortium Workflow Management System Web Service Web Services Composite Application Framework Web Services Choreography Description Language Web Service Description Language Web Services Reliable Messaging Web Services for Remote Portlets Extensible Markup Language

Literatur [Adams 2005] Adams, H., When - and when not - to pursue SOA, http://www-128.ibm.com/ developerworks/library/ar-itio1/, 23.02.2006 [Adams et al. 2002] Adams, J., Koushik, S., Vasudeva, G., Galambos, G., Patterns for e-business: A Strategy for Reuse, IBM Press, Double Oak 2002 [Aier/Dogan 2004] Aier, S., Dogan, T., Nachhaltigkeit als Gestaltungsziel von Unternehmensarchitekturen, in: Aier, S., Schönherr, M. (Hrsg.), Enterprise Application Integration – Serviceorientierung und nachhaltige Architekturen, Gito, Berlin 2004, S. 75-122 [Aier/Schönherr 2004a] Aier, S., Schönherr, M. (Ed.), Enterprise Application Integration - Band 2: Serviceorientierung und nachhaltige Architektur, Berlin 2004a [Aier/Schönherr 2004b] Aier, S., Schönherr, M., Flexibilisierung von Organisations- und IT-Architekturen durch EAI, in: Aier, S., Schönherr, M. (Hrsg.), Enterprise Application Integration - Flexibilisierung komplexer Unternehmensarchitekturen, GITO-Verlag, Berlin 2004b, S. 1-60 [Alexander 1977] Alexander, C., The Timeless Way of Building, Oxford University Press, Oxford 1977 [Alonso 2002] Alonso, G., Myths around Web Services, in: Bulletin of the Technical Committee on Data Engineering, 25, 2002, Nr. 4, S. 3-9 [Alonso et al. 2003] Alonso, G., Casati, F., Kuno, H., Machiraju, V., Web Services: Concepts, Architectures and Applications, Springer, Berlin 2003 [Alt 2004] Alt, R., Überbetriebliches Prozessmanagement - Gestaltungsmodelle und Technologien zur Realisierung integrierter Prozessportale, Habilitation, Universität St. Gallen, St. Gallen 2004 [Anderson et al. 2005] Anderson, D., Howell-Barber, H., Hill, J., Javed, N., Lawler, J., Li, Z., A study of web services projects in the financial services industry, in: Information Systems Management, 22, 2005, Nr. 1, S. 66-76 [Arsanjani 2004] Arsanjani, A., Service-oriented modeling and architecture - How to identify, specify, and realize services for your SOA, http://www-106.ibm.com/ developerworks/webservices/library/ws-soa-design1/, 30.11.2004

206

Literatur

[Bacheldor 2004] Bacheldor, B., Billion-Dollar Bet, http://www.informationweek.com/story/show Article.jhtml?articleID=22102067, 11.04.2006 [Baghdadi 2004] Baghdadi, Y., A web services-oriented approach to unlock information, Proceedings of the Information Science and Information Technology Education Joint Conference (InSITE '04), 2004, S. 585-596 [Baghdadi 2005] Baghdadi, Y., A business model for deploying web services: A data-centric approach based on factual dependencies, in: Information Systems & E-Business Management, 3, 2005, Nr. 2, S. 151-173 [Baker 2002] Baker, S., Web Services and CORBA, On the Move to Meaningful Internet Systems 2002: CoopIS, DOA, and ODBASE Confederated International Conferences CoopIS, DOA, and ODBASE 2002, 2002, S. 618-632 [Baker/Dobson 2005] Baker, S., Dobson, S., Comparing service-oriented and distributed object architectures, Proceedings of the International Symposium on Distributed Objects and Applications, LNCS Volume 3760, Springer Verlag, 2005, S. 631-645 [Baldwin/Clark 1997] Baldwin, C. Y., Clark, K. B., Managing in an age of modularity, in: Harvard Business Review, 1997, Nr. September - October, S. 84-93 [Balzer 2004] Balzer, Y., Improve your SOA project plans, http://www-128.ibm.com/ developerworks/ webservices/library/ws-improvesoa/, 23.02.2006 [Balzert 1998] Balzert, H., Lehrbuch der Software-Technik, Band 2 - Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung, Spektrum, Heidelberg, Berlin 1998 [Balzert 1999] Balzert, H., Lehrbuch Grundlagen der Informatik - Konzepte und Notationen in UML, Java und C++, Spektrum Akademischer Verlag, Heidelberg, Berlin 1999 [Balzert 2001] Balzert, H., Lehrbuch der Software-Technik, Spektrum Akademischer Verlag, Heidelberg 2001 [Baresi et al. 2003] Baresi, L., Heckel, R., Thöne, S., Varró, D., Modeling and validation of serviceoriented architectures: application vs. style, Proceedings of the 9th European software engineering conference held jointly with 11th ACM SIGSOFT international symposium on Foundations of software engineering (ESEC/FSE-11), 2003, S. 68 - 77

Literatur

207

[Barkmeyer et al. 2003] Barkmeyer, E. J., Barnard Feeney, A., Denno, P., Flater, D. W., Potts Steves, M., Wallace, E. K., Concepts for Automating Systems Integration, NISTR 6928, National Institute of Standards and Technology, U.S. Department of Commerce, 2003 [Baskerville et al. 2005] Baskerville, R., Cavallari, M., Hjort-Madsen, K., Pries-Heje, J., Sorrentino, M., Virili, F., Extensible architectures: The strategic value of service-oriented architecture in banking, Proceedings of the Thirteenth European Conference on Information Systems, 2005 [Bath 2004] Bath, U., Serviceorientierte Architektur - Komplexitätsmanagement durch Reduktion, Beitrag in: GI Regionaltreff Bonn 2004 [BEA Systems 2006] BEA Systems, BEA AquaLogic™ Product Family, http://www.bea.com/ framework.jsp?CNT=index.htm&FP=/content/products/aqualogic/, 10.04.2006 [Bennicke/Rust 2004] Bennicke, M., Rust, H., Messen im Software-Engineering und metrikbasierte Qualitätsanalyse, Working Paper, Virtuelles Software Engineering Kompetenzzentrum, 2004 [Berbner et al. 2005] Berbner, R., Heckmann, O., Mauthe, A., Steinmetz, R., Eine Dienstgüte unterstützende Webservice-Architektur für flexible Geschäftsprozesse, in: Wirtschaftsinformatik, 47, 2005, Nr. 4, S. 268-277 [Bernus et al. 1998] Bernus, P., Mertins, K., Schmidt, G., Handbook on Architectures of Information Systems, Springer, Berlin u.a. 1998 [Bieberstein et al. 2005a] Bieberstein, N., Bose, S., Fiammante, M., Jones, K., Shah, R., Service-Oriented Architecture Compass, IBM Press/Pearson, New Jersey 2005a [Bieberstein et al. 2005b] Bieberstein, N., Bose, S., Walker, L., Lynch, A., Impact of service-oriented architecture on enterprise systems, organizational structures, and individuals, in: IBM Systems Journal, 44, 2005b, Nr. 4, S. 691-708 [Bloomberg 2004a] Bloomberg, J., SOA + EDA = FUD?, http://www.devx.com/opinion/Article/ 21326?trk=DXRSS_LATEST, 24.06.2004 [Bloomberg 2004b] Bloomberg, J., When to use an SOA, http://www.zapthink.com/report.html? id=ZAPFLASH-02162004, 23.02.2006 [Blowers et al. 2004] Blowers, M., Holden, J., Rodger, A., Enterprise Architecture: An End-to-end Approach for Re-aligning IT with Business Aims, Butler Group, Hull 2004

208

Literatur

[Böhmann 2004] Böhmann, T., Modularisierung von IT-Dienstleistungen, Deutscher Universitätsverlag, Wiesbaden 2004 [Borzo 2005] Borzo, J., Business 2010 - Embracing the challenge of change, Report from the Economist Intelligence Unit sponsored by SAP, London 2005 [Brown et al. 2002] Brown, A., Johnston, S., Kelly, K., Using service-oriented architecture and component-based development to build web service applications, Rational Software Corporation, 2002 [Carr 2003] Carr, N. G., IT doesn't matter, in: Harvard Business Review, 2003, Nr. May, S. 41-49 [Cervantes/Hall 2005] Cervantes, H., Hall, R. S., Technical Concepts of Service Orientation, in: Stojanovic, Z., Dahanayake, A. (Hrsg.), Service-Oriented Software System Engineering: Challenges and Practices, Idea Group Publishing, Hershey et al. 2005, S. 126 [Chappell 2004] Chappell, D. A., Enterprise Service Bus, O'Reilly, Sebastopol, CA 2004 [Cheesman/Ntinolazos 2004] Cheesman, J., Ntinolazos, G., The SOA Reference Model, in: CBDi Journal, 2004, Nr. März, S. 9-21 [Cherbakov et al. 2005] Cherbakov, L., Galambos, G., Harishankar, R., Kalyana, S., Rackham, G., Impact of service orientation at the business level, in: IBM Systems Journal, 44, 2005, Nr. 4, S. 653-668 [Chidamber/Kemerer 1994] Chidamber, S. R., Kemerer, C. F., A Metrics Suite for Object Oriented Design, in: IEEE Transactions on Software Engineering, 20, 1994, Nr. 6, S. 476-493 [Cohn 2005] Cohn, M., Estimating With Use Case Points, in: Methods & Tools, 13, 2005, Nr. 3, S. 3-13 [Colan 2004] Colan, M., Service-Oriented Architecture expands the vision of Web services, Part 1, http://www-128.ibm.com/developerworks/webservices/library/ws-soaintro .html, 16.11.2005 [Curbera et al. 2003] Curbera, F., Khalaf, R., Mukhi, N., Tai, S., Weerawarana, S., The next step in Web Services, in: Communications of the ACM, 46, 2003, Nr. 10, S. 29-34

Literatur

209

[Derungs 1997] Derungs, M., Workflowsysteme zur Prozessumsetzung, Dissertation, Universität St. Gallen, St. Gallen 1997 [Dietzsch/Goetz 2005] Dietzsch, A., Goetz, T., Nutzen-orientiertes Management einer Serviceorientierten Unternehmensarchitektur, Wirtschaftsinformatik 2005: eEconomy, eGovernment, eSociety, Bamberg, Physica-Verlag, 2005, S. 1519-1528 [Dodd 2005a] Dodd, J., Practical Service Specification and Design Part 1: Planning the Services, in: CBDi Journal, 2005a, Nr. März, S. 22-29 [Dodd 2005b] Dodd, J., Practical Service Specification and Design Part 2a: Refining Service Requirements for Consumers, in: CBDi Journal, 2005b, Nr. April, S. 13-20 [Dodd 2005c] Dodd, J., Practical Service Specification and Design Part 2b: Refining Service Requirements, in: CBDi Journal, 2005c, Nr. Mai, S. 24-31 [Dodd 2005d] Dodd, J., Practical Service Specification and Design Part 3: Specifying Services, in: CBDi Journal, 2005d, Nr. Juni, S. 12-18 [Dodd 2005e] Dodd, J., Practical Service Specification and Design Part 4: Delivering Services, in: CBDi Journal, 2005e, Nr. Juli/August, S. 11-20 [Dostal et al. 2005] Dostal, W., Jeckle, M., Melzer, I., Service-orientierte Architekturen mit Web Services, 1, Spektrum Akademischer Verlag, München 2005 [Endrei et al. 2004] Endrei, M., Ang, J., Arsanjani, A., Chua, S., Comte, P., Krogdahl, P., Luo, M., Newling, T., Patterns: Service-Oriented Architecture and Web Services, IBM Corporation, 2004 [Erl 2005] Erl, T., Service-Oriented Architecture, Prentice Hall, New York 2005 [Esswein/Zumpe 2002] Esswein, W., Zumpe, S., Realisierung des Datenaustauschs im elektronischen Handel, in: Informatik Spektrum, 25, 2002, Nr. 8, S. 251-261 [Feiman/Hotle 2004] Feiman, J., Hotle, M., SODA Reduces Development Efforts, Gartner inc., Stamford 2004 [Fensel/Bussler 2002] Fensel, D., Bussler, C., The Web Service Modeling Framework WSMF, in: Electronic Commerce: Research and Applications, 2002, Nr. 1, S. 113-137

210

Literatur

[Ferstl/Sinz 1995] Ferstl, O. K., Sinz, E. J., Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschäftsprozessen, in: Wirtschaftsinformatik, Vol. 37, 1995, Nr. Iss. 3, S. 209-220 [Feuerlicht 2005] Feuerlicht, G., Design of service interfaces for e-business applications using data normalization techniques, in: Information Systems and E-Business Management, 3, 2005, Nr. 4, S. 363-376 [Feuerlicht/Meesathit 2004] Feuerlicht, G., Meesathit, S., Design framework for interoperable service interfaces, Proceedings of the 2nd international conference on Service oriented computing (ICSOC '04), 2004, S. 299-307 [Fielding 2000] Fielding, R. T., Architectural Styles and the Design of Network-based Software Architectures, Dissertation, University of California, Irvine 2000 [Fontanella 2005] Fontanella, J., The Service-Oriented Architecture in the Supply Chain Benchmark Report, Working Paper, Aberdeen Group, Boston 2005 [Fritz 2004] Fritz, F.-J., An Introduction to the Principles of Enterprise Services Architecture (ESA), http://www.sapinsideronline.com/spijsp/article.jsp?article_id=37906&volumes _id=5147, 26.06.2004 [Gall et al. 1998] Gall, H., Hajek, K., Jazayeri, M., Detection of logical coupling based on product release history, Proceedings of the International Conference on Software Maintenance (ICSM), 1998, S. 190-198 [Gallas 2004] Gallas, B. E., Der Aufbau eines Service Life Cycle Managements für eine Service Orientierte Architektur als Brücke zwischen Geschäftsprozess und IT Integration, in: Aier, S., Schönherr, M. (Hrsg.), Enterprise Application Integration - Band 2 : Serviceorientierung und nachhaltige Architektur, GITO Verlag, Berlin 2004, S. 232-278 [Gioldasis et al. 2003] Gioldasis, N., Moumoutzis, N., Kazasis, F., Pappas, N., Christodoulakis, S., A Service Oriented Architecture for Managing Operational Strategies, ICWSEurope 2003, LNCS 2853, 2003, S. 11-23 [Griffel 1998] Griffel, F., Componentware: Konzepte und Techniken eines Softwareparadigmas, dpunkt, Heidelberg 1998 [Gutzwiller 1994] Gutzwiller, T., Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen, Physica, Heidelberg 1994

Literatur

211

[Hafner 2005] Hafner, M., Entwicklung einer Methode für das Management der Informationssystemarchitektur im Unternehmen, Dissertation, Universität St. Gallen, Difo, Bamberg 2005 [Hagen 2004] Hagen, C., Integrationsarchitektur der Credit Suisse, in: Aier, S., Schönherr, M. (Hrsg.), Enterprise Application Integration - Flexibilisierung komplexer Unternehmensarchitekturen, GITO Verlag, Berlin 2004, S. 61-83 [Hars/Schlüter-Langdon 2002] Hars, A., Schlüter-Langdon, C., Chancen und Risiken für verteilte Informationssysteme, in: Information Management & Consulting, 17, 2002, Nr. 3, S. 13-19 [Hasselbring 2000] Hasselbring, W., Information System Integration, in: Communications of the ACM, 43, 2000, Nr. 6, S. 32-38 [Hasselbring 2006] Hasselbring, W., Software-Architektur, in: Informatik Spektrum, 29, 2006, Nr. 1, S. 48-52 [Hayward 2005] Hayward, S., Positions 2005: Service-oriented Architecture Adds Flexibility to Business Processes, Gartner inc., Stamford 2005 [He 2003] He, H., What is Service-Oriented Architecture?, http://webservices.xml.com/ pub/a/ws/2003/09/30/soa.html, 16.11.2005 [Heinrich/Lehner 2005] Heinrich, L. J., Lehner, F., Informationsmanagement, Oldenbourg, München 2005 [Helbig 2005] Helbig, J., Welcome and Introduction, Beitrag in: SOA Days Bonn 2005 [Hepp et al. 2005] Hepp, M., Leymann, F., Domingue, J., Wahler, A., Fensel, D., Semantic Business Process Management: A Vision Towards Using Semantic Web Services for Business Process Management, Proceedings of the IEEE ICEBE 2005, October 18-20, Beijing, China, 2005, S. 535-540 [Herr/Bath 2004] Herr, M., Bath, U., SBB Motivation Paper: The business-oriented background of Service Backbone, http://www.sbb.org/uploads/mages/24/SBB_Technical_Paper_ V1_0.pdf, 09.11.2004 [Herr et al. 2004] Herr, M., Bath, U., Koschel, A., Implementation of a Service Oriented Architecture at Deutsche Post MAIL, Proceedings of the European Conference on Web Services, Springer, 2004, S. 227-238

212

Literatur

[Herr/Brombach 2004] Herr, M., Brombach, S., SBB Management Paper: Benefits and application range, http://www.sbb.org/uploads/images/26/SOP_Management_Paper_V1_0.pdf, 09.11.2004 [Herr/Sannemann 2004] Herr, M., Sannemann, U., SBB Technical Paper: The architecture of Service Backbone, http://www.sbb.org/uploads/images/24/SBB_Technical_Paper_V1_ 0.pdf, 09.11.2004 [Hess 1996] Hess, T., Entwurf betrieblicher Prozesse - Grundlagen, Bestehende Methoden, Neue Ansätze, 1. Auflage, Gabler, Wiesbaden 1996 [Holmqvist/Persson 2003] Holmqvist, T. K. P., Persson, M. L., Analysis and Improvement of Product Modularization Methods: Their Ability to Deal with Complex Products, in: Systems Engineering, 6, 2003, Nr. 3, S. 195-209 [IBM 1984] IBM, Business Systems Planning: Information Systems Planning Guide, 4. Auflage, IBM, Atlanta 1984 [IBM 2006] IBM, What IBM tools and products are available for SOA?, http://www128.ibm.com/developerworks/webservices/newto/#7, 10.04.2006 [IDABC 2004] IDABC, European Interoperability Framework for Pan-European eGovernment Services, EU Enterprise and Industry Commission, 2004 [IDS 2005] IDS, ARIS for SAP NetWeaver - The Business Process Design Solution for NetWeaver, IDS Scheer, Saarbrücken 2005 [IEEE 1990] IEEE, IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, Institute of Electrical and Electronics Engineers, New York 1990 [ITGI 2005] ITGI, CobiT 4.0: Control Objectives, Management Guidelines, Maturity Models, IT Governance Institut, Rolling Meadows/IL 2005 [Jacobson et al. 1997] Jacobson, I., Griss, M., Jonsson, P., Software Reuse - Achitecture, Process and Organization for Business Success, ACM Press, New York 1997 [Kagelmann 2001] Kagelmann, U., Shared Services als alternative Organisationsform: Am Beispiel der Finanzfunktion im multinationalen Konzern, Gabler, Wiesbaden 2001

Literatur

213

[Kagermann/Österle 2006] Kagermann, H., Österle, H., Geschäftsmodelle 2010 - Wie CEOs Unternehmen transformieren, Frankfurter Allgemeine Buch, Frankfurt 2006 [Kaib 2002] Kaib, M., Enterprise Application Integration. Grundlagen, Integrationsprodukte, Anwendungsbeispiele, DUV Wirtschaftsinformatik, Wiesbaden 2002 [Kang et al. 1990] Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E., Peterson, A. S., FeatureOriented Domain Analysis (FODA), Working Paper, Software Engineering Institute, Carnegie Mellon University, Pittsburgh 1990 [Karch et al. 2004] Karch, S., Heilig, L., Bernhardt, C., Hardt, A., Heidfeld, F., Pfennig, R., SAP Netweaver, Galileo Press, Bonn 2004 [Keen et al. 2004] Keen, M., Acharya, A., Bishop, S., Hopkins, A., Milinski, S., Nott, C., Robinson, R., Adams, J., Verschueren, P., Patterns: Implementing an SOA using an Enterprise Service Bus, IBM, 2004 [Kern et al. 2002] Kern, T., Willcocks, L. P., Lacity, M. C., Application service provision: Risk assessment and mitigation, in: MIS Quarterly Executive, 1, 2002, Nr. 2, S. 113126 [Kinikin 2004] Kinikin, E., Packaged Apps Lag Business Requirements, Forrester Research Inc., Cambridge 2004 [Klesse et al. 2005] Klesse, M., Wortmann, F., Schelp, J., Erfolgsfaktoren der Applikationsintegration, in: Wirtschaftsinformatik, 47, 2005, Nr. 4, S. 259-267 [Koch/Murer 1999] Koch, T., Murer, S., Service architecture integrates mainframes in a CORBA environment, Proceedings of the third International Enterprise Distributed Object Computing Conference, EDOC '99., IEEE, 1999, S. 194-203 [Kossmann/Leymann 2004] Kossmann, D., Leymann, F., Web Services, in: Informatik-Spektrum, 27, 2004, Nr. 2, S. 117-128 [Kotonya et al. 2005] Kotonya, G., Hutchinson, J., Bloin, B., A Method for Formulating and Architecting Component- and Service-oriented Systems, in: Stojanovic, Z., Dahanayake, A. (Hrsg.), Service-Oriented Software System Engineering: Challenges and Practices, Idea Group Publishing, Hershey et al. 2005, S. 155-181 [Krafzig et al. 2004] Krafzig, D., Banke, K., Slama, D., Enterprise SOA, Prentice Hall, 2004

214

Literatur

[Krcmar 1990] Krcmar, H., Bedeutung und Ziele von Informationssystemarchitekturen, in: Wirtschaftsinformatik, 32, 1990, Nr. 5, S. 395-402 [Krcmar 2005] Krcmar, H., Informationsmanagement, 4. Auflage, Springer, Berlin et al. 2005 [Latimore/Robinson 2004] Latimore, D., Robinson, G., Component business modeling, IBM Business Consulting Services, Somers, N.Y. 2004 [Lee 1999] Lee, H.-S., Automatic clustering of business processes in business systems planning, in: European Journal of Operational Research, 1999, Nr. 114, S. 354-362 [Leist 2004] Leist, S., Methoden zur Unternehmensmodellierung - Vergleich, Anwendungen und Diskussionen der Integrationspotenziale, Habilitation, Institut für Wirtschaftsinformatik Universität St. Gallen, St. Gallen 2004 [Leser 2006] Leser, F., Business Collaboration Infrastructures, Dissertation, Universität St. Gallen, St. Gallen 2006 [Levi/Arsanjani 2002] Levi, K., Arsanjani, A., A Goal-drive Approach to Enterprise Component Identification and Specification, in: Communications of the ACM, October/45, 2002, Nr. 10, S. 45-52 [Linthicum 2000] Linthicum, D. S., Enterprise Application Integration, Addison Wesley Longman, Reading (MA) etc. 2000 [Linthicum 2003] Linthicum, D. S., Next Generation Application Integration: From Simple Information to Web Services, Addison-Wesley, Boston 2003 [LogicLibrary 2003] LogicLibrary, ‘You Can’t Manage What You Can’t Measure’: Metrics for Software Reuse, LogicLibrary Inc., 2003 [Mantel et al. 2000] Mantel, S., Knobloch, B., Rüffer, T., Schissler, M., Schmitz, K., Ferstl, O. K., Sinz, E. J., Analyse der Intergrationspotenziale von Kommunikationsplattformen für verteilte Anwendungssysteme, Working Paper, Forwin, Nürnberg 2000 [Mantel/Schissler 2002] Mantel, S., Schissler, M., Application Integration, in: Wirtschaftsinformatik, 44, 2002, Nr. 2, S. 171-174

Literatur

215

[Mantel et al. 2004] Mantel, S., Schissler, M., Zeller, T., Überbetriebliche Integration von Anwendungssystemen: Klassifikation von Integrationsproblemen und Lösungen, in: Bartmann, D., Mertens, P., Sinz, E.J. (Hrsg.), Überbetriebliche Integration von Anwendungssystemen: FORWIN-Tagung 2004, Shaker, Aachen 2004, S. 1-20 [Matthes 2005] Matthes, F., The impact of SOA on the Enterprise Application Landscape, Working Paper, SOA Days 2005, Business Conference, Deutsche Post World Net, Bonn 2005 [McCall 2004] McCall, I., Component Business Modeling (CBM) and how it maps into Service Oriented Architectures (SOA), Präsentation an der Architecture Practitioners Conference, New Orleans 2004 [McDonald et al. 2006] McDonald, M. P., Blosch, M., Jaffarian, T., Mok, L., Stevens, S., Growing IT's Contribution: The 2006 CIO Agenda, Gartner, inc., Stamford 2006 [McGovern et al. 2003] McGovern, J., Tyagi, S., Stevens, M., Mathew, S., Service-Oriented Architecture, in: McGovern, J., Tyagi, S., Stevens, M., Mathew, S. (Hrsg.), Java Web Services Architecture, Morgan Kaufmann, San Francisco 2003, S. 35-63 [Mertens et al. 1997] Mertens, P., Back, A., Becker, J., König, W., Krallmann, H., Rieger, B., Scheer, A.-W., Seibt, D., Stahlknecht, P., Strunz, H., Thome, R., Wedekind, H. (Ed.), Lexikon der Wirtschaftsinformatik, 3. Auflage, Berlin 1997 [Merz 2002] Merz, M., E-Commerce und E-Business, dpunkt Verlag, Heidelberg 2002 [Meyer 1992] Meyer, B., Applying "Design by Contract", in: IEEE Computer, 25, 1992, Nr. 10, S. 40-51 [Mougayar 2005] Mougayar, W., The SOA in IT Benchmark Report - What CIOs Should Know about How SOA Is Changing IT, Working Paper, Aberdeen Group, Boston 2005 [Mowbray/Zahavi 1995] Mowbray, T. J., Zahavi, R., The Essential CORBA: Systems Integration Using Distributed Objects, Wiley, New York 1995 [Müller et al. 2006] Müller, S., Kuhn, W., Meiler, C., Petrov, I., Jablonski, S., Integratives ITArchitekturmanagement, in: Reussner, R., Hasselbring, W. (Hrsg.), Handbuch der Software-Architektur, dpunkt, Heidelberg 2006, S. 187-209 [Müller-Stewens/Lechner 2001] Müller-Stewens, G., Lechner, C., Strategisches Management - Wie strategische Initiativen zum Wandel führen, Schäffer-Poeschel, Stuttgart 2001

216

Literatur

[Natis 2003] Natis, Y., Service-Oriented Architecture Scenario, Gartner, Inc., Stamford 2003 [Natis et al. 2006] Natis, Y. V., Bitterer, A., Friedman, T., Gassman, B., Iijima, K., Lhereux, B. J., Pezzini, M., Phifer, G., Thompson, J., Vecchio, D., Kenney, F. L., Who's Who in Enterprise-Scope Application Platform Suites, 1Q06, Gartner Inc., Stamford 2006 [Newcomer/Lomow 2004] Newcomer, E., Lomow, G., Understanding SOA with Web Services, AddisonWesley, Maryland 2004 [Niemann 2005] Niemann, K. D., Von der Unternehmensarchitektur zur IT-Governance: Leitfaden für effizientes und effektives IT-Management, (Edition CIO), Vieweg, 2005 [Oasis 2004] Oasis, UDDI Version 3.0.2, http://www.oasis-open.org/committees/uddi-spec/ doc/spec/v3/uddi-v3.0.2-20041019.htm, 29.12.2005 [Oasis 2005] Oasis, Reference Model for Service Oriented Architectures, Working Draft 09, OASIS Open, 2005 [O'Brien et al. 2005] O'Brien, L., Bass, L., Merson, P., Quality Attributes and Service-Oriented Architectures, Working Paper, The Software Engineering Institute, Carnegie Mellon University, 2005 [Oestereich 2005] Oestereich, B., Objektorientierte Softwareentwicklung: Analyse und Design mit der Unified modeling Language, 7. Auflage, Oldenbourg, München 2005 [OMG 2002] OMG, CORBA Components, 2002 [OMG 2004] OMG, OMG Model Driven Architecture, http://www.omg.org/mda/, 07.11.2005 [OMG 2006] OMG, Catalog of OMG Domain Specifications, http://www.omg.org/technology/ documents/domain_spec_catalog.htm, 02.01.2006 [Open Group 2003] Open Group, TOGAF "Enterprise Edition" Version 8.1, http://www.opengroup. org/architecture/togaf8-doc/arch/, 02.11.2005 [Österle 1981] Österle, H., Entwurf betrieblicher Informationssysteme, 1. Auflage, Hanser, München 1981 [Österle 1995] Österle, H., Business Engineering: Prozess- und Systementwicklung, 2. Auflage, Springer, Berlin et al. 1995

Literatur

217

[Österle/Blessing 2003] Österle, H., Blessing, D., Business Engineering Modell, in: Österle, H., Winter, R. (Hrsg.), Business Engineering, 2. Auflage, Springer, Berlin 2003, S. 65-85 [Österle et al. 1992] Österle, H., Brenner, W., Hilbers, K., Unternehmensführung und Informationssystem - Der Ansatz des St. Galler Informationssystem-Managements, 2. durchges. Auflage, Teubner, Stuttgart 1992 [Österle/Reichmayr 2003] Österle, H., Reichmayr, C., Out-tasking mit WebServices, in: Bullinger, H.-J., Scheer, A.-W. (Hrsg.), Service Engineering - Entwicklung und Gestaltung innovativer Dienstleistungen, Springer, Berlin 2003, S. 565-589 [Österle/Winter 2003] Österle, H., Winter, R., Business Engineering, in: Österle, H., Winter, R. (Hrsg.), Business Engineering, 2. Auflage, Springer, Berlin etc. 2003, S. 3-18 [Otto et al. 2002] Otto, B., Beckmann, H., Kelkar, O., Müller, S., E-Business-Standards, Fraunhofer IRB Verlag, Stuttgart 2002 [Özsu/Valduriez 1991] Özsu, T., Valduriez, P., Distributed database systems: Where are we now?, in: IEEE Computer, 24, 1991, Nr. 8, S. 68-78 [Papazoglou 2003] Papazoglou, M. P., Service-Oriented Computing: Concepts, Characteristics and Directions, Proceedings of the 4th International Conference on Web Information Systems Engineering (WISE 2003), 2003, S. 3-12 [Papazoglou/Georgakopoulos 2003] Papazoglou, M. P., Georgakopoulos, D., Service-Oriented Computing, in: Communications Of The ACM, 46, 2003, Nr. 10, S. 25-28 [Papazoglou et al. 2006] Papazoglou, M. P., Traverso, P., Dustdar, S., Leymann, F., Service-Oriented Computing Research Roadmap, European Union Information Society Technologies (IST) Directorate D - Software Technologies (ST), 2006 [Papazoglou/Yang 2002] Papazoglou, M. P., Yang, J., Design Methodology for Web Services and Business Processes, in: Buchmann, A.C., F.; Fiege, L.; Hsu, M.-C.; Shan, M.-C. (Hrsg.), Technologies for E-Services : Third International Workshop, TES 2002, Springer, Berlin 2002, S. 54-64 [Parnas 1972] Parnas, D. L., On the criteria to be used in decomposing systems into modules, in: Communications of the ACM, 15, 1972, Nr. 12, S. 1053-1058 [Paulk et al. 1993] Paulk, M. C., Curtis, B., Chrissis, M. B., Weber, C. V., Capability Maturity Model for Software, Version 1.1, Software Engineering Institute Carnegie Mellon University, Pittsburgh, Pennsylvania 1993

218

Literatur

[Perepletchikov et al. 2005] Perepletchikov, M., Ryan, C., Frampton, K., Comparing the Impact of ServiceOriented and Object-Oriented Paradigms on the Structural Properties of Software, Proceedings of the 2nd International Workshop on Modeling Inter-Organizational Systems (MIOS), in conjunction with the OTM 2005, 2005, S. 431-441 [Peterson 2004] Peterson, T., Integration Imperatives, in: Computerworld, 38, 2004, Nr. 30, S. 25 [Pezzini 2003] Pezzini, M., Application Integration Scenario: Building an Enterprise Nervous System, Gartner Symposium ITxpo, Gartner inc., 2003 [Picot et al. 2001] Picot, A., Reichwald, R., Wigand, R. T., Die grenzenlose Unternehmung: Information, Organisation und Management. Lehrbuch zur Unternehmensführung im Informationszeitalter, 4. vollst. überarb. u. erw, Gabler, Wiesbaden 2001 [Plummer et al. 2006] Plummer, D. C., McCoy, D. W., Abrams, C., Magic Quadrant for the Integrated Service Environment Market, Gartner Inc., Stamford 2006 [Pohland 2000] Pohland, S., Globale Unternehmensarchitekturen: Methode zur Verteilung von Informationssystemen, Weissensee Verlag, Berlin 2000 [Poulin/Carlson 2003] Poulin, J., Carlson, B., Selling Software Reuse to Management, LogicLibrary Inc., 2003 [Puschmann 2003] Puschmann, T., Collaboration Portale - Architektur, Integration, Umsetzung und Beispiele, Dissertation, Universität St. Gallen, Difo-Druck, Bamberg 2003 [Puschmann 2004] Puschmann, T., Prozessportale - Architektur zur Vernetzung mit Kunden und Lieferanten, Springer, Berlin 2004 [Quack 2004a] Quack, K., Service-orientierte Architektur, aber wie?, http://www.computer woche.de/index.cfm?pageid=256&artid=61810&type=detail&kw=soa&rc=52, 31.03.2006 [Quack 2004b] Quack, K., "Vielleicht kommen die Standards ja von SAP" - Interview mit SAPVorstandsmitglied Peter Zencke, http://www.computerwoche.de/index.cfm?pid= 254&pk=547430, 11.04.2006 [Quantz/Wichmann 2003] Quantz, J., Wichmann, T., E-Business-Standards in Deutschland, Berlecon Research, Berlin 2003

Literatur

219

[Rangan et al. 2005] Rangan, K., Cooke, A., Lenschow, R., Maguire, E., Stack Wars Define and Dominate Sector Themes, Merrill Lynch, New York (NY) 2005 [Raptis et al. 2001] Raptis, K., Spinellis, D., Katsikas, S., Multi-technology distributed objects and their integration, in: Computer Standards & Interfaces, 2001, Nr. 23, S. 157-168 [Ratzinger et al. 2005] Ratzinger, J., Fischer, M., Gall, H., Improving evolvability through refactoring, Proceedings of the 2005 international workshop on Mining software repositories, 2005, S. 1-5 [Reichmayr 2003] Reichmayr, C., Collaboration und WebServices: Architekturen, Portale, Techniken und Beispiele, Dissertation, Springer, Berlin 2003 [Richter et al. 2005] Richter, J.-P., Haller, H., Schrey, P., Serviceorientierte Architektur, in: Informatik Spektrum, 28, 2005, Nr. 5, S. 413-416 [Riehm 1997] Riehm, R., Integration von heterogenen Applikationen, Difo-Druck, Bamberg 1997 [Riehm/Vogler 1996a] Riehm, R., Vogler, P., Middleware - Begriff und Einordnung, in: Österle, H., Riehm, R., Vogler, P. (Hrsg.), Middleware - Grundlagen, Produkte und Anwendungsbeispiele für die Integration heterogener Welten, Vieweg, Wiesbaden 1996a [Riehm/Vogler 1996b] Riehm, R., Vogler, P., Middleware: Infrastruktur für die Integration, in: Österle, H., Riehm, R., Vogler, P. (Hrsg.), Middleware: Grundlagen, Produkte und Anwendungsbeispiele für die Integration heterogener Welten, Vieweg, Braunschweig etc. 1996b, S. 25-135 [Ruh et al. 2001] Ruh, W. A., Maginnis, F. X., Brown, W. J., Enterprise Application Integration, John Wiley & Sons, New York 2001 [Samtani 2002] Samtani, G., B2B Integration - A Practical Guide to Collaborative E-Commerce, Imperial College Press, London 2002 [SAP 2004a] SAP, Enterprise Services Architecture, Composite Applications, SAP xApps und mySAP Business Suite im Überblick, Walldorf 2004a [SAP 2004b] SAP, SAP Composite Application Framework, http://www.sap.com/germany/ solutions/netweaver/compositeapplicationframework.aspx, 10.12.2004

220

Literatur

[SAP 2005a] SAP, Enterprise Services Architecture, Pressemitteilung, www.sap.com/germany/ media/mc_518/500062007.pdf, 11.04.2006 [SAP 2005b] SAP, Enterprise Services Design Guide, SAP AG, 2005b [SAP 2006] SAP, SAP NetWeaver: Komponenten & Werkzeuge, http://www.sap.com/ germany/solutions/netweaver/components/index.epx, 10.04.2006 [Scheeg 2004] Scheeg, J., Management der IT-Planung, Entwicklung und Produktion: Status quo und Herausforderungen, in: Zarnekow, R., Brenner, W., Grohmann, H. (Hrsg.), Informationsmanagement - Konzepte und Strategien für die Praxis, dpunkt Verlag, Heidelberg 2004, S. 25-40 [Scheer 1998] Scheer, A.-W., ARIS - Vom Geschäftsprozess zum Anwendungssystem, 3. Auflage, Springer, Berlin 1998 [Schelp et al. 2006] Schelp, J., Hafner, M., Winter, R., Organisation des Architekturmanagements, in: Reussner, R., Hasselbring, W. (Hrsg.), Handbuch der Software-Architektur, dpunkt, Heidelberg 2006, S. 211-227 [Schelp/Winter 2002] Schelp, J., Winter, R., Enterprise Portals und Enterprise Application Integration, in: Meinhard, S., Popp, K. (Hrsg.), Enterprise-Portale & Enterprise Application Integration, dpunkt, Heidelberg 2002, S. 6-20 [Scherdin 2006] Scherdin, A., Ausprägung einer SOA in der Praxis – Erfahrungen Deutsche Post World Net, Präsentation im Doktorandenseminar Forschungsschwerpunkte, Kaubad 2006 [Schissler et al. 2002] Schissler, M., Mantel, S., Ferstl, O. K., Sinz, E. J., Kopplungsarchitekturen zur überbetrieblichen Integration von Anwendungssystemen und ihre Realisierung mit SAP R/3, in: Wirtschaftsinformatik, 44, 2002, Nr. 5, S. 459-468 [Schlamann 2004] Schlamann, H., Service Orientation: An Evolutionary Approach, in: Cutter IT Journal, 17, 2004, Nr. 5, S. 5-13 [Schwarze 1998] Schwarze, J., Informationsmanagement: Planung, Steuerung, Koordination und Kontrolle der Informationsversorgung in Unternehmen, Herne, Berlin 1998 [Schwinn 2006a] Schwinn, A., Entwicklung einer Methode zur Gestaltung von Integrationsarchitekturen für Informationssysteme, Dissertation, Universität St. Gallen, Difo, Bamberg 2006a

Literatur

221

[Schwinn 2006b] Schwinn, A., Entwurfsmusterbasierter Ansatz zur Systematisierung von Applikationsbeziehungen im Business Engineering, in: Schelp, J., Winter, R. (Hrsg.), Integrationsmanagement, Springer, Berlin et al. 2006b, S. 31-59 [Schwinn/Winter 2005] Schwinn, A., Winter, R., Entwicklung von Zielen und Messgrößen zur Steuerung der Applikationsintegration, Wirtschaftsinformatik 2005: eEconomy - eGovernment - eSociety, Bamberg, 23.05.2005, Physica, 2005, S. 587-606 [Sessions 2004] Sessions, R., Fuzzy Boundaries, in: ACM Queue, 2, 2004, Nr. 9, S. 40-47 [Shaw/Garlan 1996] Shaw, M., Garlan, D., Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, New Jersey 1996 [Simon 2002] Simon, H. A., The architecture of complexity, in: Garud, R., Kumaraswamy, A., Langlois, R.R. (Hrsg.), Managing in the modular age, Blackwell Publishers, Malden 2002, S. 15-38 [Sims 2003] Sims, O., Service Oriented Architecture Part 3 - Federation, in: CBDi Journal, Mai, 2003, Nr. S. 8-15 [Sinz 1997] Sinz, E. J., Architektur von Informationssystemen, in: Rechenberger, P., Pomberger, G. (Hrsg.), Informatik-Handbuch, Hanser-Verlag, München 1997, S. 875-887 [Sinz 2004] Sinz, E. J., Unternehmensarchitekturen in der Praxis - Architekturdesign am Reissbrett vs. situationsbedingte Realisierung von Informationssystemen, in: Wirtschaftsinformatik, 46, 2004, Nr. 4, S. 315-316 [Sinz et al. 2000] Sinz, E. J., Knobloch, B., Mantel, S., Web-Application Server, in: Wirtschaftsinformatik, 42, 2000, Nr. 6, S. 550-552 [Sprott 2004] Sprott, D., Enterprise Applications and SOA?, in: CBDi Journal, 2004, Nr. September, S. 3-16 [Stiemerling 2002] Stiemerling, O., Web-Services als Basis für evolvierbare Softwaresysteme, in: Wirtschaftsinformatik, 2002, Nr. 5, S. 435-445 [Stojanovic 2005] Stojanovic, Z., A Method for Component-Based and Service-Oriented Software Systems Engineering, Dissertation, Delft University of Technology, 2005

222

Literatur

[Sun 2003] Sun, Java 2 Platform Enterprise Edition Specification, v1.4, Sun Microsystems, 2003 [Szyperski et al. 2002] Szyperski, C., Gruntz, D., Murer, S., Component Software: Beyond ObjectOriented Programming, 2, Addison Wesley Longman, London 2002 [Turowski 2001] Turowski, K., Spezifikation und Standardisierung von Fachkomponenten, in: Wirtschaftsinformatik, 43, 2001, Nr. 3, S. 269-281 [Turowski et al. 2002] Turowski, K., Ackermann, J., Brinkop, F., Conrad, S., Fettke, P., Frick, A., Glistau, E., Jeakel, H., Kotlar, O., Loos, P., Mrech, H., Ortner, E., Raape, U., Overhage, S., Sahm, S., Schmietendorf, A., Teschke, T., Vereinheitlichte Spezifikation von Fachkomponenten, Working Paper, Gesellschaft für Informatik, Arbeitskreis 5.10.3, Augsburg 2002 [van de Loo 2004] van de Loo, K., Organizational Impact of Enterprise Services Architecture (ESA), https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/3241e590 -0201-0010-a893-dfd515af528e, 20.02.2006 [van der Aalst et al. 2003] van der Aalst, W., Weske, M., ter Hofstede, A., Business Process Management: A Survey, Proceedings of the BPM 2003, 2003, S. 1-12 [Veryard 2003] Veryard, R., Component Based Service Engineering, in: CBDi Journal, 2003, Nr. November, S. 15-23 [Veryard 2004] Veryard, R., Business Adaptability and Adaptation in SOA, in: CBDi Journal, 2004, Nr. Februar, S. 24-30 [Vinoski 2005] Vinoski, S., Old Measures for New Services, in: IEEE Internet Computing, 9, 2005, Nr. 6, S. 72-74 [Vogel 2005] Vogel, T., Serviceorientierte Architektur zur Unterstützung der Geschäftsprozesse eines IT-Dienstleisters, Diploma, Universität Karlsruhe Institut für Telematik, 2005 [Vogels 2003] Vogels, W., Web Services are not distributed objects, in: IEEE Internet Computing, 7, 2003, Nr. 6, S. 59-66 [Vogler 2004] Vogler, P., Prozess- und Systemintegration: Evolutionäre Weiterentwicklung bestehender Informationssysteme mit Hilfe von Enterprise Application Integration, Habilitation, Universität St. Gallen, 2004

Literatur

223

[von Glahn/Schomann 2003] von Glahn, C., Schomann, M., Von Shared Services zu Portal Services, in: Keuper, F. (Hrsg.), E-Business, M-Business und T-Business, Gabler, Wiesbaden 2003, S. [W3C 2001a] W3C, Semantic Web, http://www.w3.org/2001/sw/, 02.01.2006 [W3C 2001b] W3C, Web Services Description Language (WSDL) 1.1, W3C note 15 March 2001, http://www.w3.org/TR/wsdl, 29.12.2005 [W3C 2003] W3C, SOAP Version 1.2 Part 0: Primer, W3C Recommendation 24 June 2003, http://www.w3.org/TR/2002/CR-soap12-part0-20021219, 02.09.2005 [W3C 2004a] W3C, Web Services Architecture, W3C Working Group Note 11 February 2004, http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/, 26.06.2004 [W3C 2004b] W3C, Web Services Glossary, W3C Working Group Note 11 February 2004, http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/, 10.10.2005 [W3C 2005] W3C, Web Services Description Language (WSDL) Version 2.0 Part 0: Primer, W3C Working Draft 3 August 2005, http://www.w3.org/TR/2005/WD-wsdl20primer-20050803/, 29.12.2005 [WFMC 1999] WFMC, Terminology & Glossary, http://www.wfmc.org/standards/docs/TC1011_term_glossary_v3.pdf, 03.08.2004 [Whiting 2002] Whiting, R., Web Services Take Integration To A New Level, http:// www.informationweek.com/story/IWK20020411S0009, 15.04.2002 [Wilhelmi et al. 2005] Wilhelmi, C., Klesse, M., Wortmann, F., Service-orientierte Architektur - Der richtige Weg?, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen 2005 [Wilkes 2004] Wilkes, L., Time to Board the Enterprise Service Bus?, in: CBDi Journal, 2004, Nr. Juli/August, S. 4-14 [Wilkes 2005] Wilkes, L., The Web Services Protocol Stack, http://roadmap.cbdiforum.com/ reports/protocols/, 29.12.2005 [Wilkes/Veryard 2004] Wilkes, L., Veryard, R., Service-Oriented Architecture: Considerations for Agile Systems, in: Microsoft Architects Journal, 2004, Nr. 2, S. 11-23

224

Literatur

[Winter 2003a] Winter, R., An Architecture Model for Supporting Application Integration Decisions, Proc. 11th European Conference on Information Systems, Naples, 2003a [Winter 2003b] Winter, R., Modelle, Techniken und Werkzeuge im Business Engineering, in: Österle, H., Winter, R. (Hrsg.), Business Engineering, 2. Auflage, Springer, Berlin etc. 2003b, S. 87-117 [Winter 2004] Winter, R., Architektur braucht Management, in: Wirtschaftsinformatik, 46, 2004, Nr. 4, S. 317-319 [Winter/Schelp 2005] Winter, R., Schelp, J., Dienste-Orientierung im Business-Engineering Framework, in: HMD-Praxis der Wirtschaftsinformatik, 2005, Nr. 241, S. 45-54 [Woods 2003] Woods, D., Packaged Composite Applications, O'Reilly, London 2003 [WS-I 2004a] WS-I, Attachments Profile Version 1.0, http://www.ws-i.org/Profiles/ AttachmentsProfile-1.0-2004-08-24.html, 29.12.2005 [WS-I 2004b] WS-I, Basic Profile Version 1.1, http://www.ws-i.org/Profiles/BasicProfile-1.12004-08-24.html, 29.12.2005 [WS-I 2004c] WS-I, Simple SOAP Binding Profile Version 1.0, http://www.ws-i.org/Profiles/ SimpleSoapBindingProfile-1.0-2004-08-24.html, 29.12.2005 [WS-I 2005] WS-I, About WS-I, http://www.ws-i.org/about/Default.aspx, 29.12.2005 [Yourdon/Constantine 1979] Yourdon, E., Constantine, L. L., Structured Design: Fundamentals of a discipline of computer program and systems design, Prentice-Hall, New Jersey 1979 [Zachman 1987] Zachman, J. A., A Framework for Information Systems Architecture, in: IBM Systems Journal, 26, 1987, Nr. 3, S. 454-470 [Zarnekow 2004] Zarnekow, R., Produktorientiertes Informationsmanagement, in: Zarnekow, R., Brenner, W., Grohmann, H. (Hrsg.), Informationsmanagement - Konzepte und Strategien für die Praxis, dpunkt Verlag, Heidelberg 2004, S. 41-56 [Zarnekow/Brenner 2003] Zarnekow, R., Brenner, W., Auf dem Weg zu einem produkt- und dienstleistungsorientierten IT-Management, in: HMD - Praxis der Wirtschaftsinformatik, Vol. 40, 2003, Nr. 232, S. 7-16

Literatur

225

[Zarnekow et al. 2005] Zarnekow, R., Brenner, W., Pilgram, U., Integriertes Informationsmanagement, Springer, 2005 [Zhao/Cheng 2005] Zhao, J. L., Cheng, H. K., Web Services and Process Management: A Union of Convenience or a New Area of Research?, in: Decision Support Systems, 40, 2005, Nr. 1, S. 1-8 [Zimmermann et al. 2004a] Zimmermann, O., Krogdahl, P., Gee, C., Elements of Service-Oriented Analysis and Design, http://www-128.ibm.com/developerworks/webservices/library/wssoad1/, 07.04.2005 [Zimmermann et al. 2004b] Zimmermann, O., Milinski, S., Craes, M., Oellermann, F., Second Generation Web Services-Oriented Architecture in Production in the Finance Industry, Companion to the 19th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA 2004, Vancouver, ACM, 2004b, S. 283-289 [Zimmermann et al. 2003] Zimmermann, O., Tomlinson, M., Peuser, S., Perspectives on Web Services, Springer, Berlin 2003 [Zur Muehlen 2004] Zur Muehlen, M., Workflow-based Process Controlling. Foundation, Design, and Application of workflow-driven Process Information Systems, Logos, Berlin 2004

Index Abstrakter Datentyp 48 Abstraktion 32, 51, 128, 130 Anwendungssystem 10, 11, 189 Application Server 14, 58 Applikation 10, 11, 189 Applikationsarchitektur 10, 133 Architekt 180 Architektur 7 Applikationsarchitektur 10 Domänenarchitektur 133 Geschäftsarchitektur 9 Infrastrukturarchitektur 10 Integrationsarchitektur 10, 27 Management 18, 120 Muster 8 Prozessarchitektur 9 Steuerung 19, 126 Stil 8 Systemarchitektur 9 Unternehmensarchitektur 8 Autonomie 39, 105, 113, 134 BEA AquaLogic 59 Bedarfsorientierung 42 Beschaffungsstrategie 146, 175, 185 Business Engineering Modell 8, 22 Business Process Management 15, 58, 186 Client/Server 12 Composite Application 18, 60, 186, 191 Credit Suisse 103, 132, 145, 147, 173, 177 Datenintegration 13 Designprinzipien 30, 76, 126 Domänen 143 Services 30

Desktopintegration 17 Deutsche Post Brief 64, 103, 145, 148 Domäne 25, 189 Domänenarchitekt 180 Domänenarchitektur 133 EAI 58 Enterprise Service Bus 29, 58 Erfolgsfaktoren 114 ETL 13 Flexibilität 1, 103, 105, 113 Funktionsintegration 13 Geheimnisprinzip 32, 47 Geschäftsarchitektur 9 Geschäftsentität 43, 143, 168 Geschäftskomponente 141, 154, 160 Governance 176, 179 Heterogenität 2, 23, 103 IBM WebSphere 59 Industriestandards 38, 165 Information Hiding 32, 47 Informationsmanagement 18 Informationsobjekt 190 Infrastrukturarchitektur 10 Integration Datenintegration 13 Desktop- / Portalintegration 10, 17 Funktionsintegration 13 Herausforderungen 2 Integrationsmodell 10, 22 Middleware 10, 190 Präsentationsintegration 15 Workflowintegration 11, 15 Integrationsarchitektur 10

228

Integrationsmodell 22 Interoperabilität 36 J2EE 14, 57 JDBC 13 Kohäsion 40, 128, 131 Kommunikation Asynchron 14 Interaktionsstil 27 Nachrichtenbasiert 14, 26 Publish/Subscribe 16 Synchron 14 Komponentenorientierung 48, 49, 150 Komponententechnologien 55 COM+ 56 CORBA 14, 56 EJB 14, 57 Kopplung 40, 128, 131 Kosten 1, 70, 81, 101, 103, 113 Lenkungsausschuss 179 Lose Kopplung 30, 40, 41 Mainframe 12 Message broker 15 Message Broker 58 Methodik Domänenabgrenzung 136 Servicedesign 149 Serviceidentifikation 147 Metriken 126 Modularisierung 39, 48 Domänenarchitektur 134, 143 MOM 14 Nachricht 26, 190 Object Broker 14, 58 Objektorientierung 48, 49 ODBC 13 Peer-to-Peer 12 Performanz 43

Index

Portal 17, 58, 191 Präsentationsintegration 15 Prozessarchitektur 9 Prozessmodellierung 119, 150, 186 Querschnittsfunktion 143 Redundanz 1, 40, 103, 105, 134 Repository 29, 192 RPC 14 SAP ESA 60 NetWeaver 59, 186 xApps 60 Schichtenarchitektur 12, 22 Schnittstelle 189 Schnittstellenorientierung 31 Schweizerische Mobiliar 173 Semantic Web 187 Service Definition 22 Design 147 Generalisierung 44 Granularität 43, 44 Identifikation 147 Komposition 15, 17, 51, 186 Kontrakt 36 Schnittstelle 28 Spezifikation 26, 32 Typen 172 Verzeichnis 29, 192 Wiederverwendung 44, 125, 129 Service Level Agreement (SLA) 33 Serviceentwickler 180 Servicekontrakt 36 Servicemarkt 185 Serviceschnittstelle 28 SOA Architekturkomponenten 25 Architekturmodell 22

Index

Architektursteuerung 120, 131, 176 Definition 22 Designprinzipien 30, 49, 109, 120, 122, 126, 152, 170, 197 Entwurfsmethoden 47, 136, 149 Erfolgsfaktoren 114 Fallbeispiele 63 Herausforderungen 111 Integrationsplattformen 29, 58 Metriken 120, 126 Nutzen 111 Organisation 176 Servicedesign 147 Technologien 52 Treiber 64, 73, 84, 93, 103, 122 Umsetzung 65, 74, 86, 95, 114, 119 Ziele 3, 104, 120

229

SOA-Architekt 180 SOAP 52 Sourcing 146, 175, 185 Standardisierung 36, 55, 113 Systemarchitektur 9 T-Com 103, 145, 176 TP Monitor 14, 58 UDDI 53 Unternehmensarchitektur 8 Einordnung SOA 22 Web Services 30, 52 Workflow 15, 192 Workflowintegration 58, 186 WSDL 53 WS-I 54 XML 52 Zuger Kantonalbank 103, 146