Service-orientierte Architekturen : Chancen und Herausforderungen bei der Flexibilisierung und Integration von Unternehmensprozessen [1. Aufl] 9783835008151, 3835008153 [PDF]

Zitiervorschau

Volker Nissen, Mathias Petsch, Hagen Schorcht (Hrsg.) Service-orientierte Architekturen

GABLER EDITION WISSENSCHAFT

Volker Nissen, Mathias Petsch, Hagen Schorcht (Hrsg.)

Service-orientierte Architekturen Chancen und Herausforderungen bei der Flexibilisierung und Integration von Unternehmensprozessen

Deutscher Universitäts-Verlag

Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

1. Auflage Oktober 2007 Alle Rechte vorbehalten © Deutscher Universitäts-Verlag | GWV Fachverlage GmbH, Wiesbaden 2007 Lektorat: Frauke Schindler / Nicole Schweitzer Der Deutsche Universitäts-Verlag ist ein Unternehmen von Springer Science+Business Media. www.duv.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. 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. Umschlaggestaltung: Regine Zimmer, Dipl.-Designerin, Frankfurt/Main Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier Printed in Germany ISBN 978-3-8350-0815-1

Vorwort

V

Vorwort Angesichts steigender Dynamik der Unternehmensumwelt und der Notwendigkeit, in Wertschöpfungsnetzwerken überbetrieblich zusammenzuarbeiten, kommt der Flexibilisierung und unternehmensübergreifenden Integration von Geschäftsprozessen eine überragende Bedeutung zu. Bisherige Softwarearchitekturkonzepte, die in der betrieblichen Praxis noch auf weitgehend monolithische ERP-Systeme abzielen, gelten als zu unflexibel, um in Zukunft das fachliche Geschäft optimal zu unterstützen. So vollzieht sich heute ein Paradigmenwechsel hin zu serviceorientierten Architekturen (SOA), die auf dem flexiblen Einsatz logisch in sich abgeschlossener und nur lose gekoppelter Dienste (Services) beruhen. SOA stellen ein abstraktes SoftwareArchitekturkonzept dar, welches die Basis für das verteilte Bereitstellen, Suchen und Nutzen von Diensten bietet. Neben der größeren Agilität in den Unternehmensprozessen erhofft man sich weitere Vorteile, wie eine bessere Software-Wiederverwendbarkeit, kürzere Entwicklungszeiten und optimales IT-Business Alignment. Diese Veränderung erfordert neue Wege bei der Entwicklung von Anwendungssystemen. Es ist aber auch ein Umdenken in der Zusammenarbeit und Steuerung von fachlichen Organisationseinheiten und IT-Bereichen in Unternehmen notwendig. Bislang wurde das Thema SOA vorwiegend aus einer technischen Perspektive betrachtet. Dagegen stehen Diskussionen im Zusammenhang mit Chancen und Risiken bei der Flexibilisierung und Integration von Unternehmensprozessen, Aspekte der fachlichen Modellierung sowie Themen des Controlling und Monitoring in serviceorientierten Architekturen noch weitgehend aus. So fehlt im Umfeld von SOA bislang eine semantische Beschreibung von Diensten, die beispielsweise deren Nutzen und Bedeutung repräsentiert. Ebenso stellt die Bestimmung der richtigen Granularität von Services ein grundsätzliches Problem dar, welches bei der Überführung von Unternehmensprozessen in Dienste gelöst werden muss. Aus betriebswirtschaftlicher Perspektive ist die Frage nach der Wirtschaftlichkeit von SOA und sinnvollen Anwendungsfeldern zu beantworten. Im Rahmen des vorliegenden Werkes werden solche und ähnliche wichtige Fragestellungen im SOA-Kontext näher untersucht und diskutiert. In diesem Buch sind die überarbeiteten Beiträge zur Fachtagung „Serviceorientierte Architekturen“ vom Oktober 2007 an der Technischen Universität Ilmenau enthalten. Volker Nissen, Mathias Petsch, Hagen Schorcht Dieses Buch erscheint mit freundlicher Unterstützung von

Inhaltsverzeichnis

VII

Inhaltsverzeichnis Vorwort ...................................................................................................................... V Grundlagen Sven Overhage, Klaus Turowski Serviceorientierte Architekturen – Konzept und methodische Herausforderungen......3 Florian Dreifus, Katrina Leyking, Peter Loos Systematisierung der Nutzenpotentiale einer SOA....................................................19 Thomas Deelmann Integration von service-orientierten IT-Architekturen in die Geschäftsarchitektur......39 Modellierung und SOA-Entwurf Stefan Huth, Thomas Wieland Geschäftsprozessmodellierung mittels Software-Services auf Basis der EPK ..........61 Harald Störrle, Wolfgang Glock Geschäftsprozessmodellierung für Service-Orientierte Architekturen .......................77 René Fiege, Dirk Stelzer Modellierung Serviceorientierter Architekturen Ein Vergleich von Axiomatic Design mit der Strukturierten Analyse von DeMarco....95 Flexibilisierung von Unternehmensprozessen Ingo J. Timm, Arne Hormann, Thorsten Scholz Qualitätssicherung serviceorientierter Architekturen ...............................................115 Denis Heinemann, Andreas Schmietendorf, Tilmann Walther Modellgetriebene Ableitung semantischer Aspekte in serviceorientierten Architekturen ...........................................................................................................141 Falk Kretzschmar, Ralf Peters Elektronische Märkte in SOA-basierten Unternehmensprozessen ..........................155 Mathias Petsch, Volker Nissen, Timo Traub Anwendungspotenziale von Intelligenten Agenten in Service-orientierten Architekturen ...........................................................................................................167

VIII

Inhaltsverzeichnis

Prozesscontrolling und Monitoring Jan vom Brocke, Christian Sonnenberg Serviceorientiertes Prozesscontrolling – Unternehmensindividuelle Wirtschaftlichkeitsrechnungen zur Nutzung serviceorientierter Architekturen bei der Prozessgestaltung .......................................................................................185 Jochen Müller, Florian Jostock, Joachim Götze, Paul Müller Workflow Monitoring in Service-Orientierten Architekturen .....................................205 Autorenverzeichnis ...............................................................................................221 Index .......................................................................................................................225

Grundlagen

Serviceorientierte Architekturen – Konzept und methodische Herausforderungen Sven Overhage, Klaus Turowski Zusammenfassung: In diesem Beitrag werden das Konzept der Serviceorientierung und bestehende methodische Herausforderungen beschrieben, die dem Einsatz in der Praxis entgegenstehen. Um diesen Herausforderungen zu begegnen, wird die Schaffung einer Entwicklungsmethodik motiviert, die das serviceorientierte Paradigma unterstützt und zur Beantwortung von derzeit noch ungelösten Entwicklungsfragen beiträgt. Im Rahmen des Beitrags werden die zentralen Elemente einer solchen Methodik vorgestellt und im Detail beschrieben. Darüber hinaus wird ein Vergleich mit dem komponentenorientierten Entwicklungsparadigma angestellt, dessen Ähnlichkeit die Übertragung bzw. Anpassung einzelner Methoden und Werkzeuge für das serviceorientierte Paradigma gestattet.

1

Einleitung

Mit dem modularen Entwicklungsparadigma der Serviceorientierten Architektur, wonach betriebliche Anwendungssysteme durch Auswahl und Orchestrierung eines Bündels von Services realisiert bzw. miteinander integriert werden können, lassen sich zahlreiche Fortschritte erzielen, die in der Literatur bereits seit Langem propagiert werden [Bett2001, S. 302; Beute2002, S. 27f.; KoLe2004, S. 117; MDWe2002, S. 7]. So entsteht durch den Zugriff auf einen funktionierenden weltweiten Servicemarkt bei der Anwendungsentwicklung zunächst ein Flexibilitätsgewinn, da einzelne Anwendungsteile bei veränderten Anforderungen leichter durch alternative Angebote ausgetauscht werden können als bei den heutzutage vorherrschenden monolithischen Systemen. Durch die Wiederverwendung bereits realisierter Services ergeben sich darüber hinaus die übrigen mit der Komponentenorientierung bereits verbundenen Zeit-, Qualitäts- und Kostenvorteile gegenüber einer Neuentwicklung [Brow2000, S. 74f.; Same1997, S. 11-15]. Weitere vielversprechende Einsatzfelder ergeben sich vor allem bei der Anwendungsintegration, etwa bei der unternehmensübergreifenden Kopplung von Anwendungssystemen zu Interorganisationssystemen oder der Kapselung und Einbindung von Legacy-Anwendungen im Rahmen einer unternehmensinternen Anwendungsintegration [Beute2002, S. 27f.; MDWe2002, S. 7]. Ungeachtet der vielen Vorteile können sich bei der Einführung und Anwendung serviceorientierter Architekturen jedoch auch erhebliche Schwierigkeiten ergeben, die dadurch entstehen, dass das modulare Entwicklungsparadigma der Komponenten- und Serviceorientierung noch immer nicht ausreichend methodisch unterstützt wird [MDWe2002, S. 11]. Zwar sind mit XML Web-Services und Serviceorientierten Architekturen mittlerweile ausgereifte Technologien und Konzepte vorhanden, die das Entwicklungsparadigma unterstützen. Dennoch bestehen vor allem unzureichend beantwortete Entwicklungsfragen, die einen Einsatz der Serviceorientierung in der betrieblichen Praxis erschweren: x

wie erfolgt die Dekomposition einer Aufgabenstellung bzw. eines vorhandenen Legacy-Systems in Services;

4

Sven Overhage, Klaus Turowski

x

wie lassen sich eigenständige Services identifizieren;

x

wie ist die Eignung bzw. Kompatibilität einzelner Services im Vorfeld der Orchestrierung zu ermitteln;

x

welche Verschiedenheiten (Heterogenitäten) können zwischen Services auftreten und wie ist mit diesen umzugehen;

x

wie können die Eigenschaften einer Föderation von Services auf Basis der Eigenschaften der einzelnen Services vorhergesagt bzw. verifiziert werden;

x

wie soll die Zusammenstellung und Orchestrierung von Services erfolgen etc.?

Neben einer rein technologischen Unterstützung ist es deshalb notwendig, das modulare Entwicklungsparadigma auch durch eine methodische Unterstützung besser zu operationalisieren und in der Praxis handhabbar zu machen. Im Rahmen dieses Beitrags wird auf die wesentlichen Aufgabenstellungen näher eingegangen, die einer methodischen Unterstützung bedürfen. Diese Aspekte werden zu einer Konstruktionsmethodik zusammengefasst, die die Grundlage einer Konstruktionslehre für die angestrebte ingenieurmäßige Entwicklung von Services und Anwendungssystemen bildet. Zuvor werden im nächsten Kapitel zunächst begriffliche Grundlagen gelegt und Abgrenzungen vorgenommen.

2

SOA: Begriffsdefinition, Abgrenzungen und Klassifikation

2.1

Begriffsdefinition und Abgrenzung

In der technischen Literatur wird der Begriff „Serviceorientierte Architektur“ vor allem auf der Grundlage des sog. Find-Bind-Execute Paradigmas und der entsprechend definierten technischen Rollen der Beteiligten definiert. Demgemäß werden Services und deren Schnittstellen zunächst von einem Anbieter in einem Katalog publiziert. Ein Nachfrager durchsucht dann diesen Katalog, koppelt die Schnittstelle eines geeigneten Services gemäß dem jeweils im Katalog hinterlegten Schnittstellenvertrag an seine Anwendung und führt den gewünschten Dienst aus. Damit entspricht SOA im Kern einem technischen Managementkonzept und setzt erst in zweiter Linie ein darauf aufbauendes Konzept der Software-Architektur voraus. Zudem finden sich weitere, stärker an der Wirtschaftsinformatik orientierte Definitionen, die außerdem eine an den Geschäftsprozessen der jeweiligen Unternehmen ausgerichtete IT-Infrastruktur fordern, die effizient auf veränderte geschäftliche Anforderungen reagieren kann. Zu den verschiedenen Definitionen vgl. z.B. [BHMN+2004; KBSl2005; MaBe2006; MSJL2006, S. 30]. Aus technischer Sicht und hinsichtlich des zugrundeliegenden Paradigmas lassen sich die verschiedenen Definitionen jedoch zusammenfassen. Der Begriff Serviceorientierte Architektur (SOA) steht insofern als Sammelbegriff für ein bestimmtes Strukturparadigma für (betriebliche) Anwendungssysteme, das, gegenüber anderen Ansätzen der (Software-) Wiederverwendung auf den Aspekt der (Dienst-) Verwendung fokussiert. Bereits an dieser Stelle sei darauf hingewiesen, dass SOA auch breiter definiert werden kann, d. h. nicht nur auf die Wiederverwendung von Software, sondern auf die Wiederverwendung ganzer (betrieblicher) (Teil-) Systeme im weiteren Sinne

Serviceorientierte Architekturen – Konzept und methodische Herausforderungen

5

bezogen. Ein Beispiel dafür wäre etwa das Business Process Outsourcing. Diesem weiteren Begriffsverständnis wird im Rahmen dieses Beitrags nicht gefolgt, vielmehr werden schwerpunktmäßig die automatisierten Systemteile betrachtet. Nachvollziehbar wird die oben formulierte SOA-Definition, wenn ihr der jeweilige Fokus der anderen, verwandten Ansätze der Softwarewiederverwendung gegenüberstellt werden (vgl. dazu Abbildung 1-1). Zentral für die in Abbildung 1-1 dargestellten Wiederverwendungsansätze ist der Begriff des Dienstes: Ein Dienst ist eine Aktion eines (betrieblichen) Anwendungssystems, welche die Bewältigung einer bestimmten Menge von (betrieblichen) Aufgaben unterstützt [Turo2003, S. 25]. Beide in Abbildung 2-1 genannten Wiederverwendungsansätze zielen auf den mehrfachen Einsatz von Diensten in verschiedenen, zur Entwicklungszeit der Dienste nicht unbedingt vorhersehbaren Systemkontexten ab. Im Falle einer rein komponentenorientierten Vorgehensweise kommen für betriebliche Anwendungssysteme sogenannte Software-Komponenten [SGMu2002] bzw. Fachkomponenten [Turo2003] zum Einsatz.

Abb. 2-1: Lebenszyklus eines Dienstes bei unterschiedlichen Wiederverwendungsansätzen. Der Komponentenbegriff wird in der Literatur dabei nicht einheitlich verwendet (vgl. z.B. [BKSc2001, S. 92; DSWi1999, S. 387; HeSi2000, S. 40; OMG2003, S. 136f.; SGMu2002, S. 41]). Hier soll die Definition des Arbeitskreises WI-Kobas „Komponentenorientierte betriebliche Anwendungssysteme“ der Gesellschaft für Informatik verwendet werden [ABCF+2002, S. 1]: Eine Komponente besteht aus verschiedenartigen (Software-) Artefakten. Sie ist wiederverwendbar, 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.

6

Sven Overhage, Klaus Turowski

Beim Einsatz von Fachkomponenten wird die Verantwortung für die Softwareentwicklung an den Komponentenhersteller delegiert. Dem Verwender obliegt es jedoch, für die Fachkomponente eine Laufzeitumgebung zur Verfügung zu stellen und den Betrieb von Fachkomponente und Umsystem sicherzustellen. Das SOA Paradigma geht einen Schritt weiter, indem der Verwender eines Dienstes zusätzlich die Verantwortung für den Betrieb der Software, die den Dienst letztlich implementiert, an einen Dritten delegiert, sodass, aus der Sicht des Verwenders, der Eindruck einer höheren Anwendungsnähe entsteht, da mit der Delegation der Betriebsverantwortung von einer gegenüber dem eigentlichen Dienst anwendungsferneren Aufgabe abstrahiert werden kann. Gleichwohl besteht bei den beiden einander gegenübergestellten Wiederverwendungsszenarien die Notwendigkeit zu Auswahl und Komposition (oder Orchestrierung, um den im Kontext von SOA üblichen Begriff zu verwenden), die in Abbildung 2-1 der Plakativität geschuldet bleiben. Berücksichtigt man diese Aufgaben, so liegt es nahe, den sehr allgemeinen, oben definierten Dienstbegriff weiter zu einer SOA-spezifischen Service-Definition zu verfeinern: Als Service wird eine zusammengehörende Menge von vermarktbaren Diensten bezeichnet, die einem authorisierten Nutzerkreis unter Nutzung standardisierter Kommunikationsprotokolle über wohldefinierte Schnittstellen angeboten werden. Services umfassen Schnittstellenbeschreibungen der von ihnen angebotenen Dienste, die in einer standardisierten Beschreibungssprache verfasst sind. Implementierungsdetails bleiben dem Nutzer verborgen. Die Diskussion der mit SOA einhergehenden Herausforderungen in Kapitel 3 vorbereitend, werden im Folgenden zunächst weitere strukturelle Ähnlichkeiten von SOA und komponentenorientierten Ansätzen, als einem verwandten und beim heutigen Stand der Forschung besser verstandenen Wiederverwendungsparadigma, untersucht und auf der Basis von [KrTu2002] klassifiziert. Ausgehend von den oben gegebenen Definitionen sind die maßgeblichen Eigenschaften von Fachkomponenten und SOA-spezifischen Services in Tabelle 2-1 einander gegenübergestellt. Das Kriterium der Abgeschlossenheit erfüllt eine Komponente dann, wenn ihr ihre Bestandteile eindeutig zuordenbar sind, sodass sie als Ganzes klar von anderen Systemteilen abgegrenzt werden kann. Dieser Aspekt der Abgeschlossenheit ist in der Definition von SOA-spezifischen Services nicht explizit enthalten. Eine Festlegung in dieser Hinsicht ist auch verzichtbar, da ein Verwender vornehmlich an den vom Service erbrachten Leistungen interessiert ist, nicht jedoch an den strukturellen Gesichtspunkten der den Service realisierenden Implementierung, die ausschließlich den Anbieter interessieren. SOA-spezifischen Services liegt eine gegenüber der Nutzung von Fachkomponenten andere Sichtweise auf den Wiederverwendungsgegenstand zugrunde. Bei Fachkomponenten ist der Leistungserbringer, nämlich die Fachkomponente selbst Gegenstand der Wiederverwendung. Der Begriff Fachkomponente bezieht sich hierbei auf die Typebene, bei einer (Wieder-) Verwendung wird zunächst eine Instanz gebildet. Bei SOA-spezifischen Services hingegen ist die von den angebotenen Diensten erbrachte Leistung Gegenstand der Wiederverwendung. Eine Instanziierung erfolgt nicht notwendigerweise, mehrere Nutzer können auf eine Instanz des Service zugreifen.

Serviceorientierte Architekturen – Konzept und methodische Herausforderungen

Eigenschaft

Fachkomponente

7

SOA-spezifischer Service

Abgeschlossenheit

Abgeschlossen

-

Gegenstand der Wiederverwendung

Leistungserbringer

Leistung

Gegenstand der Vermarktung

Leistungserbringer

Leistung

Schnittstellen

Stellt Dienste über wohldefinierte Schnittstellen zur Verfügung

Stellt Dienste über wohldefinierte Schnittstellen zur Verfügung

Informationen über Realisierung

Verbirgt Realisierung

Verbirgt Realisierung

Kombinierbarkeit

Kann in Kombination mit anderen Komponenten eingesetzt werden, die zur Zeit der Entwicklung nicht unbedingt vorhersehbar ist

Kombination mit anderen Services werden nicht ausgeschlossen

Aufbau (aus Sicht des Verwenders)

Besteht aus (Software-) Artefakten

Nur Schnittstellenspezifikation

Tab. 2-1: Gegenüberstellung der Eigenschaften von Fachkomponenten und SOA-spezifischen Services. Ähnliches gilt für den Gegenstand der Vermarktung. Bei Fachkomponenten bezieht sich dieser Aspekt auf die Fachkomponente selbst, also die Gesamtheit aller (Software-) Artefakte, aus denen sich die Fachkomponente zusammensetzt. Bei SOA-spezifischen Services hingegen sind nur die von den angebotenen Diensten erbrachten Leistungen Gegenstand der Vermarktung. Hier wird somit nicht die Vermarktbarkeit des Programms zur Realisierung der angebotenen Dienste betrachtet, sondern ausschließlich die Vermarktbarkeit der damit erzeugten Leistungen. Sowohl Fachkomponenten als auch SOA-spezifische Services stellen ihre Dienste über wohldefinierte Schnittstellen bereit. Übereinstimmung findet sich auch bei der Verfügbarkeit von Informationen über ihre Realisierung. Zu den Merkmalen von Fachkomponenten und SOA-spezifischen Services gehört das Verbergen von Informationen über Implementierungsdetails. Unterschiede sind feststellbar, wenn das Merkmal der Kombinierbarkeit untersucht wird. Für Fachkomponenten wird die Kombination von Leistungserbringern in zur Zeit der Entwicklung nicht unbedingt vorhersehbarer Weise gefordert. Bei SOA-spezifischen Services wird nicht die Kombination der Leistungserbringer, sondern die Kombination der Leistungen selbst betrachtet. Eine Fachkomponente besteht aus (Software-) Artefakten, hierzu zählen der ausführbare Code, darin verankerte Grafiken, Textkonstanten usw., die einen initialen Zustand der Komponente beschreibenden Daten, z.B. Voreinstellungen oder Parameter, sowie Spezifikation, (Anwender-) Dokumentation und (automatisierte) Tests [ABCF+2002, S. 1]. Ein SOA-spezifischer Service hingegen „besteht“ für den

8

Sven Overhage, Klaus Turowski

Verwender zunächst ausschließlich aus dem (Software-) Artefakt Schnittstellenspezifikation. 2.2

Klassifikation

SOA-spezifische Services können sehr unterschiedlich komplexe betriebliche Aufgaben unterstützen. Die Bandbreite an Komplexität reicht hierbei von der Währungsumrechnung bis hin zur Implementierung sämtlicher Funktionen einer Lohnbuchhaltung. Im Folgenden wird aufbauend auf [KrTu2002] ein Klassifikationsrahmen in Form eines morphologischen Kastens für SOA-spezifische Services entwickelt, mit dessen Hilfe eine Einordnung der unterschiedlichen Ausprägungsformen von SOA-spezifischen Services möglich und die Begründung spezifischer Herausforderungen in Kapitel 3 vereinfacht wird. Bei SOA-spezifischen Services lassen sich verschiedene Leistungsverrechnungsarten unterscheiden. Aus dem Blickwinkel des Nutzers kann es sich um ein kostenloses Angebot handeln, die Verrechnung kann nutzungsabhängig vorgenommen werden oder die Leistung wird zu einem nutzungsunabhängigen Festpreis angeboten. Durch den SOA-spezifischen Service kann eine betriebswirtschaftlich nicht sinnvoll weiter unterteilbare Einzelleistung angeboten werden. Ebenso ist ein Angebot von mehreren Einzelleistungen durch einen SOA-spezifischen Service möglich. Ferner kann ein SOA-spezifischer Service ein Leistungsbündel anbieten, das dem Verwender als eigenständige Gesamtleistung erscheint, intern jedoch durch die Kombination von mehreren Einzelleistungen zusammengesetzt wird. Ein weiteres Kriterium zur Klassifikation von SOA-spezifischen Services ist die Nutzung anderer Dienste (speziell anderer SOA-spezifischer Services). Hier gilt es zu unterscheiden, ob der betrachtete SOA-spezifische Service überhaupt andere Dienste in Anspruch nimmt, und wenn ja, ob die Verknüpfung bereits vor der Anfrage fest vorgegeben ist, oder ob Auswahl und Dienstaufruf während der Bearbeitung der Anfrage dynamisch vorgenommen werden (Ad-hoc-Bündelung). Mit dem Merkmal Zustand wird unterschieden, ob der betrachtete SOA-spezifische Service über die Dauer einer Anfrage hinaus einen bestimmten Zustand bewahren kann (zustandsbehaftet), oder ob der SOA-spezifische Service bei jeder Anfrage im Initialzustand gestartet wird (zustandslos). Nutzt ein SOA-spezifischer Service andere zustandsbehaftete SOA-spezifische Services, sind ggf. entsprechende Mechanismen zur Überwachung (geschachtelter) Transaktionen notwendig. SOA-spezifische Services können nach dem Zeitpunkt differenziert werden, zu dem sie typischerweise in das nutzende Anwendungssystem integriert werden. Unterschieden werden kann die Ad-hoc-Integration von einer festen Verknüpfung. Ad-hocIntegration bedeutet, dass Auswahl und Dienstaufruf dynamisch zur Zeit des Auftretens einer entsprechenden Nachfrage im nutzenden Anwendungssystem stattfinden. Feste Verknüpfung bedeutet hingegen, dass für eine Aufgabe immer die Dienste eines vordefinierten SOA-spezifischen Service genutzt werden. Hinsichtlich des Automatisierungsgrads wird zwischen Voll- und Teilautomatisierung differenziert. Teilautomatisierung ist z.B. für den im Rahmen dieses Beitrags nicht weiter betrachteten Fall des Business Process Outsourcing relevant. In Tabelle 2-2 sind die genannten Merkmale zur Klassifikation und die möglichen Ausprägungen zusammengefasst.

Serviceorientierte Architekturen – Konzept und methodische Herausforderungen

9

Tab. 2-2: Merkmale SOA-spezifischer Services Idealtypische Ausprägungen von Services, die etwa bei der Untersuchung von Web Services beobachtet werden können (vgl. hierzu [KrTu2002], eine ähnliche Einteilung findet sich auch bei [MSJL2006, S. 382-384]) sind vom Typ x

Information,

x

Funktionsbibliothek oder

x

Prozessbündel.

Ein typisches Merkmal von Services des Typs Information, die z.B. aktuelle Börsenoder Devisenkurse bereitstellen, ist dass die Speicherung von Zustandsdaten über die Dauer einer singulären Dienstnutzung hinaus üblicherweise nicht vorgesehen ist. Dem stehen die Services vom Typ Funktionsbibliothek gegenüber, die ihre volle Wirksamkeit erst dann entfalten, wenn sie zustandsbehaftet sind und die von anderen Anwendungssystemteilen abhängen können. Ein Beispiel ist ein Service, der typische Dienste für die Lohnbuchhaltung zur Verfügung stellt. Für den Service wäre eine eigene persistente Datenhaltung notwendig, da beispielsweise zur Führung von Gehaltskonten die Identität von Mitarbeitern abzufragen ist, der Familienstand und die Steuerklasse der Mitarbeiter zur korrekten Berechnung abzuführender Abgaben herangezogen werden müssen und vor der Verwendung einer Lohn- und Gehaltsabrechnung in der Regel eine umfangreiche Parametrisierung vorgenommen werden muss. Aufgrund der engen Verflechtung der Lohnbuchhaltung mit anderen Systemen einer betrieblichen Anwendungslandschaft ist ferner die Nutzung von weiteren Diensten durch den Service sinnvoll. So kann z.B. eine Schnittstelle zum Inkasso-Exkasso-System des den Service nutzenden Unternehmens bestehen, um Buchungen auf Kontokorrentkonten des Unternehmens zu veranlassen. Prozessbündel, die dritte idealtypische Ausprägung von Services, integrieren mehrere Einzelleistungen, die über andere Services realisiert sein können, zu einer komplexen Gesamtleistung. Ein Prozessbündel wird vom originären Verwender eines Service als Einheit wahrgenommen. Besonderes Merkmal ist hierbei, dass, abhängig von der individuell nachgefragten Leistung, die Verknüpfung zu den anderen Services ad-hoc vorgenommen werden muss, z.B. bei kundenindividuellen Reiseangeboten, mit verschiedenartigen Transportmitteln und Bezahlverfahren.

10

3

Sven Overhage, Klaus Turowski

Bestehende Herausforderungen

Mit der Einführung und Anwendung der Serviceorientierung in die betriebliche Anwendungsentwicklung entsteht eine Vielzahl neuer Entwicklungsaufgaben, die es durch geeignete Methoden und Werkzeuge, d.h. mit einer Methodik, zu unterstützen gilt. In Abhängigkeit von ihrem Gegenstand lassen sich diese Aufgaben entweder dem Teilprozess der Serviceentwicklung, dessen Ziel die Bereitstellung wieder verwendbarer Services ist, oder der Anwendungsentwicklung bzw. -integration, deren Ziel die Verbindung von Services zu Anwendungen bzw. Föderationen ist, zuordnen. Dementsprechend sind zur Unterstützung des serviceorientierten Entwicklungsparadigmas zwei spezialisierte Teilmethodiken zu schaffen, die jeweils eine Menge aufeinander abgestimmter Methoden und Werkzeuge bereitstellen. Zur Realisierung von Services wird in der Regel eine bewährte Entwicklungstechnik wie die funktionale oder objektorientierte Programmierung eingesetzt. Dementsprechend weist die Implementierungsphase eine starke Ähnlichkeit zur funktionalen bzw. objektorientierten Entwicklung auf und lässt sich durch Methoden und Werkzeuge unterstützen, die bereits in Zusammenhang mit diesen Entwicklungsparadigmen entstanden sind. Unterschiede ergeben sich jedoch durch die anzustrebende Generalisierung, die die Wiederverwendbarkeit des Services in verschiedenen Entwicklungskontexten sicherstellen soll. Deswegen sind als Bestandteile einer Methodik für die Serviceentwicklung zusätzliche Methoden und Werkzeuge bereitzustellen, mit denen die Entwicklung generalisierter Dienste gefördert wird. Hierfür finden sich vor allem im Rahmen der Domänenanalyse und Domänenimplementierung [CzEi2000, S. 19-59; Prie1990; Same1997, S. 160-168] sowie der Produktlinienentwicklung [JGJo1997] wichtige Ansätze, die als Bestandteile in die angestrebte Entwicklungsmethodik aufzunehmen sind. Dennoch verbleiben verschiedene Entwurfsfragen, für die bislang keine ausgereifte methodische Unterstützung existiert. So ist bspw. unklar, wie auf Basis eines Domänenmodells geeignete Services zu finden sind, die fachlich eigenständig sind und dem modularen Prinzip maximaler Kohäsion bei gleichzeitig minimaler Kommunikation [Parn1972] entsprechen. Zu entsprechenden Vorarbeiten im Bereich der Komponentenorientierung vgl. bspw. [AlDi2006; Alba2003]. Darüber hinaus ist zu klären, wie Fragen des Datenschutzes bei zustandsbehafteten Services zu beantworten oder Kosten der Indirektion beim Aufruf anderer Services zu minimieren sind. Noch immer in der Entstehung begriffen ist jedoch vor allem eine Methodik, mit der sich die Verbindung von Services zu Anwendungssystemen bzw. Föderationen unterstützen lässt. Zu den zentralen Bausteinen einer solchen Methodik (vgl. Abbildung 3-1 und bspw. [Crnk2001; ZaWi1997]) gehören Methoden und Werkzeuge für x

die Spezifikation von Services,

x

die Zertifizierung von Services,

x

die Katalogisierung von Services,

x

die Suche von Services,

x

die Durchführung statischer Kompatibilitätstests,

x

die Adaptergenerierung,

Serviceorientierte Architekturen – Konzept und methodische Herausforderungen

11

x

die Ableitung der Eigenschaften von Anwendungssystemen bzw. Föderationen auf Basis der Eigenschaften der einzelnen Services sowie

x

die Orchestrierung von Services.

Ein Spezifikationsrahmen, nach dessen Vorgaben die nach außen sichtbaren Eigenschaften von Services beschrieben werden, stellt dabei zunächst das zentrale Element der Methodik dar, da die mit ihm bereitgestellten Informationen über Services die Grundlage für die Entwicklung und Anwendung der anderen Methoden bzw. Werkzeuge darstellt [OvTh2005]. Gleichzeitig stellt die Existenz und Standardisierung eines solchen Spezifikationsrahmens eine grundlegende Voraussetzung für die Entstehung von Servicemärkten dar [HaTu2005; OvTh2003]. Mit ihm müssen deshalb all diejenigen Eigenschaften von Services in angemessener Weise beschrieben werden können, die zur Durchführung der Anwendungsentwicklung bzw. einer Anwendungsintegration benötigt werden [Brow2000, S. 103; HoNo2001, S. 244]. Vor allem müssen alle funktionalen, qualitativen und programmiertechnischen Eigenschaften der Außensicht von Services beschrieben werden können, die für den Such- und Auswahlprozess relevant sind.

Kompositionsmethodik

Ableitung von Eigenschaften

Adaptergenerierung

Kompatibilitätstests

Katalogisierung und Suche

Komposition/Orchestrierung von Services

Zertifizierung von Services Vollständige Spezifikation der Außensicht von Services

Abb. 3-1: Elemente einer Kompositionsmethodik und zu unterstützende Entwicklungsaufgaben Die geforderte Entwicklung von Methoden und Werkzeugen zur Zertifizierung von Services dient hauptsächlich der Steigerung des Vertrauens in die jeweils als Spezifikation bereitgestellten Informationen. Im Rahmen der Zertifizierung wird folglich vor allem die Übereinstimmung von Services mit ihrer jeweils spezifizierten Außensicht untersucht und durch ein entsprechendes Zertifikat bescheinigt [ABCG+2001, S. 769; FlDe2001, S. 701; IEEE1991; MLPB+2001]. Damit wird ein gewisser Ausgleich für die Schwierigkeiten bei der Verifizierung einer Servicespezifikation durch die Anwendungsentwickler bzw. -integratoren geschaffen. Demgegenüber stellt die Entwicklung leistungsfähiger Methoden und Werkzeuge zur Katalogisierung von Services sowie zur Suche nach ihnen vor allem eine wesentliche

12

Sven Overhage, Klaus Turowski

Voraussetzung für den Aufbau von Verzeichnissen und Bibliotheken (sog. Repositorien) dar [MMMi1998; Same1997, S. 178f.]. Mit solchen Repositorien, die bspw. auf dem UDDI (Universal Description, Discovery, and Integration) Standard aufbauen können, lässt sich eine effiziente Auswahl von Services für die Wiederverwendung realisieren, weshalb sie bereits ein zentrales Element der XML Web-Services Technologie bilden. Für die Suche werden Services zunächst bezüglich ihrer Eigenschaften nach einem Klassifikationsschema angeordnet [Prie1991; PrFr1987; Same1997, S. 179-184] und in einem Repositorium abgelegt. Die Qualität der mit der Katalogisierung von Services erzielbaren Ergebnisse hängt maßgeblich vom Umfang der bereitgestellten Informationen über Services ab, die zur Klassierung verwendet werden können. Während der Suche sind die Eigenschaften der in einem Repositorium angeordneten Services dann mit den Kriterien zu vergleichen, die im Rahmen einer Anfrage formuliert wurden. Dabei kann grundsätzlich zwischen textbasierten, klassifikationsbasierten und spezifikationsbasierten Vorgehensweisen unterschieden werden, die vor allem im Hinblick auf die Komplexität und die Qualität der ermittelten Ergebnisse voneinander abweichen [FrPo1994; MMMi1995, S. 547, 550]. Textbasierte Suchmethoden überprüfen die katalogisierten Informationen über Services lediglich auf das Vorhandensein von Schlüsselwörtern, die im Rahmen einer Abfrage vorgegeben wurden. Dagegen unterstützen klassifikationsbasierte Methoden ein differenzierteres Vorgehen bei der Suche nach Schlüsselwörtern, etwa indem sie die Vorgabe unterschiedlicher Schlüsselwörter erlauben und mit diesen jeweils unterschiedliche Facetten (Aspekte) der katalogisierten Information durchsuchen. Die besten Ergebnisse lassen sich in der Regel jedoch durch die Vorgabe einer Referenzspezifikation erzielen, die im Rahmen einer Suche mit den Spezifikationen der einzelnen Services detailliert verglichen wird [MMMi1995, S. 551f.]. Somit sind spezifikationsbasierte Suchmethoden den anderen meist überlegen. Im Gegensatz zu diesen Methoden besitzen sie jedoch eine in der Regel deutlich höhere Komplexität, die durch den detaillierten Vergleich von Spezifikationen entsteht [MMMi1995, S. 552]. Daher kommen bei der Entwicklung von Suchmethoden hauptsächlich relaxierende Vergleichsverfahren zum Einsatz [ZaWi1995, S. 147; ZaWi1997, S. 334]. Diese besitzen eine deutlich geringere Komplexität, liefern jedoch üblicherweise nur eine Vorauswahl potenziell geeigneter Services, die im Folgenden genauer zu untersuchen sind. Die Qualität der mit spezifikationsbasierten Suchmethoden erzielbaren Ergebnisse hängt jedoch nicht nur vom eingesetzten Vergleichsverfahren, sondern vor allem auch vom Umfang und der (effizienten) statischen Vergleichbarkeit der jeweils einzubeziehenden Informationen ab [MMMi1995, S. 552]. Eine wesentliche Abhängigkeit von der Vergleichbarkeit der zur Verfügung gestellten Informationen besteht auch bei den Methoden und Werkzeugen, mit denen statische Kompatibilitätstests durchgeführt werden können. Ähnlich wie spezifikationsbasierte Suchmethoden nutzen diese die in Servicespezifikationen enthaltenen Informationen zur Ermittlung der Kompatibilität, indem sie einen detaillierten Vergleich zweier Spezifikationen durchführen [YeSt1997; ZaWi1995; ZaWi1997]. Im Unterschied zur Vorgehensweise bei der Suche nach Services, bei der die effiziente Ermittlung einer Menge potenziell geeigneter Services im Mittelpunkt steht, kommen im Rahmen von Kompatibilitätstests jedoch möglichst exakte Vergleichsverfahren zum Einsatz, mit denen sich eine umfassende und korrekte Aussage über die Kompatibilität zweier Spezifikationen ermitteln lässt.

Serviceorientierte Architekturen – Konzept und methodische Herausforderungen

13

Eine Vielzahl der im Rahmen von Kompatibilitätstests entdeckten Inkompatibilitäten zwischen Services lässt sich durch die Zwischenschaltung geeigneter Adapter beseitigen [YeSt1894, S. 176; YeSt1997, S. 293; ZaWi1995, S. 147f.; ZaWi1997, S. 334], deren Entwicklung somit eine wichtige, durch geeignete Methoden und Werkzeuge zu unterstützende Teilaufgabe des serviceorientierten Entwicklungsprozesses darstellt. Zur Unterstützung dieser Aufgabe sind vor allem Verfahren für eine systematische und zumindest teilweise automatisierbare Adaptergenerierung zu entwickeln, mit denen zunächst der vorhandene Anpassungsbedarf aus den Spezifikationen zweier Services im Rahmen einer Analyse berechnet werden kann. In Abhängigkeit von den jeweils ermittelten Ergebnissen ist dann entweder zu entscheiden, ob entsprechende Maßnahmen zur Ableitung eines geeigneten Adapters zur Anwendung gebracht werden können, oder festzustellen, dass keine Anpassung ausgeführt werden kann. Neben der Beseitigung von Inkompatibilitäten zwischen Services sind als weitere Aufgabenbereiche für die Adaptergenerierung vor allem die gezielte Veränderung der Funktionalität und der Qualität des Gesamtsystems zu nennen. So lassen sich durch die Zwischenschaltung von Adaptern bspw. funktionale Konflikte beheben, die bei redundant angebotenen Funktionen verschiedener Services entstehen [FSHS1997, S. 26; Turo2003, S. 168-174]. Die Verfügbarkeit von Servicespezifikationen ist ebenso eine Voraussetzung für die Entwicklung von Methoden und Werkzeugen, mit denen eine Ableitung der Eigenschaften des zu entwickelnden Anwendungssystems auf Basis der Eigenschaften der zu verbindenden Services durchgeführt werden kann. Hierdurch wird es möglich, die aus der Verbindung von Services resultierenden Eigenschaften des Gesamtsystems im Voraus, d.h. vor der Konfigurierung zu ermitteln [DMMu2003, S. 2-3; Wall2003, S. 10f.; WSHK2001]. So lässt sich bereits während des Entwurfs verifizieren, ob eine Systemarchitektur in der Lage sein wird, die bestehenden qualitativen Anforderungen zu erfüllen. Zur Bestimmung von Systemeigenschaften werden die in den Spezifikationen enthaltenen Informationen über Services gemäß der Architektur des jeweiligen Anwendungssystems miteinander verknüpft und unter Verwendung eines Vorhersagemodells, das als zentrales Element mit der jeweils anzuwendenden Methode bereitzustellen ist, ausgewertet [LaOr2001; RSPo2003; ReSc2002; Wall2003, S. 29-31].

4

Zusammenfassung und Ausblick

In diesem Beitrag wurden vor allem die bestehenden Herausforderungen im Detail beschrieben, die den Einsatz der Serviceorientierung in der heutigen Praxis erschweren. Dabei wurde noch vorhandener Forschungsbedarf beschrieben und die Schaffung einer Konstruktionsmethodik zur Unterstützung des Entwicklungsprozesses als wichtiges Ziel motiviert. Die Entwicklung einer solchen Methodik stellt zugleich einen wichtigen Erfolgsfaktor dar, der über die Durchsetzungsfähigkeit dieses vermeintlich neuen Entwicklungsparadigmas maßgeblich mit entscheiden wird. Ferner wurde die bestehende Ähnlichkeit zur komponentenorientierten Entwicklung hervorgehoben, die bereits seit Längerem diskutiert und erforscht wird. Vor allem aufgrund dieser Ähnlichkeit wird es möglich, bereits vorhandene Erkenntnisse und Konzepte auf die Serviceorientierung zu übertragen und so zugleich die Entwicklung einer speziell auf das Serviceparadigma angepassten Methodik zu befördern.

14

Sven Overhage, Klaus Turowski

Die Entwicklung einer solchen Konstruktionsmethodik stellt einen zentralen Forschungsgegenstand an der Universität Augsburg dar. Auf der Grundlage eines Spezifikationsrahmens, mit dem sich die Außensicht von Services beschreiben lässt, wird dabei angestrebt, die in diesem Beitrag genannten Methoden und Werkzeuge sukzessive zu entwickeln und für die Benutzung durch Dritte zur Verfügung zu stellen. Dabei wird gezielt mit anderen Universitäten zusammengearbeitet, um zu einer in der Breite getragenen Lösung zu gelangen.

Literaturverzeichnis [ABCF+2002] Ackermann, J.; Brinkop, F.; Conrad, S.; Fettke, P.; Frick, A.; Glistau, E.; Jaekel, H.; Kotlar, O.; Loos, P.; Mrech, H.; Ortner, E.; Overhage, S.; Raape, U.; Sahm, S.; Schmietendorf, A.; Teschke, T.; Turowski, K. (2002). Vereinheitlichte Spezifikation von Fachkomponenten: Gesellschaft für Informatik (GI). [AlDi2006] Albani, A.; Dietz, J.: The Benefit of Enterprise Ontology in Identifying Business Components. In: M. Bramer (Hrsg.): IFIP International Federation for Information Processing: Artificial Intelligence in Theory and Practice IFIP 19th World Computer Congress, TC 12: IFIP AI 2006 Stream, August 21–24, 2006. Santiago, Chile 2006 [AKTW2003] Albani, A.; Keiblinger, A.; Turowski, K.; Winnewisser, C.: Komponentenmodell für die strategische Lieferkettenentwicklung. In: W. Uhr; W. Esswein; E. Schoop (Hrsg.): Wirtschaftsinformatik 2003, Medien, Märkte, Mobilität, Band II. Dresden, Germany 2003, S. 61-80 [ABCG+2001] Apperly, H.; Booch, G.; Councill, W. T.; Griss, M.; Heineman, G. T.; Jacobson, I.; Latchem, S.; McGibbon, B.; Norris, D.; Poulin, J.: The Near-Term Future of Component-Based Software Engineering. In: W. T. Councill; G. T. Heineman (Hrsg.): Component-Based Software Engineering: Putting the Pieces Together. Addison-Wesley, Upper Saddle River, NJ 2001, S. 753-774. [Bett2001] Bettag, U.: Web-Services. In: Informatik Spektrum 24 (2001) 5, S. 302-304. [Beute2002] Beutenmüller, U.: Web Services: Top oder Flop? In: Information Management & Consulting 17 (2002) 3, S. 26-30. [BHMN+2004] Booth, D.; Haas, H.; McCabe, F.; Newcomer, E.; Champion, M.; Ferris, C.; Orchard, D. (2004). Web Services Architecture: World Wide Web Consortium. [BKSc2001] Baster, G.; Konana, P.; Scott, J. E.: Business Components - A Case Study of Bankers Trust Australia Limited. In: Communications of the ACM 44 (2001) 3, S. 92-98. [Brow2000] Brown, A. W.: Large-Scale, Component-Based Development. Prentice Hall, Upper Saddle River, NJ 2000. [Crnk2001] Crnkovic, I.: Component-Based Software Engineering - New Challenges in Software Development. In: Software Focus 2 (2001) 4, S. 127-133. [CzEi2000] Czarnecki, K.; Eisenecker, U. W.: Generative Programming: Methods, Tools, and Applications. Addison-Wesley, Upper Saddle River, NJ 2000. [DMMu2003] Dumitrascu, N.; Murphy, S.; Murphy, L.: A Methodology for Predicting the Performance of Component-Based Applications. In: J. Bosch; C. Szyperski; W. Weck (Hrsg.): 8th International Workshop on Component-Oriented Programming (WCOP'03). Darmstadt, Germany 2003.

Serviceorientierte Architekturen – Konzept und methodische Herausforderungen

15

[DSWi1999] D'Souza, D. F.; Wills, A. C.: Objects, Components, and Frameworks with UML: The Catalysis Approach. Addison-Wesley, Upper Saddle River, NJ 1999. [FlDe2001] Flynt, J.; Desai, M.: The Future of Software Components: Standards and Certification. In: W. T. Councill; G. T. Heineman (Hrsg.): Component-Based Software Engineering: Putting the Pieces Together. Addison-Wesley, Upper Saddle River, NJ 2001, S. 693-708. [FrPo1994] Frakes, W. B.; Pole, T. P.: An Empirical Study of Representation Methods for Reusable Software Components. In: IEEE Transactions on Software Engineering 20 (1994) 8, S. 617-630. [FSHS1997] Ferstl, O. K.; Sinz, E. J.; Hammel, C.; Schlitt, M.; Wolf, S.: Bausteine für komponentenbasierte Anwendungssysteme. In: HMD 197 (1997) 34, S. 24-46. [HaTu2005] Hahn, H.; Turowski, K.: Modularity of the Software Industry: A Model for the Use of Standards and Alternative Coordination Mechanisms. In: International Journal of IT Standards and Standardization Research 3 (2005) 2, S. 29-41. [HeSi2000] Herzum, P.; Sims, O.: Business Component Factory: A Comprehensive Overview of Component-Based Development for the Enterprise. John Wiley & Sons, New York, NY 2000. [HoNo2001] Houston, K.; Norris, D.: Software Components and the UML. In: W. T. Councill; G. T. Heineman (Hrsg.): Component-Based Software Engineering: Putting the Pieces Together. Addison-Wesley, Upper Saddle River, NJ 2001, S. 243-262. [IEEE1991] IEEE: IEEE Standard Glossary of Software Engineering Terminology. New York: Institute of Electrical and Electronics Engineers, 1991. [JGJo1997] Jacobson, L.; Griss, M.; Jonsson, P.: Software Reuse - Architecture, Process, and Organization for Business Success. Addison-Wesley, Upper Saddle River, NJ 1997. [KoLe2004] Kossmann, D.; Leymann, F.: Web Services. In: Informatik Spektrum 26 (2004) 2, S. 117-128. [KBSl2005] Krafzig, D.; Banke, K.; Slama, D.: Enterprise SOA - Service -Oriented Architecture Best Practices. Prentice Hall, Upper Saddle River, NJ 2005. [KrTu2002] Krammer, A.; Turowski, K.: Spezifikationsbedarf von Web Services. In: E. Ortner; S. Overhage (Hrsg.): 1. Workshop Entwicklung von Anwendungen auf der Basis der XML Web-Service Technologie. Darmstadt 2002, S. 1-16 [LaOr2001] Lau, K.-K.; Ornaghi, M.: A Formal Approach to Software Component Specification. In: D. Giannakopoulou; G. T. Leavens; M. Sitaraman (Hrsg.): Workshop on Specification and Verification of Component-Based Systems (SAVCBS'01). Tampa Bay, FL 2001, S. 88-96 [MaBe2006] Marks, E. A.; Bell, M.: Executive's Guide to Service-Oriented Architecture. John Wiley & Sons, Hoboken, NJ 2006. [MDWe2002] Minz, R.; Datel, A.; Wenzky, H.: Web Services - nur eine Schimäre? In: Information Management & Consulting 17 (2002) 3, S. 6-12. [MLPB+2001] Morris, J.; Lee, G.; Parker, K.; Bundell, G.; Peng Lam, C.: Software Component Certification. In: IEEE Computer 34 (2001) 9, S. 30-36. [MMMi1995] Mili, H.; Mili, F.; Mili, A.: Reusing Software: Issues and Research Directions. In: IEEE Transactions on Software Engineering 21 (1995) 6, S. 528-561.

16

Sven Overhage, Klaus Turowski

[MMMi1998] Mili, R.; Mili, A.; Mittermeir, R. T.: A Survey of Software Storage and Retrieval. In: Annals of Software Engineering 5 (1998) 2, S. 349-414. [MSJL2006] McGovern, J.; Sims, O.; Jain, A.; Little, M.: Enterprise Service Oriented Architectures - Concepts, Challenges, Recommendations. Springer, Dordrecht 2006. [OMG2003] OMG (2003). UML 2.0 Superstructure Specification: Object Management Group. [OvTh2003] Overhage, S.; Thomas, P.: A Business Perspective on Component Trading: Criteria, Immaturities, and Critical Success Factors. In: IEEE (Hrsg.): Euromicro 2004, 31 August - 4 September 2004. Rennes, France 2004, S. 108-117 [OvTh2005] Overhage, S.; Thomas, P.: WS-Specification: Ein Spezifikationsrahmen zur Beschreibung von Web-Services auf Basis des UDDI-Standards. In: O. K. Ferstl; E. J. Sinz; S. Eckert; T. Isselhorst (Hrsg.): Wirtschaftsinformatik 2005: eEconomy, eGovernment, eSociety. Bamberg, Germany 2005, S. 1539-1558 [Parn1972] Parnas, D. L.: On the Criteria to be Used in Decomposing Systems into Modules. In: Communications of the ACM 15 (1972) 12, S. 1053-1058. [Prie1990] Prieto-Díaz, R.: Domain Analysis: An Introduction. In: Software Engineering Notes 15 (1990) 2, S. 47-54. [Prie1991] Prieto-Díaz, R.: Implementing Faceted Classification for Software Reuse. In: Communications of the ACM 34 (1991) 5, S. 89-97. [PrFr1987] Prieto-Díaz, R.; Freeman, P.: Classifying Software for Reusability. In: IEEE Software 4 (1987) 1, S. 6-16. [RSPo2003] Reussner, R.; Schmidt, H. W.; Poernomo, I.: Reliability Prediction for Component-Based Software Architectures. In: Journal of Systems and Software 66 (2003) 3, S. 241-252. [ReSc2002] Reussner, R. H.; Schmidt, H. W.: Using Parameterised Contracts to Predict Properties of Component-Based Software Architectures. In: I. Crnkovic; S. Larsson; J. Stafford (Hrsg.): Workshop on Component-Based Software Engineering (in association with 9th IEEE Conference and Workshops on Engineering of Computer-Based Systems). Lund, Sweden 2002 [Same1997] Sametinger, J.: Software Engineering with Reusable Components. Springer: Berlin, Heidelberg, 1997. [SGMu2002] Szyperski, C.; Gruntz, D.; Murer, S.: Component Software: Beyond ObjectOriented Programming. 2. Aufl., Addison-Wesley: Harlow 2002. [Turo2003] Turowski, K.: Fachkomponenten: Komponentenbasierte betriebliche Anwendungssysteme. Shaker: Aachen, 2003. [Wall2003] Wallnau, K. C.: A Technology for Predictable Assembly from Certifiable Components: Software Engineering Institute, Carnegie Mellon University, 2003. [WSHK2001] Wallnau, K. C.; Stafford, J.; Hissam, S.; Klein, M.: On the Relationship of Software Architecture to Software Component Technology. In: J. Bosch; C. Szyperski; W. Weck (Hrsg.): 6th Workshop on Component-Oriented Programming (WCOP'01). Budapest, Hungary 2001

Serviceorientierte Architekturen – Konzept und methodische Herausforderungen

17

[YeSt1994] Yellin, D. M.; Strom, R. E.: Interfaces, Protocols, and the Semiautomatic Construction of Software Adaptors. 9th ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA'94). Bd. 29 (10), Portland, OR, USA 1994, S. 176-190. [YeSt1997] Yellin, D. M.; Strom, R. E.: Protocol Specifications and Component Adaptors. In: ACM Transactions on Programming Languages and Systems 19 (1997) 2, S. 292-333. [ZaWi1995] Zaremski, A.; Wing, J. M.: Signature Matching: A Tool for Using Software Libraries. In: ACM Transactions on Software Engineering and Methodology 4 (1995) 2, S. 146-170. [ZaWi1997] Zaremski, A.; Wing, J. M.: Specification Matching of Software Components. In: ACM Transactions on Software Engineering and Methodology 6 (1997) 4, S. 333-369.

Systematisierung der Nutzenpotentiale einer SOA Florian Dreifus, Katrina Leyking, Peter Loos Zusammenfassung: Die Herausforderungen bei der Wirtschaftlichkeitsanalyse von IT-Investitionen erfahren bei der Bewertung von SOA eine Veränderung. Die Betrachtung der daraus resultierenden Implikationen bei der Ableitung angepasster Bewertungsverfahren verlangt nach fundierten, theoretischen Vorüberlegungen, die im Rahmen der Ausarbeitung durch eine Systematisierung der Nutzenpotentiale angestoßen wird.

1

Einleitung

Die vielfältigen negativen Erfahrungen im Zuge des E-Hypes Ende der neunziger Jahre sowie kontinuierlich sinkende IT-Budgets rücken Wirtschaftlichkeitsanalysen erneut in den Mittelpunkt der Betrachtung. Die Wirtschaftsinformatik, als Schnittstellendisziplin zwischen Informatik und Wirtschaftswissenschaften, nimmt sich dieser Thematik durch die Bereitstellung geeigneter Verfahren und Methoden an. Trotz aller dabei erzielten Fortschritte kommt die Adressierung praxisrelevanter Herausforderungen, wie eine verursachungsgerechte Internalisierung von Kostenund Nutzenpositionen, vielfach immer noch zu kurz. Die Bewertung innovativer Technologien verschärft diese Herausforderungen, da in dieser Konstellation auf keine adäquate Erfahrungsbasis zurückgegriffen werden kann. Serviceorientierte Architekturen (SOA), als Paradigma zukünftiger Applikationslandschaften, können auf Grund der gegenwärtigen Umsetzung durch Web Services zu den innovativen Technologien gezählt werden, denen ein großes Potential zugesprochen wird. Fundierte Anwendungserfahrungen fehlen jedoch. Die Bewertung einer Investition in SOA kann somit zur Verschärfung existierender Problemfelder führen, auf Grund ihres konzeptionellen Charakters in dezidierten Bereichen zu einer Simplifizierung beitragen sowie gänzlich neue Forschungsfragen aufwerfen. Bestehende Verfahren und Methoden müssen daher auf ihre Anwendbarkeit im SOA-Kontext überprüft, gegebenenfalls angepasst oder komplett neue Ansätze abgeleitet werden. Die Gewährleistung einer sinnvollen und nachhaltigen Durchführung dieser Maßnahmen, insbesondere in Hinblick auf die Ableitung neuer Verfahren oder Methoden, setzt stringente theoretische Vorüberlegungen voraus. Einen Teilaspekt dieser theoretischen Überlegungen, in deren Fokus die Identifikation und systematische Darstellung konstituierender Faktoren einer Wirtschaftlichkeitsanalyse sowie deren Abhängigkeiten stehen sollte, stellt die Betrachtung des Nutzens aus relevanten Unternehmensperspektiven dar. Dieser Aspekt steht im Mittelpunkt der Ausarbeitung. Hierzu werden zunächst die allgemeinen Herausforderungen bei der Bewertung von IT-Investitionen vorgestellt und jeweils dargelegt, inwiefern die zentralen Charakteristika einer SOA diese tangieren respektive um neue Aspekte ergänzen. Die Herausforderungen führten zur Erstellung zahlreicher Bewertungsansätze, die anhand des Klassifikationsschemas von Nagel [Nage1990] im Anschluss vorgestellt werden. Das Klassifikationsschema wird in diesem Zusammenhang um eine Kategorie erweitert, bevor abschließend dezidierte Beiträge zur Bewertung von SOA den Eingang in die Diskussion finden. Die im Verlauf der Betrachtung identifizierten Veränderungen der Herausforderungen an eine Bewertung zum einen, sowie die

20

Florian Dreifus, Katrina Leyking, Peter Loos

wissenschaftliche Diskussion detaillierter, SOA-spezifischer Bewertungsverfahren zum anderen, zeigen ein Forschungsdefizit innerhalb der Wirtschaftsinformatik auf. Da eine Adressierung dieses Defizits auf Basis theoretischer Vorüberlegungen vollzogen werden sollte, wird im weiteren Verlauf der Ausarbeitung aufeinen Teilaspekt hiervon abgestellt. Im Zentrum dieses Teilaspektes steht die Systematisierung wesentlicher Nutzenpotentiale von SOA. Hierbei kommt es zur Analyse des Nutzens einer SOA aus relevanten Unternehmensperspektiven, wodurch ein möglichst breites Nutzenspektrum abgedeckt wird. Das hierdurch, theoretisch geprägte Modell wird zum Abschluss der Ausarbeitung in Hinblick auf ausgewählte Praxiserfahrungen diskutiert.

2

Herausforderungen bei der Bewertung von IT Investitionen

Wirtschaftlichkeitsanalysen stoßen in der Theorie und vor allem in der Praxis auf Herausforderungen, die sich in Anlehnung an die Klassifikation von Picot, Reichwald und Wigand [PRWi2003], in eine der unten dargestellten Kategorien einordnen lassen, und die im Folgenden näher diskutiert werden:

2.3 Ganzheitliche Betrachtung 2.2 Verursachungsgerechte Zurechnung

2.4 Kontextabhängigkeit

Bewertung von IT Investitionen

2.1 Nahtlose Nutzenerhebung

2.5 Innovationsrestriktionen

Abb. 2-1: Herausforderungen bei der Bewertung von IT Investitionen 2.1

Nahtlose Nutzenerhebung

Die Nutzenerhebung als solches kann nach Brugger [Brug2005, 85] in ihrer einfachsten Form als dreistufiger Prozess angesehen werden, dessen Startpunkt durch die Identifizierung der Nutzenpotentiale gegeben ist. Die Tatsache, dass eine Vielzahl der Nutzenpotentialen nicht direkt in monetären Größen darstellbar sind, verlangt in einem zweiten Schritt ihre dezidierte Quantifizierung, auf Basis derer abschließend eine Monetarisierung stattfinden kann. Ein nahtloser Übergang von der Identifikation relevanter Nutzeffekte hin zu monetären Größen, dem eine hohe Praxisrelevanz zu Teil wird, ist oftmals auf Grund des dabei auftretenden Maßgrößenproblems im Zuge der Quantifizierung nicht gegeben. Das Maßgrößenproblem spiegelt die Problematik bei der Ableitung geeigneter Indikatoren zur Darstellung der Nutzeffekte wider [PRWi2003, 199]. Dies wird durch die Tatsache begünstigt, dass eine Vielzahl der Nutzenpotentialen qualitativer Natur sind und folglich oftmals nur ordinal oder nomi-

Systematisierung der Nutzenpotentiale einer SOA

21

nal quantifizierbar sind [Zang1973, 149-162], wodurch folglich die Monetarisierung erschwert wird. Im Rahmen der Bewertung von SOA-Invesitionen ist eine Verschiebung der aufgezeigten Problematik vorstellbar, die unter günstigen Vorraussetzungen zu einer Simplifizierung führen kann. Eine serviceorientierte Architektur, die von der Granularität der eingesetzten Services auf Teilprozesse respektive Aktivitäten ausgerichtet ist, erlaubt eine einfachere, da auf eine Ebene isolierte Erfassung der Mehrwertpotentiale. Teilgeschäftsprozesse bzw. Aktivitäten fließen in Geschäftsprozesse ein, die, ein stringentes Geschäftsprozessmanagement vorausgesetzt, einen wertschöpfenden Charakter aufweisen, der sich in entsprechenden Kennzahlen niederschlägt. Die damit verbundene Vorgabe eines Mengengerüsts vereinfacht folglich die an die Identifikation von Nutzenpotentialen anschließende Quantifizierung. Die Verschiebung der Problematik erfolgt dabei in so fern, als dass adäquate Prozesskennzahlen, für die möglichst auch monetäre Zusammenhänge bekannt sind, existieren. Wobei an dieser Stelle, ungeachtet der Verschiebung der Problematik einer adäquaten Quantifizierung als solches, nach wie vor die Herausforderungen besteht, einen nachvollziehbaren Zusammenhang zwischen der Serviceunterstützung und ihrer Auswirkung auf die Kennzahl darzulegen. 2.2

Verursachungsgerechte Zurechnung

Die verursachungsgerechte Allokation der Kosten einer IT-Investition in Form von Lizenz-, Implementierungs- oder Schulungskosten bereitet im Allgemeinen keine größeren Schwierigkeiten. Hierzu kann auf standardisierte Frameworks wie das Total Cost of Ownership Modell zurückgegriffen werden. Schwierigkeiten entstehen vielmehr bei der Herleitung nachvollziehbarer Wirkungsketten im Zuge der Analyse indirekter Nutzenaspekte. Die daraus resultierende Problematik einer verursachungsgerechten Zurechnung liegt hierbei zum einen in zeitlich verzögerten, zum andern in räumlich verteilten Nutzenaspekten begründet. Zeitliche Verzögerungen, die Horvarth [Horv2006, 735] auch unter dem Begriff des Zeitrestriktionsproblems zusammenfasst, treten beispielsweise dann auf, wenn es Folgeinvestitionen bedarf, um die vollen Potentiale der initialen Investition zu realisieren. Die zeitliche Verzögerung kann in diesem Zusammenhang auch von den allgemeinen Charakteristika der Nutzenpotentiale abhängen (siehe z.B. eine verbesserte Kundenbindung). Verbundprobleme, die Herausforderungen im Hinblick auf Abhängigkeitsbeziehungen zwischen Teilsystemen und den daraus entstehenden Implikationen zusammenfassen, verstärken diese Problematik noch. Die räumliche Verteilung von Nutzeffekten beinhaltet ähnlich dem Verbundproblem zum einen die Problematik der Identifikation relevanter Bereiche des arbeitsteiligen Leistungsverbunds eines Unternehmens, in dem die jeweiligen Nutzeffekte auftreten, zum anderen deren adäquate Aufspaltung im Anschluss an die Identifikation. Die fortschreitende Vernetzung forciert diese Problemkonstellation, wodurch zusammenfassend die Zuordnung entstehender Nutzenpotentiale auf eine zentrale Quelle vielfach nicht möglich ist und es somit oftmals zu einer subjektiven Aufteilung der Nutzeffekte kommt. Werden diese Aspekte einer Betrachtung in Hinblick auf SOA-spezifische Investitionen unterzogen, so kommt es bezüglich der zeitlichen Verzögerung zu einer Verschärfung der Problematik. Dies ist zum einen auf den konzeptionellen Charakter von SOA im Allgemeinen zurückzuführen, zum anderen auf die Wiederverwendung im Speziellen. Der konzeptionelle Charakter einer SOA verlangt zur Ausschöpfung der vollen Potentiale nach einer ganzheitlichen Adaption, die sich in der Regel schrittweise über einen längeren Zeitraum erstreckt. Diese führt ähnlich wie die Wiederverwendung zu

22

Florian Dreifus, Katrina Leyking, Peter Loos

einer Vielzahl an Nutzenpotentialen, die sich erst in Zukunft einstellen. Trotz des zentralen Vernetzungsaspekts, der durch SOA forciert wird, kann das Problem der räumlichen Verteilung von Wirkungseffekten einer Investition abgemildert werden. Vorraussetzung hierfür ist eine teilprozessorientierte Granularität, die es erlaubt, den Service und den damit verbundenen Teilprozess als zentralen Bewertungsgegenstand in den Mittelpunkt der Analyse zu stellen. Hierdurch eröffnet sich jedoch ein neues Problemfeld in Hinblick auf eine klare Verteilung der Nutzenpotentiale, die durch die simultane Nutzung eines Services durch mehrere Teilprozesse entsteht. 2.3

Ganzheitliche Betrachtung

Nur durch eine ganzheitliche Betrachtung, die in der Lage ist, auch komplexe Wechselbeziehungen im organisatorisch-technischen-personellen Gesamtsystem zu berücksichtigen, kann eine adäquate Wirtschaftlichkeitsanalyse gewährleistet werden [PRWi2003, 199]. Die funktionale, nach tayloristischen Prinzipien geprägte Aufbauorganisation erschwert bei bereichsübergreifenden IT-Systemen die Gewährleistung einer ganzheitlichen Erfassung, insbesondere im Hinblick auf die Berücksichtigung von Wechselwirkungen. Diese Problematik gilt es auch bei der Bewertung serviceorientierter Architekturen zu beachten, die zwar eine isolierte und detaillierte Betrachtung des Mehrwerts auf Teilprozessebene erlauben, den es jedoch auf Prozesslevel zu aggregieren gilt. Dabei sind mögliche Wechselwirkungen und Doppelerfassungen, die zu einer Verfälschung des Ergebnisses führen können, zu vermeiden. Der ganzheitlichen Betrachtung der Wirtschaftlichkeit einer SOA kommt des Weiteren dahingegen eine zentrale Rolle zu, als dass es sich bei SOA um ein holistisches Gesamtkonzept handelt. Dieses kann zwar als reines Integrationswerkzeug interpretiert und bewertet werden, jedoch versprechen erst die zentralen Aspekte einer kontinuierlichen Wiederverwendung sowie stringenten Modularisierung und die daraus resultierende steigende Unternehmensagilität die volle Realisierung des SOA-Nutzens. 2.4

Kontextabhängigkeit

Die Kontextabhängigkeit stellt auf die Problematik ab, dass ökonomische Wirkungen von IT-Investitionen durch die unternehmensspezifischen Rahmenbedingungen, auf die sie bei ihrer Implementierung treffen, nachhaltig beeinflusst werden [PRWi2003, S.199f]. Konkret bedeutet dies, dass Nutzenpotentiale, die in einem Unternehmen den zentralen Mehrwert einer IT-Investition beeinflussen, sich in einem alternativen Unternehmenskontext als völlig unerheblich erweisen, da sie spezifische Faktoren für eine erfolgreiche Implementierung und die damit verbundene Realisierung des Potentials voraussetzen. Dies geht des Weiteren mit unterschiedlichen Anforderungen von Unternehmen an IT-Systeme einher, die sich im Allgemeinen, insbesondere in Hinblick auf Kernprozesse, aus der Geschäftsstrategie ergeben und den Mehrwert einer Investition nachhaltig beeinflussen können. In die allgemeine Kategorie der Kontextabhängigkeit fällt auch die Systemabgrenzungsproblematik, welche die Abhängigkeit der Wirtschaftlichkeit von der Abgrenzung des jeweiligen Bewertungsgegenstandes thematisiert [Horv2006, 735]. Insbesondere letztgenannter Aspekt erfährt im SOA-Kontext eine Verstärkung. Konnte bei Anwendungssystemen, wie einem ERP oder CRM, auf Grund der unterstützten Prozesse eine wenn auch teilweise schwierige Abgrenzung stattfinden, so fällt dies bei der Bewertung von SOA

Systematisierung der Nutzenpotentiale einer SOA

23

gänzlich schwerer. An dieser Stelle muss nochmals auf den Konzeptcharakter von SOA hingewiesen werden, der zwar durch konkrete Ausgestaltungen und den damit verbundenen Implementierungen instanziiert wird, welcher jedoch die Bewertung des Gesamtkonzepts erschwert. Eine sinnvolle Abgrenzung zu finden, welche die vollen Potentiale einer SOA berücksichtigt und nicht nur auf vereinzelte Integrationsmaßnahmen abstellt, erscheint äußerst schwierig. Auch die dringend notwendige unternehmensspezifische Ausgestaltung einer SOA führt zu einer Steigerung der Kontextabhängigkeit, die eine Bewertung beinhalten muss. 2.5

Innovationsrestriktionen

Innovationsrestriktionen treten bei der Bewertung gänzlicher neuer Unterstützungsaspekte der IT in den Mittelpunkt der Betrachtung. Es gilt in diesem Zusammenhang, Potentiale zu bewerten, die über eine reine Substitution traditioneller, manuell durchgeführter Arbeitsverfahren hinausgeht. Folglich fehlt es an relevanten Erfahrungswerten, die eine Bewertung deutlich erschweren und oftmals Prognosen nach sich ziehen, die mit einer hohen Unsicherheit verbunden sind. Technologien, bei denen sich das Erfahrungsdefizit nicht isoliert auf ein Unternehmen beschränkt, verstärken diese Problematik noch, da die Nutzung externer Erfahrungswerte nicht in betracht gezogen werden kann. Da es sich bei serviceorientierten Architekturen, auf Grund ihrer Umsetzung durch Web Services, um eine innovative respektive neuartige Technologie handelt, muss diesem Aspekt zentrale Beachtung bei der Bewertung der Wirtschaftlichkeit geschenkt werden. Insbesondere unter Berücksichtigung der Tatsache, dass es bisher kaum Erfahrungen über die Umsetzung eines ganzheitlichen SOA-Ansatzes gibt. 2.6

Zusammenfassung

Die Herausforderungen im Zuge einer adäquaten Bestimmung des Mehrwerts von IT-Investitionen erfahren durch den Bewertungsgegenstand einer serviceorientierten Architektur teilweise eine Verschärfung, in einigen Teilaspekten jedoch auch eine Relaxierung. Im Allgemeinen machen die dabei aufgezeigten Problemfelder, die größtenteils aus der fortschreitenden informations- und kommunikationstechnischen Vernetzung in Unternehmen resultieren, den Einsatz klassischer Wirtschaftlichkeitsrechenverfahren weitgehend unbrauchbar. Dies liegt darin begründet, dass klassische Investitionsrechnungen auf einen isolierten Bewertungsgegenstand abstellen. Im Rahmen von Investitionen in IT gilt es jedoch, neben den Investitionsaufwendungen für die Technik bzw. Software als solches, die oftmals höheren Begleitaufwendungen für Maßnahmen zur Änderung und Anpassung organisatorischer und arbeitsrelevanter Aspekte zu berücksichtigen. Gleiches gilt für die Erfassung des Mehrwerts, der in unterschiedlichen Facetten auftreten kann. Die Auswirkungen einer nicht adäquaten Berücksichtigung der vorangegangenen Anforderungen zeigt Hirschmeier auf. So werden beispielsweise, entgegen der Anforderung einer nahtlosen Nutzenerhebung, vielfach nur Kostensenkungspotentiale bei der Bewertung von IT Investitionen berücksichtigt, während weitere Nutzenpotentiale unberücksichtigt bleiben. Hierdurch werden Unterbewertungen und damit verbundene Fehlentscheidungen deutlich begünstigt. Aber auch die Problematik einer Überwerbewertung derjenigen Potentiale, die leicht zu quantifizieren sind lässt sich beobachten, die mit ähnlichen negativen Implikationen wie eine Unterbewertung einhergeht. Dies

24

Florian Dreifus, Katrina Leyking, Peter Loos

führt zusammenfassend vielfach dazu, dass Faustregeln und Intuition als Entscheidungsgrundlage dienen und dabei betriebswirtschaftliche Messgrößen ebenso wie stringente Vorgehensweisen verdrängen [Hirs2005, 4ff]. All diese Aspekte sind in gleicher Art und Weise in der Lage, zu einem kontinuierlichen Verlust der Glaubwürdigkeit und Akzeptanz seitens des Controllings und des Managements in die Bewertungsergebnisse beizutragen. Daher verwundert es auch kaum, dass im Verlaufe der letzten Jahre und Jahrzehnte eine Vielzahl an Verfahren zur Bewertung von IT-Investitionen entstanden sind, die sich dezidiert der immateriellen Charakteristika, der kontinuierlichen Vernetzung und dem damit verbundenen Implikationen widmen. Anhand des Klassifizierungsschemas nach Nagel werden im folgenden Abschnitt zentrale Bewertungsverfahren dargelegt, Repräsentanten der jeweiligen Klassen aufgezeigt und das Klassifizierungsschema um eine weitere Kategorie ergänzt, bevor es abschließend zu einem Überblick über SOA-relevante Beiträge in diesem Bereich kommt.

3

Verfahren zur Bewertung von IT Investitionen

Die im letzten Abschnitt aufgezeigten Herausforderungen bei der Wirtschaftlichkeitsanalyse von IT-Investitionen haben im Verlaufe der letzten Jahrzehnte zur Entwicklung zahlreicher, teilweise äußerst spezifischer Verfahren geführt. Diese lassen sich nach dem umfangreichen Klassifikationsschema der Methoden zur Nutzenanalyse von Investitionen in Informationssystemen (IS) nach Nagel [Nage1990] in klassische ein- und wenig dimensionale Verfahren der Investitionsrechnung, klassische mehrdimensionale Ansätze, Vorgehensweisen mit einem strategischen Fokus sowie indikatorengetriebene Verfahren untergliedern. Die Barwertmethode, Annuitäten-Methode oder die Amortisationsrechnung [PeSt2004] stellen bekannte Vertreter der ein- und wenig dimensionalen Verfahren der Investitionsrechnung dar. Trotz der bereits im letzten Abschnitt angesprochenen zentralen Schwächen dieser Verfahren, erfreuen sie sich auf Grund ihrer einfachen Anwendbarkeit einer hohen Beliebtheit in der Praxis. Mehrdimensionale Verfahren erlauben dagegen neben der Erfassung des rein quantitativen, monetarisierbaren Nutzens auch die Berücksichtigung von qualitativen Nutzenpotentialen. Zentrale Vertreter dieser Kategorie sind u.a. die Nutzwertanalyse [Zang1973] oder die Nutzwert-Kosten-Analyse [Niem1988]. Das Model von Nolan, Norton & Company [Nage1990, 105ff] kann als typischer Repräsentant strategischer Verfahren angesehen werden, bei denen im allgemeinen der Abgleich von Potentialen einer IT-Investition mit den Vorgaben der Unternehmensstrategie fokussiert wird. Im Kontext der indikatorengetriebenen Verfahren kommen komprimierte Kennzahlen zur Ermittlung des Wertes von IS-Investitionen zum Einsatz. Als Beispiel kann hier die Balanced Scorecard [KaNo1992] angeführt werden, die von Van der Zee und De Jong [ZeJo1999] an die Anforderungen im ISKontext angepasst wurde. Neben den vier bisher aufgezeigten Kategorien zur Nutzenanalyse, die auf Nagel zurückgehen, lässt sich eine fünfte Kategorie in Form von Erklärungsmodellen ableiten, der eine vergleichsweise geringe Beachtung zukommt. Modelle, die sich in diese Kategorie einordnen lassen, basieren auf deskriptiven Theorien zur Beschreibung von Ursache-Wirkungsbeziehungen sowie den damit verbundenen ökonomischen Potentialen im Hinblick auf allgemeine architekturbezogene Merkmale und Eigenschaften. So entwickelt beispielsweise Buxmann [Buxm1996] auf Basis der Netzeffekttheorie eine deskriptive Theorie zur Beschreibung der Standardisierung von Anwendungssystemen. Eine formale

Systematisierung der Nutzenpotentiale einer SOA

25

Beschreibung der Potentiale von Modularisierung und der damit verbundenen Wiederverwendung im Hinblick auf die Softwareentwicklung und -wartung findet bei Sneed [Snee1992] statt. Baldwin und Clark [BaCl2000] betrachten ausführlich die allgemeinen Potentiale von Modularisierung und formalisieren sie unter Ausnutzung der Optionspreistheorie. Im Rahmen der Wirtschaftlichkeitsanalyse serviceorientierter Architekturen lässt sich bisher kaum eine notwendige Adaption bzw. Anpassung vorhandener Vorgehensweise konstatieren. Die aktuelle Forschung beschäftigt sich in diesem Bereich primär mit der Diskussion generischer Nutzenpotentiale [Mali2005; DJMZ2005, 23; KBSl2005, 239-255, 323f, 339f, 355f, 372f; Erl2005, 453ff, 461f; WoMa2006, 22f, 36-41, 43-51, 143f], ohne dabei auf die speziellen Anforderungen einer SOA an die Wirtschaftlichkeitsanalyse einzugehen. Daran schließen sich vereinzelt ROI-Berechnungen auf Basis ausgewählter Praxisbeispiele an [Barn2005; Barn2006], die jedoch auf keine ganzheitliche Betrachtung des SOAAnsatzes abstellen. Eine Ausnahme der ansonsten sehr generisch geführten Nutzendiskussion stellen in diesem Zusammenhang die Beiträge von Fiedler und Seufert [FiSe2007] sowie vom Brocke [voBr2007] dar. Fiedler und Seufert stellen unterschiedliche Ansatzpunkte für die ROI-Betrachtung vor, die von sehr oberflächlichen Ansätzen wie dem Announcement Ansatz bis hin zum Strategy-Maps-Ansatz von Kaplan und Norton reichen. Der Brückenschlag zu SOA wird insofern vollzogen, als dass die einzelnen Verfahren bezüglich ihrer Anwendbarkeit im SOA-Kontext diskutiert werden. Es wird in diesem Zusammenhang des Weiteren auf generelle Schwierigkeiten bei der Kosten-Nutzen-Bestimmung einer SOA-Investition abgestellt, die deckungsgleich mit dem im letzten Abschnitt vorgestellten Innovations- und Komplexitätsproblem ist. Eine dezidierte Ableitung von Ansätzen zur Adressierung dieser Problemfelder entfällt jedoch gänzlich. Diesem Defizit wirkt vom Brocke durch die Konzeption eines serviceorientierten Prozessmanagements entgegen. Basierend auf dem serviceorientierten Prozessmanagement leitet er den Ordnungsrahmen einer serviceorientierten Prozesscontrolling-Methode ab, bei der Prozessmodelle als Grundlage der Bewertung dienen. Die Prozessmodelle werden hierzu derart aufbereitet, dass einzelne Gestaltungsentscheidungen im SOA-Kontext unmittelbar in ökonomischen Zielwerten darstellbar sind. Die dadurch entstehende Methode erlaubt die detaillierte Bewertung des Einsatzes von SOA auf Aktivitätsebene, wobei sich die Betrachtung von Nutzenpotentialen auf das Outsourcing, die Integration und das Networking beschränken. Zwar unterstützt der von vom Brocke abgeleitete Ordnungsrahmens bei einer formalisierten Mehrwertdiskussion, jedoch bedarf es für eine nachhaltigere Diskussion eines formalen Erklärungsmodells, das unter anderem die Betrachtung der Wirkungen einer SOA aus unterschiedlichen Perspektiven erlauben sollte, auf welche im Folgenden näher eingegangen wird.

4

Systematisierung der Nutzenpotentiale einer SOA

4.1

Relevante Perspektiven und Ebenen des Nutzenanfalls

Serviceorientierte Architekturen repräsentieren ein fachliches IT-Konzept, das primär auf die Flexibilisierung und Integration bestehender Anwendungslandschaften abstellt. Hierdurch soll eine adäquate Unterstützung von Geschäftsprozessen, zum einen im Hinblick auf eine zeitnahe Umsetzung von Änderungen, zum anderen hinsichtlich eines nahtlosen Ablaufs, ermöglicht werden. Ein Großteil des Nutzens einer Serviceorientierung wird folglich auf Prozessebene internalisiert. Infolgedessen

26

Florian Dreifus, Katrina Leyking, Peter Loos

nimmt die Prozessperspektive bei der angestrebten Systematisierung der Nutzenpotentiale sowie ihrer Verortung im Unternehmenskontext eine zentrale Rolle ein. Im Zuge der angestrebten, detaillierten Nutzendiskussion findet in diesem Zusammenhang eine hierarchische Untergliederung der Prozessperspektive in Teilprozess-, Prozess- sowie Plattformebene statt. Die aus fachlicher Sicht geprägten und in der Prozessdimension zu adressierenden Nutzenpotentiale in Form von Agilitätssteigerungen und Integrationsaspekten werden durch Kostensenkungspotentiale bei der Betrachtung aus IT-Perspektive ergänzt. Kostensenkungspotentiale ergeben sich dabei primär durch die Wiederverwendung von Services, Konsolidierungsoptionen sowie die Möglichkeit, existierende Altsysteme effizienter in IT Landschaften zu integrieren. Die Potentiale treten dabei auf Infrastruktur- ebenso wie auf Anwendungssystemebene auf, was eine Untergliederung der IT-Perspektive in diese beiden Ebenen erfordert.

Staat

Lieferanten

Organisationsperspektive

IT Infrastrukturebene

Anwendungssystemebene

Organisationsstruktur

Plattformebene

Prozessebene

Teilprozessebene IT-Perspektive

Prozessperspektive

Kunden

Partner

Externe Unternehmenssicht (Geschäftliches Umfeld)

Abb. 4-1: Relevante Bewertungsperspektiven bei der Nutzendiskussion Neben der Diskussion des Nutzens einer Serviceorientierung aus Prozess- bzw. ITPerspektive, deren Auswahl auf Grund der allgemeinen Charakteristika und der speziellen Ausprägung von SOA mit Web Services als gerechtfertig erscheint, gilt es des Weiteren, auch eine Erörterung aus Organisationsperspektive vorzunehmen.

Systematisierung der Nutzenpotentiale einer SOA

27

Eine Diskussion aus Organisationsperspektive offenbart vordergründig zunächst eine Vielzahl an Herausforderungen, auf die im Rahmen der Ausarbeitung nicht näher eingegangen wird, eröffnet jedoch auch neue Chancen, die es bei einer ganzheitlichen Nutzendiskussion zu berücksichtigen gilt. Neben den bereits aufgeführten drei Betrachtungsperspektiven, denen im Rahmen einer ganzheitlich geführten Nutzendiskussion Beachtung geschenkt werden sollte, scheint es überdies angebracht, die relevanten Akteure Elemente des geschäftlichen Umfelds in die jeweiligen Betrachtungen mit ein zu beziehen. Denn insbesondere die Gestaltung und Wahrung effizienter Schnittstellen zu Kunden, Partnern, Lieferanten oder staatlichen Organisation offenbart innovative Nutenpotentiale, die es zu berücksichtigen gilt. Die bisher aufgeführten Perspektiven, die sich in unterschiedliche Ebenen untergliedern, stellen unter Berücksichtigung geschäftlicher Umfeldfaktoren den zentralen Ordnungsrahmen dar, entlang dessen eine SOA-spezifische Nutzendiskussion geführt wird. Der Fokus liegt in diesem Zusammenhang, wie bereits erwähnt, auf einer Nutzendiskussion aus Prozessperspektive, die durch gezielte Argumente aus IT- und Organisationsperspektive untermauert wird. Die unten angeführte Abbildung verdeutlicht nochmals graphisch die unterschiedlichen Diskussionsperspektiven, ihre Relation untereinander sowie die zentralen Elemente des geschäftlichen Umfelds. 4.2

Prozessperspektive

Bei der Betrachtung des Nutzens aus Prozessperspektive kommt es zur Unterscheidung von drei zentralen Ebenen – der Teilprozess-, Prozess- und Plattformebene. Die Ebenen sind in Bezug auf ihre Granularität ansteigend und hierarchisch geordnet. Auf Teilprozessebene werden die Nutzenpotentiale analysiert, die aus dem gezielten Einsatz eines dezidierten Services zur Unterstützung eines Teilprozesses resultieren. Teilprozesse fließen in Prozesse ein, die auf der nachfolgenden Ebene einer Betrachtung zugeführt werden. Die Analyse konzentriert sich hierbei auf die Auswirkungen der Serviceorientierung eines kompletten Prozesses. Die Vielzahl an Prozessen und den Teilprozessen, aus denen sie sich zusammensetzen, verlangt nach einem adäquaten Prozessmanagement, das auf der Plattformebene anzusiedeln ist. Die Bezeichnung Plattform wurde in diesem Zusammenhang gewählt, da eine ganzheitliche SOA-Adaption ein Prozessmanagement verspricht, bei dem, ähnlich dem Plattformkonzept in der Automobilindustrie, auf Basis einer Anzahl an Basisservices, die in unterschiedlichem Kontext wiederverwendet werden können, sich innovative Teilprozesse implementieren lassen, die im Anschluss eine zeitnahe Unterstützung differenzierender Prozesse erlauben. Das Hauptaugenmerk der Betrachtung liegt dabei auf den Potentialen eines ganzheitlichen/unternehmensweiten SOA-Einsatzes und den damit verbundenen Wirkungen auf das Controlling und die Implementierung während des Prozessmanagementkreislaufs. 4.2.1

Teilprozessebene

In Abhängigkeit der Gestaltung und der damit verbundenen Verwendungsmöglichkeiten fließen Teilprozesse in einen oder mehrere Prozesse ein. Die Prozesse geben dabei die Zielvorgabe bezüglich dem Output und der Performance des Teilprozesses vor. Teilprozesse erfahren bei der Erfüllung dieser Vorgaben durch Anwendungssysteme respektive durch deren Komponenten eine Unterstützung, die bis zur vollständigen Automatisierung reichen kann. Folglich kann ein Teilprozess manuell,

28

Florian Dreifus, Katrina Leyking, Peter Loos

teilautomatisiert oder vollautomatisiert ablaufen. Ein gezielter SOA-Einsatz auf dieser Ebene, der mit der Unterstützung eines Teilprozesses durch einen Service gleichzusetzen ist, adressiert somit primär die Verbesserung einer bestehenden Unterstützung durch ein Anwendungssystem respektive die Teil- bzw. Vollautomatisierung eines zuvor manuell durchgeführten Teilprozesses. Dies resultiert aus der Möglichkeit, mit Hilfe serviceorientierter Architekturen auch sehr granulare und spezifische Anforderungen einer effizienten Umsetzung zuzuführen [BBFJ2006, 4 f]. Die damit verbundenen Potentiale, die sich in Form von Qualitätsverbesserungen oder der Reduktion von Durchlaufzeiten niederschlagen, können unter dem Begriff des Automationsnutzens zusammengefasst werden. Neben der Möglichkeit, eine bereits bestehende Unterstützung eines Teilprozesses gezielt zu verbessern bzw. seinen Automatisierungsgrad zu steigern, ist es auch denkbar, dass lediglich bestehende Funktionalität, beispielsweise aus Altsystemen, herausgekapselt und als Service dargestellt wird [WoMa2006, 333f]. Dies führt zu Steigerungen der Kompatibilität bzw. Interoperabilität. Der dadurch entstehende Integrationsnutzen wird in erster Linie auf Prozessebene, auf der es insbesondere bei bereichsübergreifenden Prozessen vielfach zu Medienbrüchen kommt, internalisiert, kann sich aber auch durch einen verbesserten Austausch von Informationen direkt auf Teilprozessebene niederschlagen. Führt man eine Betrachtung dieser Ebene im Hinblick auf das geschäftliche Umfeld durch, so besteht ein weiteres Potential im gezielten Outtasking [GBMu2006, 31ff] bzw. der Einbindung externer Services. So bietet beispielsweise der Marktplatz bindingpoint.com über 200 äußert spezifische und granulare Services, die Teilprozesse wie die Reservierung von Hotels oder die Verifizierung von Kreditkarten übernehmen und sich auf Grund der Verwendung einheitlicher Standards nahtlos in bestehende IT-Landschaften einfügen lassen. 4.2.2

Prozessebene

Der Mehrwert eines IT-Einsatzes auf Prozessebene ergibt sich im Allgemeinen aus der Unterstützung des Prozesses bei der Erfüllung seiner aus der Unternehmensstrategie abgeleiteten Ziele und den damit einhergehenden Kennzahlen. Teilprozesse fließen in Prozesse ein. Folglich gelten die auf Teilprozessebene gemachten Aussagen bezüglich einer SOA-Adaption, insbesondere in Bezug auf den Automationsnutzen, auch auf Prozessebene. Die mit Hilfe der Unterstützung von Teilprozessen durch IT erzielbaren Potentiale können jedoch nur dann vollständig realisiert werden, wenn die Durchgängigkeit der Prozessunterstützung d.h. die Vermeidung potentieller System- bzw. Medienbrüchen gewährleistet ist. Findet ein Prozess vollständige Unterstützung durch ein integriertes Standardsoftwaresystem wie beispielsweise ein ERP, so ist diese Durchgängigkeit per se gewahrt. Findet keine vollständige Unterstützung durch ein Softwaresystem statt, d.h. mindestens ein Teilprozess wird durch eine alternative Anwendung unterstützt, was insbesondere bei bereichs- bzw. unternehmensübergreifende Prozesse oftmals zu konstatieren ist, bereitet die Aufrechterhaltung der Durchgängigkeit Probleme. Bei der Adressierung dieser Herausforderung kann der Einsatz von SOA einen zentralen Beitrag leisten. Der Beitrag begründet sich dabei in der Möglichkeit, Kompatibilität zwischen den einzelnen Geschäftsprozessen sicherzustellen und folglich eine nahtlose medien- bzw. systembruchfreie Durchführung zu gewährleisten. Die Kompatibilität wird dabei primär durch die Verwendung offener Standards wie WSDL oder SOAP sichergestellt [DJMZ2005, 9]. Die dadurch entstehenden Poten-

Systematisierung der Nutzenpotentiale einer SOA

29

tiale können unter dem Integrationsnutzen zusammengefasst werden, der sich in verkürzten Durchlaufzeiten, einer erhöhten Prozessqualität, sowie Steigerungen der Prozesstransparenz niederschlägt. Die Transparenzsteigerung erfährt in diesem Zusammenhang auf Grund der Granularität von Services und der damit verbundenen Möglichkeit, relevante Prozesskennziffern am Entstehungsort zu messen, noch eine weitere Verstärkung. Auf Basis einer erhöhten Transparenz können Abweichungen der Ist- von Sollwerten frühzeitig erkannt und entsprechende Gegenmaßnahmen zeitnah eingeleitet werden. Neben der Adressierung traditioneller, allgemeiner Prozesskennzahlen wie der Durchlaufzeit sowie unternehmensindividueller Leistungsparameter, kann durch eine Serviceorientierung auch das Kriterium der Änderungsfreundlichkeit [Allw1998] eines Prozesses positiv beeinflusst werden. Diese wird vielfach durch starre Implementierungen von Prozessen in Anwendungssystemen, die nachträgliche Veränderungen erschweren, negativ beeinflusst. Infolgedessen können notwendige Modifikationen, wie sie beispielsweise auf Grund der Änderung von Kundenbedürfnissen oder gesetzlichen Rahmenbedingungen notwendig werden, nur mit erheblichen Ressourcen- und Zeitaufwand umgesetzt werden. Die lose Kopplung von Services und ihre Granularität, die sich an den Anforderungen von Teilprozessen orientieren kann, ist in der Lage, diesem Defizit auf Prozessebene Abhilfe zu schaffen. Gezielte Änderungen an Teilprozessen, die durch einen dezidierten Service eine Unterstützung erfahren, können in der Regel isoliert vorgenommen werden, wodurch folglich weit reichende Implikationen mit der IT- Unterstützung vor- oder nachgelagerter Teilprozesse vermieden werden [KBSl2005, 247 f]. Auch besteht die Möglichkeit einer nahtlosen Integration komplett neuer Teilsprozesse in den Kontrollfluss. Hierdurch kann die Unternehmensagilität eine Steigerung erfahren, auf deren Auswirkungen die nachfolgende Plattformebene Bezug nimmt. 4.2.3

Plattformebene

Während auf den Ebenen zuvor die Annahme einer isolierten Serviceorientierung zugrunde lag, wird auf Plattformebene auf die Potentiale einer ganzheitlichen Adaption abgestellt. Auf Grund der damit eingenommenen, holistischen Betrachtungsperspektive im Hinblick auf die Prozesse adressieren die hierdurch erzielbaren Potentiale in erster Linie das Geschäftsprozessmanagement (GPM). Im Mittelpunkt des GPM steht eine kontinuierliche Prozessoptimierung, um auf Basis strategischer Vorgaben die Konkurrenzfähigkeit von Unternehmen am Markt zu wahren [ScSe2006, 4ff]. Die kontinuierliche Prozessoptimierung setzt dabei einen ganzheitlichen GPMKreislauf voraus, der sich aus den Phasen Strategie, Design, Implementierung und Controlling zusammensetzt [Allw2005, 89ff]. Auf Grund stetig steigender Agilitätsanforderungen wird hierbei insbesondere den beiden letztgenannten Phasen eine hohe Bedeutung zu Teil. Das Prozesscontrolling muss in der Lage sein, möglichst frühzeitig sich ändernde Anforderungen und Bedürfnisse zu erkennen, die es auf Basis einer Strategieänderung und der damit verbunden Neugestaltung oder Adjustierung von Prozessen auch möglichst zeitnah im Rahmen der Prozessimplementierung umzusetzen gilt. Standen auf der Prozessebene überwiegend die operativen Aspekte des Prozesscontrollings im Vordergrund, nehmen auf Plattformebene vor allem die strategischen Implikationen in Form der frühzeitigen Erkennung veränderter Anforderungen und Bedürfnisse die zentrale Rolle ein. Hierbei geht es insbesondere um die Erkennung bestimmter Muster und Abhängigkeiten aus den extrahierten Prozessdaten. Die dazu notwendige Beschaffung und Aufbereitung von Informationen wird

30

Florian Dreifus, Katrina Leyking, Peter Loos

durch Anwendungssysteme unterstützt respektive durch sie erst ermöglicht. Die Realisierung der damit verbundenen Potentiale wird jedoch auf Grund heterogener Anwendungslandschaften stark gehemmt. Folglich führt eine mit Hilfe von Services forcierte Integration, neben den bereits aufgezeigten Facetten des Integrationsnutzens, des Weiteren zu einem nachhaltigen strategischen Controlling im Zuge des Geschäftsprozessmanagements. Dies erfährt durch eine feingranulare Modularisierung in Form von Services dahingegen noch eine Verstärkung, als dass hierdurch eine Messung der relevanten qualitativen und quantitativen Prozesskennzahlen am Entstehungsort möglich wird, was zu einer zweifelsfreien Herkunft und der damit einhergehenden Zuordnung der Daten führt. Die damit verbundene Möglichkeit einer frühzeitigen Erkennung von Wandelerscheinungen und Veränderungen führt nur dann zu einem Nutzen für das Unternehmen, wenn auf Basis der daraus resultierenden Strategieveränderung die Empfehlungen des daran anschließenden Prozessdesigns zeitnah eine Umsetzung finden. Dies scheitert jedoch vielfach an unflexiblen Anwendungssystemen, die eine zeitnahe Reaktion auf Grund historisch gewachsener interner wie externer Verflechtungen nicht zulassen [ScSe2006, 32f]. Eine modulare Ausrichtung von Anwendungssystemen im Allgemeinen und somit von SOA im Speziellen verspricht diese Schwachstelle in zweierlei Hinsicht positiv zu adressieren. Auf Grund der im Zuge einer Serviceorientierung forcierten losen Kopplung von Services können Anpassung oder Erweiterungen von bestehenden Prozessen ebenso wie die Erstellung komplett neuer Prozesse leichter auf Ebene der IT abgebildet werden [KBSl2005, 6f, 239ff]. Als weiteren Aspekt wird durch die Modularität in Form von Services die Wiederverwendung mit Nachdruck vorangetrieben. Wiederverwendung an sich schlägt sich dabei auf allen bisher betrachteten Ebenen nieder, jedoch kommt sie erst aus dem Betrachtungswinkel der Plattformebene zur vollen Entfaltung. Im Allgemeinen werden der Wiederverwendung eine positive Wirkung auf die Softwarequalität, die Kosten sowie die Produktivität zugesprochen [z.B. Rada1995, 40; Same1997, 11]. Während Qualitätssteigerungen in erster Linie aus Teilprozess- bzw. Prozessperspektive relevant sind, da sie sich auf dort angesiedelte Ausführungsaspekte beziehen, treten Produktitvitätssteigerungen auf Plattformebene in den Mittelpunkt der Betrachtung. Sie beziehen sich dabei auf die Umsetzung von Anforderungen durch die Geschäftsprozesse Eine erhöhte Produktivität durch Reduktion des Aufwands führt in diesem Zusammenhang einerseits zu niedrigeren Entwicklungskosten, auf die an dieser Stelle nicht näher eingegangen wird, andererseits zu einer Reduktion der Entwicklungszeit und folglich zu einer Verkürzung der „Time To Market“ bei der Umsetzung neuer Anforderungen. Die „Time to Market“, eine von produzierenden Industrien geprägte Kennzahl, gibt in diesem Zusammenhang Auskunft über die Länge des Zeitraums, von der Initiierung einer Prozessveränderung bzw. einer vollständigen Neugestaltung bis zu deren vollständigen Implementierung. Das hohe Potential einer Optimierung dieses Parameters liegt in der Tatsache begründet, dass gerade im Hinblick auf die Initiierung eines Wandels, beispielsweise durch die Adressierung eines neuen Marktsegments, der Implementierungsdauer einer zentrale Rolle zukommt, da der aus dem Wandel zu erzielende Mehrwert mit der kontinuierlichen Schließung des sog. „Windows of Opportunity“ sukzessive sinkt. Abschließend lässt sich konstatieren, dass durch die Modularisierung und die Integration auf Plattformebene Unternehmen in die Lage versetzt werden, Wandelerscheinungen frühzeitig zu erkennen (Controlling) und daraus notwendige Veränderungen zeitnah umzusetzen (Implementierung). Die dadurch erzielbaren Potentiale bezüglich einer Agilitätssteigerung werden in der Wirtschaftsinformatik auch vielfach

Systematisierung der Nutzenpotentiale einer SOA

31

unter dem Begriff des Real Time Enterprises [Sche2003] diskutiert, zu dessen Entwicklung SOA folglich einen zentralen Beitrag leisten kann. 4.3

IT-Perspektive

4.3.1

Infrastrukturebene

Die in einer Organisation eingesetzten Software- und Hardwarelösungen werden durch die Infrastrukturebene repräsentiert. Betriebssysteme lassen sich ihr dabei ebenso zuordnen wie die Rechnerausstattung eines Arbeitsplatzes, Datenbanken oder komplette Netzwerklösungen [PRWi2003, 145]. Ihr primäres Nutzenpotential liegt in der Kombination einzelner Infrastrukturkomponenten und der damit verbundenen Unterstützung dezidierter Aufgaben begründet. Die Hauptaufgabe besteht in diesem Zusammenhang darin, eine adäquate Unterstützung der auf der Infrastruktur aufbauenden Anwendungssysteme sicherzustellen. Die Infrastrukturelemente repräsentieren somit die fundamentale Grundlage einer Unterstützung von Geschäftsprozessen, deren Existenz eine unabdingbare Notwendigkeit darstellt. Hierdurch kommt es im Allgemeinen zu einer reinen Kostenfokussierung auf dieser Ebene. Eine Diskussion der positiven Wirkungen einer Serviceorientierung stellen daher in erster Linie auf Kostenreduktionspotentiale ab. Primär geht die Serviceorientierung mit Investitionskosten einher, wie sie beispielsweise für einen Enterprise Service Bus (ESB) oder den Aufbau eines zentralen Service-Repositories anfallen. Jedoch trägt insbesondere der Enterprise Service Bus dazu bei, eine möglichst hohe Technologieunabhängigkeit bei der Serviceorientierung zu wahren [DJMZ2005, 8]. In Folge dessen wird die Investitionssicherheit aufrechterhalten und potentielle Lock In-Effekte vermieden. Durch die bereits erwähnten Potentiale eines gezielten Outsourcings bzw. -taskings im Zuge der Serviceorientierung wird des Weiteren die Möglichkeit eröffnet, interne Infrastrukturressourcen abzubauen bzw. ihren Einsatz zu optimieren. Dieser Aspekt findet sich in ähnlicher Ausprägung auch auf Anwendungssystemebene wieder. Eine Optimierung mit der Zielsetzung des effizienten Einsatzes vorhandener Ressourcen wird neben der Möglichkeit des Outsourcings bzw. -taskings ferner durch den zielgerichteten Einsatz Adaptive Computing-orientierter Ansätze im SOA-Kontext forciert [WoMa2006, 399ff]. 4.3.2

Anwendungssystemebene

Anwendungssysteme dienen der Erfüllung betrieblicher Aufgaben, die sich primär in der Unterstützung von Geschäftsprozessen widerspiegelt. Sie verbinden dabei Menschen und Maschinen über in der Infrastrukturebene bereitgestellte Kommunikationsnetze und führen zur Teil- bzw. Vollautomatisierung der durch sie unterstützten Prozesse. Folglich stellt sich ein Großteil der damit verbundenen Nutzenpotentiale ihres Einsatzes auf der (Teil-)Prozessdimension ein, wodurch die Wirtschaftlichkeit einer Investition in sie maßgeblich beeinflusst wird. Da im Zuge der Serviceorientierung die Prozessdimension bei der Bewertung immer stärker in den Fokus der Betrachtung rückt – es geht nicht um die Bewertung einer monolithischen Anwendung wie einem ERP, sondern um die Bewertung eines Konzepts, das auf Teilprozessebene bereits ansetzt – stellt die Betrachtung auf Anwendungsebene

32

Florian Dreifus, Katrina Leyking, Peter Loos

hauptsächlich auf Kostengesichtspunkte hinsichtlich des Betriebs der Anwendungssysteme ab. Eine kostenfokussierte Diskussion in Bezug auf die IT-Unterstützung wäre an dieser Stelle bereits auf Prozessebene denkbar gewesen. Von dieser Vorgehensweise wurde jedoch auf Grund der allgemeinen Problematik bei der Verrechnung von Gemeinkosten, die nicht den Betrachtungsgegenstand dieser Ausarbeitung darstellen, Abstand genommen. Folglich kommt es auf der Anwendungsebene zu einer ganzheitlichen Diskussion möglicher Kostensenkungspotentiale aus IT-Perspektive, in der auch auf Projektkosten abgestellt wird. Die bereits aufgezeigten Potentiale der Wiederverwendung von Services erfahren auf Anwendungssystemebene eine Erweiterung, die sich in Kostensenkungspotentialen manifestiert. So ist infolge einer fortschreitenden SOA-Adaption mit der Senkung von Projektkosten bei der Implementierung neuer Anforderungen zu rechnen, da hierbei auf grundlegende Funktionalitäten zurückgegriffen werden kann und diese nicht neu respektive mehrfach entwickelt werden müssen. Des Weiteren stellt eine Vielzahl an Wiederverwendungen in unterschiedlichem Kontext eine hohe Robustheit und somit Qualität einzelner Funktionalitäten sicher. Folglich können Kosten für Tests reduziert und Risiken für Fehlentwicklungen minimiert werden. Neben diesen eher projektspezifischen Faktoren wird der Wiederverwendung überdies ein Beitrag zur Vermeidung redundanter Datenhaltung zugetraut [KBSl2005, 6f], wodurch die Schaffung einer soliden Datenbasis für die Entscheidungsfindung unterstützt wird, deren Mehrwert bereits im Rahmen der Diskussion über ein verbessertes Controlling ausführlich dargelegt wurde. Ferner wird in diesem Zusammenhang der Aufwand für Data Mining sowie den damit verbundenen Aktivitäten zur Aufbereitung und Analyse reduziert. Dieser die komplette Systemlandschaft betreffende Aspekt erfährt dahingegen noch eine Verstärkung, dass auch Altsysteme durch ein sog. Service Enablement in diesen Prozess Eingang finden können und somit eine größtmögliche Ganzheitlichkeit gewahrt bleibt. Das Service Enablement führt dabei im Allgemeinen zu einer effizienten Ausnutzung bereits getätigter Investitionen und erlaubt eine stufenweise und folglich risikominimierte Adaption von SOA. Abschließend lässt sich festhalten, dass im Zuge einer voranschreitenden SOA-Einführung mit einer allgemeinen Konsolidierung bestehender Anwendungssystemlandschaften zu rechnen ist und es durch die Verwendung einheitlicher Standards zu einer Betriebskostensenkung der oftmals proprietären Schnittstellen zwischen Systemen kommt. Ob eine Reduktion von allgemeinen Wartungskosten eintritt, bleibt abzuwarten, da durch die Verteiltheit und eine steigende Komplexität einer fortschreitenden Servicelandschaft neue Anforderungen an die Wartung gestellt werden, die zum jetzigen Zeitpunkt noch nicht absehbar sind. 4.4

Organisationsperspektive

4.4.1

Organisationsstruktur

Die Verknüpfung von Produktionsfaktoren zur Erzeugung und Verwertung von Sachund Dienstleistungen stellt die grundlegende Aufgabe von Unternehmen dar. Zur Erfüllung dieser Aufgaben bedarf es Regeln, die das Zusammenwirken von menschlichen und maschinellen Aufgabenträger koordinieren. Diese Regeln werden im Allgemeinen als Organisation bezeichnet, die sich in Aufbau- und Ablauforganisation untergliedern lässt [Sche2002, 3ff]. Die Ablauforganisation, in deren Fokus das zeitlich-logische Verhalten von Vorgängen zur Aufgabenerfüllung innerhalb des

Systematisierung der Nutzenpotentiale einer SOA

33

Unternehmens steht, wird dabei maßgeblich durch Geschäftsprozesse repräsentiert [Sche2002, 4], aus deren Perspektive die Nutzenpotentiale einer SOA-Investition bereits ausführlich diskutiert wurden. Daher wird auf dieser Ebene in erster Linie auf positive Einflussfaktoren einer SOA-Adaption im Hinblick auf die Aufbauorganisation abgestellt, in deren Fokus die statischen Strukturen eines Unternehmens stehen. Aus der Nutzenperspektive betrachtet kann durch SOA eine für IT- wie auch fachliche Abteilungen einheitliche Sprache geschaffen werden [BBFJ2006, 17], auf deren Basis eine nachhaltige Optimierung der Leistungs-, Informations- und Kommunikationsbeziehungen zwischen beiden Bereichen ermöglicht wird. Hierdurch können Reibungsverluste und Fehlinterpretation im alltäglichen Informationsaustausch vermieden werden, die vielfach für das Scheitern von Projekten verantwortlich sind. Des Weiteren kann mittels SOA eine nachhaltige Unterstützung bei der generellen organisatorischen Gestaltung erfolgen. Im Mittelpunkt der organisatorischen Gestaltung steht die Sicherstellung der Verteilung von Aufgaben auf organisatorische Einheiten, sowie deren Koordination. Hierdurch soll langfristig die Erreichung der Unternehmensziele gewährleistet werden. Eine Serviceorientierung mit einer prozessorientierten Granularität kann in diesem Zusammenhang beispielsweise bei der Organisationsproblematik von Supportprozessen einen positiven Beitrag leisten. So erfährt neben dem bereits aufgezeigten Outtasking auch der Shared ServiceAnsatz zur Adressierung der Problematik von Supportprozessen eine Unterstützung durch SOA [vgl. WoMa2006, 36ff]. Die Wahrung einer möglichst hohen technologischen Unabhängigkeit im SOA-Kontext erlaubt es in diesem Zusammenhang des Weiteren, organisationsinterne ebenso wie organisationsexterne Zusammenschlüsse systemseitig leichter durchzuführen und stellt somit nicht mehr den beschränkenden Faktor derartiger Maßnahmen dar. Die Einführung serviceorientierter Architekturen kann, neben den bereits aufgezeigten Potentialen aus Organisationsperspektive, ferner auch zu Auswirkungen auf die allgemeine Organisation der IT-Abteilung führen. So wird eine explizite Zerlegung der Zielsetzung eines Projekts in Teilziele möglich, wodurch die Projektziele klarer festgelegt und eine verbesserte Steuerung ermöglicht wird. Somit können insbesondere Mitarbeiter aus der IT- ebenso wie der Fachabteilung effizienter eingesetzt werden. Auch wenn ein Aufwand für Schulungen im Zuge der Adaption von SOA entsteht, erlaubt eine serviceorientierte Architektur im Gegenzug bereits vorhandenes Wissen, beispielsweise über Programmiersprachen, weiterhin anzuwenden, da die Umsetzung der Funktionalität von Services nach wie vor in diesen Technologien vorgenommen werden kann [WoMa2006, 333-376]. 4.5

Geschäftliches Umfeld

Unternehmen repräsentieren aus einer systemorientierten Betrachtungsweise Subsysteme nationaler oder globaler Wirtschaftssysteme. In diesem Zusammenhang kann ein Unternehmen als ein offenes System angesehen werden, das komplexe Beziehungen über die Systemgrenzen hinweg pflegt. Die Elemente, mit denen ein Unternehmen dabei in Beziehung steht, lassen sich im Allgemeinen einer der folgenden Klasse zuordnen – Kunden, Partner, Lieferanten und Staat. Daneben ließe sich des Weiteren noch die Gruppe der Fremdkapitalgeber unterscheiden, die jedoch in der folgenden Diskussion außen vor bleibt. Der Nutzen durch die Serviceorientierung bezieht sich aus dieser Sicht in erster Linie auf Geschäftsprozess, die über die Unternehmensgrenzen hinweg gehen und dabei externe Anwendungssysteme, wie sie bei Kunden oder Lieferanten im Einsatz sind, mit einbeziehen. Die

34

Florian Dreifus, Katrina Leyking, Peter Loos

durch SOA erzielbare Kompatibilität hilft dabei den Abstimmungs- und Änderungsaufwand hinsichtlich Schnittstellen zu reduzieren und unterstützt bei der nachhaltigen Umsetzung innovativer Kooperationsansätze wie dem Responsive Replenishment, eine Erweiterung des Vendor Management Inventory-Ansatzes [vgl. WoMa2006, 256f]. Der Staat spielt bei der Betrachtung des SOA-Nutzens insofern eine Rolle, als durch ihn gesetzliche Vorgaben für das Reporting und Controlling entstehen, die es einzuhalten gilt (Compliance) und die einem stetigen Wandel unterzogen sind. Ein weiteres Nutzenpotential im Zuge von SOA aus externer Sicht besteht in der Möglichkeit, existierende Services anderen Unternehmen zur Nutzung anzubieten und somit eine ausreichende Auslastung sicherzustellen und neue Einnahmequellen zu generieren [Barr2003, 22]. Die aufgezeigten Nutzenpotentiale werden auf den bereits betrachteten Ebenen internalisiert. Die Berücksichtigung geschäftlicher Umfeldfaktoren repräsentiert folglich keine neue Bewertungsperspektive, sondern stellt vielmehr eine relevante Betrachtungssicht zur Verfügung, der bei einer SOAspezifischen Nutzendiskussion auf Grund der Interoperabilitätspotentiale besondere Beachtung geschenkt werden sollte.

5

Praxisbeispiele

Nachdem im vorherigen Kapitel die theoretischen Nutzenpotentiale einer SOA aus unterschiedlichen Perspektiven betrachtet wurden, kommt es zum Abschluss der Ausarbeitung zu einer daran angelehnten Diskussion ausgewählter Praxiserfahrungen. Die Auswahl der Praxiserfahrungen orientierte sich dabei an einer möglichst hohen Abdeckung der oben aufgeführten Nutzenperspektiven. Serviceorientierte Architekturen bedürfen, wie bereits mehrfach angesprochen, einer spezifischen Ausprägung. Um eine Vergleichbarkeit zu wahren beziehen sich die folgenden Ausführungen daher auf Erfahrungen die im Zuge der Adaption der Enterprise SOA gemacht und von Woods und Mattern [WoMa2006] ausführlich dokumentiert wurden. Bei der Enterprise SOA handelt es sich um die spezifische Ausprägung einer serviceorientierten Architektur der in Walldorf ansässigen beheimateten SAP AG. Neben der Vergleichbarkeit gab ferner die stringente Prozessorientierung bei der Gestaltung von Services den Ausschlag zur Konzentration auf diese Instanziierung. Ein exzellentes Beispiel, wie insbesondere die Beziehungen eines Unternehmens zu seinem geschäftlichen Umfeld nachhaltig verbessert werden können, gibt der Einsatz von SOA bei Europas zweitgrößtem Hersteller und Großhändler für Zucker. Durch ein immer größer werdendes Netz an Landwirten, die den Grundstoff der Zuckerproduktion in Form von Zuckerrüben liefern, stiegen auch die Herausforderungen an eine adäquate Informationsverteilung. Eine weitere Herausforderung stellt die Tatsache dar, dass die Landwirte in der Regel Anteile am Unternehmen besitzen und folglich als Partner in Erscheinung treten. Des Weiteren beziehen sie direkt vom Unternehmen auch Materialien wie Saatgut oder Dünger, so dass sie, neben der Lieferanten- und der Partnerrolle, auch als Kunde fungieren. Durch den Einsatz von Services in Kombination mit einer Portallösung wurde es möglich, die Abläufe dezidierter Teilprozesse den Landwirten transparent zu machen. Konkret bedeutet dies, dass mit Hilfe von Services direkte Zugriffsmöglichkeiten auf geplante Liefermengen ebenso wie eine Übersicht auf Anteilsscheine oder den aktuellen Lieferstatus von Bestellungen realisiert werden konnten. Wo es vorher zu einem fehlerbehafteten Mailversand vordefinierter Informationen kam, kann jetzt ein individueller Informationsbedarf nahezu in Echtzeit befriedigt werden. Neben den allgemeinen

Systematisierung der Nutzenpotentiale einer SOA

35

Automationsnutzen kann hierdurch auch eine Steigerung der Lieferantenzufriedenheit erzielt werden, die sich im Allgemeinen in einer engeren Bindung niederschlägt. Auch die dritte Rolle, die ein Landwirt annehmen kann, wird durch SOA adressiert. So konnte mit Hilfe von Services der Prozess einer Bestellung über das Internet nahtlos integriert werden, wodurch Medienbrüche beseitigt und Durchlaufzeiten verkürzt werden konnten. Somit wurde bei dieser Anwendung von SOA in erster Linie Nutzen auf Teilprozess- und vor allem Prozessebene geschaffen, die eine Betrachtung des geschäftlichen Umfelds notwendig machten. Dass SOA insbesondere für die Lösung von Integrationsproblemen ein großes Potential beigemessen wird, zeigt auch das nächste Beispiel. Die Tochtergesellschaft eines französischen Medienkonzerns, die sich für das Anzeigengeschäft verantwortlich zeichnet, ermöglicht seinen Kunden die Annahme von Aufträgen über das Internet. Auf Grund einer mangelnden Interoperabilität mit den Backendsystem kam es jedoch bei dem dazugehörigen Prozess der Auftragsbearbeitung zu Systembrüchen mit den damit verbundenen Folgen eines ineffizienten Prozessablaufs. Durch die Darstellung der einzelnen Teilprozesse in Form von granularen, wiederverwendbaren Services konnte eine Integration, die sich vor allem in Kosteneinsparungen niederschlug, realisiert werden. Ferner kam es zusätzlich, auf Grund der Möglichkeit neue Funktionalitäten einzubinden, zu einer Steigerung der Kundenzufriedenheit. Neben diesen Potentialen aus Prozesssicht konnten auch Mehrwertpotentiale auf Plattformebene gehoben werden. Diese beziehen sich auf eine erfolgreich vollzogene Wiederverwendung der für den Auftragsbearbeitungsprozess entwickelten Services in einem anderen Kontext, wodurch neben den Entwicklungskosten vor allem die Entwicklungszeit erheblich gesenkt werden konnte. Einen primär aus organisatorischer Perspektive betrachteten Nutzen konnte die IT-Tochter eines großen italienischen Mischkonzerns mit Fokus auf der Luftfahrt aus der Adaption von SOA ziehen. So wurde es durch SOA möglich eine nahtlose Zentralisierung der Treasuryfunktion vorzunehmen, die zuvor dezentral über mehr als 100 Filialen verteilt war. Durch den Einsatz von Services und eines Portals konnte dies ohne größere Änderungen von Abläufen oder Reorganisationsmaßnahmen geschehen. Auch die aus IT-Perspektive angesprochenen Kostensenkungspotentiale werden durch den Einsatz von SOA durch Unternehmen nachverfolgt. So stellt die SOA-Einführung eines führenden Stahlunternehmens in erster Linie auf die durch SOA erzielbare Konsolidierung und die damit verbundenen Senkung der Total Cost of Ownership ab. Wenn auch der dazugehörige Prozess noch nicht vollständig abgeschlossen ist, was auf Grund der über Jahrzehnte gewachsenen IT-Landschaft auch nicht weiter verwundert, so bestätigen erste Resultate diese Erwartungen.

6

Fazit

Die Ausarbeitung zeigte auf, inwiefern die Herausforderungen bei der Bestimmung des Mehrwerts einer allgemeinen IT-Investition durch den Bewertungsgegenstand einer serviceorientierten Architektur eine nachhaltige Veränderung erfahren. Allgemein lies sich dabei feststellen, dass es durch den Vernetzungscharakter einer SOA stellenweise zu einer Verschärfung der Problemsituation kommt, die jedoch im Gegenzug, auf Grund der Prozessnähe einer SOA, mit partiellen Simplifizierungen einhergeht. Unter den wenigen SOA spezifischen Wirtschaftlichkeitsanalysen, die sich diesen Anforderungen annehmen und dabei einen allgemeingültigen Charakter aufweisen, erscheint die von vom Brocke vorgeschlagene Methode am vielver-

36

Florian Dreifus, Katrina Leyking, Peter Loos

sprechensten. Sie adressiert die Nutzenpotentiale auf Aktivitätsebene und sorgt anschließend für eine ganzheitliche Aggregation der Ergebnisse auf Prozessebene. Da die Methode dabei ausschließlich auf drei Nutzenpotentiale einer SOA abstellt, besteht grundsätzlich weiterer Forschungsbedarf in diesem Gebiet, weswegen es im Hauptabschnitt der Ausarbeitung zu einer Systematisierung der Nutzenpotentiale, die als Grundlage einer Herleitung SOA spezifischer Bewertungsverfahren angesehen wird, kam. Die dabei aufgezeigten Perspektiven, mit den dazugehörigen Betrachtungsebenen, bieten bei der Herleitung von Methoden zu Bewertung der Wirtschaftlichkeit serviceorientierter Architekturen einen strukturiertes Rahmenkonstrukt, dass in erster Linie die Nachvollziehbarkeit einer Methode unterstützt. Allgemein ist die Erstellung spezifischer Verfahren mit Aufwand verbunden, wodurch sich die Frage nach dem damit verbundenen Mehrwert aufdrängt. Denkbar wäre die Anwendung bestehender Verfahren, mit dem Bewusstsein, dass diese die dargstellten Anforderungen nicht zur Gänze erfüllen. Dennoch gilt es hierbei zu bedenken, dass im Gegensatz zu abgegrenzten Standardapplikationen, der Mehrwert einer SOA in unterschiedlichsten Facetten und auf teilweise divergierenden Ebenen auftreten kann, die es im Hinblick einer nachhaltigen Bewertung zu beachten gilt. Eine isolierte und in erster Linie auf Kostenreduktion fokussierte Wirtschaftlichkeitsbetrachtung, wie sie vielfach in der Praxis zu konstatieren ist, wird nicht in der Lage sein, die für die Einführung einer SOA notwendigen Mittel und Aufwendungen über einen längeren Zeitraum zu rechtfertigen.

Literaturverzeichnis [Allw2005] Allweyer, T.: Geschäftsprozessmanagement - Strategie, Entwurf, Implementierung, Controlling. W3L: Herdecke, Bochum, 2005. [Allw1998] Allweyer, T.: Adaptive Geschäftsprozesse. Rahmenkonzept und Informationssysteme. Gabler: Wiesbaden, 1998. [BaCl2000] Baldwin, C. Y.; Clark, K. B.: Design Rules - Vol. 1: The Power of Modularity. MIT Press: 2000. [Barn2005] Barnes, M.: Mitsui-Soko Drives Service-Oriented Architecture for Business Agility. Gartner Research: Stamford, 2005. [Barn2006] Barnes, M.: Superpartners Uses Service-Oriented Architecture to Increase market Share. Gartner Research: Stamford, 2006. [Barr2003] Barry, D. K.: Web Services and Service-Oriented-Architectures: Your Road Map to emerging IT, 2003. [BBFJ2006] Bieberstein, N.; Bose, S.; Fiammante, M.; Jones, K.; Shah, R.: Service-Oriented Architecture (SOA) Compass - Business Value, Planning, and Enterprise Roadmap. IBM Press : Upper Saddle River, 2006. [Brug2005] Brugger, R.: Der IT Business Case. – Kosten erfassen und analysieren, Nutzen erkennen und quantifizieren, Wirtschaftlichkeit nachweisen und realisieren. Springer: Berlin, 2005. [Buxm1996] Buxmann, P.: Standardisierung betrieblicher Informationssysteme. Wiesbaden, 1996.

Systematisierung der Nutzenpotentiale einer SOA

37

[DJMZ2005] Dostal, W.; Jeckle, M.; Melzer, I.; Zengler, B.: Service-orientierte Architekturen mit Web Services Konzepte - Standards - Praxis. Spektrum: München, 2005. [Erl2005] Erl, T.: Service-oriented architecture concepts, technology, and design. Upper Saddle River, NJ : Prentice Hall Professional Technical Reference, 2005. [FiSe2007] Fiedler, M.; Seufert, A.: Der SOA-Entscheidungsprozess und Ansatzpunkte für ROI-Betrachtungen. In: HMD - Praxis der Wirtschaftsinformatik 253, S. 28-36, 2007. [GBMu2006] Gross, J.; Bordt, J.; Musmacher, M.: Business Process Outsourcing. Grundlagen, Methoden, Erfahrungen. Wiesbaden, 2006. [Hirs2005] Hirschmeier, M.: Wirtschaftlichkeitsanalysen für IT-Investitionen – Modelle und Methoden zur Beurteilung von IT-Investitionen. WiKu: Berlin, 2005. [Horv2006] Horváth, P.: Controlling. 10. Auflage. Vahlen, München, 2006. [KaNo1992] Kaplan, R. S.; Norton, D. P.: The Balanced Scorecard - Measures That Drive Performance. In: Harvard Business Review, 70 (1992) 4, S. 71-79. [KBSl2005] Krafzig, D.; Banke, K.; Slama, D.: Enterprise SOA Service- Oriented Architecture best practices. Prentice-Hall: New York, 2005. [Mali2005] Malinverno, P.: The Successful Business Case for SOA. Gartner Research: Stamford, 2005. [Nage1990] Nagel, K.: Nutzen der Informationsverarbeitung Methoden zur Bewertung von strategischen Wettbewerbsvorteilen, Produktivitätsverbesserungen und Kosteneinsparungen. 2., überarb. Aufl. R. Oldenbourg: München, 1990. [Niem1988] Niemeier, J.: Konzepte der Wirtschaftlichkeitsberechnung bei integrierten Informationssystemen. In: Horvàth, P. (Hrsg.): Wirtschaftlichkeit neuer Produktions- und Informationstechnologie. Stuttgart, S. 15-34, 1988. [PeSt2004] Perridon, L.; Steiner, M.: Finanzwirtschaft der Unternehmung. 13., überarb. und erw. Aufl. Vahlen: München, 2004. [PRWi2003] Picot, A.; Reichwald, R.; Wigand, R. T.: Die grenzenlose Unternehmung. 5., aktualisierte Auflage. Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH: Wiesbaden, 2003. [Rada1995] Rada, R.: Software Reuse. Intellect Books: Bristol, 1995. [Same1997] Sametinger, J.: Software Engineering with Reusable Components, 1997. [Sche2002] Scheer, A. W.: ARIS - Vom Geschäftsprozess zum Anwendungssystem. Vierte, durchgesehene Auflage. Springer: Berlin, 2002. [Sche2003] Scheer, A. W.: Real-Time Enterprise mit beschleunigten Managementprozessen Zeit und Kosten sparen. Springer: Berlin, 2003. [ScSe2006] Schmelzer, H. J.; Sesselmann, W.: Geschäftsprozessmanagement in der Praxis - Kunden zufrieden stellen Produktivität steigern wert erhöhen. 5., vollständig überarbeitete Auflage. Hanser: München, 2006. [Snee1992] Sneed, H.: Softwaresanierung (Reverse und Reengineering). Rudolf Müller Fachbücher: Köln, 1992. [ZeJo1999] van der Zee, J. T. M.; de Jong, B.: Alignment is Not Enough: Integrating Business and Information Technology Management with the Balanced Business Scorecard. In: Journal of Information Systems 16 (1999) 2, S. 137-156.

38

Florian Dreifus, Katrina Leyking, Peter Loos

[voBr2007] vom Brocke, J.: Wirtschaftlichkeit serviceorientierter Architekturen - Management und Controlling von Prozessen als Serviceportfolios. In: HMD - Praxis der Wirtschaftsinformatik (2007) 253, S. 84-111. [WoMa2006] Woods, D.; Mattern, T.: Enterprise SOA. 1. Auflage. O'Reilly: Sebastopol, 2006. [Zang1973] Zangemeister, C.: Nutzwertanalyse in der Systemtechnik eine Methodik zur multidimensionalen Bewertung und Auswahl von Projektalternativen. 4. Aufl. Komm. Wittemann: München, 1973.

Integration von service-orientierten IT-Architekturen in die Geschäftsarchitektur Thomas Deelmann Zusammenfassung: Der vorliegende Beitrag untersucht die Möglichkeit der Integration von service-orientierten IT-Architekturen in die Geschäftsarchitektur aus einem strategischen Blickwinkel. Nach Betrachtung des grundsätzlichen Einsatzzweckes von IT (Substitution von Arbeit durch Kapital) werden auf Basis einer Diskussion der Analyseeinheiten Strategie, IT, und Geschäftsmodell sowie ihren Zusammenhängen Services in diesen Kontext mit einbezogen und dadurch als ein aus strategischer Perspektive geeigneter Ansatz zur SWEntwicklung charakterisiert.

1

Einleitung

Betrachtet man allein die Medienpräsenz (vgl. für eine Entwicklung im Zeitverlauf exemplarisch [oV2007]), so sind service-orientierte Architekturen (SOA) seit einigen Jahren zu einem beliebten Software-Architekturprinzip geworden. Hierbei werden Dienste angeboten, gefunden, verwaltet und integriert. In einer ersten Phase dominierten die technischen Aspekte von SOA und eine enge Verbindung zu Webservices wurde hervorgehoben. In der jüngeren Zeit lassen sich zusätzlich geschäftsorientierte und finanzielle Reflektionen beobachten. Vor diesem Hintergrund reduziert dieser Beitrag SOA auf seine kernfunktionalen Elemente. Er verfolgt das Ziel, zunächst eine Geschäftsarchitektur zu erstellen und mit Hilfe eines Analogieschlusses die service-orientierte Architektur in die Geschäftsarchitektur zu integrieren. Gelingt dies, so kann dem SOA-Prinzip weiterhin der Charakter eines relevanten strategischen Ansatzes zur SW-Entwicklung zugesprochen werden, anstatt sich der Gefahr ausgesetzt zu sehen, lediglich einen weiteren Trend in der IT-Branche darzustellen. Hierzu wird nach diesem einleitenden Abschnitt zunächst ausgewählten Charakteristika von SOA ein korrespondierender geschäftsorientierter Analyseansatz gegenübergestellt und die strategische Einordnung von SOA als IT-Architekturkonzept herausgearbeitet. Anschließend wird ein umfassendes Integrationsmodell zum Business-IT-Alignment skizziert, das mit einem Analogieschluss von Service-orientierter und Geschäftsmodellarchitektur schließt. Ein abschließendes Kapitel fasst die einzelnen gewonnenen Zwischenergebnisse zusammen und zeigt weiteren Forschungsbedarf auf.

2

Strategische Einordnung von SOA als IT-Architekturkonzept

Mit Hilfe von SOA kann eine Organisation als eine Menge von Services, die über die gesamte Organisation verteilt und jedem zugänglich sind, modelliert werden. [Masa2005, 125] Eine solche Architektur unterscheidet sich von klassischen

40

Thomas Deelmann

Architekturprinzipien durch z.B. eine veränderte Autarkie, Reichweite, Zugänglichkeit, Aufrufbarkeit etc. Ohne an dieser Stelle weiter über z.B. technische Designprinzipien oder Integrationsschemata diskutieren zu wollen, erscheint es sinnvoll, zunächst zu abstrahieren und den traditionellen Einsatzgrund von Informationstechnologie (IT) nochmals zu vergegenwärtigen. Entwicklungen im Bereich der IT wurden im Wesentlichen mit dem Ziel forciert, Produktionsfaktoren gegeneinander zu substituieren. Im vorliegenden Fall ist menschliche Arbeitsleistung gegen Kapital eingetauscht worden. Als Beispiel kann hier der Einsatz von Tabellenkalkulationssoftware herangezogen werden. Komplexe Berechnungen können mit Hilfe eines Softwareeinsatzes i. d. R. schneller gelöst werden, als dies Menschen möglich ist. [HRPL1999, 1-23] Dieser IT-Einsatz „im Kleinen“, d. h. auf der Ebene einer einzelnen Verrichtung, lässt sich auch analog „im Großen“ beobachten, wenn Funktionen von organisatorischen Bereichen, ganzen Unternehmen oder sogar Marktmechanismen fast vollständig durch IT substituiert werden. Als Beispiele lassen sich die Funktionen Lohn- und Gehaltsabrechnungen, die Konzernbilanzkonsolidierung, das Geschäftsmodell von z.B. Print-on-Demand oder die Auktionsplattform eBay nennen. Der IT-Einsatz und damit die weitgehende Substituierung von Arbeit durch Kapital kann auf allen diesen Zwischenstufen beobachtet werden. Aus einer Geschäfts- oder Organisationsperspektive lässt sich das Geschäftsmodell als Analyseeinheit für die gerade beschriebenen Sachverhalte heranziehen. Das Geschäftsmodell ist die „abstrahierende Beschreibung der ordentlichen Geschäftstätigkeit einer Organisationseinheit“ [SDLo2003, 22]. Eine Organisationseinheit kann dabei ein Unternehmen oder ein Konzern, aber auch eine Abteilung oder ein einzelner Mitarbeiter sein. [Deel2007, 122-123] Aus Perspektive der IT kann ein Service (im Sinne einer SOA) eine entsprechende Analyseeinheit repräsentieren. Ein Service kann feingranular sein und bspw. den Vorgang Bonitätsprüfung durchführen. Er kann jedoch auch grobgranular sein und den Vorgang Gehaltsabrechnung abbilden. In einer IT-Architektur, die auf Services aufbaut, lassen sich auf Grund von Kapselungen und Autarkieaspekten kleinere Vorgänge leichter vollständig als Service abbilden als große und umfangreiche Vorgänge. Letztere wiederum lassen sich bspw. als Service abbilden, indem sie aus kleineren zusammengesetzt werden. Geschäftsmodell und Service können demnach als grundsätzlich ähnliche und korrespondierende Analyseeinheiten betrachtet werden, welche eine in sich abgeschlossene und eigenständige Tätigkeit aus unterschiedlichen Perspektiven betrachten. In einer geschäftsorientierten Sicht entspricht eine in sich abgeschlossene und eigenständige Tätigkeit der Analyseeinheit Geschäftsmodell, in Sicht der entspricht sie einem Service. Bei der Geschäftsmodellbetrachtung ist es unerheblich, ob die Substitution von Arbeit durch Kapital bereits vorgenommen wurde. Bei der Servicebetrachtung ist diese Substitution hingegen bereits erfolgt. Abstrahierend bzw. strategisch können Geschäftsmodelle und Services mit ähnlichen Integrationsüberlegungen betrachtet werden, die sich lediglich im Grad der IT-Unterstützung unterscheiden. Diese Ähnlichkeit von Geschäftsmodell und Service kann in einem weiteren Schritt herangezogen werden, um horizontale und vertikale Interdependenzen zu iden-

Integration von service-orientierten IT-Architekturen in die Geschäftsarchitektur

41

tifizieren, welche das sog. Business-IT-Alignment unterstützen oder beschränken können. Um diese Ähnlichkeit strategisch ausnutzen zu können, erscheint es sinnvoll, zunächst die Begriffe Strategie, Informationstechnologie und Geschäftsmodell zueinander in Beziehung zu setzen, bevor in einem nächsten Schritt horizontale und vertikale Interdependenzen zwischen Geschäftsmodellen (und dementsprechend Services) und Strategien herausgearbeitet werden. Mit Hilfe eines Analogieschlusses werden im Laufe des Beitrages die Überlegungen schließlich auf Basis und mit dem Verständnis der obigen Ausführungen bezüglich der Ähnlichkeiten der Analyseeinheiten auch auf Service und SOA übertragen.

3

Geschäftsarchitektur – Strategie, IT und Geschäftsmodell

3.1

Strategie

Organisationen agieren eingebettet in eine Wettbewerbsumgebung. Diese besteht aus Trends, Kunden, Lieferanten, Wettbewerbern, Branchenentwicklungen etc. Unter Berücksichtigung dieser Faktoren werden Grundsatzentscheidungen getroffen, abgestimmt und umgesetzt. Die Koordination des Verhaltens unterschiedlicher Abteilungen zur Erreichung gemeinsamer Ziele wird als Strategie bezeichnet. [Port1999, 21] Der Formulierung einer Strategie zur Erreichung eines Zieles liegen verschiedene organisationsspezifische und -individuelle Aktivitäten zu Grunde, die in ihrer Kombination zu einer Positionierung im Wettbewerbsumfeld führen. [KiMa2000, 129-137; Port1996, 64-68] Zusätzlich zur Positionierung der Organisation müssen Aktivitäten so kombiniert werden, dass sie miteinander korrespondieren. Es können verschiedene Stärkegrade von Kombinationen unterschieden werden. Eine Kombination ersten Grades liegt vor, wenn die Einzelaktivitäten sich nicht gegenseitig stören oder behindern. Bei einer Kombination zweiten Grades verstärken sich die Aktivitäten gegenseitig. Bei einer Kombination dritten Grades liegt eine gegenseitige Optimierung der Aktivitäten vor. Die Aktivitäten können mit Hilfe von sog. Activity-System Maps visualisiert werden. Hierbei werden primäre oder höherrangige Aktivitäten zunächst zueinander in Beziehung gestellt, bevor in ihrem Umfeld sekundäre oder niederrangige Aktivitäten platziert und verknüpft werden. [Port1996, 70-75] Diese beiden Sichtweisen, die Positionierung einer Organisation im Wettbewerbsumfeld sowie die Kombination von Ressourcen einer Organisation, werden als Market 1 Based View bzw. als Resource Based View bezeichnet. Beide versuchen, eine Erklärung auf die Frage zu geben, wie Organisationen Erfolge erzielen. Als Kritikpunkt wird beiden Sichtweisen entgegengebracht, dass sie lediglich einen mittelfristigen Erklärungsansatz für kurzfristig messbare Erfolgskriterien (z.B. Gewinn) liefern, jedoch 1

Michael Porter (Market Based View, MBV) und Igor Ansoff (Resource Based View, RBV) werden nach h. M. als diejenigen Autoren betrachtet, welche die jeweiligen Fragestellungen (MBV: Wie positioniere ich mich im Wettbewerb, um erfolgreich zu sein? RBV: Wie und in welcher Form kombiniere ich meine Ressourcen, um erfolgreich zu sein?) etabliert haben und prominent vertreten.

42

Thomas Deelmann

keinen Erklärungsansatz für das langfristige und erfolgreiche Bestehen von Organisationen liefern. Einen solchen Erklärungsansatz will die Theorie der Kernkompetenzen bieten. [HaPr1994] Zusammenfassend und kombinierend lässt sich festhalten, dass Kernkompetenzen beschreiben, was eine Organisationseinheit einzigartig macht und ihr langfristiges Bestehen am Markt ermöglicht, indem die Organisationseinheit Asymmetrien gegenüber anderen Organisationseinheiten [MEFo2002, 38-40] nutzt. Diese Asymmetrie bzw. Einzigartigkeit kann mittelfristig durch Positionierung im Markt bzw. Kombination von Ressourcen dahingehend umgesetzt werden, dass ein kurzfristig messbarer (finanzieller) Erfolg erzielt wird. 2

Die Strategie einer Organisationseinheit determiniert nachgeordnete Bereiche , also bspw. die genutzte Technik, die Rekrutierung, die Entwicklung oder den Einsatz von Personal, die Unternehmenskultur oder die Organisationsstruktur, wird selbst jedoch von verschiedenen Aspekten, z.B. den Umwelteinflüssen aus technologischer, politischer oder rechtlicher Hinsicht, beeinflusst. Strategie wird weiterhin auch von internen Kräften beeinflusst. Die Entwicklung von Strategien und strategischen Konzepten als Instrument der 3 Unternehmenssteuerung gehört zu den Kernaufgaben des Managements. Es lassen sich verschiedene Vorgehensweisen und Schulen der Strategieentwicklung unterscheiden. [Ghem2002, 37-74] Bei der Umsetzung dieser Strategien treten, unabhängig von anderen Ereignissen, in der Praxis Schwierigkeiten auf, z.B. eine (logisch) fehlerhafte oder unvollständige Strategie, eine nicht erfolgte oder fehlgeschlagene Kommunikation, Gegenseitige Abhängigkeiten von verschiedenen Modellen und Strategien sind zu berücksichtigen (Hier ist die Maßgeblichkeit von Gesamtmodellen und -strategien gegenüber Teilmodellen und -strategien zu beachten. Ebenso ist die Möglichkeit der Nebenbedingungscharakteristik von Teilmodellen und -strategien gegenüber übergeordneten zu berücksichtigen.) [LPBr1999, 13] oder nicht abgestimmte Umsetzungen und damit heterogene Einzellösungen auf der Ebene von Teilstrategien [KaNo2004, 5-6]. 3.2

Informationstechnologie

Informationstechnologien können entsprechend des Einsatzgebietes und ihres Nutzens in drei aufeinander aufbauende Kategorien eingeteilt werden [Nage1990, 24-25]: x

Nutzen durch substituierenden Einsatz von Informationstechnologien: Substitution von Arbeit durch Kapital; IT übernehmen Regeltätigkeiten.

x

Nutzen durch komplementären Einsatz von Informationstechnologien: Durch den Einsatz von Software, welche die Arbeitstätigkeit unterstützt, wird die Produktivität gesteigert; Fähigkeiten können gezielter eingesetzt werden.

x

Nutzen durch strategischen Einsatz der Informationstechnologie: Innovative Anwendungen tragen zum Erlangen strategischer Wettbewerbsvorteile bei. Sie verändern nicht nur die Organisationseinheit selbst (bspw. Produkte, Prozesse,

2

3

Vgl. in diesem Zusammenhang auch unterstützend [Port2002, 45], der konsistente Entscheidungen in den Bereichen Produktion, Entwicklung, Service etc. als Essenz von guten Strategien identifiziert hat. Vgl. für eine reflexierende Bestandsaufnahme des sog. Strategischen Managements: [Wüth2005].

Integration von service-orientierten IT-Architekturen in die Geschäftsarchitektur

43

Strukturen), sondern auch Branchen und Wettbewerb. Es können sich durch Technologien Branchenstrukturen verändern, Eintrittsbarrieren gegen neue Mitbewerber aufbauen, kritische Erfolgsfaktoren einer Firma dominant unterstützen lassen und neue Märkte können geschaffen werden. Auf die drei Nutzenkategorien lassen sich weitere Kriterien anwenden. Als Kriterien können die Zuordnung zu einer Unternehmens- oder Organisationsebene, die Art der Anwendung sowie der Typ der möglichen Bewertung unterschieden werden (vgl. Abbildung 3-1). Nutzenkategorie

Zuordung zu Unternehmensebene

Anwendungen

Bewertbarkeit

Kostenersparnis

Operative Ebene

Substitutive Anwendungen

Rechenbar

ProduktivitätsTaktische Ebene verbesserung

Komplementäre Anwendungen

Kalkulierbar

Strategische Wettbewerbs- Strategische Ebene vorteile

Innovative Anwendungen

Entscheidbar

Abb. 3-1: Analyse der Nutzenkategorien von Informationstechnologien [Nage1990, 31] Der Nutzen von IT in spezifischen Situationen ist häufig von Umfeldvariablen abhängig. Zur Kategorisierung von unterschiedlichen Nutzenpotenzialen werden häufig Portfoliodarstellungen gewählt. Als Portfoliodimensionen können z.B. die Informationsintensität der Wertschöpfungskette und der Informationsgehalt der jeweils hergestellten Produkte herangezogen werden. Versicherungen haben eine hohe Informationsintensität in der Wertschöpfungskette und die Versicherungsprodukte einen hohen Informationsgehalt. Im Bergbau sind beide Dimensionen eher schwach ausgeprägt (vgl. Abbildung 3-2). Im rechten oberen Quadranten ist das Potenzial der IT am größten, im linken unteren am geringsten. Weitere Möglichkeiten der Nutzung von IT-Portfolios zeigt Nagel auf. Parameter sind bspw. die Qualität der Ressourcen, der Einfluss der IT auf Prozesse oder die strategische Notwendigkeit des IT-Einsatzes (vgl. [Nage1990, 114, 121, 122] sowie die dort angegebene Literatur).

44

Thomas Deelmann

hoch - Banken - Ölraffinerien

- Versicherungen

- Maschinenbau

- Fluggesellschaften

Informationsintensität der Wertschöfpungskette - Zementindustrie

- Druckerei

- Bergbau

niedrig niedrig

hoch Informationsgehalt der Produkte

Abb. 3-2: Portfoliodarstellung Informationsgehalt Produkt-Wertkette [Sche1990, 192] 3.3

Zusammenwirken von Informationstechnologien und Strategie

Der Informationstechnologie bzw. ihrem Einsatz wird in der Wirtschaftsinformatik eine enge Verbindung zu betriebswirtschaftlich-funktionalen Aspekten unterstellt. Zunehmend wird eine Verbindung auch zwischen der Strategie der Organisationseinheit und der Informationstechnologie gefordert. I. d. R. wird von einer wechselseitigen Beeinflussung ausgegangen. [HeKa2002, bes. 16] Die Strategie gibt hier die Rahmenbedingungen für die Informationstechnologie vor. Die Informationstechnologie weist Restriktionen in ihren Einsatzmöglichkeiten auf, die sich auf die Umsetzbarkeit der Strategie auswirken. [Scot2005, 904-936] Gleichzeitig ermöglichen Informationstechnologien neue Arten der Geschäftstätigkeit, die wiederum von der Strategie und anderen unternehmerischen Bereichen ausgenutzt werden können (z.B. die Entwicklung neuer Hard- und Software, die Möglichkeiten einer verbesserten Anwenderunterstützung oder die Möglichkeiten, die sich durch die innovative Nutzung 4 vorhandener Technologien in Verbindung mit neuen Geschäftspraktiken ergeben ). Nagel greift die Möglichkeit der Kreation von Betätigungsfeldern durch die Schaffung 5 neuer Marktchancen gemäß den Porter’schen strategischen Stoßrichtungen auf. Österle hält eine Veränderung von ganzen Wirtschaftssektoren für möglich. [Öste1995, 8-9] Scheer stellt diese wechselseitige Beeinflussung dar, nimmt jedoch gleichzeitig eine Rangreihung der Wichtigkeit durch eine Vorgehensabfolge bei der Informationstechnologieentwicklung vor. Ausgehend von einer betriebswirtschaftlichen Ausgangs4

5

Vgl. für ein prominentes Beispiel der durch IT ermöglichten neuen Art der Geschäftstätigkeit das Phänomen des E-Business. Fallbeispiele hierzu u. a. in [Merz1999; Zwiß2002; Pepe2002; Keup2003]. [Nage1990, 109-112]; IT wird als Treiber für den Aufbau neuer Geschäftsbereiche, für die Schaffung neuer Märkte in etablierten Branchen sowie mit Hilfe der abgeleiteten Nachfrage nach neuen Produkten als Schaffer von Märkten gesehen.

Integration von service-orientierten IT-Architekturen in die Geschäftsarchitektur

45

situation innerhalb einer Organisationseinheit wird zunächst ein Fachkonzept erstellt, aus dem ein DV-Konzept abgeleitet wird. Auf dessen Basis schließlich wird die Implementierung der Informations- und Kommunikationstechnik vorgenommen. [Sche1998; Sche2001] Das Zusammenspiel von Wettbewerbsstrategie und IT-Einsatz einer Organisationseinheit äußert sich in der Regel dadurch, dass IT die Strategie unterstützt und gleichzeitig auch wettbewerbsstrategische Vorgaben von der Strategie erhält. Neben dem tatsächlichen Einsatz von IT ist auch das verfügbare Potential der IT von Interesse. Es determiniert nämlich einerseits den Einsatz und induziert gleichzeitig Modifikationen der Wettbewerbsstrategie (vgl. Abbildung 3-3).

Abb. 3-3: Wettbewerbsstrategie und Informationstechnologie [Wolf1999, 157] Eine Abstimmung sollte jedoch nicht nur zwischen Organisationsstrategie und Informationstechnologie, sondern auch zwischen verschiedenen unter- und übergeordneten Organisationseinheiten erfolgen. Abbildung 3-4 zeigt das Zusammenwirken von dezentralen und zentralen Organisationseinheiten. Hierbei geben die zentralen Geschäftseinheiten Informationen an die dezentralen Organisationseinheiten ab und erhalten gleichzeitig von diesen Informationen über die regionale Situation. Sowohl auf der zentralen wie auch auf der dezentralen Ebene übernehmen Strategie- und Fachabteilungen (Business) sowie IT-Funktionen der Organisationseinheit verschiedene Aufgaben. So ist es eine klassische Aufgabe von zentralen Fachabteilungen, Anforderungen für eine Informationstechnologie zu konsolidieren. Der zentrale IT-Bereich erstellt daraufhin das funktionale und technische Design. Der dezentrale IT-Bereich wiederum bereitet die Infrastruktur vor und übernimmt die Installation der IT. Die dezentrale Fachabteilung schließlich ist verantwortlich für das sog. Change Management, d. h. die Sicherstellung, dass Organisation und Mitarbeiter die neue Informationstechnologie akzeptieren und nutzen.

46

Thomas Deelmann

Sending

Business units/regional operations

Worldwide/corporate operations Business

IS

Business

Key functions: • Prepare infrastructure

Key functions:

Key functions:

• Define business needs, usability requirements

• Define solutions

• Create functional/ technical design

• Document business processes

• Build solution architecture

• Conduct user-acceptance testing

• Develop system

• Develop communications and behavioral-training programs for users

• Consolidate requirements • Verify/accept developed solution • Develop communications and systemstraining programs • Manage organizational, behavioral change • Coordinate deployment • Ensure readiness for launch in field

• Test system • Manage software versions

IS

Key functions:

• Ensure localization support for software • Install software • Manage regional IS development • Ensure smooth migration of data

• Execute changemanagement process (organizational, behavioral change) • Deploy system

Receiving

Abb. 3-4: Abstimmung zwischen zentralen und dezentralen Geschäftseinheiten [AHSc2004, 86] 3.4

Zusammenwirken von Geschäftsmodell und Strategie

In der Literatur sind verschiedene Interpretationen der Konzepte von Strategie und Geschäftsmodell und ihres Zusammenhangs zu finden: Teilweise werden sie als deckungsgleich, sich ergänzend oder als nicht kombinierbar angesehen (vgl. Abbildung 3-5). [SLFS2004, 427-442] Im Rahmen des vorliegenden Beitrages werden Strategie und Geschäftsmodell als disjunkt betrachtet.

Abb. 3-5: Interpretationsmöglichkeiten Strategie und Geschäftsmodell

6

Unter Berücksichtigung der o. g. Interpretationen von Geschäftsmodell und Strategie werden in diesem Beitrag beide zusätzlich als komplementär betrachtet. [Magr2002, 86-92] Das Geschäftsmodell beschreibt eine Organisation und ihre ordentliche 6

In Anlehnung an [SLFS2004, 428], die allerdings nur die Optionen B bis F anbieten (und im Original mit A bis E bezeichnen). Die neue Option A ist nach Ansicht des Verfassers jedoch zu ergänzen.

Integration von service-orientierten IT-Architekturen in die Geschäftsarchitektur

47

Geschäftstätigkeit, die Strategie beschreibt das koordinierte Vorgehen zur Erreichung von Zielen. Während das Geschäftsmodell die Zeitpunktbetrachtung einer Organisationseinheit erlaubt, beschreibt die Strategie entweder einen Weg zur Erhaltung der aktuellen Position im Wettbewerb oder einen Weg zur Herbeiführung einer neuen Position im Wettbewerbsumfeld. [Seid2003, 6] Sie liefert damit eine Zeitraumbetrachtung (vgl. Abbildung 3-6).

Abb. 3-6: Zusammenwirken von Geschäftsmodell und Strategie Um von dem Geschäftsmodell einer Organisationseinheit zum Zeitpunkt t1 zu einem zukünftigen Geschäftsmodell zum Zeitpunkt t2 zu gelangen, wird eine Strategie verfolgt. Hierbei zeigt die Strategie den Weg zur Erreichung eines Zieles auf, das Geschäftsmodell den Zielzustand. [HeKa2002, 124; LiCa2001, 10, 14; PaGi2003, 87102] Bei der Gestaltung des zukünftigen Geschäftsmodells können zwei grundsätzliche Möglichkeiten unterschieden werden. Zum einen kann das zukünftige Geschäftsmodell dem aktuellen entsprechen, die heutige Wettbewerbsposition soll demnach beibehalten werden. Zum anderen kann es sich vom aktuellen unterscheiden, eine neue Wettbewerbsposition wird angestrebt. Soll das zukünftige Geschäftsmodell dem heutigen ähnlich sein, dann ist die Strategie der Organisationseinheit entsprechend auszurichten: Die Aktivitäten sind auf den Umgang mit Wettbewerbssituationen, bspw. die Abwehr von Preiserhöhungsversuchen der Lieferanten, ausgerichtet. Sollen sich die beiden Geschäftsmodelle (zu den Zeitpunkten t1 und t2) voneinander unterscheiden, dann ist die Strategie auf die Transformation der Organisationseinheit ausgerichtet: Sie verfolgt bspw. das Ziel, einen online-gestützten Vertriebskanal gegenüber bereits vorhandenen traditionellen Vertriebskanälen zu etablieren. 3.5

Zusammenwirken von Informationstechnologie und Geschäftsmodell

In der Literatur sind verschiedene Interpretationen des Zusammenwirkens von IT und Geschäftsmodell existent. So stellen Hedman und Kalling die Verbindung zwischen dem Geschäftsmodell und generischen IT-Applikationen, also der IT-Architektur, her (vgl. Abbildung 3-7). Die Struktur eines Geschäftsmodells wird hierbei zunächst lediglich in die zu Grunde liegenden Ressourcen, Organisation und Prozesse sowie in das Angebot gegenüber dem Markt unterteilt. Anschließend wird das Geschäftsmodell mit Informationstechnologie kombiniert. Alle drei grundlegenden Blöcke werden von korrespondierenden Systemen unterstützt. Zugleich werden Marktsysteme mit in die Betrachtung aufgenommen. Mit ihnen kann ggf. eine Integration erfolgen. Beispiele für diese Marktsysteme sind CRM- und SCM-Systeme von Kunden, Lieferanten und Wettbewerbern. Ein Beispiel für das die Ressourcen unterstützende System kann ein

48

Thomas Deelmann

Lagerhaltungssystem oder Wissensmanagementsystem sein. ERP-Systeme unterstützen Organisation und Prozesse des Geschäftsmodells, während CAD- oder auch Umfragesysteme das Angebot gegenüber dem Markt unterstützen.

Business Model Structure

Business Model and IS Market Systems

Offering

Offering Systems

Activities and Organization

Value Chain and Organizational Systems

Resource

Resource and Competence Systems Market Systems

Examples and Systems Customers, Suppliers, and Competitors (CRM, SCM) Products and Services (CAD, Embedded Systems,Survey Systems) Activities and Organization (Value Chain and Organizational Systems / ERP) (Physical Resource Management Systems, Knowledge Management) Customers, Suppliers, and Competitiors (CRM, SCM)

Abb. 3-7: Transition Geschäftsmodell in IT-Architektur [HeKa2002, 129ff] Bei dieser Transition können strukturelle Ähnlichkeiten zwischen Elementen des Geschäftsmodells (Business Specifications) und den Informationstechnologieen (IT Specifications bzw. System Specifications) genutzt werden. Grundlage ist hierbei, dass es übereinstimmende Muster zwischen diesen Konzepten gibt, die eine 7 Transition ermöglichen. Die Gestaltung von Geschäftsmodellen unter dem Einfluss moderner Informationsund Kommunikationstechnologie befindet sich im Spannungsfeld zweier Entwicklungen: Die Diffusion neuer Informationstechnologien ermöglicht neue Geschäftsmodelle. Andererseits erfordert die Umsetzung innovativer und neuartiger Geschäftsmodelle die Anpassung der relevanten Informationstechnologien. Beide Veränderungsrichtungen führen zu einer erhöhten Komplexität und Dynamik bei der Gestaltung und Abbildung von sowohl entsprechenden Geschäftsmodellen wie auch Informationstechnologien. [Kilo2002, 142-143] 3.6

Zusammenwirken von IT, Strategie und Geschäftsmodell

Informationstechnologie steht in wechselseitigen Beeinflussungen mit anderen Disziplinen des Unternehmens, z.B. Organisation, Absatzwege, Personal. In ihrer Gesamtheit können sie mit Hilfe eines Geschäftsmodells repräsentiert werden und führen zu einem Geschäftserfolg. 7

Diese Notiz soll allerdings nochmals mit der Anmerkung versehen werden, dass Kilov das Geschäftsmodell eher aus einer Informationstechnologie- denn aus einer Wirtschaftsperspektive betrachtet: „We treat business modelling [...] as an essential part of software engineering. Mastery of software engineering concepts is one of the most important prerequisites the success of an information management project.“ [Kilo2002, 3].

Integration von service-orientierten IT-Architekturen in die Geschäftsarchitektur

49

Das Strategic Alignment Model will diese wechselseitigen Beeinflussungen abbilden. Hierbei spiegelt es die Annahme wider, dass Geschäftserfolg auf der Abstimmung zwischen der Geschäftsstrategie, der IT-Strategie, der Geschäftsinfrastruktur und ihren Prozessen sowie der IT-Infrastruktur und korrespondierenden Prozessen beruht (vgl. Abbildung 3-8). Zwischen der Geschäfts- und der IT-Strategie muss eine Integration ebenso erfolgen, wie zwischen Geschäftsinfrastruktur und ihren Prozessen sowie der IT-Infrastruktur und Prozessen. Eine mangelhafte Integration führt zu nicht abgestimmten Aktivitäten. Gleichzeitig ist zwischen den strategischen Komponenten und ihren ausführenden Elementen ein sog. Strategic Fit herzustellen. Andernfalls besteht die Gefahr von nicht umsetzbaren Strategien.

External

Business Strategy

Strategic Integration

Strategic Fit

Internal

Organizational Infrastructure and Processes

IS Strategy

Strategic Fit

Organziational Integration

IS Infrastructure and Processes

Abb. 3-8: Strategic Alignment Model (in Anlehnung an [TeTe1995, 13-17]; vgl. auch [HeVe1993]) Die Artikulation von Geschäftsmodellen kann die Differenz zwischen den Möglichkeiten sowie der Anwendung von Informationstechnologien verringern. [OPTu2005, 17] 3.7

Zwischenfazit – Entwicklung eines Geschäftsarchitekturrahmens

In den vorhergehenden Abschnitten wurden Zusammenhänge zwischen Informationstechnologie und Strategie, zwischen Strategie und Geschäftsmodell, zwischen Geschäftsmodell und Informationstechnologie sowie zwischen Strategie, Informationstechnologie und Geschäftsmodell vorgestellt. Insbesondere bei Strategie und IT wird hierbei häufig von einem Verhältnis der Über- und Unterordnung ausgegangen. Eine ausführliche Betrachtung von Interdependenzen zwischen den verschiedenen Funktionen einer Organisationseinheit unterbleibt jedoch in der Regel. Das Strategic Alignment Model greift die Notwendigkeit einer strategischen Übereinstimmung auf und betrachtet auch die Integration von IT und Strategie bzw. IT und organisatorischer Infrastruktur und Prozessen, jedoch erscheint dieses Modell nicht umfassend genug, wird doch lediglich auf der internen Ebene eine Unterteilung zwischen IT und Organisation vorgenommen. Weitere betriebliche Funktionen werden nicht explizit in die Abstimmung eingebunden. Um die IT stärker in die Geschäftsarchitektur einer Organisationseinheit einzubinden, erscheint es hilfreich, wenn die Interdependenzen (sowohl horizontal wie auch vertikal) insbesondere zwischen verschiedenen Modellen und Strategien herausgearbeitet und berücksichtigt werden.

50

Thomas Deelmann

4

Horizontale und vertikale Interdependenzen bei Modellen und Strategien

4.1

Über- sowie Unterordnung von Modellen und Strategien

Geschäftsmodelle und Strategien von Organisationseinheiten sind per Definition für den Einsatz auf der Ebene der betrachteten Organisationseinheit geeignet. Für den Einsatz in einem Teilbereich einer Organisationseinheit sind entsprechende Teilmodelle und -strategien zu entwickeln. Sie leiten sich aus den organisationsweiten Modellen und Strategien ab. Ein Teilmodell kann zum einen ein Geschäftsmodell einer hierarchisch nachgeordneten Geschäftseinheit und zum anderen ein Modell eines betrieblichen Bereiches sein. Ein Beispiel für den ersten Fall ist bei Unternehmen zu finden, die über verschiedene sog. strategische Geschäftseinheiten verfügen. Beide hierar8 chische Ebenen besitzen ein Geschäftsmodell. Teilmodelle des zweiten Falles sind Abstraktionen oder Konstruktionen, die einzelne betriebliche Teil- oder Funktionsbereiche (z.B. Abteilungen) repräsentieren. Als Beispiele für solche typischen betriebswirtschaftlichen Unternehmensmodelle können die Konzepte von Buchungssatz und Konto des externen Rechnungswesens, die Konzepte von Kostenart, Kostenstelle und Kostenträger des internen Rechnungswesens oder das Konzept der Stellenpläne des Personalwesens genannt werden. [Sche1990, 47] Auch Informationsmodelle können als solche Teilmodelle betrachtet werden. Teilmodelle lassen sich dahingehend charakterisieren, als dass sie aus einer relativen Betrachtungsposition ein hierarchisch übergeordnetes Modell, i. d. R. zumindest ein Geschäftsmodell, besitzen. Eine Teilstrategie kann zum einen die Geschäftsstrategie einer hierarchisch nachgeordneten Geschäftseinheit und zum anderen die Strategie eines betrieblichen Bereiches sein. Ein Beispiel für den ersten Fall ist wiederum bei Organisationseinheiten zu finden, die über verschiedene strategische Geschäftseinheiten verfügen. Beide besitzen eine Strategie für die jeweilige Organisationseinheit. Als Beispiel für den zweiten Fall kann eine IT-Strategie als Strategie der IT-Abteilung betrachtet werden. Es handelt sich hierbei um eine Teilstrategie der Gesamtorganisations9 einheit. 4.2

Vertikale Interdependenzen

Organisationseinheiten können sich in einem Über- und Unterordnungsverhältnis befinden. Eine solche Situation liegt bspw. regelmäßig vor, wenn eine Organisationseinheit von einer anderen Weisungen empfängt. Dieses Verhältnis von Über- und Unterordnung kann auf Modelle und Strategien übertragen werden. Die übergeordneten Elemente sind für die untergeordneten maß8

9

Vgl. [OPTu2005, 4], die verschiedene Geschäftsmodelle von Apple im Musikbereich (Abspielgerät iPod; Online-Musikshop iTunes; Abspielsoftware iTunes) hervorheben, welche sich gegenseitig verstärken und sowohl als individuelle Geschäftsmodelle wie auch als Elemente eines übergeordneten Geschäftsmodells verstanden werden können. Vgl. [MSLe2003, 482-495], die jedoch den Begriff der Funktionalstrategie nutzen.

Integration von service-orientierten IT-Architekturen in die Geschäftsarchitektur

51

geblich und bilden einen Rahmen, innerhalb dessen eine Ausgestaltung möglich ist. Gleichzeitig können Teilmodelle und -strategien Bedingungen für die Bildung dieses Rahmens stellen. In Anlehnung an Hahn kann der Zusammenhang von über- und untergeordneten Strategien mit dem Konzept der Vereinheitlichung beschrieben werden, der Zusammenhang von Modellen mit dem Konzept der Föderation. [Hahn2004, 69] Bei der Vereinheitlichung umfasst eine übergeordnete Strategie die Teilstrategien. Für die Ableitung von Teilstrategien werden Informationen aus der übergeordneten Strategie genutzt. Bei der Föderation erfolgt eine Kopplung individueller über- und untergeordneter Modelle. Informationen verbleiben in den jeweiligen individuellen Modellen, eine Aggregation findet i. d. R. nicht statt (vgl. Abbildung 4-1).

Integriert

Vereinheitlicht

Föderiert

Konzept Nutzung gemeinsames Modell

Abbildung auf gemeinsames Metamodell

Verschiedene, individuelle Modelle werden gekoppelt

Vollständige Abbildung auf gemeinsames Modell

Nutzung eines gemeinsamen Metamodells

Nutzung einer Ontologie

Semantik

Gemeinsames Modell

Komposition / Metamodelle

Metadaten

Beispiele

CIMOSA, GRAI

ebXML, NIST PSL, UEML

Ansatz

Abb. 4-1: Vertikale Modellzusammenhänge [Hahn2004, 69] 4.3

Horizontale Interdependenzen

Neben der Situation einer Über- bzw. Unterordnung von zwei Organisationseinheiten treten Situationen auf, in denen zwei Organisationseinheiten nebeneinander, d. h. auf einer hierarchischen Ebene existieren. In einem solchen Fall haben beide Organisationseinheiten die Aufgabe, zu den Zielen der ihnen übergeordneten Einheit beizutragen. Beide Organisationseinheiten besitzen hierbei entweder ein eigenständiges Ge10 schäftsmodell (bspw. im Falle der o. g. strategischen Geschäftseinheiten) oder ein eigenständiges Modell ihres betrieblichen Bereiches, welcher sich vom jeweils anderen unterscheidet. Ausgehend von diesem Modell verfolgen beide Einheiten eigene Strategien: Die IT-Fachabteilung verfolgt eine IT-Strategie, die Marketing-

10

[LiCa2001, 2-3] stellen die Situation multipler Geschäftsmodelle fest und schlagen einen Weg der Identifikation vor: „Furthermore, a firm with several divisions may have several operating business models. How can you tell? If the divisions could be spun off with no impact on their ability to compete or remain profitable, their operating business models are independent.“

52

Thomas Deelmann

Abteilung verfolgt eine Marketing-Strategie. Es gilt nun, diese beiden Modelle und 11 Strategien so zu gestalten, dass sie sich nicht gegenseitig behindern. 4.4

Zusammenwirken horizontaler und vertikaler Interdependenzen

Es kann festgehalten werden, dass zwei Organisationseinheiten auf einer hierarchischen Ebene mit autarken (Geschäfts-)Modellen und Strategien ausgestattet sein können, diese jedoch so abgestimmt werden müssen, dass sie sich in ihren Zielen gegenseitig nicht behindern, ihre horizontalen Interdependenzen also beachtet werden.

Modell Maßgeblichkeit Vertikale Interdependenzen

Strategie Maßgeblichkeit

Nebenbedingung

Teilmodell Wechselwirkungen

Teilstrategie

Teilmodell

Wechselwirkungen

Nebenbedingung Wechselwirkungen

Teilstrategie

Teilmodell

Wechselwirkungen

Teilstrategie

Horizontale Interdependenzen

Abb. 4-2: Horizontale und vertikale Interdependenzen Abbildung 4-2 zeigt die identifizierten horizontalen und vertikalen Interdependenzen. Modelle und Strategien werden jeweils als zusammengehörig und komplementär dargestellt. Übergeordnete Modelle und Strategien sind maßgeblich für nachgeordnete, letztere können jedoch Nebenbedingungen für erstere vorgeben. Diese Nebenbedingungen sind Begrenzungen und Beschränkungen, die bspw. durch rechtliche Rahmenbedingungen oder getätigte Investitionen entstehen können. Weiterhin können zwischen Modellen bzw. Strategien einer hierarchischen Ebene Wechselwirkungen identifiziert werden, die es zu beachten gilt.

11

Die Überlegung der horizontalen Interdependenzen findet bspw. auch im Business-IT-AlignmentModell ihren Ausdruck, hier allerdings nur mit einer reduzierten Anzahl von Abstimmungseinheiten. In [FlFl2003] wird der Ansatz erheblich erweitert, wenn die Autoren eine Abstimmung zwischen den Kompetenzen von drei Bereichen fordern, die in jeden Unternehmen anzutreffen sind (Produktion, Produktentwicklung und Vertrieb und Verkauf). Nach Ansicht des Verfassers ist jedoch auch dieses erweiterte Verständnis von Abstimmungseinheiten noch unzureichend, da nicht alle Funktionen einer Organisationseinheit berücksichtigt werden.

Integration von service-orientierten IT-Architekturen in die Geschäftsarchitektur

53

Bei einer Nichtbeachtung dieser Interdependenzen sind verschiedene Auswirkungen zu befürchten: x

konträre Aussagen von Teilmodellen und -strategien,

x

nicht implementierungsfähige übergeordnete Strategien und nicht erreichbare übergeordnete Ziele, ausgedrückt in Modellen,

x

unabgestimmtes Vorgehen durch nicht übereinstimmende Kommunikation,

x

Verunsicherung bei beteiligten Mitarbeitern und Geschäftspartnern.

Innerhalb dieses Geflechts von wechselseitigen Dependenzen und möglichen Auswirkungen müssen in der Praxis sowohl Geschäftsmodelle und Gesamtstrategien wie auch Modelle einzelner betrieblicher Bereiche und ihre korrespondierenden Strategien erstellt werden. 4.5

Zwischenfazit – Analogieschluss von Service-orientierter und Geschäftsmodellarchitektur

Das Zusammenspiel von Strategie und Geschäftsmodell wird in der Literatur uneinheitlich diskutiert. Die hier vorgeschlagene Interpretation als komplementäre Konstrukte wird dabei durchaus unterstützt. Werden die diskutierten horizontalen und vertikalen Interdependenzen akzeptiert, so helfen sie der Gestaltung einer Geschäftsarchitektur, indem das Zusammenwirken von IT und Strategie gefördert wird. Neben der Betrachtung der Analyseeinheit Geschäftsmodell und ihrer Interaktion mit der Strategie können die angestellten Überlegungen grundsätzlich auch auf Services bzw. SOA übertragen werden. Ermöglicht wird dies durch das geschaffene Verständnis auf Basis des der obigen Ausführungen bezüglich der Ähnlichkeiten der Analyseeinheiten. Weiter oben wurde bereits festgestellt, dass sowohl ein Geschäftsmodell als auch ein Service einen in sich abgeschlossenen Vorgang aus unterschiedlichen Perspektiven betrachten. Für das Geschäftsmodell ist es unerheblich, ob eine Substitution von Arbeit durch Kapital (hier: IT) bereits vorgenommen wurde. Bei der SOA-Betrachtung ist eine solche Substitution bereits erfolgt. Beide Konstrukte unterscheiden sich durch den Grad der IT-Unterstützung, sind ansonsten jedoch verhaltensähnlich und können einseitig substituier- und ergänzbar in die Geschäftsarchitektur von Organisationen und Unternehmen eingefügt werden. Mit einem Rückgriff auf die Beispiele aus Kapitel 2 soll die Integration von Services bzw. des SOA-Architekturprinzips in die etablierte Geschäftsarchitektur nochmals verdeutlicht werden: Die exemplarischen Geschäftsmodelle „Lohn- und Gehaltsabrechnung“, „Konzernbilanzkonsolidierung“, „Print-on-Demand“ sowie „Marktmechanismus Auktion“ lassen sich grundsätzlich ebenfalls als Service darstellen und implementieren. Abbildung 4-3 will diesen Zusammenhang grafisch illustrieren. Eine exemplarische hierarchische Organisationsdarstellung ist geschäftsmodellorientiert dargestellt, d. h. je nach gewünschter Granularitätsstufe können wie in Abschnitt 4.1 gesehen unterschiedliche Geschäftsmodelle identifiziert werden (der A-Konzern besitzt ebenso ein Geschäftsmodell, wie die Teilfunktion Prüfung interner Kundendaten ein Geschäftsmodell darstellt bzw. darstellen kann). Die Abbildung von Geschäftsmodellen in Form von Services bzw. die Integration von Services in die Geschäftsarchitektur ist bei

54

Thomas Deelmann

kleinen Abschnitten (z.B. Teilfunktionen, Funktionen) tendenziell eher umsetzbar als bei großen (z.B. Unternehmen, Bereich). Geschäftsmodellorientierte Organisationsdarstellung (illustrativ)

Substituierbarkeit Arbeit durch Kapital (hier: IT, Services)

A-Konzern

Unternehmen

eher schwerer Bereich

Sparte A

Sparte B

Sparte C

Abteilung

Finanzen

Produktion

HR

Be lieb i

Stelle

Funktion

…

Bonitätsprüfung

ge hie … ra fun … ktio rchis nal che eB reit Tiefe e un … …d

eher leichter Teilfunktion

Prüfung int. Kundendaten

…

…

Abb. 4-3: Illustrative Organisationsdarstellung und SOA-Einsatzmöglichkeit Mit diesem Weg, SOA in die Geschäftsarchitektur zu integrieren, kann zur Unterstützung des Business-IT-Alignments mit Hilfe eines Analogieschlusses auf die weiter oben beschriebenen Überlegungen zur Geschäftsarchitektur (Strategie, IT, Geschäftsmodell) sowie zu den horizontalen und vertikalen Interdependenzen zurückgegriffen werden. Es ist zum einen insbesondere das Zusammenwirken mit der Geschäfts- sowie der hieraus abgeleiteten IT-Strategie zu berücksichtigen. Mögliche Determinanten bzw. Unterstützungsmöglichkeiten sind bspw. in den Punkten Geschäftskritikalität, strategische Priorisierung, Informationsintensität des abzubildenden Wertschöpfungskettenelements, Informationsgehalt der Produkte oder Veränderungsgeschwindigkeit einer Organisationseinheit zu sehen. Hierbei können Services sowohl neues Potenzial freisetzen, als auch in ihrem Umsetzungs- oder Implementierungszeitplan priorisiert werden. Zum anderen muss bei der Gestaltung von Services bzw. der elektronischen Umsetzung von Geschäftsmodellen durch Services auf Interdependenzen mit anderen Services geachtet werden. Hierbei sind sowohl Wechselwirkungen mit Services derselben Ebene (horizontale Interdependenzen), als auch Maßgeblichkeiten und Nebenbedingungen von Services auf anderen Ebenen (vertikale Interdependenzen) zu berücksichtigen.

Integration von service-orientierten IT-Architekturen in die Geschäftsarchitektur

55

Der vorgestellte Integrationsansatzes durch den Analogieschluss von Geschäftsmodell und Services und damit von einer geschäftsmodellorientierten Architektur auf eine serviceorientierte Architektur fördert also nicht nur das Zusammenwirken von Strategie und Geschäftsmodell, sondern ermöglicht ebenfalls die Integration von Services bzw. SOA in die Geschäftsarchitektur.

5

Zusammenfassung

Der vorliegende Beitrag hat die Möglichkeit der Integration von service-orientierten IT-Architekturen in die Geschäftsarchitektur aus einer strategischen Perspektive untersucht. Hierzu wurde zunächst die klassische Substitutionsfunktion von Arbeit durch Kapital (hier: IT) betrachtet und die Ähnlichkeit der Analyseeinheiten Geschäftsmodell und Service herausgearbeitet. Auf Basis einer Analyse von Strategie, IT und Geschäftsmodell und ihren Zusammenhängen wurde durch einen Analogieschluss der Service in diesen Kontext mit einbezogen. Im Ergebnis lässt sich feststellen, dass sich service-orientierte IT-Architekturen gut in die Geschäftsarchitektur integrieren lassen. Weiterer Forschungsbedarf wird in der detaillierten empirischen Ausgestaltung der festgestellten Ähnlichkeit von Geschäftsmodell und Service und dem Umgang hiermit im Softwareerstellungs- und -integrationsprozess gesehen. Von Interesse scheint auch die Beantwortung der Frage zu sein, inwieweit es sich bei SOA um eine weitere Modeerscheinung im Bereich der IT-Architekturen oder um ein nachhaltiges Paradigma handelt. Die Verbindung zum Geschäftsmodell und die Nützlichkeit der Kapselung im Substitutionsprozess sind hier als ein erster Analyseinput zu verstehen; weitere Analysefelder sind zu identifizieren und heranzuziehen.

Literaturverzeichnis [AHSc2004] Agrarwal, A.; Harding, D. P.; Schumacher, J. R.: Organizing for CRM. In: McKinsey Quarterly, 3/2004, S. 81-91. [Deel2007] Deelmann, T.: Geschäftsmodellierung – Grundlagen, Konzeption und Integration. Logos-Verlag, Berlin, 2007. [FlFl2003] Fleury, A.; Fleury, M. T.: The Evolution of Strategies and Organizational Competencies in the Telecommunication Industry. In: International Journal of Information Technology & Decision Making, 4 (2003) 2, S. 577-596. [Ghem2002] Ghemawat, P.: Competitive and Business Strategy in Historical Perspective. In: Business History Review, 76 (2002) Spring, S. 37-74. [LPBr1999] Luftman, J. N.; Papp, R.; Brier, T.: Enablers and Inhibitors of Business-IT Alignment. In: Communications of the AIS, 1 (1999) 11, S. 1-33. [Hahn2004] Hahn, A.: Interoperabilität in Supply Chains und E-Logistics. In: IndustrieManagement, 3 (2004) 20, S. 67-70. [HaPr1994] Hamel, G.; Prahalad, C. K.: Competing for the Future. Harvard Business School Press: Boston, 1994. [HeKa2002] Hedman, J.; Kalling, T.: IT and Business Models. Liber/Abstrakt, Malmö, Schweden, 2002.

56

Thomas Deelmann

[HeVe1993] Henderson, J. C.; Venkatraman, N.: Strategic Alignment – Leveraging Information Technology for Transforming Organizations. In: IBM Systems Journal, 1 (1993) 32, S. 4-16. [HRPL1999] Hoch, D. J.; Roeding, C. R.; Purkert, G.; Lindner, S. K.: Secrets of Software Sucess. Harvard Business School Press: Boston, MA, USA, 1999. [KaNo2004] Kaplan, R. S.; Norton, D. P.: Strategy Maps – Converting intangible assets into tangible outcomes. Harvard Business School Press, Boston, MA, USA, 2004. [Kilo2002] Kilov, H.: Business Models – A Guide for Business and IT. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2002. [KiMa2000] Kim, W. C.; Mauborgne, R.: Knowing a Winning Business Idea When You See One. In: Harvard Business Review, 5 (2000) 78, S. 129-137. [Keup2003] Keuper, F. (Hrsg.): E-Business, M-Business und T-Business – Digitale Erlebniswelten aus Sicht von Consulting-Unternehmen. Gabler-Verlag, Wiesbaden, 2003. [LiCa2001] Linder, J. C.; Cantrell, S.: Changing Business Models: Surveying the Landscape. Institute for Strategic Change, Cambridge, MA, USA, 2001. [Magr2002] Magretta, J.: Why Business Models Matter. In: Harvard Business Review, 5 (2002) 80, S. 86-92. [Masa2005] Masak, D.: Moderne Enterprise Architekturen. Springer, Berlin, Heidelberg, 2005. [MEFo2002] Miller, D.; Eisenstat, R.; Foote, N.: Strategy from the Inside Out: Building Capability-Creating Organizations. In: California Management Review, 3 (2002) 44, S. 37-54. [Merz1999] Merz, M.: Electronic Commerce – Technologien. dpunkt-Verlag, Heidelberg, 1999.

Marktmodelle,

Anwendungen

und

[MSLe2003] Müller-Stewens, G.; Lechner, C.: Strategisches Management – Wie strategische Initiativen zum Wandel führen. 2. Aufl., Schäffer-Poeschel Verlag, Stuttgart, 2003. [Nage1990] Nagel, K.: Nutzen der Informationsverarbeitung – Methoden zur Bewertung von strategischen Wettbewerbsvorteilen, Produktivitätsverbesserungen und Kosteneinsparungen. Oldenbourg Verlag, München, 1990. [OPTu2005] Osterwalder, A.; Pigneur, Y.; Tucci, C. L.: Clarifying Business Models: Origins, Present, and Future of the Concept. In: Communications of the Association for Information Systems, Vol. 16, 2005, S. 1-25. [Öste1995] Österle, H.: Business Engineering – Prozeß- und Systementwicklung. Bd. 1. 2. Aufl., Springer-Verlag, Berlin, Heidelberg, New York, 1995. [oV2007] Google Inc.; http://www.google.com/trends?q=%22Service+oriented+Architecture% 22&ctab=0&geo=all&date=all&sort=0; Abruf am 2007-05-28. [PaGi2003] Pateli, A. G.; Giaglis, G. M.: A Methodology for Business Model Evolution: Application in the Mobile Exhibition Industry. In: Giaglis, G. M.; Werthner, H.; Tschammer, V.; Froeschl, K. A. (Hrsg.): Proceedings of The Second International Conference on Mobile Business. Wien, 16.-18. Juni 2003, S. 87-102. [Pepe2002] Pepels, W. (Hrsg.): E-Business-Anwendungen in der Betriebswirtschaft. Verlag neue Wirtschafts-Briefe, Herne, Berlin, 2002.

Integration von service-orientierten IT-Architekturen in die Geschäftsarchitektur

57

[Port1996] Porter, M. E.: What Is Strategy? In: Harvard Business Review, 6 (1996) 74, S. 6178. [Port1999] Porter, M. E.: Wettbewerbsstrategie. 10. Aufl., Campus Verlag, Frankfurt, New York, 1999. [Port2002] Porter, M. E.: An interview with Michael Porter. In: Academy of Management Executive, 2 (2002) 16, S. 43-52. [Sche1990] Scheer, A.-W.: EDV-orientierte Betriebswirtschaftslehre. 4. Aufl., SpringerVerlag, Berlin, Heidelberg, New York, 1990. [Sche1998] Scheer, A.-W.: Wirtschaftsinformatik – Referenzmodelle für industrielle Geschäftsprozesse. 2. Aufl., Springer-Verlag, Berlin, Heidelberg, New York, 1998. [Sche2001] Scheer, A.-W.: ARIS – Modellierungsmethoden, Metamodelle, Anwendungen. 4. Aufl., Springer-Verlag, Berlin, Heidelberg, New York, 2001. [Scot2005] Scott, G. M.: Still not solved: The persistent problem of IT strategic planning. In: Communications of the AIS, 16/2005, S. 904-936. [SDLo2003] Scheer, C.; Deelmann, T.; Loos, P.: Geschäftsmodelle und internetbasierte Geschäftsmodelle – Begriffsbestimmung und Teilnehmermodell. In: Loos, P. (Hrsg.): Working Papers of the Research Group Information Systems & Management. Paper 12, Mainz, 2003. [Seid2003] Seidl, D.: The Role of general strategy concepts in the practice of strategy. Münchner betriebswirtschaftliche Beiträge – Munich Business Research, #2003-10, München, 2003. [SLFS2004] Seddon, P. B.; Lewis, G. P.; Freeman, P.; Shanks, G.: The Case of Viewing Business Models as Abstraction of Strategy. In: Communications of the AIS, 13/2004, S. 427-442. [TeTe1995] Teufel, S.; Teufel, B.: Bridging Information Technology and Business – Some Modeling Aspects. SIGOIS Bulletin, 1 (1995) 16, S. 13-17. [Wolf1999] Wolf, F.: Verteilungsaspekte im Rahmen der strategischen Informationssystemplanung. Josef Eul Verlag, Lohmar, Köln, 1999. [Wüth2005] Wüthrich, H. A.: Strategisches Management Quo vadis? Eine paradoxe Auslegeordnung. In: ZfO, 6 (2005) 74, S. 364-366. [Zwiß2002] Zwißler, S.: Electronic Commerce, Electronic Business. Springer-Verlag, Berlin, Heidelberg, 2002.

Modellierung und SOA-Entwurf

Geschäftsprozessmodellierung mittels Software-Services auf Basis der EPK Stefan Huth, Thomas Wieland Zusammenfassung: Um die Lücke zwischen technischer und semantischer Beschreibung bei der Geschäftsprozessmodellierung für service-orientierten Architekturen zu schließen, schlagen wir in diesem Papier eine Erweiterung der ereignisgesteuerten Prozessketten vor. Es kann damit ein Übergang zwischen den EPK und dem technischen Standard BPMN geschaffen werden. Die zusätzlichen Elemente werden eingeführt und an einem Beispiel erläutert.

1

Einleitung

In den letzten zehn Jahren wurden eine ganze Reihe von Ansätzen zur graphischen Modellierung von Geschäftsprozessen vorgestellt. Einige davon konnten sich inzwischen zu Standards bzw. Quasi-Standards entwickeln. Eine solche Modellierung ist zwar nicht für alle Abläufe innerhalb eines Unternehmens oder einer anderen Organisation erforderlich. Zur Anwendung von formalen Analysemethoden mit dem Ziel einer Verifikation oder Optimierung der Prozesse sind solche formale Modelle jedoch unverzichtbar. Die Globalisierung und die Weiterentwicklung der Informationstechnologie haben inzwischen allerdings zu einem Paradigmenwechsel bei der Geschäftsprozessmodellierung geführt. Nach herkömmlicher Methode realisiert die IT die Unterstützung der Prozesse in Form von Komponenten, die eng miteinander gekoppelt sind und jeweils einen bestimmten Teil der Geschäftslogik abbilden. Solche Komponenten werden häufig mit einer Container-Umgebung wie einem Applikationsserver verwaltet und mehr oder weniger zentral betrieben und administriert. Heute hat sich die Sichtweise gewandelt. Verstärkt wird die Idee der sog. serviceorientierten Architektur (SOA) (vgl. [KBSl2004]) favorisiert, bei der interne Dienste durch zahlreiche externe Dienste ergänzt werden, um beispielsweise automatisch Produktionsmaterial von Zulieferern anzufordern, Rechnungen oder Sozialversicherungsabrechnungen an Kunden bzw. Partner zu schicken oder aber Kreditkartenprüfungen vorzunehmen. Dabei stehen nicht mehr die IT-Systeme und ihre Komponenten, sondern die Geschäftsprozesse im Zentrum der Betrachtung. Die Bausteine sind nun lose gekoppelte Dienste (Services) mit gröberer Granularität, aus denen sich die IT-Unterstützung der Abläufe eines Unternehmens zusammensetzt. Die Gestaltung des Zusammenspiels der Dienste wird dabei auch als Orchestrierung bezeichnet. Bei SOA lassen sich neue Anwendungen, Dienstleistungsprodukte und damit auch Prozesse sehr viel leichter realisieren, indem vorwiegend bestehende Dienst-Bausteine neu kombiniert und nur die wenigen fehlenden Elemente ergänzt werden. Auf diese Weise gewinnt das Unternehmen die Dynamik zurück, die es im globalen Wettbewerb benötigt. Aus formaler Sicht hat die SOA-Idee aber auch Einfluss auf die Art, in der Geschäftsprozesse modelliert werden. Denn es ist nicht mehr ausreichend, die Modellierung der Geschäftsprozesse auf ein Unternehmen oder gar nur eine Organisationseinheit zu beschränken. Die tatsächlichen Prozesse reichen längst über Unternehmensgrenzen hinweg. Daher müssen

62

Stefan Huth, Thomas Wieland

auch deren Abbildungen in der IT in der Lage sein, sich übergreifend und in Form von loser Kopplung mit anderen Systemen zu integrieren. Aus unserer Sicht ist es dafür auch notwendig, die Formalismen der Geschäftsprozessmodellierung zu erweitern, und zwar um den Begriff „Service“ (oder „Dienst“). Wir schlagen daher vor, eine weit verbreitete Notation zur Geschäftsprozessmodellierung, die ereignisgesteuerten Prozessketten (EPK), um Elemente für Services zu erweitern. Im Folgenden wollen wir diese Elemente näher erläutern, Beispiele für deren Anwendung in Szenarios mit Service-Kompositionen geben und diesen Ansatz mit anderen formalen Dienstdarstellungen wie BPMN vergleichen.

2

Notationen zur Geschäftsprozessmodellierung

Zunächst wollen wir einen kurzen Überblick über die gebräuchlichsten Modellierungsnotationen für Geschäftsprozesse geben. Um deren Hintergründe und Tendenzen besser einordnen zu können, wollen wir dabei noch einen Blick auf die Organisationen werfen, von denen sie forciert werden. Die Modellierungssprachen lassen sich in grafische und textuelle unterteilen. Einen Überblick gibt folgende Tabelle. Textuelle Sprachen

Grafische Sprachen

Business Process Execution Language (BPEL)

Unified Modelling Language (UML)

Electronic Business XML (ebXML)

Business Process Modelling Notation (BPMN)

XML Process Definition Language (XPDL)

Ereignisgesteuerte Prozessketten (EPK)

Tab. 2-1: Arten von Sprachen zur Geschäftsprozessmodellierung Um komplexe Arbeitsabläufe zu beschreiben, bieten grafische Notationen umfangreichere Möglichkeiten. Sie tragen wesentlich zum visuellen Verständnis bei und können für einige formale Analysemethoden genutzt werden. Für Workflow-Systeme und Laufzeitumgebungen sind allerdings textbasierte formale Sprachen notwendig. Für jegliche grafische Notation ist es daher von entscheidender Bedeutung, ob sich ihre Modelle automatisch in XML-basierte Sprachen umwandeln lassen. Ein recht früher Ansatz wurde vorgestellt von der Workflow Management Coalition (WfMC, www.wfmc.org), die im Jahr 1993 gegründet wurde. Ihr Ziel ist es, die Verbreitung von Workflow-Management-Systemen zu erhöhen und Standards für die Terminologie sowie für die Schnittstellen bei derartigen Systemen zu schaffen. Sie hat dazu – erstmals im Jahr 1995 – das Workflow Reference Model vorgeschlagen. Es soll im Wesentlichen dazu dienen, die Interoperabilität zwischen Workflow-Teilsystemen verschiedener Hersteller zu erhöhen. Für eine umfassende abstrakte Geschäftsprozessmodellierung ist es indes weniger geeignet. Eine bedeutsame Institution bei Standards im Bereich Software Engineering ist die Object Management Group (OMG, www.omg.org), bekannt beispielsweise als die „Gralshüter“ von CORBA und UML. Verständlich ist der ursprüngliche Vorschlag der OMG, die Softwaremodellierungsnotation UML auch als grafische Notation für Geschäftsprozessmodellierung zu verwenden. Parallel dazu wurde bei der IBM die

Geschäftsprozessmodellierung mittels Software-Services auf Basis der EPK

63

Business Process Modelling Notation (BPMN) [Whit2004] entworfen, welche von einer Organisation namens Business Process Management Initiative (BPMI) betreut wurde. Im Jahr 2005 fusionierte die BPMI mit der OMG und übergab die Pflege von BPMN an diese. Der jetzige OMG-Standard BMPN ist inzwischen eine weithin akzeptierte und verbreitete Spezifikationssprache. Alternativ bzw. komplementär dazu sind die XML-basierten formalen Sprachen Business Process Execution Language (BPEL) [AAAs2007] und Electronic Business XML (ebXML). Beide sind bei der Organization for the Advancement of Structured Information Standards (OASIS, www.oasis-open.org) entwickelt worden und werden auch von dieser koordiniert. Sowohl BPEL als auch ebXML stellen nicht-grafische Beschreibungen für Arbeitsabläufe dar. Für unseren Kontext ist vor allem BPEL von Bedeutung, handelt sich doch um das heute am meisten genutzte Format für Geschäftsprozessmodellierung in XML. Die OMG und OASIS sind beide herstellerneutrale Vereinigungen. Sie verstehen sich nicht als Konkurrenten, sondern arbeiten eng miteinander zusammen und ergänzen sich gegenseitig. Dementsprechend sind auch bswp. BPMN und BPEL nicht als Alternativen mit gleicher Zielsetzung, sondern als komplementäre Konzepte zu verstehen. Neben diesen Organisationen gibt es noch eine ganze Reihe von Firmen, vorwiegend aus der IT-Branche, sowie Hochschulen und Forschungseinrichtungen, die ihre eigenen Ansätze für Geschäftsprozessmodellierung entwickelt haben. Einige dieser Vorschläge basieren auf den Notationen, die von o.g. Organisationen herausgegeben wurden. Ein weiterer bedeutender Vertreter einer rein grafischen Notation sind schließlich die ereignisgesteuerten Prozessketten (EPK). Dieses Konzept wurde gemeinsam von SAP und der Universität des Saarlands seit 1992 als halbformale Beschreibung von Geschäftsprozessen und Arbeitsabläufen entwickelt (vgl. [Sche2006]). Diese werden vom gröberen zum feineren Niveau modelliert. Dabei kann eine Ebene in weitere Einzelprozesse aufgeteilt werden, die dann separat in größerer Detailtiefe dargestellt werden. Die Elemente des EPK-Formalismus sind Funktionen, Ereignisse und der Kontrollfluss. In der eEPK, der erweiterten EPK, finden sich zudem Organisationseinheiten, Dokumente und Informationsobjekte. Die ereignisgesteuerten Prozessketten werden verwendet, um einen Prozess aus der Geschäftsperspektive zu beschreiben. Sie können so ein Mittel zur individuellen Anpassung von prozessorientierten Informationen sein. Das EPK-Konzept bildet auch die Basis der ARIS-Plattform, wie sie von der IDS Scheer AG vertrieben wird.

3

Services in Geschäftsmodellen

Die herkömmlichen Techniken für die Geschäftsprozessmodellierung haben im letzten Jahrzehnt gute Dienste geleistet. Angesichts des oben beschriebenen heutigen Paradigmenwechsels von isolierten IT-Systemen zu service-orientierten Systemen stellen sich auch für die Geschäftsprozessmodellierung einige Herausforderungen, die es zu meistern gilt.

64

3.1

Stefan Huth, Thomas Wieland

Geschäftliche Relevanz von Services

Für die reine Modellierung eines geschäftlichen Ablaufs ohne die Perspektive auf ein unterstützendes IT-System ist der klassische Ansatz immer noch sinnvoll und nützlich. Doch diese Situation ist immer seltener anzutreffen und zwar aus gutem Grund: Um Geschäftsprozesse heute kosteneffizient und flexibel etablieren zu können, ist deren Unterstützung durch perfekt zugeschnittene IT-Systeme zwingend erforderlich. Immer wenn Fachexperten und IT-Experten gemeinsam daran arbeiten, ein Modell zu entwickeln, zu verfeinern und zu optimieren, stehen die IT-Fachleute vor der Aufgabe, die Konsequenzen in Ihre Überlegungen einzubeziehen, die sich aus einer service-orientierten Realisierung ergeben. In diesem Sinne hebt sich die „SOA-Geschäftsprozessmodellierung“ deutlich von der klassischen Vorgehensweise ab. In einem EPK-Modell könnte nun jede Funktion durch einen Service realisiert werden. Ein solcher Service ist aber nicht nur ein beliebiges Artefakt der Programmierung. Bereits die Entscheidung, welche Art von Service genutzt werden soll, ist genauso technischer wie strategisch-ökonomischer Natur. Es ist festzulegen, in welche der drei folgenden Kategorien dieser Service fallen soll: 1. rein interner Service, der nur innerhalb des Unternehmens bzw. der Organisation installiert und genutzt wird 2. interner Service, der vom Unternehmen selbst zur Verfügung gestellt und gewartet wird, der aber so ausgereift und leistungsfähig ist, dass er Dritten zur Nutzung angeboten werden könnte und damit ggf. ein neues Geschäftsmodell eröffnet 3. ein Service, der intern wegen fehlender Datengrundlage, aus Kostengründen oder wegen organisatorischer Restriktionen nicht zur Verfügung gestellt werden kann und daher von einem externen Anbieter genutzt wird Offensichtlich führen die zweite als auch die dritte Kategorie zu technischen, aber auch zu wirtschaftlichen Implikationen. Wenn man beispielsweise externe Dienste einbindet, erzeugt man damit Abhängigkeiten und erhöht die Komplexität des Managements der IT-Dienstleistungen und der Softwarekomponenten. Daraus wird offensichtlich, dass selbst in einem Prozessmodell mit rein geschäftlichem Fokus diese Aspekte nicht außer Acht gelassen werden dürfen, sondern sich auf die eine oder andere Weise ausdrücken lassen sollten. Dafür ist eine Erweiterung der Notationsmöglichkeiten erforderlich. 3.2

Aufrufarten von Services

Services können nach zwei verschiedenen Mustern aufgerufen werden: x

synchron, d.h. der Prozess wartet so lange, bis der Dienst abgearbeitet ist, und fährt dann unmittelbar mit dem nächsten Schritt fort, oder

x

asynchron, d.h. das Ergebnis des Service wird erst zu einem späteren Zeitpunkt zurückgegeben.

Daher hat die Art des Aufrufs des Services hinter einer EPK-Funktion eine direkte Auswirkung auf das Modell. Bei einem optimierten Modell sollte der asynchrone Charakter einer Funktion berücksichtigt und aktiv genutzt werden, zum Beispiel durch Ausführung einer anderen Funktion parallel dazu in der Zwischenzeit, so dass der gesamte Workflow nicht durch das Warten auf die Beendigung des Service

Geschäftsprozessmodellierung mittels Software-Services auf Basis der EPK

65

blockiert wird. Diese Rückantwort eines asynchronen Dienstes ist dann einfach ein weiteres Ereignis. Es sollte indessen explizit modelliert werden, da es sich dabei ja nicht um ein Ereignis handelt, das von einer Person oder einer Organisationseinheit ausgelöst wird, sondern durch ein automatisiertes technisches System. Daher erscheint es sinnvoll und ratsam, diese besondere Eigenschaft eines derartigen Ereignisses im Modell widerzuspiegeln. Letztlich könnten ganze Prozessketten durch ein solches Ereignis gestartet werden. Im schlimmsten Fall könnte der Service auch einen Fehler zurückgeben, zum Beispiel weil der externe Dienst nicht erreichbar ist oder einen bestimmten Fehlerzustand anzeigt. Bei Funktionen, die von diesem Service abhängen, gilt es sie im Hinblick auf diese Möglichkeit zu modellieren. 3.3

Dynamisches Auffinden von Services

Das SOA-Konzept verspricht, dass solche Softwaresysteme nicht mehr monolithisch und fest „verschraubt“ sind, sondern dynamisch und agil. So ist es beispielsweise möglich, dass ein Service von einem IT-System aufgerufen wird, der zum Zeitpunkt des Entwurfs dieses Systems noch völlig unbekannt war, der sich höchstens an eine vordefinierte Schnittstelle halten muss. Zur Laufzeit setzt sich das System mit einem Verzeichnisdienst in Verbindung, fragt nach einem Service, der eine bestimmte Aufgabe erfüllt und dafür eine bestimmte Schnittstelle unterstützt, und erhält die technischen Daten für einen oder mehrere vormals unbekannte Services. Solche Verzeichnisdienste können beispielsweise von branchenspezifischen Marktplätzen für Zulieferer angeboten werden. Aber auch ein Enterprise Service Bus als Vermittlung in einer unternehmensweiten service-orientierten Architektur kann als Verzeichnisdienst auftreten. Für die Geschäftsprozessmodellierung kann es somit zu der Situation kommen, dass Funktionen in einem Modell eingefügt werden, die nicht nur völlig extern sind, also außerhalb der Kontrolle der jeweiligen Organisation oder Organisationseinheit, sondern die auch noch zum Zeitpunkt der Erstellung des Modells unbekannt sind. All diese Aspekte, die dem service-orientierten Entwurf des IT-Systems inhärent sind, welches den Geschäftsprozess unterstützt, könnten auch in einem Prozessmodell ausgedrückt werden, in dem nur die klassische Notation eingesetzt wird. In diesem Fall wären die oben beschriebenen Besonderheiten jedoch nicht explizit und damit leicht erkennbar, sondern lediglich implizit. Zudem ist es sehr viel leichter, die technischen von den geschäftlichen Aspekten zu trennen, wenn diese Situationen auf einen Blick erfassbar sind. Diese Ziele sollen mit der sEPK-Erweiterung erreicht werden.

4

sEPK – service-orientierte ereignisgesteuerte Prozessketten

Die von uns vorgeschlagene Erweiterung, die wir sEPK nennen wollen für „serviceorientierte ereignisgesteuerte Prozessketten“, fügt neue Elemente für eine serviceorientierte Geschäftprozessmodellierung hinzu. Um das Lesen und unmittelbare Verstehen solcher erweiterten Prozessmodell zu erleichtern, gibt es verschiedene Symbole für Services, deren Eigenschaften und Implikationen. Eine Intension hinter der Schaffung der neuen Symbole war, dass der Modellierer damit sofort die Struktur des Geschäftsprozessmodells erkennen kann, ohne dass der dazu in den Kom-

66

Stefan Huth, Thomas Wieland

mentaren nachschlagen muss. Mit einem Blick lassen sich so Prozessereignisse, die von Funktionen herrühren, von synchronen oder asynchronen Dienstresultaten unterscheiden. In diesem Abschnitt wollen wir einen Überblick über die neuen Erweiterungen für den EPK-Formalismus geben. 4.1

Neue Elemente für die EPK

Das erste Symbol ist eine Abwandlung des Funktionssymbols der EPK-Notation. Es stellt eine Funktion eines synchron aufgerufenen Service dar (Abbildung 4-1). Man setzt es wie eine normale Funktion in einem Geschäftsprozess innerhalb einer Prozesskette ein. Ein synchroner Service wird üblicherweise als entfernter Prozeduraufruf realisiert. Um mit dem nächsten Ereignis oder Service fortzufahren, muss die aufgerufene Funktion geendet haben.

Abb. 4-1: Synchroner Service (sEPK-Notation) Abbildung 4-2 zeigt das Symbol für einen asynchronen Service. Genau wie der synchrone Service kann der asynchrone anstelle einer normalen Funktion verwendet werden. Der einzige Unterschied ist hierbei, dass der asynchrone Service nicht geendet haben muss, um zum nächsten Schritt weiterzugehen. Der Service kann daher aufgerufen und anschließend „vergessen“ werden. Diese Eigenschaft sollte jedoch vom Modellierer des Prozesses berücksichtigt werden. In Abschnitt 4.2 wollen wir daher einen genaueren Blick auf die Nutzung von asynchronen Services in EPKs werfen.

Abb. 4-2: Asynchroner Service Eine der wichtigsten Neuerungen in der sEPK ist das Service-Template-Symbol (Abbildung 4-3). Wenn bei der Modellierung ausgedrückt werden soll, dass ein bestimmter Service zur Entwurfszeit noch unbekannt ist und erst zur Laufzeit zu bestimmen ist, sollte dieses Symbol dafür eingesetzt werden. Es wird nur über einen Namen spezifiziert. Das Template kann sowohl für einen synchronen als auch für einen asynchronen Service stehen. Die physikalische Instanz dieses Services wird dann erst zur Laufzeit bestimmt, z.B. durch Nachschlagen bei einem entsprechenden Verzeichnisdienst.

Geschäftsprozessmodellierung mittels Software-Services auf Basis der EPK

67

Abb. 4-3: Service-Template Neben den Funktionen benötigt die service-orientierte Geschäftsprozessmodellierung noch einige besondere Ereignisse. Das erste neue Element ist das AusnahmeEreignis („exception“, Abbildung 4-4). Es weist darauf hin, dass eine Ausnahme von einem Service geworfen werden könnte, die zu behandeln ist.

Abb. 4-4: Ausnahme-Ereignis Daneben wird noch das Timeout-Ereignis als neues Element eingeführt (Abbildung 4-5). Es wird verwendet für Timeouts, die im Zusammenhang mit Services auftreten könnten. Das kann beispielsweise der Fall sein, wenn ein Service aufgerufen wird und nicht innerhalb einer vorgegebenen Zeit antwortet. Es kann aber auch für Fälle verwendet werden, in denen Funktionen von Mitarbeitern ausgeführt werden müssen und die Situation eines versäumten Termins explizit berücksichtigt werden soll. Dies kann etwa für automatisierte Workflow-Systeme von Bedeutung sein. Bei Services treten Timeouts zwar häufiger bei synchronen Diensten auf. Sie sind jedoch auch bei asynchronen Services möglich.

Abb. 4-5: Timeout-Ereignis Als letztes neues Element wollen wir das Nachricht-erhalten-Ereignis (Abbildung 4-6) vorschlagen. Es stellt ein Ereignis dar, das verwendet wird um auszudrücken, dass eine Nachricht von einem anderen System erwartet wird, die behandelt werden sollte. Ein typischer Fall ist die Rückgabenachricht eines asynchronen Dienstes. Diese Art von Ereignis kann beispielsweise auch bei der Realisierung mittels einer nachrichtenorientierten Middleware eingesetzt werden. Wie andere Ereignisse auch kann es sowohl eine Prozesskarte starten als auch inmitten eines Workflow stehen.

68

Stefan Huth, Thomas Wieland

Abb. 4-6: Nachricht-erhalten-Ereignis 4.2

Integration in die EPK

Die Symbole der sEPK können wie die anderen Elemente der eEPK verwendet werden. Sie bieten lediglich zusätzliche Möglichkeiten für die Modellierung von Prozessen mit Services. Abbildung 4-7 zeigt eine mögliche Anwendung in einem Geschäftsprozess. Dabei wird eine Prozesskette durch ein Nachricht-erhaltenEreignis gestartet.

Abb. 4-7: Prozesskette, die von einem Nachricht-erhalten-Ereignis gestartet wird Beim Modellieren eines Workflows können synchrone und asynchrone Services nacheinander oder parallel ausgeführt werden. Abbildung 4-8 zeigt, wie die beiden Arten von Services parallel genutzt werden können. Wird der synchrone Service verwendet, so wird die Kette normal nach der Beendigung der Funktion fortgesetzt. Falls der asynchrone Service aufgerufen wird, setzt sich der Prozess fort ohne zu wissen, ob und wann die Funktion endet. Um sicherzustellen, dass die Funktion erfolgreich beendet werden konnte, sollte daher bei der Modellierung ein entsprechendes Ereignis eingefügt werden.

Geschäftsprozessmodellierung mittels Software-Services auf Basis der EPK

69

Abb. 4-8: Workflow mit synchronen und asynchronen Services Es ist auch möglich so lange abzuwarten, bis der asynchrone Dienste antwortet. Doch der übliche Anwendungsfall einer asynchronen Kommunikation beinhaltet, dass die Funktion aufgerufen wird und die Antwort zu einem späteren Zeitpunkt eintrifft. Daher ist dies ein entscheidender Aspekt bei der Modellierung mit Services, besonders dann, wenn es parallele Wege in der Prozesskette gibt. Betrachten wir daher noch das Zusammengehen der beiden Äste genauer. Wenn zwei oder mehr Zweige miteinander verbunden sind, bedeutet das, dass der gesamte Prozess so lange warten muss, bis alle beendet sind, d.h. bis eine Antwort eintrifft oder ein Timeout-Ereignis eintritt. Bei synchronen Diensten, die zumeist entfernte Prozeduraufrufe verwenden, wird die Kette fortgesetzt, wenn die Funktion endet. Bei asynchronen Diensten – und ebenfalls bei einer typischen Kommunikation mittels nachrichtenorientierter Middleware – ist der Funktionsaufruf mit dem Absenden der Nachricht beendet. Die Antwort hängt dann vom aufgerufenen Service ab. Im schlimmsten Fall, falls die Antwort ganz ausbleibt, kommt so der gesamte Workflow durch das Warten auf eine Nachricht zum Erliegen. In dieser Situation sollte ein Nachricht-erhaltenEreignis eingesetzt werden, das der Service auslöst, um über seinen erfolgreichen Abschluss zu informieren. Bei asynchronen Diensten kommt gelegentlich auch das „fire and forget“-Muster vor, bei dem ein Service aufgerufen wird und sich die aufrufende Kette nicht für das Resultat interessiert. Die Konsequenz davon ist letztlich, dass also ein Workflow auch mit dem Aufruf eines Service enden kann – ohne zu wissen, ob alle Aufrufe aus

70

Stefan Huth, Thomas Wieland

der Kette auch erfolgreich abgearbeitet werden konnten (Abbildung 4-9). Ein Beispiel dafür ist das Verschicken einer E-Mail an einen Kunden, wenn ein Bestellvorgang abgeschlossen ist. Diese Modellierungsvariante steht im Widerspruch zu den Bildungsregeln von EPKs. Daher ist sie nur in seltenen Ausnahmefällen zu verwenden. Sie zeigt indessen, dass das SOA-Paradigma über das Potenzial verfügt, die Praktiken der Geschäftsprozessmodellierung auch in unkonventionelle Richtungen zu erweitern.

Abb. 4-9: Ein Workflow endet mit dem Aufruf eines asynchronen Service 4.3

Zusammengesetzte Services

Abbildung 4-10 zeigt den Vorgang einer elektronisch unterstützten Bestellung bei einem Vertraglieferanten der Hochschule Coburg, in eine sEPK überführt. Ausgangspunkt hierfür war eine eEPK des Prozesses. Der Besteller gibt die gewünschten Waren in den Bestellservice ein. Dieser fragt, über einen externen Service des Lieferanten, die Preise der gewünschten Artikel ab. Da hierbei u.U. manuelle Eingaben auf Seiten des Lieferanten erforderlich sind, ist dieser Service als asynchron gekennzeichnet. Anschließend werden die erhaltenen Daten in das System eingetragen. Wenn die Bestellung komplett ist, wird diese vom Nutzer (Besteller) signiert und abgeschickt. Der Kostenstellenverantwortliche kann die Liste, samt Preise, über den Bestellservice abfragen und signiert diese ebenfalls, falls die Bestellung keine Fehler enthält. Die Haushaltsstelle der Hochschule entnimmt die Liste dem Bestellservice und trägt eine Vormerkung in das interne Buchungskonto ein. Anschließend werden die Signaturen überprüft. Da es an der Hochschule noch keine einheitliche PKI gibt, ist der Service zur Signaturprüfung in Abhängigkeit von den beteiligten Personen dynamisch aufzusuchen. Sind alle Angaben korrekt, wird der Service des Lieferanten aufgerufen, um die Bestellung auszuführen. Damit ist der Bestellvorgang abgeschlossen.

Geschäftsprozessmodellierung mittels Software-Services auf Basis der EPK

71

Waren sollen bestellt werden

Besteller

Materialliste Materialliste

Bestellservice

S Waren eingeben

Gewünschte Waren eingegeben

S

S

Preisliste

Bestellservice

S Preise eintragen

Preise erhalten

Kostenstellenverantwortlicher

Produktservice Preise abfragen

Bestellservice Prüfen und signieren

Bestellung vollständig

Bestellung Geprüft und genehmigt

Haushaltsstelle

S

Buchhaltungsservice Bestellung eintragen

Bestellung vorgemerkt

Signaturen gegen PKI prüfen

Signaturen korrekt

T S

S

Bestellung beim Lieferanten ausführen

Bestellung abgeschlossen

Abb. 4-10: Beispiel für einen mit sEPK modellierten Prozess

72

5

Stefan Huth, Thomas Wieland

Modellierung von SOA-Systemen mittels sEPK

Obwohl die Ergänzungen des vorgeschlagenen sEPK-Formalismus gegenüber den klassischen eEPK nur eine Erweiterung um einige grafische Bausteine und Notationsregeln bestehen, sind es doch gerade diese Elemente, die für einen serviceorientierten Workflow entscheidend sind. Zudem hat diese Erweiterung den Vorteil, dass sie sich harmonisch mit den üblichen Elementen integriert. Die sEPK als Erweiterung der eEPK verfügt insgesamt – verglichen mit anderen grafischen Notationen wie BPMN – über mehr Funktionselemente, wie Organisationseinheiten oder Information/Material- und Ressourcen-Objekten. Somit lassen sich auf diese Weise mehr Facetten des Workflows abbilden. Da die neuen Elemente optional sind, entsteht durch deren Vermeidung aus der sEPK wieder die eEPK. Falls es dagegen notwendig und sinnvoll ist, Services als Funktionen anzubieten oder Funktionen als Services zu kennzeichnen, können die neuen Symbole verwendet werden. Die verschiedenen formalen Notationen aus Abschnitt 1 dienen alle unterschiedlichen Zwecken. Damit lässt sich zusammen genommen eine Werkzeugkette aufbauen, die von der reinen Geschäftsprozessanalyse bis zum Laufzeitsystem der entsprechenden IT-Komponenten reicht. Zunächst analysieren Fachexperten die realen Prozesse und erzeugen dazu formale Beschreibungen, z.B. unter Verwendung der EPK-Notation. Oft ist dieser Schritt auch mit einer Optimierung dieser Prozesse verbunden. Diese Informationen können dann verwendet werden, um die rechnergestützten Abbildungen direkt zu modellieren, im Falle eines SOA-Ansatzes mittels BPMN. Doch diese beiden Formalismen gehen von sehr unterschiedlichen Sichtweisen auf die Geschäftsprozesse und die Informationssysteme aus. Während die EPKs sich auf die Geschäftslogik und die organisatorischen Randbedingungen konzentrieren, sind BPMN-Modelle stärker technologiezentriert und arbeiten daher auf einem anderen Abstraktionsniveau. Es fehlt also eine Verbindung zwischen diesen beiden Modellen. Diese Verbindung stellt der oben vorgestellte Formalismus der serviceorientierten EPKs dar. Fügt man diese Modellierungsmöglichkeit in die Werkzeugkette ein, so erhält man eine relativ bruchfreie schrittweise Verfeinerung von der Geschäftsprozessanalyse bis zur Ablaufumgebung (Abbildung 5-1).

Fachexperten erzeugen

(e)EPC

ITExperten verfeinern

sEPC

Automatische Transformation

BPMN

Automatische Transfor- mation

BPEL

Abb. 5-1: Werkzeugkette von der Prozessanalyse bis zur Prozessablaufumgebung Die anfängliche formale Prozessbeschreibung mittels EPKs (oder eEPKs) wird nach wie vor von Fachexperten erledigt. Mit dem Ziel einer service-orientierten Architektur übernehmen dann IT-Experten dieses Modell und verfeinern bzw. konkretisieren es. Dabei werden Funktionen daraufhin überprüft, ob sie als Services realisiert werden können oder müssen, es werden synchrone und asynchrone Kommunikationspfade hinzugefügt und mögliche Ausnahme sowie Nachricht-erhalten-Ereignisse integriert

Geschäftsprozessmodellierung mittels Software-Services auf Basis der EPK

73

oder modifiziert. Das Ergebnis ist dann immer noch ein Geschäftsprozessmodell, das jedoch die nichtfunktionale Anforderung erfüllt, dem SOA-Paradigma zu genügen. Der entscheidende Vorteil dieses Zwischenschritt ist, dass mit dieser Verfeinerung und Klarstellung das EPK-Modell auf ein technologie-orientiertes Niveau gebracht wird – und das ohne einen vollständigen Bruch der Methodik. Auf diese Weise kann eine Abbildung von der geschäftlichen auf die technische Realisierung hergestellt werden. Auf der anderen Seite basieren die sEPK auf denselben Bausteinen wie BPMN, so dass eine automatische Transformation von sEPK nach BPMN möglich wird. Der nächste Schritt, die weitere automatische Transformation von BPMN in die Ausführungssprache BPEL ist bereits Forschungsziel verschiedener Arbeitsgruppen, bietet jedoch auch noch einige systematische Herausforderungen [ODAH2006] [OADH2006] [ReMe2006].

6

Vergleich zwischen sEPK und BPMN

Man könnte die sEPK-Notation als eine Abbildung der BPMN-Elemente in den EPKFormalismus betrachten. Wie oben erläutert erlangen diese Erweiterungen Bedeutung durch den Einfluss der Serviceorientierung auf Geschäftsprozesse und deren Modellierung. Die Ähnlichkeit zwischen sEPK und BMPN ist daher nicht zufällig, sondern durchaus beabsichtigt, da es sich bei BPMN um einen weit verbreiteten Standard für Geschäftsprozessmanagement handelt. Doch BPMN ist verhältnismäßig stark technik-orientiert und verfügt nicht über Elemente wie Organisationseinheit oder Informationsobjekt, die wesentliche Bestandteile der eEPK sind. Auf der anderen Seite verfügt aber BPMN über einige Merkmale, die in eEPK und sogar noch in sEPK fehlen, zum Beispiel bei der Modellierung von eventbasierten Gateways in einem Workflow. Der BPMN-Standard beinhaltet dafür ein eigenes Darstellungsformat. Selbst mit sEPK muss zur Modellierung einer solchen Verzweigung eine umfangreichere Ereignisverknüpfung angelegt werden. Dies ist zwar eine Einschränkung im Vergleich zu BPMN. Eine Erweiterung des EPKFormalismus um derartige Möglichkeiten hätte jedoch eine zu große, umwälzende Änderung und eine Abkehr von den bekannten Bildungsregeln für EPK bedeutet. Damit wären die Abwärtskompatibilität und letztlich wohl auch die Akzeptanz gefährdet gewesen. Daher verzichtet der sEPK-Vorschlag auf solche Formate. Eine weitere Abweichung zwischen den beiden Notationen liegt in der Unterteilung der sonstigen Ereignisse bei BPMN. Dort wird zwischen Start-, Zwischen- und Endereignissen unterschieden. Jeder der drei Typen wird durch ein eigenes Symbol gekennzeichnet. In der sEPK-Notation gibt es nur eine Art von Ereignis und keine Unterscheidung nach dessen Position im Workflow. In Abbildung 6-1 findet sich der Prozess aus Abschnitt 4.3 (Abbildung 4-10) wieder, diesmal mittels BPMN modelliert. Der auffälligste Unterschied zwischen den beiden Workflows sind die verschiedenen Ereignisarten sowie die Kennzeichnung von synchronen bzw. asynchronen Services bei sEPK. Die anderen Elemente werden in ähnlicher Form verwendet.

74

Stefan Huth, Thomas Wieland

Abb. 6-1: Beispiel für einen mit BPMN modellierten Prozess (gleicher Prozess wie in Abb. 4-10)

Geschäftsprozessmodellierung mittels Software-Services auf Basis der EPK

7

75

Fazit und Ausblick

Die service-orientierten ereignisgesteuerten Prozessketten verbinden die Vorteile der gebräuchlichen eEPK-Notation mit den Eigenschaften des technischen Formats BPMN. Dabei wird der eEPK-Formalismus um die Elemente synchroner und asynchroner Service, Template-Service, Ausnahme-Ereignis, Timeout-Ereignis sowie Nachricht-erhalten-Ereignis erweitert. Damit eröffnet sich die Möglichkeit, sowohl klassische Workflows als auch Prozesse für service-orientierte Architekturen zu modellieren. Da sich die BPMN-Definition noch im Fluss befindet und es bereits jetzt immer noch einige wenige Elemente gibt, die kein Pendant in der sEPK haben, ist als weiterer Ausbau eine kontinuierliche Aktualisierung sowie eine noch stärkere Abdeckung der BPMN-Elemente im Rahmen einer noch etwas umfangreicheren sEPK geplant. Der nächste Schritt ist dann, ein grafisches Werkzeug zu schaffen, mit dem sich sEPK-Modelle in BPMN und diese weiter in eine Ausführungssprache wie BPEL transformieren lassen, wie in Abb. 5-1 gezeigt. Mit einem solchen Werkzeug kann der Benutzer Prozesse auf der Basis bestehender oder geplanter Services modellieren und die erzeugten BPEL-Daten unmittelbar in eine Ablaufumgebung integrieren (wie auch in [Whit2005] vorgeschlagen). Die wissenschaftliche interessanteste Idee an diesem Werkzeug ist die Transformation von Modellen zwischen verschiedenen Notationen während der Bearbeitung. So könnte ein Prozess von sEPK nach BPMN ohne Informationsverlust umgewandelt werden. Das ist möglich, da sich die sEPK-Elemente injektiv auf die BPMN-Gegenstücke abbilden lassen. Somit sind alle Bestandteile für ein service-orientiertes Geschäftsprozessmanagement gegeben. Die nächste Herausforderung ist dann die Transformation der Modelle nach BPEL, die sicher nur teilweise automatisch erfolgen kann.

8

Danksagung

Diese Arbeit wurde unterstützt durch eine Fördermaßnahme des Bayerischen Staatsministeriums für Wirtschaft, Technologie, Verkehr und Infrastruktur, wofür die Autoren ihren Dank ausdrücken möchten. Weiterer Dank geht an unsere Kollegen an der Hochschule Coburg sowie bei CORYX Software für anregende Diskussionen und kritische Anmerkungen.

Literaturverzeichnis [AAAs2007] Alves, A.; Arkin, A.; Askary, S. et al.: Web services business process execution language version 2.0. Technical report, WS-BPEL TC OASIS, January 2007. [KBSl2004] Krafzig, D.; Banke, K.; Slama, D.: Enterprise SOA: Service-Oriented Architecture Best Practices. Prentice Hall PTR: Upper Saddle River, NJ, 2004. [ODAH2006] Ouyang, C.; Dumas, M.; van der Aalst, W.; ter Hofstede, A: From business process models to process-oriented software systems: The BPMN to BPEL way. BPM Center Report BPM-06-27, BPMcenter.org, 2006.

76

Stefan Huth, Thomas Wieland

[OADH2006] Ouyang, C.; van der Aalst, W.; Dumas, M.; ter Hofstede, A.: Translating BPMN to BPEL. BPM Center Report BPM-06-02, BPMcenter.org, 2006. [ReMe2006] Recker, J.; Mendling, J.: On the translation between BPMN and BPEL: Conceptual mismatch between process modeling languages. In T. Latour und M. Petit, Hrsg., Proceedings of Workshops and Doctoral Consortium for the 18th International Conference on Advanced Information Systems Engineering. Namur University Press, Luxembourg, 2006. [Sche2006] Scheer, A.-W.: ARIS – Business Process Modelling. Springer: New York et al., 3. Auflage, 2006. [Whit2004] White, S.A.: Business Process Modeling Notation (BPMN) version 1.0. Business Process Management Initiative, bpmi.org, 2004. [Whit2005] White, S.A.: Using BPMN to model a BPEL process. BPTrends, 3(3):1–18, 2005.

Geschäftsprozessmodellierung für Service-Orientierte Architekturen Harald Störrle, Wolfgang Glock Zusammenfassung: In diesem Beitrag stellen wir eine Fachmodell-getriebene Methode für SOA-Entwicklungsprojekte vor. In der Begrifflichkeit der Gartner Group wird dieser Ansatz als „Business Driven SOA“ bezeichnet. Zentrales Anliegen der vorgestellten Methode ist die Durchgängigkeit beim Übergang vom fachlichen zum technischen Modell inkl. der Überführung in den Betrieb. Wir stellen unseren Ansatz zunächst im Überblick dar, und gehen dann auf die Transformation des zentralen Artefaktes der Analysephase (fachliche Prozessmodelle) in Artefakte der Entwurfsphase (technische Prozessmodelle) im Detail ein. Im Vergleich zu anderen Ansätzen dieser Art ist unser Ansatz weitaus detaillierter und präziser beschrieben und bereits in zwei industriellen Großprojekten validiert worden.

1

Einleitung

In den letzten Jahren hat sich die Service-Orientierte Architektur (SOA) zu einem bedeutenden Paradigma für die Realisierung von Anwendungssystemen entwickelt, wenn auch die wissenschaftliche Aufbereitung erst am Anfang steht (cf. [HHVo2006, S. 395]). Insbesondere Projekte zur Integration und Konsolidierung von Anwendungslandschaften kommen heute kaum mehr an SOA-Konzepten vorbei. Wie so oft in der IT ist es auch beim Thema SOA schwer, Marketingschlagworte von echtem Fortschritt zu unterscheiden. Daher wollen wir in unserem Beitrag zunächst kurz unsere Sicht auf das Thema SOA darstellen. Services sind in unseren Augen fachliche ausgerichtete und getriebene SoftwareKomponenten. Beschreibungen von Services sind daher primär Beschreibungen der unterstützten Geschäftsprozesse, nicht der unterstützenden Anwendungssysteme oder gar zugrundeliegender Technik. Da Beschreibungen zwangsläufig zweckbezogene Abstraktionen (also Modelle, siehe [Stac1977]) sind, sind folglich Beschreibungen von Services Modelle. Die wichtigsten Modelle stellen Geschäftsprozesse, fachliche und technische Services, Informationen und Applikationen dar. Wenn aber Modelle zentral für die Entwicklung service-orientierter Systeme sind, dann handelt es sich bei SOA-Ansätzen immer implizit um modellgetriebene Prozesse im Sinne der Model Driven Architecture (MDA, siehe [OMGr2003]). Im Gegensatz zu bekannten Ansätzen des Geschäftsprozessmanagements (GPM) (stellvertretend sei ARIS genannt), bietet SOA aber eine Durchgängigkeit hin zur Entwicklung und sogar zum Betrieb, die GPM-Ansätze noch vermissen lassen. Das Paradigma der Service-Orientierung hat als zentrales Anliegen die Integration heterogener Anwendungslandschaften bei gleichzeitiger Beibehaltung bzw. Erhöhung der Reaktionsfähigkeit und Steuerbarkeit von Organisationen und Reduktion der IT-Kosten. Dies soll dadurch erreicht werden, dass die Geschäftsprozesse einer Organisation als lose gekoppelte Services strukturiert werden. Ihre Verbindung zu Prozessen erfolgt dann nicht klassisch durch Programmierung, sondern durch Konfiguration („Orchestrierung“) basierend auf den Beschreibungen der Services, also deren fachlichen Modellen.

78

Harald Störrle, Wolfgang Glock

Der Erfolg von Integrationsmaßnahmen hängt gleichermaßen von der Fachabteilung, der Anwendungsentwicklung und der IT-Betriebsorganisation ab: die Anwendungsentwicklung muss die Geschäftsprozesse automatisieren, der Betrieb muss im laufenden Betrieb die Verfügbarkeit sicherstellen und die Fachabteilung muss die Geschäftsprozesse leben und verbessern. Für einen Erfolg müssen offensichtlich alle drei Stakeholder zusammenwirken. Aus unserer Sicht liegt der Nutzen und Beitrag von SOA vor allem darin, eine gemeinsame und tragfähige Metapher für alle drei Stakeholder – als eine von allen akzeptierbare Kommunikationsbasis – bereit zu stellen. 1.1

Service-Orientierte Architektur ist nicht gleich Web-Services

Zunächst sind die beiden Themenbereiche Web-Services und SOA grundsätzlich voneinander zu trennen. Web-Services sind eine von vielen möglichen technologischen Grundlagen zur Implementierung einer SOA. Umgekehrt ist eine SOA eine sinnvolle, gar natürliche, aber keineswegs zwangsläufig notwendige Architektur für Systeme auf der Basis von Web-Services. Aus unserer Sicht ist SOA ein primär konzeptueller Ansatz, also eine Art Architekturmuster oder Architekturstil bzw. Entwurfs-Metapher [BMRS1998, Shaw1995], in jedem Fall ein Element der Methodik bzw. des Entwicklungsprozesses. Web-Services andererseits sind ein eher technologisch bzw. von der Middleware-Ebene her getriebener Ansatz. Die Implikationen dieses Ansatzes beziehen sich daher in erster Linie auf die technische Architektur; die Implikationen der SOA hingegen beziehen sich auf die Entwicklungsmethodik, den Prozess und die Organisation insgesamt. Das gleiche Argument liefert auch die Abgrenzung zwischen SOA und anderen, eher technisch ausgerichteten Middleware-Technologien wie Corba, RPC oder Jini. Insofern ist SOA mehr als „Corba++“. 1.2

Services sind fachliche Komponenten

Eine Service-Orientierte Architektur ist zuallererst eine spezielle Klasse von Software- und Systemarchitektur, und adressiert damit die klassischen Architekturthemen wie Architectural Glue, Wiederverwendung und Komponenten. Wir definieren in unserem Ansatz einen Service als eine fachlich motivierte und daher grobkörnige Komponente (Business Objects [Sims1994]), deren Lebenszyklus von der Anforderung über die klassischen Entwicklungsphasen bis in den Betrieb und die Wartung reicht (Lifecycle components [Stör1998, Stör2001]). 1.3

Service als Metapher verbindet Stakeholder

An dieser Stelle nun bietet die Service-Orientierte Architektur einen neuen, vielversprechenden Ansatz. Das zentrale Konzept des Services definiert eine fachlich oder technisch motivierte Komponente grober Granularität, kleiner als eine (Teil-)Applikation, aber größer als ein Modul.

Geschäftsprozessmodellierung für Service-Orientierte Architekturen

79

Abb. 1-1: Die Metapher "Service" erlaubt es den drei Stakeholdern Fachabteilung, Anwendungsentwicklung und IT-Betrieb, ihre Belange gleichermaßen einzubringen. Services zeichnen sich also durch drei Eigenschaften aus: 1. Services sind groß genug, um Gegenstand nicht-trivialer fachlicher Betrachtungen zu sein: Fachabteilungen können ihre Anforderungen sinnvoll in Services strukturieren und diesen zuordnen. 2. Services sind ein Mittel der Anwendungsentwicklung zur groben Strukturierung ihrer Produkte, insbesondere zur Darstellung von Applikationen als aggregierte bzw. komponierte Services und damit dann auch zur Kopplung bzw. Integration. 3. Services sind so klein, dass sie zur Betriebszeit als Einheiten der Verwaltung und Abrechnung durch die Betriebsorganisation genutzt werden können. Daher ist der Begriff „Service“ eine gemeinsame Metapher aller drei Stakeholder für Funktionalität, die in einer bestimmten Qualität bereitgestellt bzw. genutzt wird. Dies ist aus unserer Sicht der zentrale Sinn und Nutzen von SOA eine gemeinsame begriffliche Basis für Fachabteilung, Anwendungsentwicklung und Betriebsabteilung. Dieser gemeinsame Begriff kann einerseits für die durchgängige und integrative Steuerung von Entwicklungsprozessen genutzt werden (Service als Inkrement und Deliverable). Andererseits können Services zur nachvollziehbaren und handhabbaren Strukturierung einzelner Applikationen dienen (Service als Einheit der Versionierung und Integration). Abb. 1-1 stellt diesen Zusammenhang anschaulich dar. Der wichtigste Nutzen liegt aber wohl in der ausbau- und konsensfähigen, und insofern nachhaltigen Strukturierung von Applikationslandschaften, mit der Option der langfristigen sukzessiven Integration weiterer Funktionalität. Der Vorteil einer gemeinsamen Metapher „Service“ gegenüber jeweils anderen Einheiten und Kriterien

80

Harald Störrle, Wolfgang Glock

der verschiedenen Stakeholder liegt in der Vereinfachung und Vereinheitlichung der Kommunikation und Sichtweisen. Dieser Vorteil kann kaum überbewertet werden.

2

Ansatz

Unsere Arbeit wird im Wesentlichen von der praktischen Erfahrung in großen Projekten getrieben. Große Projekte bedeutet dabei die Ablösung umfangreicher, gewachsener IT-Anwendungen bzw. ganzer Anwendungslandschaften insbesondere aus dem öffentlichen Bereich, eine mehrjährige Projektlaufzeit, dezentrale Projektorganisation, Projektteams größer 50 Personen, große Datenvolumen und hohe Nutzerzahlen, sowie ein komplexes fachliches Umfeld. 2.1

Projektrahmenbedingungen

Die IT großer Unternehmen steht heute vor mehreren Herausforderungen gleichzeitig. Zum einen gelten heute ganz andere Maßstäbe für Reaktionszeiten und Marktagilität als noch vor einem Jahrzehnt. Auch Behörden und größte Unternehmen können sich heute diesen Forderungen nicht mehr entziehen. Zum anderen besteht ein permanenter Kostendruck, der sich oft in Zusammenschlüssen oder Übernahmen auswirkt. Dadurch entstehen föderale Unternehmen mit uneinheitlichen, jeweils gewachsenen Anwendungslandschaften und Unternehmenskulturen und sehr ungleichen Fähigkeitsprofilen. Der Erfolg solcher Zusammenschlüsse ist essentiell vom Gelingen der Informationstechnischen Integration abhängig, die nur im Wege des Zusammenwirkens aller Beteiligten erreicht werden kann. Daher zeigen heute viele Projekte folgende Eigenschaften. x

Kostendruck Die Fachbereiche sollen als Dienstleister gestärkt werden, die Geschäftprozesse definieren, automatisieren und optimieren. Hier liegt ein wesentliches Einsparungspotential.

x

Föderale Projektstruktur Als Integrationsprojekte weisen SOA-Projekte fast immer eine signifikante Größe und föderierte Struktur auf. In der Vergangenheit wurde dieser Faktor oft als entscheidender Faktor für Projektfehlschläge genannt (z.B. die Projekte „FISCUS“/fiscus“).

x

Koexistenz und Integration Regelmäßig sind Projekte strategisch auf Investitionssicherung und Wiederverwendung stabiler und komplexer Systemfunktionalität (z.B. Berechnungen, Prüfungen) ausgerichtet. Dazu ist die Integration alter und neuer, ggf. auch zugekaufter Systemteile und deren „friedliche Koexistenz“ über Jahre hinweg erforderlich. Teilweise ist auch absehbar, dass dieser Modus nie mehr verlassen werden wird. Insofern sollte man eher von einer Organisationsform als von einem Projekt sprechen.

x

Komplexe Anwendungslandschaft Komplexe Anwendungslandschaften können heute viele Tausend Benutzer in unterschiedlichen Organisationsformen vereinen. Mandantenfähigkeit, dynamische Anpassbarkeit, komplexe heterogene ITLandschaften und bei extremen Durchsatzanforderungen sind daher Standardanforderungen.

Der im Folgenden beschriebene Ansatz auf der Basis der zentralen Metapher der Service-Orientierung geht gezielt auf diese Rahmenbedingungen ein. Die Mittel dazu sind gemeinsame Notationen zur Standardisierung und Vereinfachung der Kom-

Geschäftsprozessmodellierung für Service-Orientierte Architekturen

81

munikation und Regeln zur methodischen Modellierung und Qualitätssicherung. Vor allem aber auch die Aktivierung und Einbindung („Mitnehmen“) der Mitarbeiter, die wir einerseits durch Ausbildung und methodische Begleitung im Projekt erreichen, andererseits dadurch, dass die Entwicklung des Projektvorgehens partizipativ im Sinne der lernenden Organisation gestaltet wird – also permanente Überprüfung und Reflexion. 2.2

Ein Ansatz zur methodischen SOA-Modellierung

SOA-Strategien stellen die Beschreibung des Geschäfts (Business) vor die Umsetzung in der Technik und die hier dargestellte Vorgehensweise zur Überführung der Fachlichkeit in Anwendungslösungen folgt diesem Leitgedanken. Das Geschäft – repräsentiert durch Fachmodelle – wird über eine Folge von Umformungs- und Anreicherungsschritt in eine technische Repräsentation gebracht um schließlich in den Betrieb überführt zu werden. Abb. 2-1 zeigt eine schematische Übersicht über die Phasen und Übergänge im Lebenszyklus von service-orientierten Subsystemen. SOLL-Analyse Analyse

Entwurf

Implementation

Betrieb

Facharchitektur Fachliches Prozessmodell Fachliches Service-Modell Fachliches Datenmodell

Transformation

Technisches Prozessmodell

Transformation

Technisches Service-Modell

Prozessimplementierung

Applikation Deployment

ServiceImplementierung

Steuerdaten

Nachrichtenmodell

IST-Analyse

Abb. 2-1: Jedes service-orientierte Subsystem wird in einer Art „Mini-Wasserfall“ erstellt; der Gesamtprozess besteht aus vielen solchen Teilprozessen. Der in Abb. 2-1 gezeigte Ablauf unterscheidet sich kaum vom hergebrachten Wasserfallvorgehen, jedoch gilt er je Subsystem, das Projekt als Ganzes besteht aus einem lose gekoppelten Bündel solcher Mini-Wasserfälle, um die Steuerbarkeit („Agilität“) des Projektes sicherzustellen. Im Gegensatz zum klassischen Wasserfall- oder auch zu inkrementellen Vorgehensmodellen ist die Anforderungserhebung in zwei komplementäre Stränge von IST- und SOLL-Analyse aufgelöst, die keine (vorgelagerten) Phasen sind, sondern kontinuierlich fortlaufende, projektbegleitende Tätigkeiten. Eine Gesamtübersicht ist in Abb. 2-2 dargestellt, eine genauere Beschreibung der Vorgehensweise ist in [GlSt2006] erschienen. Abb. 2-2 zeigt einerseits Kontinuität von IST- und SOLL-Analysen, andererseits das asynchrone Nebeneinander von Teilprojekten. Die Voraussetzungen für dieses Nebeneinander werden in einem Vorprojekt gelegt, das die technische und fachliche Architektur festlegt. In der Regel wird es neben regulären Teilprojekten auch immer herausgehobene Grundlagenprojekte geben, die zentrale Services entweder aus existierenden Anwendungen herauslösen oder neu erstellen. Die Koexistenz alter

82

Harald Störrle, Wolfgang Glock

und neuer, eigener und fremder Services, Systeme und Systemteile ein Dauerzustand.

Abb. 2-2: Das SOA Projektvorgehen enthält viele kleine asynchrone Teilprojekte im Rahmen eines Gesamtvorhabens. Im Gegensatz zu herkömmlichen iterativen Vorgehensmodellen (z.B. RUP) ist keine Synchronisation zwischen Teilprojekten zur Auslieferung vorgesehen. Die Teilprojekte können (und werden) sich personell und zeitlich, aber auch funktional überlappen. Eine zentrale Detailplanung ist nicht vorgesehen, nur eine bedarfsgesteuerte Koordination und Moderation – mehr ist in föderierten Projektorganisationen auch nicht möglich. In diesem Umfeld ergeben sich neue Herausforderungen für die Qualitätssicherung. Zum einen muss zwischen Qualitäten einzelner Services und Qualitäten des Gesamtsystems aller Services unterschieden werden. Hierfür sind jeweils andere Maße und Maßnahmen angezeigt: Während die Qualitätssicherung für einzelne Services im Wesentlichen der Qualitätssicherung kleiner modellgetriebener Entwicklungsprojekte entspricht, ist die Qualitätssicherung des Gesamtsystems eher mit Begriffen des Betriebs zu fassen. In diesem Bereich gibt es gegenwärtig zahlreiche offene Fragen (siehe auch Abschnitt 5.2 „Ausblick“). 2.3

Artefakte der Vorgehensweise

Jeder Teilprozess leistet für sich eine modellgetriebene Entwicklung. In jeder Phase werden verschiedene Artefakte in Form von Modellen genutzt bzw. erzeugt. Die Notation ist UML 2 mit Zielgruppen spezifischen Ergänzungen bzw. BPMN/BPMNartigen Notationen, was der Werkzeugumgebung geschuldet ist. Hier wird an einer weiteren Standardisierung und der Durchgängigkeit gearbeitet. Das Prinzip der Zielgruppen spezifischen Ergänzungen und Aufbereitung der Modellinhalte, hat sich allerdings bewährt und sorgt für eine hohe Akzeptanz und Identifikation mit den Ergebnissen. Abb. 2-1 zeigt die Artefakte jedes Prozessschrittes in der Übersicht. 2.3.1

Analysephase

In der Analysephase wird zunächst ein klassisches Kontextmodell entwickelt, strukturell und funktional in Fachdomänen verfeinert und bildet so die Fach-

Geschäftsprozessmodellierung für Service-Orientierte Architekturen

83

architektur. Daneben werden Schnittstellen und Nutzungsbeziehungen zwischen den Fachdomänen und der Bezug zu Rollen erfasst. Von Beginn an dient die Facharchitektur auch zur Planung und als Leitbild bzw. Orientierungshilfe für das Projektteam. Nach der erstmaligen Erstellung werden diese Modelle verfeinert und oft um Schnittstellen und Verbindungen angereichert, erhält aber immer ihren fachlichen Charakter und einen hohen Abstraktionsgrad. Diese Domänen werden durch fachliche Prozessmodelle mit Abläufen verfeinert (siehe Kapitel 2.4.1). Der fachliche motivierte Geschäftsprozesse ist für uns ein essentieller Information zur Entwicklung einer SOA. Dadurch wird eine sinnvolle Granularität und der notwendige Funktionsumfang für das Service-Design bestimmt, Abhängigkeiten erkannt und die Nachvollziehbarkeit, insbesondere durch die Fachabteilung, gewährleistet. Wie in [Snee2007] dargestellt, ist eine wesentliche Aufgabe die Identifikation eines Service-Modells, das der Umsetzung der Prozesse zugrunde liegt. Dieses fachliche Modell stellt eine notwendige Service-Landschaft ohne das Korsett der bestehenden Anwendungswelt dar. Einflussfaktoren für einen Service-Schnitt können die Datensichten, Funktionsbetrachtungen oder Aktivitätsgruppen sein. Ergänzt werden diese Modelle um eine konsistente Datensicht, repräsentiert durch ein fachliches Datenmodell bzw. Informationsmodell in Form von UML 2 Klassenmodellen. Diese stellt wiederum die fachliche Sicht auf die Daten eines Anwendungssystems oder –landschaft dar und unterstützt die Konsistenz in der Datennutzung in allen Modellen. Auch die Normierung der fachlichen Begrifflichkeiten ist dabei ein wichtiger Nebeneffekt 2.3.2

Entwurfsphase

Artefakte der Entwurfsphase sind insbesondere die technischen Prozessmodelle, die in Kapitel 2.4.2 weiter detailliert werden. Abgeleitet aus dem fachliche Service- und dem technischen Prozessmodell wird ein technisches Service-Modell entwickelt und in mehreren Iterationen verfeinert und ausgebaut. Das technische Service-Modell zeigt Services und Service-Operationen in einem auch durch die Technik beeinflussten Schnitt. Hierbei fließen die Rahmenbedingungen der technischen IST-Analyse der bestehenden Systeme, die für die Service-Implementierung genutzt werden sollen ein. Ein Nachrichtenmodell stellt, ähnlich wie das damit eng gekoppelte fachliche Datenmodell, einen Standard für den Nachrichtenaustausch zwischen Services dar. Hierdurch lassen sich formale Prüfungen der Schnittstellen und über Generierungsschritte initiale Artefakte einer technischen Service-Implementierung konsistent ableiten (z.B. XSD, WSDL). 2.3.3

Implementationsphase und Betrieb

Eines der Ziele in einer SOA ist eine grob granulare Service-Modellierung zu erreichen um die Komplexität der Orchestrierung und den Verwaltungsaufwand der Services zu reduzieren. Gerade in der Anfangsphase stabilisiert sich der ServiceSchnitt erst nach mehrfacher Iteration (Top-Down, Bottom-up) und Feedback-Zyklen mit der Geschäftsprozessmodellierung.

84

Harald Störrle, Wolfgang Glock

Dabei erfolgt eine Typisierung und Taxonomie der Services in z.B. funktions-, datenbezogen, Prozess-Services oder Service für eine Benutzeroberfläche. Die Anwendungsinfrastruktur stellt die Funktionalität zur Umsetzung der Services in einem Realisierungsmodell dar. Funktionalität wird den Services bzw. Service-Operationen zugeordnet. Wir nutzen zur Darstellung, neben den vorhandenen Mitteln in den eingesetzten Werkzeuge, UML 2 Struktur- und Komponentenmodellen ergänzt um textuelle, technische Konzepte. Gute Erfahrungen haben wir auch mit tabellarischen Darstellungen gemacht, die die Zuordnung und Abdeckung bis hin zur fachlichen Modellierung übersichtlich zeigen und auch aus den Modellen abgeleitet werden können. Der Betriebsaspekt einer SOA-Landschaft wird nur selten betrachtet, ist aber entscheidend für den Erfolg eines Vorhabens. In der Betriebsumgebung steht die SOAInfrastruktur, wie Process-Engines, Application-Server, ggf. ein ESB, die DBMS usw.. Auf diesen wird der Anwendungs-Code „deployed“, betrieben und überwacht. Dieser Themenbereich wird von uns aktuell weiter untersucht. 2.4

Fachliche und technische Prozessmodelle

Im Folgenden wollen wir auf den Teilaspekt der Prozessmodellierung eingehen und die dort verwendeten Artefakte und anschließend die Methoden der Transformation erläutern. Folgende Grafik detailliert die Übersicht aus Abb. 2-1 in Bezug auf eine Prozesssicht.

Abb. 2-3: Artefakte und Transformationsschritte der Prozesssicht

Geschäftsprozessmodellierung für Service-Orientierte Architekturen

2.4.1

85

Fachliches Prozessmodell

Ein Geschäftsprozess ist ein wertschöpfender (bzw. kostentreibender) ziel- und regelgerichteter Ablauf der betrieblichen Realität einer Organisation. In diesem Bereich gibt es leider keine einheitliche bzw. konsistente Terminologie (siehe z.B. [MeNN2007] für eine begriffliche Analyse). Wir werden im Folgenden zwischen Typen von Abläufen in der betrieblichen Realität („Geschäftsprozess“) und ihren 1 Modellen („Geschäftsprozess-Modell“) differenzieren. Der Grad der Detaillierung wird durch die Zielgruppe (z.B. Technik, Partner) bestimmt und ist von Rahmenbedingungen, wie dem Einsatz von Altsystemen oder einer Neuentwicklung abhängig. Geschäftsprozess-Modelle dienen der Sammlung, Präzisierung und Abstimmung von Regeln und Vorgehensweisen zur standardisierten Abwicklung von geschäftlichen Vorfällen. Sie sind damit wesentlicher Input für die konsistente Konzeption von Service-Modellen. Die iterative Vervollständigung der fachlichen Prozessmodelle hat dabei regelmäßig Auswirkungen auf das Service-Design. Zur Beschreibung von Geschäftsvorfällen (Typen) verwenden wir Anwendungsfalldiagramme der UML 2, angereichert um zahlreiche Informationsrubriken. Die Szenarien eines Anwendungsfalles beschreiben wir durch ein UML 2 Aktivitätsdiagramm (ggf. rekursiv verfeinert). Der Entwurf von Benutzeroberflächen als Basis für die Entwicklung von GUI-Services ergänzen die fachliche Modellierung, wird hier aber nicht näher betrachtet. 2.4.2

Technisches Prozessmodell

Das technische Prozessmodell zeigt die geplante Umsetzung auf einer technischen Plattform – in diesem Fall für eine SOA. Somit spiegelt sich hier ein MDA Ansatz wieder, der die fachliche, technik-neutralen Konzept um die Aspekte einer ServiceOrientierung anreichert. Entsprechend eines bereitgestellten technischen ServiceModells wird die Granularität – in der Regel vergröbert - und der Prozessablauf angepasst. Durch Querbezüge zwischen dem fachlichen und technischen Prozessmodell wird die Abdeckung und Konsistenz verfolgt. Entsprechend der Architekturkonzepte werden Aspekte wie Transaktionshandling, Sperren u.ä. in den Prozess eingebracht oder notwendige Anforderungen aus der Betriebsicht (z.B. Protokollierung, Monitoring) ergänzt. Die Notation des technischen Prozessmodells wird nach unserer Erfahrung stark durch die Werkzeugauswahl und den Entwickungsprozess beeinflusst. Soll aus der Orchestrierung der Services für den Prozess direkt ausführbarer BPEL-Code erzeugt werden, sind BPMN bzw. BPMN-nahe Notationen sinnvoll. Sollen umfangreiche Funktionalität aus bestehenden, komplexen Anwendungssystemen über Wrapper1

Neben der Unterscheidung zwischen Schema (Typ) und Beispielen (Instanz) von Geschäftsprozessen, muss mit Stachowiak [Sta1977] auch zwischen den Elementen der (betrieblichen) Realität (Originale) und ihren Abstraktionen (Modelle) unterschieden werden. Somit könnte eine Instanz eines betrieblichen Ablaufs z.B. als „Geschäftsvorfall“, ein Modell davon entsprechend als „Geschäftsvorfall-Modell“ bezeichnet werden. Im üblichen Sprachgebrauch wird diese Differenzierung nicht vorgenommen.

86

Harald Störrle, Wolfgang Glock

Techniken eingebunden werden und ist eine IST-Analyse noch im Gange, hat sich eine Modellierung mit UML 2 Aktivitätsdiagrammen, ergänzt um eine technische Attributierung als hilfreich gezeigt. 2.4.3

Prozessimplementation

Die Anwendungsinfrastruktur stellt die Funktionalität zur Umsetzung der Services als Basis der Geschäftsprozesse zur Verfügung. Unterschiedlichste Rahmenbedingungen und Plattformen – von Legacy-Anwendungen im Hostumfeld bis zu Neuimplementierung in einer J2EE Umgebung – machen eine einheitliche Notation schwierig. Wiederum hat die Werkzeugauswahl einen entscheidenden Einfluss auf die Modellierung. Für eine werkzeugneutrale Beschreibung einer Systemarchitektur kommen UML 2 Struktur- und Komponentenmodellen mit textuellen Beschreibungen zum Einsatz. Im Konfigurationsmanagement werden die Entwicklungsartefakte wie BPEL-Code, WSDL, J2EE-Code verwaltet und bereitgestellt. Werkzeuge zur Code-Analyse werden gerade im Bereich der Hostanwendungen aktuell geprüft um daraus ServiceImplementierungen im Rahmen der IST-Analyse abzuleiten. Die Analyseergebnisse werden in die Implementierungsmodelle übernommen.

3

Implementierung fachlicher Prozessmodelle

Die Umsetzung fachlicher Modelle in eine ausführbare Implementation erfolgt in einem mehrstufigen Prozess. Da die Umformung statischer Modelle in der Literatur bereits vielfach betrachtet wurden und auch praktisch keine große Herausforderung darstellen, wollen wir im Folgenden als Beispiel die deutlich komplexeren und wissenschaftlich nicht ausreichend verstandenen Transformationsschritte zwischen fachlichen und technischen Prozessmodellen im Detail betrachten. Die Transformation von fachlichen Prozessmodellen in eine ausführbare Implementation dient zwei Zwecken. Zum einen fehlen fachlichen Prozessmodellen technische Aspekte, die ergänzt werden müssen. Dazu kommen Implementationsdetails, Erweiterungen und algorithmische Konkretisierungen, die eingearbeitet werden müssen. Zum anderen werden fachliche Prozessmodelle in Notationen formuliert, die auf die fachliche Analyse und die damit verbundenen Aufgaben zugeschnitten sind. Diese Notationen eignen sich in der Regel nicht für die Ausführung im Produktivbetrieb, so dass hierfür eine andere Notation genutzt wird. Mit den unterschiedlichen Notationen gehen in realen Projekten auch unterschiedliche Werkzeuge einher. Daher ist neben der inhaltlichen Umsetzung eines fachlichen Modells in eine Implementation auch die Formatumsetzung von einer fachlich orientierten Notation in Implementationsnotation erforderlich. Unserer Erfahrung nach empfiehlt es sich, die inhaltliche Umsetzung auf den Entwurfsmodellen durchzuführen, da nur an dieser Stelle eine vollautomatische Umsetzung leichter realisiert werden kann. Außerdem kann so die Unterstützung durch die Implementationsumgebung optimal ausgenutzt werden. In unserem Vorgehen (siehe Abb. 3-) werden Analysemodelle als UML 2 Aktivitätsdiagramme in ADONIS erstellt, in ADONIS zu Entwurfsmodellen erweitert, exportiert und mit einem separaten Werkzeug nach BPEL konvertiert. Diese Dateien können in den Oracle BPEL

Geschäftsprozessmodellierung für Service-Orientierte Architekturen

87

Designer importiert werden, auf Wunsch in einem BPMN-Dialekt angezeigt und manuell mit Werkzeugunterstützung nachbearbeitet werden. Das Ergebnis dieser Nachbearbeitung ist ausführbarer, produktionsreifer BPEL-Code.

Abb. 3-1: Die Implementierung fachlicher Prozessmodelle erfolgt in drei Schritten Aufgrund des begrenzten Platzes können wir an dieser Stelle nur die Transformation von Analyse- zu Entwurfsprozessmodellen genauer betrachten (der Pfeil links oben).

4

Umformung fachlicher in technische Prozessmodelle

Ausgangspunkt der Transformation sind fachliche Prozessmodellen als Ergebnis der fachlichen Analyse. In unserem Ansatz werden sie in Form von UML 2 Aktivitätsdiagrammen dargestellt, die um umfangreiche fachliche Zusatzinformationen erweitert werden. Endpunkt der Transformation sind technische Prozessmodelle, die ebenfalls in Form von UML 2 Aktivitätsdiagrammen beschrieben werden. Die Transformation verändert die Struktur der Aktivitätsdiagramme mit den Zielen x

die Menge des Datenaustausches zwischen Services zu reduzieren,

x

die Zuordnung zwischen vordefinierten und benutzten Services zu erleichtern,

x

die Nutzung vordefinierter Services zu optimieren und

x

Spezialisierungen loser Spezifikationen vorzunehmen.

Im Folgenden beschreiben wir drei Arten von strukturverändernden Umformungen von Aktivitätsdiagrammen. 4.1

Datenflussoptimierung

Ein konstituierendes Merkmal von Services ist ihre gegenseitige Isolation bzw. Unabhängigkeit voneinander. Insbesondere dürfen offensichtlich keine Datenstrukturen gemeinsam genutzt werden. Das bedeutet, dass alle erforderlichen Ausgangsdaten bzw. produzierten Ergebnisdaten durch eine geeignete Infrastruktur zu transportieren sind, was erheblichen Verwaltungsaufwand (Marshalling, Unmarshalling) für jeden Service-Aufruf nach sich zieht. Dieses bereits von CORBA und ähnlichen Technologien bekannte Phänomen wird durch die in der SOA-Welt verbreitete Be-

88

Harald Störrle, Wolfgang Glock

nutzung von XML-Datencontainern noch potenziert, da der Nutzdatenanteil von XMLNachrichten typischerweise bei nur 10-30% liegt. Eine teilweise Lösung liegt in der Zusammenfassung vieler kleiner zu wenigen großen Nachrichten („Dokumente“) um den Nutzdatenanteil pro Nachricht zu verbessern. Die zugkräftigere Lösung liegt aber in der Vermeidung von Datenverkehr durch geschickte Gruppierung von Verarbeitungsschritten, so dass Ketten von Verarbeitungsschritten in einem Service zusammengefasst werden können. Dazu dienen die Transformationsschritte Aggregation, Eingliederung und Umgruppierung (siehe Abb. 4-1). Ausgliederung Durch Ausgliederung wird eine zusammenhängende Teilaktivität zu einer eigenständigen Aktivität zusammengefasst, ausgegliedert und als Verfeinerung einer neu eingefügten Aktion eingebunden (CallActivityAction im UML 2 Metamodell). Hierbei bleibt die Gesamt-Ablauflogik vollständig erhalten, lediglich die Gliederung des Modells ändert sich. Eingliederung Das duale Gegenstück zur Aggregation ist die Eingliederung: hierbei werden die Aktionen einer abgespaltene Aktivität in die übergeordnete Aktivität eingefügt. Dabei bleibt die Ablauflogik vollständig erhalten, lediglich die Gliederung des Modells ändert sich. Umgliederung Durch Kombination von Eingliederung und Ausgliederung kann eine Umgliederung erreicht werden. Hierbei werden Teilaktivitäten von zwei aufeinander folgenden verfeinerten Aktionen von der einen Verfeinerung zur anderen verschoben.

Abb. 4-1: Datenflussoptimierung durch Aus- und Eingliederung Umordnung Manchmal ist aus fachlicher Sicht eine Reihenfolge von Aktionen vorgegeben, die aus technischer Sicht problematisch oder unvorteilhaft ist, z.B. weil die Umgliederung dadurch verhindert wird. In solchen Fällen kann eine Umordnung erfolgen.

Geschäftsprozessmodellierung für Service-Orientierte Architekturen

4.2

89

Wiederverwendung vorgefertigter Services, Anpassungsmaßnahmen

Ein zentrales Anliegen aller Komponentenarchitekturen ist die Förderung von Wiederverwendung. Da einerseits Services als grobgranulare Komponenten definiert sind, und andererseits bekanntlich der Grad der Wiederverwendbarkeit mit der Größe (und Spezialisierung) von Komponenten abnimmt, muss man bei grobgranularen Komponenten in Kauf nehmen, dass die zur Wiederverwendung bereitgestellte Funktionalität nicht vollständig der gewünschten Funktionalität entspricht, und Anpassungen erforderlich sind. Im Folgenden beschreiben wir einige gängige Anpassungsmaßnahmen. Austausch Eine Aktion kann durch einen vordefinierten Service ausgetauscht werden, wenn der Dienst funktional gleichwertig oder mächtiger ist. Grundsätzlich gelten hier die einschlägigen, z.B. aus objektorientierten Programmiersprachen bekannten Typersetzungsregeln (insbesondere Kontravarianz). Differenzen hinsichtlich der Funktionalität, des Schnittstellenformates oder der Dienstgüte können oft durch Umbaumaßnahmen (Abrollung, Einfügung, Umordnung u.a.) überbrückt werden. Abrollung Fallunterscheidungen und Schleifen können häufig ohne Bedeutungsverlust abgerollt werden (siehe Abb. 4-2). Offensichtlich muss die Fallunterscheidung in der Regel verändert werden, um vorverlagert werden zu können, und dieser Schritt ist nicht immer (aber doch oft genug) möglich. Ein Spezialfall ergibt sich für Schleifen. Bei einer Abrollung ergibt sich keine Veränderung der Reihenfolge von Aktionen, während offensichtlich Entscheidungspunkte verändert werden. Das heißt, dass Trace-Semantiken erhalten bleiben, Bisimulations-Äquivalenzen aber nicht.

Abb. 4-2: Schematische Darstellung einer Entscheidungsabrollung Einfügung Eine wichtige Umbaumaßnahme ist das Einfügen von Arbeitsschritten, z.B. zur Anpassung der Aufrufschnittstellen von Services. Typische erforderliche Maßnahmen sind Aufbereitung, Konvertierung und Formatierung von Parametern und Resultaten, oder die Auffüllung mit benötigten Parametern bzw. Absorption nicht benötigter Resultate. Andere Maßnahmen können mit der Initialisierung und Beendigung von Service-Operationen und mit der Sicherstellung von Dienstgütemerkmalen oder anderen technisch motivierten Vorgängen zu tun haben.

90

4.3

Harald Störrle, Wolfgang Glock

Spezialisierung

Der Übergang von Analysemodellen zu Entwurfsmodellen erfordert oft die detailliertere Ausgestaltung einzelner Arbeitsschritte oder den Austausch komplexer Konstrukte oder Gestaltungsmuster durch einfachere Idiome. Verfeinerung Der am nächsten liegende und auch häufigste Arbeitsschritt ist die Verfeinerung. Hierbei wird ein einzelner fachlich definierter Arbeitsschritt durch den Aufruf einer eigenen Aktivität mit größerem Detailgrad ersetzt, ohne dass am Ausgangsmodell weitere Veränderungen vorgenommen werden. Technisch entspricht dies dem Austausch eines ActivityNode durch eine CallActivityAction, die eine neu zu schaffende Activity aufruft.

Abb. 4-3: Schematische Darstellung der Verfeinerung einer einzelnen Aktion Sequentialisierung Ein verwandter Fall ist das Auflösen von Nebenläufigkeit: in der fachlichen Modellierung kann durch Fork/Join-Konstrukte zum Ausdruck gebracht werden, dass die Reihenfolge aus fachlicher Sicht beliebig ist. In einer technischen Realisierung ist aber entweder eine nebenläufige Ausführung nicht möglich oder, bei sehr unterschiedlichen Laufzeiten der parallelen Zweige, nicht optimal, so dass eine spezielle bzw. speziellere Ausführungsreihenfolge vorgegeben werden soll. Dies kann durch Sequentialisierung erreicht werden. Offensichtlich ist die Sequentialisierung auch hinsichtlich der Trace-Menge eine Implementierung, keine Äquivalenz.

5

Diskussion

5.1

Erfahrungen

Die hier vorgestellte Methode zur modellgetriebenen Erstellung von service-orientierten Systemen wurde im Laufe von etwa fünf Jahren in der Industrie entwickelt und zuletzt in zwei Großprojekten erfolgreich eingesetzt. Die Projekte zeichnen sich durch die in Abschnitt 2.1 beschriebenen Eigenschaften aus. Insbesondere die föderale Struktur und die damit verbundenen zentrifugalen Tendenzen verstärken die allfälligen Probleme großer und komplexer Software-Projekte. Aufgrund dieser schwierigen Projektvorgeschichte ist unser wichtigstes Ergebnis wohl, dass es uns überhaupt gelungen ist, Akzeptanz durch die Projektmitarbeiter zu erreichen: Akzeptanz einerseits für einen Modellierungsansatz im Allgemeinen (bzw. den hier Vorgestellten im Besonderen), als auch für das Projekt als solches. Beides war alles andere als selbstverständlich. Unser Ansatz führte wie gewünscht dazu, dass sich die Projektbeteiligten einbinden ließen und aktiv mitarbeiteten. Die Kommunikation zwischen verschiedenen, räumlich verteilten Teilorganisationen wurde im

Geschäftsprozessmodellierung für Service-Orientierte Architekturen

91

Projektverlauf zusehends besser. Wir sind überzeugt davon, dass hierfür zwei Faktoren entscheidend waren: Zum einen die erwähnte Einbindung und nachhaltige Aktivierung aller Stakeholder durch eine verbindende Metapher. Zum anderen gelang durch die gemeinsame begriffliche Basis die Fokussierung auf real zu lösende Aufgaben und damit den Projektfortschritt. Ausufernde und ziellose Diskussionen konnten so reduziert werden. Die häufig zu beobachtende Verkürzung von SOA auf den technischen Aspekt ist aus unserer Sicht kontraproduktiv. Als hinderlich hat sich die unzureichende Werkzeugunterstützung erwiesen. Insbesondere die Durchgängigkeit ist nicht ausreichend gewährleistet und resultiert in unbefriedigenden Kompromisslösungen, die entweder schmerzhafte Reibungsverluste mit sich bringen oder man begibt sich in vollkommene Abhängigkeit zu einem Hersteller, dem man im Folgenden oft hilflos ausgeliefert ist. Ein weiteres Problem ist der QS Prozess, da heute weder die Qualitätssicherung von Modellen ausreichend verstanden wird, noch Erfahrungswerte bezüglich der Spezifika der Service-Orientierung vorliegen. Hier wurde oft Neuland erschlossen, mit den entsprechenden Folgen für die Projektplanung. 5.2

Ausblick

Aus dieser Einschätzung ergeben sich unmittelbar die weiteren Aufgaben, an denen wir gegenwärtig arbeiten: Unterstützung der Qualitätssicherung, Definition und Verifikation der Transformationsregeln, sowie einer durchgängigen Werkzeugunterstützung. Daneben ist es aus unserer Sicht unbefriedigend, dass wir den Beitrag unserer Methode aktuell lediglich auf der Basis subjektiver Einschätzungen dokumentieren können. Wir hoffen, dies durch begleitende Messung von Produkt- und Prozessqualität künftig verbessern zu können und konnten hier die ersten Erfolge verzeichnen. 5.3

Methodische Überlegungen

Die Projekte, die wir mit unserem Ansatz betreut haben (und betreuen), sind aus unserer Sicht und auch aus Sicht unserer Kunden sehr erfolgreich verlaufen in dem Sinne, dass die Projektziele erreicht und die Ziele der Kunden erfüllt wurden. Wir schreiben diese Erfolge unserem Ansatz zu, können aber eine kausale UrsacheWirkung-Beziehung nicht nachweisen. Der Einfluss anderer Faktoren wie der Rahmenbedingungen, der beteiligten Personen lässt sich nicht exakt quantifizieren und wir können insbesondere auch nicht beweisen, dass andere Ansätze nicht ähnlich erfolgreich hätten sein können. Ohne dass wir dieses Problem herunterspielen wollen, müssen wir doch festhalten, dass diese Problematik im Bereich der Methoden und Prozesse industrieller Anwendungsentwicklung zwangsläufig auftritt. Auch der konkrete Nutzen einer herkömmlichen Geschäftsprozessmodellierung lässt sich nur schwer nachweisen, wird aber allgemein als substantiell akzeptiert. Abhilfe könnte die empirische Evaluierung des Entwicklungsprozesses bzw. der Verbesserungen von Produkt und Prozess leisten, obwohl auch auf diesem Weg ein kausaler Zusammenhang nicht stringent belegbar wäre.

92

6

Harald Störrle, Wolfgang Glock

Verwandte Arbeiten

Unsere Sicht der SOA fokussiert stark auf die Verbindung der Sichten aller Beteiligten statt der Betonung der Technologie. Die Gartner Group hat diesen Ansatz in ihrem Bericht [NPSI2006] als „Business Driven SOA“ bezeichnet. Im Gegensatz dazu stehen Ansätze wie die SOA Method (SOMA, cf. [Arsa2004]) und [Snee2007], die stark auf den technischen Aspekt eingehen, insbesondere auf Web-Services. Beiden Ansätzen gemein ist die relativ grobe Beschreibung, in der viele relevante Details unterdrückt werden und die für die praktische Verwendung dadurch unbrauchbar wird. Unsere stark integrative und übergreifende Sicht findet sich unter verschiedenen Namen schon früher, z.B. im Business Objects Ansatz von Sims et al. (cf. [MSJL2006,Sims1994]) in den Lifecycle Components (cf. [Stör1999]). Die Umformung von fachlichen in technische Prozessmodelle ist ebenfalls Gegenstand zahlreicher Untersuchungen, z.B. werden in [MeZi2005, ZiMe2005] und [StIv2007] fachliche Prozessmodelle in Form von Ereignis-Prozessketten (EPKs) erstellt und direkt nach BPEL transformiert. Zu grundsätzlichen konzeptuellen Problemen solcher Ansätze siehe auch [ReMe2006]. Über die aus unserer Sicht sehr wichtige Integration in begleitenden Transformationen von Service-Modellen wird keine Aussage getroffen. Aalst et al. Übersetzen einen Petrinetz-Dialekt nach BPEL [AtHK2003, AaLa2005]. Über die Transformation von UML 2 Aktivitätsdiagrammen nach BPEL sind uns keine Untersuchungen bekannt, allerdings gibt es Arbeiten, die von UML 2 Aktivitätsdiagrammen nach EPKs oder umgekehrt übersetzen, z.B. basierend auf Vergleichen der Notationen wie [NFZi1997].

Literaturverzeichnis [AaLa2005] Aalst, W.M.P.v.d, Lassen, K.B.: Translating Workflow Nets to BPEL4WS. Bericht BPM-05-16, BPM Center Eindhoven, 2005. siehe WWW: http://is.tm.tue.nl/staff/ wvdaalst/ BPMCenter/reports/2005/BPM-05-16.pdf. [Allw2005] Allweyer, Th.: Geschäftsprozessmanagenment, W3L-Verlag, Herdecke/Bochum, 2005. [Arsa2004] Arsanjani, A.: Service-Oriented Modeling and Architecture, verfügbar unter http://www.ibm.com/developerworks/webservices/library/ws-soa-design1/ November 2004 siehe auch http://www.ibm.com/developerworks/rational/downloads/06/rmc_soma/. [AtHK2003] Aalst, W.M.P.v.d., Hofstede, A.H.M.t., Kiepuszewski, B., Barros, A.P.: Workflow Patterns. J. Distributed and Parallel Databases. 14(3) 5—51, Juli 2003. [BMRS1998] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M.: PatternOrientierte Software-Architektur. Addison-Wesley, 1998. [ERL2005] Erl, T.: Service Oriented Architecture, Prentice Hall 2005. [Gimn2006] Gimnich, R.: SOA-Migration – Approaches and Experience. In: Kaiser, U., Kroha, P., Winter, A. (Hrsg.): Proc. Ws. Reengineering Prozesse (RePro’06), Softwaretechnik-Trends 1 (27) 2006. [Gimn2007] Gimnich, R.: Komponentisierung in der SOA-Migration. In: [GRWi2007], S. 1314.

Geschäftsprozessmodellierung für Service-Orientierte Architekturen

93

[GlSt2006] Glock, W.; Störrle, H.: Ein Erfahrungsbericht über die agile Steuerung eines Großprojektes durch fachliche Anforderungen. In: Softwaretechnik-Trends, 1 (2007), Fachgruppentreffen der GI-FG 2.1.6 Requirements Engineering 2006, Gesellschaft für Informatik. [GRWi2007] Gimnich, R., Riedinger, V., Winter, A. (Hrsg.): Proc. 9. Ws. SoftwareReengingeering (WSR 2007), Softwaretechnik-Trends 2 (27) 2007. [HHVo2006] Hess, A.; Humm, B., Voß, M.: Regeln für serviceorientierte Architekturen hoher Qualität. Informatik Spektrum 19 (6) 2006, S. 395-411. [MSJL2006] McGovern, J., Sims, O., Jain, A., Little, M.: Enterprise Service Oriented Architecture. Springer-Verlag, 2006. [MeUm2006] Metz, P., Umbach, H.: Use Cases vs. Geschäftsprozesse Das Requirements Engineering als Gewinner klarer Abgrenzung. In: Informatik Spektrum, 6 (29) 2006, S. 424-432. [MeZi2005] Mendling, J., Ziemann, J.: Transformation of BPEL Processes to EPCs. In: Nüttgens, M., Rump, F.J. (Hrsg.): Proc. 4th GI Ws. Event-Driven Process Chains (EPK 2005), CEUR Workshop Proceedings Volume 167, ISSN-1613-0073, S. 41-53, Dezember 2006, Gesellschaft für Informatik, Bonn. [NPSI2006] Natis, Y.V., Pezzini, M., Schulte, R.W., Ijima, K.: Predicts 2007: SOA Advances. Gartner Group Report, November 2006. [NFZi1997] Nüttgens, M., Feld, T., Zimmermann, V.: Business Process Modeling with EPC and UML -- Transformation or Integration?, S. 250-261. In: Schader, M. Korthaus, A. (Hrsg.): Proc. Unified Modeling Language (UML’98): Technical Aspects and Applications. Physica-Verlag, 1998. [OMGR1998] Object Management Group: Unified Modeling Language (UML) v.0.8. (verfügbar unter www.uml.org). [OMGr2003] Object Management Group: Model Driven Architecture (MDA) Guide 1.0.1. (verfügbar unter www.omg.org/mda als omg/2003-06-01). [OMGR2007] Object Management Group: Unified Modeling Language (UML) v.2.1.1. (verfügbar unter www.uml.org). [ReMe2006] Recker, J., Mendling, J.: On the Translation between BPMN and BPEL: Conceptual Mismatch between Process Modeling Languages. In: Latour, T., Petit, M. (Hrsg.): Proc. 11th Intl. Ws. Exploring Modeling Methods in Systems Analysis and Design (EMMSAD 2006), S. 521-532, 2006. [Shaw1995] Shaw, M.: Comparing Architectural Design Styles. IEEE Software (12) 6: 27-41, 1995. [Sims1994] Sims, O.: Business Objects. Delivering Cooperative Objects for Client-Server. McGraw-Hill, 1994. [Snee2007] Sneed, H. M.: Migration in eine Service-orientierte Architektur. In: [GRWi2007], S. 15-18. [StIv2007] Stein, S., Ivanov, K.: EPK nach BPEL Transformation als Voraussetzung für praktische Umsetzung einer SOA. In: Bleek, W.-G., Raasch, J., Züllighoven, H. (Hrsg.): Proc. Software Engineering 2007 (Fachtagung des GI-Fachbereiches Softwaretechnik), Gesellschaft für Informatik, LNI 105, S. 75–80.

94

Harald Störrle, Wolfgang Glock

[Stac1977] Stachowiak, H.: Allgemeine Modelltheorie. Springer-Verlag, 1977. [Stör1999] Störrle, H.: A different notion of components, In: Schürr, A., Hofmann, P. (Hrsg.): Proc. Ws. Object-Oriented Modeling of Embedded and Realtime Systems (OMER’99), Universität der Bundeswehr (München), Fakultät für Informatik, Bericht Nr. 1999-01. [Stör2001] Störrle, H.: Models of Software Architecture. Book on Demand, 2001. [Stör2005] Störrle, H.: UML 2 erfolgreich einsetzen. Addison-Wesley Deutschland, 2005. [Stör2006] Störrle, H.: A Comparison of (e)EPCs and UML 2 Activity Diagrams. In: Mendling, J., Nüttgens, J., Rump, F.J.. (Hrsg.): Proc. 5. Intl. Ws. Event Process Chains (EPK’06), CEUR Workshop Proceedings Volume 224, Dezember 2006, Ges. für Informatik, Bonn. [ZiMe2005] Ziemann, J., Mendling, J.: EPC-Based Modeling of BPEL Processes: A Pragmatic Transformation Approach. In: Proc. 7th Intl. Conf. Modern Information Technology in the Innovation Processes of the Industrial Enterprises (MITIP’05), Genua, 2005.

Modellierung Serviceorientierter Architekturen – Ein Vergleich von Axiomatic Design mit der Strukturierten Analyse von DeMarco René Fiege, Dirk Stelzer Zusammenfassung: Axiomatic Design ist eine Methode, die für den Entwurf beliebiger Systeme eingesetzt werden kann. Im Forschungsprojekt „Axiomatic Design im Entwurf Serviceorientierter Architekturen“ (AD-SOA) der Technischen Universität Ilmenau wurde Axiomatic Design für die Modellierung Serviceorientierter Architekturen (SOA) angepasst. Die Grundgedanken von Axiomatic Design sind denen bekannter Methoden aus dem Software Engineering ähnlich. Im Vergleich zu traditionellen Modellierungsmethoden strukturiert Axiomatic Design Entwurfsprozesse stärker und stellt Entwurfs- und Prüfregeln zur Beurteilung der Entwurfsentscheidungen bereit. Axiomatic Design wurde im Software Engineering bisher nur in ausgewählten Projekten eingesetzt, verspricht aber auf Grund seiner spezifischen Eigenschaften ein großes Potential für die Modellierung von SOA. Wir vergleichen Axiomatic Design exemplarisch mit einer Methode der Strukturierten Analyse. Ziel dieses Beitrags ist es zu untersuchen, ob Axiomatic Design einen Beitrag zur Modellierung von SOA leistet, der über den Beitrag traditioneller Methoden des Software Engineerings hinausgeht.

1

Einleitung

Serviceorientierte Architekturen (SOA) sollen wandlungsfähige bzw. „agile“ Architekturen für Informationssysteme (IS) ermöglichen, die leicht an neue Anforderungen angepasst werden können, [Erl2004; SiHu2005, 71 ff.; ZiTP2003]. Axiomatic Design kann die Modellierung von SOA unterstützen [FiSt2007]. Hierzu wurde im Forschungsprojekt „Axiomatic Design im Entwurf Serviceorientierter Architekturen“ (ADSOA) der Technischen Universität Ilmenau eine Methode entwickelt, in deren Rahmen Axiomatic Design zur Modellierung von SOA eingesetzt werden kann, um die Entwurfsergebnisse in SOA-Projekten zu verbessern. Axiomatic Design wurde ursprünglich für das Mechanical Engineering entwickelt [Suh1990, 18]. Es handelt sich dabei um eine Methode zur strukturierten Gestaltung 1 von Objekten [Suh2001]. Die Ziele von Axiomatic Design korrespondieren mit den Architekturzielen von SOA und von IS-Architekturen. Unter IS-Architekturen verstehen wir hier „… the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution“ [IEEE2000]. Axiomatic Design kann insbesondere ausgewogene Granularität, lose Kopplung und hohe Autonomie fördern [FiSt2006; FiSt2007]. Die Erreichung dieser Ziele ist wichtig, um die Wiederverwendbarkeit der Architekturbestandteile zu erhöhen [BiLi2006, 101; BuGa2005, 602; DuHo2003, 1 ff.; Erl2005, 290 ff.].

1

Objekte können Materialien, beliebige Systeme, Software, Hardware, strategische Geschäftspläne, Organisationen und Prozesse sein.

96

René Fiege, Dirk Stelzer

Die Grundgedanken von Axiomatic Design sind denen bekannter Methoden aus dem Software Engineering ähnlich, z.B. der Strukturierten Analyse und dem Strukturierten Design sowie der objektorientierten Analyse und dem objektorientierten Design [CoYo1991; Wein1978; YoCo1979; Your1991]. Eine wesentliche Gemeinsamkeit aller Methoden ist die hierarchische Dekomposition eines Problems in viele individuell identifizierbare Subprobleme. Bei allen Methoden werden Module und Beziehungen zwischen den Modulen von IS-Architekturen modelliert [Balz1998, 558]. Im Vergleich zu traditionellen Modellierungsmethoden strukturiert Axiomatic Design jedoch Entwurfsprozesse stärker und stellt Entwurfs- und Prüfregeln zur Beurteilung der Entwurfsentscheidungen bereit. Traditionelle Modellierungsmethoden sind im Software Engineering weit verbreitet, scheinen aber in der Gestaltung von SOA keine wesentliche Rolle zu spielen [BBFJ2006; Erl2005]. Axiomatic Design wurde bisher im Software Engineering nur in ausgewählten Projekten eingesetzt [z.B. KiSK1991; SuDo2000; YiPa2004], verspricht aber auf Grund seiner spezifischen Eigenschaften ein großes Potential für die Modellierung von SOA [FiSt2006; FiSt2007]. Ziel dieses Beitrags ist es zu untersuchen, ob Axiomatic Design einen Beitrag zur Modellierung von SOA leistet, der über den Beitrag traditioneller Methoden des Software Engineerings hinausgeht. Leider haben wir aus Platzgründen in diesem Beitrag nicht die Möglichkeit, Axiomatic Design mit allen traditionellen Modellierungsmethoden des Software Engineerings zu vergleichen. Wir beschränken uns daher auf den Vergleich von Axiomatic Design mit der Strukturierten Analyse von DeMarco, die als ein typischer Vertreter dieser Methoden gilt. Im folgenden Abschnitt stellen wir Architekturziele für SOA und für IS-Architekturen vor. Anschließend geben wir einen Überblick über traditionelle Modellierungsmethoden des Software Engineerings. Danach stellen wir Axiomatic Design und die Strukturierte Analyse nach DeMarco [DeMa1978] einander gegenüber, um Gemeinsamkeiten und Unterschiede aufzuzeigen. Im Anschluss analysieren wir, inwieweit beide Methoden die Erreichung der Architekturziele unterstützen können. Der Beitrag wird mit einer kurzen Zusammenfassung und einem Ausblick abgeschlossen.

2

Ziele für die Entwicklung von SOA und von IS-Architekturen

Architekturziele repräsentieren Prinzipien, die eine IS-Architektur charakterisieren [Erl2005, 290; Häus2004, 267]. Diese Ziele müssen bereits im Entwurf berücksichtigt werden, damit sie sich in der resultierenden Architektur widerspiegeln. Typische Architekturziele von SOA sind: Agilität, Wiederverwendbarkeit und Komponierbarkeit sowie angemessene Granularität, lose Kopplung, hohe Autonomie, Zustandslosigkeit, Auffindbarkeit, Abstraktheit, Interoperabilität, Geschäftsorientiertheit, Nachhaltigkeit, Neutralität und wohldefinierter Servicekontrakt [BuGa2005, 602; DJMZ2005, 9; EKAP2005, 28; Erl2005, 290; HaSc2006, 277; MaBe2006, 39 ff.; SiHu2005, 76-77]. In [FiSt2006; FiSt2007] konnten wir zeigen, dass Axiomatic Design helfen kann, die Ziele Wiederverwendbarkeit, angemessene Granularität, lose Kopplung und hohe Autonomie zu erreichen. Wir beschränken uns im Folgenden auf die Betrachtung dieser Ziele. Diese Architekturziele sind wichtige Beurteilungsgrößen für die Qualität im Bereich der serviceorientierten, der objektorientierten und der strukturierten Softwareentwicklung [EKAP2005, 28; Erl2005, 290 ff.; GhJM2003, 41; Häus2004, 265]. Die

Modellierung Serviceorientierter Architekturen

97

Wiederverwendbarkeit fördert die Verwendung vorhandener Module einer ISArchitektur in einem anderen Kontext [Brau1994]. Der Grundgedanke aller Softwareentwicklungsparadigmen basiert auf dem im Software Engineering bekannten Prinzip der „separation of concerns“ [Balz1998; Erl2005, 290]. Dieses Grundprinzip geht auf Dijkstra und Wirth zurück [Dijk1969; Wirt1971]. Es beschreibt die Art und Weise der Dekomposition eines Problems in viele individuell identifizierbare Subprobleme. Ziel ist es, durch einen modularen Aufbau die Wiederverwendbarkeit einzelner Teile eines Softwaresystems zu gewährleisten. Wiederverwendbarkeit ist somit eines der wichtigsten Architekturziele, dessen Erreichung von der Erfüllung der anderen Ziele abhängt [Balz1998, 637ff.; DuHo2003, 3ff.; EKAP2005, 28; Erl2005, 313; HaSc2006, 281; PaYa2002, 58-60]. Lose Kopplung ist ein wichtiges Ziel in der Serviceorientierung und der traditionellen Softwareentwicklung. Es umfasst die Reduzierung von Abhängigkeiten zwischen den Modulen einer IS-Architektur. Außerdem sollten die Module schmale Schnittstellen aufweisen [DuHo2003, 4; Häus2004, 265]. Eine lose Kopplung erhöht die Wiederverwendbarkeit, weil Module unabhängig von anderen Modulen einfach wiederverwendet werden können. Das Ziel hohe Autonomie stammt aus der Serviceorientierung. Es erfordert, dass die Funktionalität, die innerhalb eines Service gekapselt ist, im Hinblick auf einen definierten Kontext (z.B. eine zu erfüllende betriebswirtschaftliche Funktion) klar abgegrenzt werden kann [Erl2005, 303]. Autonomie entspricht dem Ziel hohe Kohäion, das aus der traditionellen Softwareentwicklung bekannt ist [Balz1998, 474; VACI2005, 117]. Eine hohe Kohäsion liegt vor, wenn sich die Funktionalität eines Moduls auf genau einen Kontext bezieht [DuHo2003, 3; Erl2005, 304]. Die klare Abgrenzung der Funktionalität eines Moduls erhöht dessen Wiederverwendbarkeit [Erl2005, 318]. Eine hohe Kohäsion minimiert darüber hinaus Abhängigkeiten zwischen Modulen und fördert die lose Kopplung [Balz1998; Erl2005, 303; VACI2005, 118]. Das Ziel ausgewogene Granularität ist sowohl in der Serviceorientierung als auch in der traditionellen Softwareentwicklung bekannt [Erl2005; Same1997, 123]. Granulaität beschreibt den Umfang und die Art der Funktionen, welche durch ein Modul einer IS-Architektur unterstützt werden [Balz1998, 559; Erl2005, 299, 302; MaBe2006, 40, 124]. Je weniger Funktionen vorhanden sind und je konkreter diese auf einen einzelnen Aufgabenbereich ausgerichtet sind, desto feiner ist die Granularität. Die Granularität ist das Ergebnis der Definition der Module im Rahmen der Modellierung einer IS-Architektur [RoLi2004, 54]. In erster Linie wird sie durch das Abstraktionsniveau der Aufgaben bestimmt, die durch die Module erfüllt werden [Erl2005, 299; ZiKG2004]. Die Granularität sollte angemessen gewählt werden, um die Wiederverwendungspotentiale der Module einer IS-Architektur zu erhöhen [BiLi2006, 101; RoLi2004]. Es gibt verschiedene Ansätze, um beim Zuschneiden der Module deren Granularität zur Erhöhung der Wiederverwendbarkeit zu verbessern [Häus2004, 267; Raas1993, 375; Same1997, 24]: Durch das Herauslösen von Bestandteilen aus Modulen und die Zusammenführung dieser Bestandteile in neue Module wird die Kopplung verringert und die Kohäsion erhöht. Durch Herauslösen von Bestandteilen, die in mehreren Modulen enthalten sind, können Redundanzen vermieden werden. Die redundanten Bestandteile können in neuen Modulen zusammengefasst werden. Durch Schichtenbildung, bei der Module, die eine gleichartige Rolle spielen, auf einer Schicht der Aufrufhierarchie zusammengefasst

98

René Fiege, Dirk Stelzer

werden, können häufig verwendete Module einer höheren Schicht zur Verfügung gestellt werden [Same1997, 24].

3

Modellierungsmethoden des Software Engineerings

In diesem Abschnitt geben wir einen Überblick über wichtige Analyse- und Entwurfsmethoden des Software Engineerings. Historisch lässt sich die Softwareentwicklung in die strukturierte (oder traditionelle) und die objektorientierte Softwareentwicklung unterteilen [Balz2001]. Entsprechende Methoden werden im Folgenden kurz beschrieben. 3.1

Methoden der strukturierten Softwareentwicklung

Die Strukturierte Analyse wurde zuerst von DeMarco beschrieben [DeMa1978]. Im Laufe der Zeit wurde sie von verschiedenen anderen Autoren, z.B. Weinberg [Wein1978] und Yourdon [Your1989] modifiziert und weiterentwickelt. Seit ihren Anfängen in den siebziger Jahren hat sie sich zu der wichtigsten Methode der Systemanalyse entwickelt. Inzwischen wurde sie weitgehend von der objektorientierten Analyse und den Notationsmitteln der Unified Modeling Language (UML) abgelöst [Balz2001, 432]. Die Strukturierte Analyse umfasst eine Klasse von Methoden zur Erstellung einer formalen Systembeschreibung im Rahmen der Analysephase eines Softwareentwicklungsprojektes. Sie ist der erste Schritt der klassischen strukturierten Softwareentwicklung. Das Ergebnis der Strukturierten Analyse enthält eine hierarchisch gegliederte technische Spezifikation für das Systemverhalten. Die Strukturierte Analyse beinhaltet graphische Analysemethoden, die mit Hilfe eines Top-Down-Vorgehens ein komplexes System in immer einfachere Funktionen bzw. Prozesse aufteilt und gleichzeitig eine Datenflussmodellierung durchführt [Raas1993, 85]. Die Strukturierte Real-Time-Analyse wurde im Wesentlichen durch Hatley und Pirbhai [HaPi1987] sowie Ward und Mellor [WaMe1985a; WaMe1986; WaMe1985b] geprägt. Wie bei der Strukturierten Analyse handelt es sich bei der Real-TimeAnalyse um eine Klasse von Methoden, die in der Analysephase eines Softwarentwicklungsprojektes eingesetzt werden können. Die Real-Time-Analyse basiert auf der Strukturierten Analyse und erweitert diese, sodass ereignisgesteuerte Systeme mit Zeitanforderungen an die Initialisierung und Terminierung von Prozessen und Funktionen modelliert werden können [Balz2001, 454]. Strukturiertes Design ist eine Entwurfsmethode, die u. a. durch Stevens [StMC1974], Myers [Myer1978] sowie Yourdon und Constantine [YoCo1979] geprägt wurde. Im Rahmen des Strukturierten Design wird eine Softwarearchitektur entworfen, die aus hierarchisch angeordneten funktionalen Modulen besteht [Balz2001, 1024]. Die Entwurfsspezifikation wird mit Hilfe von Strukturdiagrammen und Modulspezifikationen dokumentiert. Das Strukturierte Design ist der zweite Schritt im Rahmen der klassischen strukturierten Softwareentwicklung. Sie wird nach Durchführung der Strukturierten Analyse angewendet. Im Strukturierten Design kann mit Hilfe von Transformationsregeln die Spezifikation der Strukturierten Analyse in einen strukturierten Softwarearchitekturentwurf überführt werden. Im Gegensatz zur Strukturierten Analyse werden im Strukturierten Design technische Details einge-

Modellierung Serviceorientierter Architekturen

99

bracht, die während der Implementierung eines Softwaresystems berücksichtigt werden müssen [GhJM2003, 434ff.]. Eine weitere Entwurfsmethode der strukturierten Softwareentwicklung ist Modulares Design. Modulares Design erweitert das Strukturierte Design, indem neben der funktionalen Abstraktion die Datenabstraktion als weiteres Konzept zur Erstellung eines Softwarearchitekturentwurfes verwendet wird [Balz2001, 1033]. Im Gegensatz zum Strukturierten Design, in welchem nur funktionale Module betrachtet werden, verwendet Modulares Design sowohl funktionale Module als auch Datenobjekt- und Datentyp-Module, um die Systemkomponenten einer Softwarearchitektur zu modellieren. 3.2

Methoden der objektorientierten Softwareentwicklung

Nach 1990 erlebte die objektorientierte Analyse im Rahmen der objektorientierten Softwareentwicklung eine rasante Entwicklung. Geprägt wurde sie u. a. von Booch [Booc1994], Coad und Yourdon [CoYo1991] sowie Rumbaugh et al. [RBPE1991]. Die objektorientierte Analyse ist der erste Schritt der objektorientierten Modellierung. In der objektorientierten Analyse werden die Anforderungen an ein Softwaresystem erfasst und als fachliche Lösung mit Hilfe objektorientierter Konzepte modelliert. Die Notation erfolgt heute i. d. R. mit Hilfe der UML. Es entsteht eine Spezifikation, die sich aus einem statischen und einem dynamischen Modell zusammensetzt [Balz2005, 11]. Das statische Modell beschreibt u. a. die Daten (Attribute) und die Klassen des Systems sowie die Assoziationen zwischen den Klassen und die Vererbungsstrukturen. Das dynamische Modell beschreibt das Verhalten des zu entwickelnden Systems. Zusammen mit der Entwicklung der objektorientierten Analyse bildete sich Anfang der 90er Jahre das objektorientierte Design heraus. Geprägt wurde es u. a. wiederum von Booch [Booc1994], Coad und Yourdon [Your1991] sowie Rumbaugh et al. [RBPE1991]. Das objektorientierte Design ist der zweite Schritt der objektorientierten Modellierung. Es wird nach Durchführung der objektorientierten Analyse angewendet. Die Spezifikation der objektorientierten Analyse werden im objektorientierten Design aufgegriffen und unter den geforderten technischen Rahmenbedingungen des zu entwickelnden Softwaresystems weiter verfeinert [GhJM2003, 139ff.]. Ziel ist es, einen Entwurf zu erstellen, der den Anforderungen an das Softwaresystem gerecht wird und gleichzeitig eine Einbettung dieses Systems in die Anwendungsund Plattformumgebung ermöglicht [Balz2001, 986]. 3.3

Methoden zur Entwicklung Serviceorientierter Architekturen

Im Zusammenhang mit der Entwicklung Serviceorientierter Architekturen bilden sich derzeit die Begriffe Serviceorientierte Analyse und Serviceorientiertes Design heraus [BBFJ2006; Erl2005]. Die Konzepte der Serviceorientierten Analyse und des Serviceorientierten Designs sind vergleichbar mit den Konzepten der objektorientierten Analyse und dem objektorientierten Design. In der Serviceorientierten Analyse geht es um die Ermittlung von Anforderungen an eine SOA und die Modellierung vorläufiger Servicekandidaten. Im Serviceorientierten Design werden die Ergebnisse der Serviceorientierten Analyse aufgegriffen und unter Berücksichtigung der gegebenen technischen Rahmenbedingungen weiter verfeinert. Es gibt zwar Ansätze, um

100

René Fiege, Dirk Stelzer

die Serviceorientierte Analyse und das Serviceorientierte Design zu unterstützen [Arsa2004; BBFJ2006; EAAC2004; Erl2005; ZiKG2004; ZSWP2005], allerdings befinden sich diese Methoden noch in einem sehr frühen Entwicklungsstadium und es liegen kaum Anwendungserfahrungen vor. In diesem Beitrag verzichten wir daher auf eine detaillierte Darstellung dieser Methoden und deren Vergleich mit Axiomatic Design.

4

Axiomatic Design versus Strukturierte Analyse

Sowohl die Strukturierte Analyse als auch das Strukturierte Design sind Methodenklassen. Die SADT [Ross1985], die Strukturierte Analyse von DeMarco [DeMa1978], die Strukturierte Systemanalyse von Gane und Sarson [GaSa1979] sind Beispiele für Methoden der Strukturierten Analyse. Das Strukturierte Design nach Yourdon [YoCo1979], die Jackson Design Methode [Jack1975] und die Warnier Methode [Warn1974] gehören zu den strukturierten Design Methoden. Alle strukturierten Methoden weisen folgende Gemeinsamkeiten auf: Top-Down-Vorgehen, bei welcher das System hierarchisch strukturiert wird, Zerlegung des Systems in überschaubare Bestandteile, einfache grafische Modellnotation (z.B. über Fluss- und Kontextdiagramme). In den folgenden Abschnitten stellen wir Axiomatic Design beispielhaft einer der traditionellen Entwurfsmethoden gegenüber. Auf Grund des begrenzten Seitenumfanges können wir in diesem Beitrag nur eine Methode heranziehen. Wir haben uns aus zwei Gründen für die Strukturierte Analyse von DeMarco entschieden. Erstens besteht der Hauptbeitrag von Axiomatic Design in der Unterstützung der Analysephase eines Softwareentwicklungsprojektes [FiSt2007] und zweitens ist die Strukturierte Analyse von DeMarco historisch gesehen die erste Strukturierte AnalyseMethode [DeMa1978]. 4.1

Modellierung von SOA mit Axiomatic Design

Axiomatic Design wurde Ende der 1970er Jahre von Nam Pyo Suh am Massachusetts Institute of Technology (MIT) für das Mechanical Engineering entwickelt [Suh1990, 18]. Es handelt sich dabei um eine Methode, mit der man strukturiert beliebige Objekte entwerfen kann. Das Grundprinzip von Axiomatic Design umfasst die strukturierte Suche und Zuordnung geeigneter Lösungen für zuvor festgelegte Anforderungen. Ein Entwurf ist definiert als Ergebnis dieses Zuordnungsprozesses [Suh2001, 2ff.]. Er beschreibt, welche Anforderungen durch welche Lösung erfüllt werden können. Axiomatic Design basiert auf dem Konzept der Domänen, dem Dekompositionsprozess sowie auf dem so genannten Unabhängigkeits- und dem Informationsaxiom. Beide Axiome formulieren Richtlinien für den Entwurfsprozess. Das Konzept der Domänen umfasst die Kundendomäne, die funktionale und die physische Domäne sowie die Prozessdomäne. Der Entwurfsprozess erstreckt sich über alle Domänen. Er beginnt in der Kundendomäne und endet in der Prozessdomäne. Jede Vorgängerdomäne beschreibt Anforderungen, jede Folgedomäne die korrespondierenden Lösungen. Zwischen allen Domänen erfolgt eine Zuordnung von Anforderungen zu korrespondierenden Lösungen [Suh2001, 10-14]. Während der Zuordnung zwischen den Domänen wird das Unabhängigkeitsaxiom angewendet. Im Folgenden wird dies exemplarisch anhand der Zuordnung zwischen

Modellierung Serviceorientierter Architekturen

101

der funktionalen und der physischen Domäne erläutert. Das Unabhängigkeitsaxiom verlangt, dass die Unabhängigkeit der so genannten funktionalen Anforderungen in der funktionalen Domäne nach Zuordnung so genannter Designparameter in der physischen Domäne gewahrt bleibt. Vollständige Unabhängigkeit liegt dann vor, wenn jede funktionale Anforderung durch genau einen Designparameter erfüllt wird. Der Zuordnungsprozess zwischen den Domänen wird hierarchisch im Top-DownVerfahren durchgeführt, um den Entwurf weiter zu verfeinern. Man spricht in diesem Zusammenhang vom Dekompositionsprozess (Abb. 4-1). Der Dekompositionsprozess verlangt, dass zwischen den Domänen hin und her gesprungen wird. Wie in Abb. 4-1 dargestellt, springt man ausgehend von einer funktionalen Anforderung in die physische Domäne, um einen geeigneten Designparameter zuzuordnen. Anschließend erfolgt der Rücksprung in die funktionale Domäne.

Abb. 4-1: Dekompositionsprozess Dieser Prozess wird so lange wiederholt, bis so genannte „elementare FA-DPKombinationen“ gefunden wurden. Eine Elementarkombination (diese sind in Abb. 41 fett hervorgehoben) liegt vor, wenn für eine funktionale Anforderung ein Designparameter gefunden wird, der unmittelbar, d. h. ohne weitere Dekomposition, implementierbar ist. Sobald eine Hierarchieebene im Dekompositionsprozess fertig gestellt wurde, wird das Unabhängigkeitsaxiom zur Prüfung der Unabhängigkeit der funktionalen Anforderungen herangezogen. Erst danach wird der Dekompositionsrozess auf tiefer liegenden Ebenen fortgesetzt. Die Entwurfsergebnisse werden in der so genannten Gesamteinflussmatrix dokumentiert. Diese Matrix beinhaltet sämtliche FA und DP und zeigt, welche FA von welchen DP abhängen. Liegen alternative FA-DP-Kombinationen vor, die das Unabhängigkeitsaxiom erfüllen, wird das Informationsaxiom angewendet, um den besten Entwurf zu ermitteln. Das Informationsaxiom ermöglicht eine quantitative Bewertung gegebener Entwürfe und ermöglicht eine Reduktion der Komplexität sowie eine Erhöhung der Zuverlässigkeit [ClHi2000, 274; Suh2001, 39ff.]. Das Informationsaxiom verlangt, dass der so genannte Informationsgehalt reduziert wird. Von den Entwürfen, die das Unabhängigkeitsaxiom erfüllen, wird derjenige ausgewählt, bei welchem der geringste

102

René Fiege, Dirk Stelzer

Informationsgehalt ermittelt wird. Man spricht in diesem Zusammenhang vom Selektionsprozess. Die Anwendung von Axiomatic Design zur Modellierung von SOA basiert auf den Grundlagen, die oben beschrieben wurden. Die funktionalen Anforderungen bilden dabei logische Kontexte ab (z.B. die betriebswirtschaftliche Funktion „Rechnung buchen“ oder die Entität „Buchhaltungssystem“), nach denen später Operationen und Services gruppiert werden können. Die Designparameter repräsentieren Daten der Serviceverarbeitung [Erl2005, 35-37]. Ein zentrales Hilfsmittel zur Modellierung der SOA und Dokumentation der Entwurfergebnisse ist die Gesamteinflussmatrix. Im Inhaltsbereich dieser Matrix werden die Serviceoperationen, Servicekandidaten und Abhängigkeiten zwischen Servicekandidaten abgebildet. Auf Grund des begrenzten Seitenumfangs wird hier auf eine detaillierte Beschreibung der Anwendung von Axiomatic Design zur Modellierung von SOA verzichtet. Diese Beschreibung kann allerdings in [FiSt2006; FiSt2007] nachgelesen werden. In diesen Quellen wird u. a. die Modellierung von SOA mit Hilfe von Axiomatic Design im Rahmen eines Fallbeispiels demonstriert. 4.2

Strukturierte Analyse von DeMarco

Die Strukturierte Analyse ist seit der Mitte der 1970er Jahre entwickelt worden und wurde erstmals von DeMarco in seinem Werk „Structured Analysis and System Specification“ [DeMa1978] beschrieben. Verglichen mit älteren Methoden der Softwareentwicklung beinhaltet die Strukturierte Analyse nach DeMarco keine neuen Basiskonzepte. Allerdings war die Art und Weise neu, wie bekannte Basiskonzepte miteinander kombiniert wurden [Balz2001, 432]. Diese Methode erlaubt die Erstellung einer Entwurfspezifikation in Form eines Strukturierten Analyse-Modells, das alle zur Beschreibung eines Softwaresystems notwendigen Informationen enthält. Ein großer Vorteil ist die einfache Modellnotation, die auf leicht erlernbaren und verständlichen grafischen Hilfsmitteln basiert. Die Grafiken zeigen z.B. die Module eines Systems und ihre Schnittstellen [DeMa1978]. Die Strukturierte Analyse von DeMarco basiert auf den Hilfsmitteln Kontext- und Flussdiagramm, Data Dictionary, Entscheidungstabellen, Pseudo Code und Funktionsbäumen [DeMa1978]. Das Hierachiekonzept (vgl. Abb. 4-2) verlangt eine funktionsorientierte Zerlegung. Dabei wird ausgehend von einem abstrakten Datenflussdiagramm – dem so genannten Kontextdiagramm – jede Funktion des zu modellierenden Softwaresystems verfeinert und durch ein eigenes Datenflussdiagramm beschrieben. Wird eine Funktion nicht weiter unterteilt, ist die Blattebene der Hierarchie erreicht worden. Eine solche Funktion wird durch eine so genannte MiniSpezifikation (MiniSpec) in Form von Pseudo Code, Entscheidungstabellen oder Entscheidungsbäumen genauer beschrieben. Das Kontextdiagramm beinhaltet eine abstrakte Funktion, die das Gesamtsystem repräsentiert. Außerdem beschreibt es die Schnittstellen des Systems mit seiner Umgebung und die Datenflüsse zwischen den Schnittstellen mit dem System. Datenflussdiagramme verfeinern das Kontextdiagramm. Die Funktion des Kontextdiagrammes wird hierarchisch in Teilfunktionen zerlegt. Umgebungsschnittstellen werden im Datenflussdiagramm nicht verfeinert. Datenflüsse zwischen Funktionen des Systems verlaufen immer über Datenspeicher.

Modellierung Serviceorientierter Architekturen

103

A

a4

a5

B

a7 B a7

v

w

z2

B

Abb. 4-2: Hierarchiekonzept der Strukturierten Analyse Die Datenflussdiagramme bilden die hierarchische Zerlegung des Systems ab. Sie sind ineinander verschachtelt. Jede Funktion in einem Datenflussdiagramm einer Hierarchieebene kann durch Datenflussdiagramme auf tiefer liegenden Hierarchieebenen weiter verfeinert werden. Dabei werden auch die Datenflüsse, allerdings nicht die Datenspeicher verfeinert. Der Zusammenhang zwischen den Datenflüssen der verschiedenen Datenflussdiagramme aller Hierarchieebenen wird durch die Einträge im so genannten Data Dictionary hergestellt [DeMa1978, 42]. Es enthält sämtliche Speicher und Datenflüsse und zeigt deren Zusammensetzung als Folge der Verfeinerung auf tieferen Hierarchieebenen. Für die Datenflüsse im Entwurf in Abb. 4-2 wären z.B. folgende Einträge im Data Dictionary sinnvoll: A=a1+a2, a2=x+y, a6=v+w, C=c1+c2. Jede Funktion, die nicht durch ein weiteres Datenflussdiagramm verfeinert wird, muss durch eine Minispezifikation beschrieben werden. Sie definiert, wie eine Funktion die eingehenden Datenflüsse in ausgehende Datenflüsse transformiert. Dies kann z.B. mit Hilfe von Pseudocode beschrieben werden. 4.3

Gemeinsamkeiten und Unterschiede

Axiomatic Design und die Strukturierte Analyse von DeMarco weisen folgende Gemeinsamkeiten auf. x

Beide Methoden unterstützen ein Top-Down-Vorgehen, bei welchem das zu modellierende System hierarchisch strukturiert wird. Nach der Methode von

104

René Fiege, Dirk Stelzer 2

DeMarco erfolgt eine funktionsorientierte Zerlegung , bei der das System als Ganzes als Funktion bestehend aus hierarchisch verschachtelten Subfunktionen abgebildet wird. x

Sowohl in der Methode nach DeMarco als auch im Axiomatic Design werden während der hierarchischen Zerlegung die Daten modelliert, die zwischen den funktionalen Modulen des Systems ausgetauscht werden.

x

Zur Abbildung der Systemarchitektur werden bei beiden Methoden einfache grafische Notationshilfsmittel verwendet. Das Kontextdiagramm und das Datenflussdiagramm der Methode von DeMarco bilden u. a. die funktionalen Module und die Datenflüsse ab. Das Datenflussdiagramm des Axiomatic Designs ist sehr ähnlich, da es die Ergebnisse der Einflussmatrix ebenfalls als funktionale Module und Datenflüsse darstellt.

Der wesentliche Unterschied zwischen den Methoden besteht in der Bereitstellung von Entwurfs- und Prüfregeln. x

Während der hierarchischen Strukturierung und Zerlegung des Systems im Axiomatic Design werden zur Überprüfung der Entwurfsentscheidungen das Unabhängigkeits- und Informationsaxiom angewendet. Die Anwendung des Unabhängigkeitsaxioms hilft dabei, die Stärke der Kopplung zwischen Systemmodulen zu reduzieren und Zyklen zu eliminieren [FiSt2007; KiSK1991, 253; Suh2001]. Die Anwendung des Informationsaxioms kann z.B. dabei helfen, die Komplexität des zu entwickelnden Systems zu reduzieren [FiSt2007; Suh2001].

x

Eine derartige Prüfung der Entwurfsschritte ist im Vorgehen der Strukturierten Analyse nach DeMarco nicht vorgesehen [DeMa1978]. Zwar lässt sich in der Strukturierten Analyse eine ähnliche Evaluierung z.B. durch Erweiterung der Methodik und Einführung von Prüfschritten unter Anwendung von Kopplungsoder Komplexitätsmetriken etablieren. Allerdings sind solche Prüfschritte nicht originär in der Strukturierten Analyse verankert.

x

Zur Herstellung des Zusammenhangs zwischen Datenflüssen einer Hierarchieebene und den verfeinerten Datenflüssen einer tiefer liegenden Ebene benötigt man in der Strukturierten Analyse das Data Dictionary. Im Axiomatic Design benötigt man kein zusätzliches Hilfsmittel. Die Abhängigkeiten lassen sich aus den hierarchischen Beziehungen der Gesamteinflussmatrix auslesen.

x

Im Axiomatic Design existiert mit der Gesamteinflussmatrix ein Darstellungsmittel, in welchem alle modellierten Architekturelemente eines Systems, d. h. seine funktionalen Module, die Datenflüsse zwischen den Modulen und die hierarchischen Abhängigkeiten der Module abgebildet werden können. Dies erleichtert z.B. die Überprüfung der Integrität der Datenflüsse auf den verschiedenen Hierarchieebenen und die Konsistenzprüfung sämtlicher Abhängigkeiten im System. In der Strukturierten Analyse nach DeMarco sind die Architekturelemente auf mehrere Darstellungsmittel, d. h. das Kontextdiagramm, mehrere verschachtelte Datenflussdiagramme und das Data Dictionary verteilt.

x

In der Strukturierten Analyse werden im Gegensatz zum Axiomatic Design Datenspeicher und externe Schnittstellen modelliert.

2

Im Allgemeinen werden in der Strukturierten Analyse neben der funktionsorientierten Zerlegung auch andere Zerlegungsstrategien, z.B. die essentielle Zerlegung, angewendet [Raas1993, 76].

Modellierung Serviceorientierter Architekturen

5

105

Analyse des Beitrages zur Erreichung der Architekturziele

In diesem Abschnitt werden wir den Beitrag von Axiomatic Design und der Strukturierten Analyse von DeMarco zur Förderung der Architekturziele ausgewogene Granularität, lose Kopplung und hohe Autonomie analysieren. Wie in Abschnitt 2 dargelegt, sind diese Ziele sowohl für SOA als auch für IS-Architekturen im Allgemeinen wichtig. Sie spielen daher in der Serviceorientierung und der traditionellen Softwareentwicklung eine zentrale Rolle. Axiomatic Design ist im Software Engineering eine neue Methode. In die Welt der SOA wurde sie nach unserem Kenntnisstand bisher nur im Rahmen des Forschungsprojektes AD-SOA der Technischen Universität Ilmenau übertragen und angewendet. Wie in Abschnitt 2 dargestellt, weist Axiomatic Design eine Reihe von Gemeinsamkeiten zu traditionellen Methoden des Software Engineerings auf. Deshalb beschäftigen wir uns im Folgenden mit der Frage, ob Axiomatic Design für die Entwicklung von SOA tatsächlich einen sinnvollen Beitrag leistet, der über den Beitrag traditioneller Methoden hinausgeht. Die Gegenstände beider Methoden können je nach Anwendungsgebiet unterschiedlich sein. Während es in der Strukturierten Analyse nach DeMarco um die Modellierung von Softwarearchitekturen geht, werden mit der hier vorgestellten Axiomatic Design-Methode Serviceorientierte Architekturen gestaltet. In beiden Fällen werden jedoch Bestandteile und Beziehungen zwischen Bestandteilen von IS-Architekturen modelliert. Die Bestandteile sind in der Strukturierten Analyse z.B. Funktionen von Softwareprogrammen. Werden Serviceorientierte Architekturen mit Axiomatic Design gestaltet, sind die Bestandteile z.B. die Operationen von Services oder die Services selbst. Um den Vergleich beider Methoden zu erleichtern, abstrahieren wir von den Begriffen der unterschiedlichen Bestandteile und verwenden im Folgenden nur den Begriff Modul. 5.1

Hohe Autonomie

Die Anwendung von Axiomatic Design fördert eine hohe Autonomie der Services, da Entwurfsanforderungen klar voneinander abgegrenzt werden und die Entstehung kohärenter Teillösungen gefördert wird. Im Rahmen der Zuordnung und hierarchischen Dekomposition wird sichergestellt, dass für jede funktionale Anforderung einer Dekompositionsebene auf der nächst tieferen Ebene ausschließlich FA-DPKombinationen erarbeitet werden, die einen Beitrag zur Erfüllung dieser funktionalen Anforderung leisten. Auf jeder Dekompositionsebene werden so kohärente Teillösungen gruppiert, die auf die Erfüllung einer funktionalen Anforderung abzielen. Auf diese Weise entstehen Module (Services oder Operationen), deren Bestandteile ebenfalls auf genau einen definierten Kontext (z.B. eine Funktion) ausgerichtet sind. Die Entstehung kohärenter Module wird auch in der Strukturierten Analyse nach DeMarco gefördert, da hier eine hierarchische Zerlegung der Funktionen des Gesamtsystems erfolgt. Auf jeder Dekompositionsebene werden hierzu Funktionen festgelegt. Pro Funktion sind anschließend die ein- und ausgehende Datenströme zu definieren. Die genaue Festlegung einzelner ein- und ausgehender Teildatenströme erfolgt nach Verfeinerung der Funktionen auf der nächsten Dekompositionsebene. Im Axiomatic Design werden die funktionalen Anforderungen (FA) und korrespondierenden Lösungen (DP) immer paarweise definiert. Dabei bilden die DP die Daten ab, die durch die entstehenden Module verarbeitet werden. Die Daten werden zusammen mit den FA auf der nächsten Dekompositionsebene verfeinert. Im

106

René Fiege, Dirk Stelzer

Axiomatic Design sind die Ableitung der Module und deren Daten sehr stark an die festgelegten FA gebunden. Im Gegensatz zur Strukturierten Analyse nach DeMarco wird daher größerer Wert darauf gelegt, dass die Module nur die Daten erhalten, die für ihre Aufgabenerledigung tatsächlich benötigt werden – eine weitere wichtige Voraussetzung, um kohärente Teillösungen zu erzeugen [Raas1993, 374]. Im Gegensatz zur Strukturierten Analyse von DeMarco erfolgt im Axiomatic Design die Modellierung des Gesamtsystems mit der Gesamteinflussmatrix, die bereits während der Modellierung die Darstellung sämtlicher Architekturelemente in einer Übersicht ermöglicht. So können schon während der Modellierung leicht Faktorisierungsschritte umgesetzt werden, um Teilmodule aus einem Modul herauszulösen und in einem eigenen Modul abzulegen. Dadurch kann sowohl die Kohäsion des vereinfachten als auch des übrig bleibenden Moduls verbessert werden [Raas1993, 375]. 5.2

Lose Kopplung

Durch Axiomatic Design wird das Ziel der losen Kopplung gefördert, da die Unabhängigkeit von Entwurfsbestandteilen bewusst angestrebt wird. Dies wird durch das Unabhängigkeitsaxiom erreicht. Es stellt sicher, dass jede funktionale Anforderung durch möglichst wenige Designparameter beeinflusst wird. Abhängigkeiten sind nur auf oder unterhalb der Diagonalen der Gesamteinflussmatrix erlaubt. Durch Verminderung der Abhängigkeiten in der Gesamteinflussmatrix wird im Gesamtsystem die Anzahl der Beziehungen zwischen den Modulen (Services oder Operationen) reduziert. Das Unabhängigkeitsaxiom stellt außerdem sicher, dass problematische zyklische Kopplungen sofort eliminiert werden. DeMarco weist im Rahmen der Beschreibung seiner Methode darauf hin, dass die Anzahl der ein- und ausgehenden Datenflüsse einer Funktion Auswirkungen auf die Zweckmäßigkeit eines Entwurfes hat [DeMa1978, 113]. Er schlägt vor, die Anzahl der Datenflüsse so gering wie möglich zu halten. Auf die Kopplungsbeziehungen zwischen einzelnen Modulen geht er allerdings nicht direkt ein. In der Strukturierten Analyse nach DeMarco sind keine vergleichbaren Entwurfs- oder Prüfregeln vorhanden, die während der Modellierung beachtet werden müssen. Zwar lässt sich in der Strukturierten Analyse eine ähnliche Evaluierung etablieren, z.B. durch Erweiterung der Methodik und Einführung von Prüfschritten unter Anwendung von Kopplungsmetriken. Allerdings sind solche Prüfschritte nicht originär in der Methode verankert. Axiomatic Design leistet somit einen Beitrag zur Förderung der losen Kopplung, der über den Beitrag der Strukturierten Analyse von DeMarco hinausgeht. 5.3

Ausgewogene Granularität

Sowohl Axiomatic Design als auch die Strukturierte Analyse von DeMarco fördern eine ausgewogene Granularität, da Entwurfsbestandteile in überschaubarer Komplexität entstehen. Das Top-Down-Vorgehen bei der Zuordnung und Dekomposition bewirkt bei beiden Methoden, dass ein Gesamtsystem rekursiv in immer feiner granulierte Subsysteme zerlegt wird. Jede Dekompositionsebene enthält nur die Teillösungen, die dem Abstraktionsniveau dieser Ebene entsprechen. Auf diese Weise wird die Komplexität des gesamten Systems über mehrere Ebenen auf Einheiten überschaubarer Größe verteilt. So wird sichergestellt, dass keine zu grob granulierten Module entstehen. Die Granularität kann durch lose Kopplung und hohe

Modellierung Serviceorientierter Architekturen

107

Kohäsion gefördert werden (vgl. Abschnitt 2). Wie wir bereits gezeigt haben, können beide Ziele durch Axiomatic Design stärker gefördert werden als durch die Strukturierte Analyse von DeMarco. Ein besonderer Beitrag, den Axiomatic Design zur Förderung der ausgewogenen Granularität leistet, resultiert aus der Beseitigung zyklischer Kopplungen. Diese Kopplungsart liegt dann vor, wenn sich zwei Module gegenseitig aufrufen. Zyklen können jedoch auch über mehrere Module verlaufen. Sie weisen auf schlecht zugeschnittene Module hin, also auf eine schlechte Granularität [RoLi2004, 40ff.], und führen u. a. zur Senkung der Wiederverwendbarkeit und Entwurfsklarheit. Sie sind i. d. R. die Folge einer oberflächlichen Modellierung, bei welcher nicht darauf geachtet wurde, ob inhaltlich passende Bestandteile in einem Modul platziert wurden [RoLi2004, 40ff.]. Durch Anwendung des Unabhängigkeitsaxioms im Axiomatic Design können zyklische Kopplungen sofort beseitigt werden. Der Designer muss daher bereits während der Modellierung sehr stark darauf achten, welche und wie viele Bestandteile er in ein Modul (Services oder Operationen) aufnimmt. Die Granularität kann auch durch Beseitigung von Redundanzen verbessert werden. Redundanzen lassen sich im Allgemeinen durch Faktorisierung beseitigen. Dabei werden aus den Modulen eines Gesamtsystems redundante Submodule herausgelöst und in ein anderes Modul aufgenommen, auf das alle anderen Module zugreifen können [Häus2004, 267]. Dadurch wird die Granularität der Module feiner. Es entstehen allgemein nutzbare Module, was sich positiv auf die Wiederverwendbarkeit im Gesamtsystem auswirkt. Solche Faktorisierungsmaßnahmen können natürlich sowohl nach Anwendung der Strukturierten Analyse von DeMarco als auch nach Anwendung von Axiomatic Design durchgeführt werden. Im Gegensatz zur Strukturierten Analyse von DeMarco existiert im Axiomatic Design mit der Gesamteinflussmatrix aber ein Hilfsmittel, in welchem die Architekturelemente des gesamten Systems in einer Übersicht dargestellt werden können. Dies erleichtert die Aufdeckung und Eliminierung der Redundanzen.

6

Zusammenfassung und Ausblick

In diesem Papier haben wir Axiomatic Design exemplarisch mit der Strukturierten Analyse von DeMarco im Hinblick auf deren Beitrag zur Modellierung Serviceorientierter Architekturen verglichen. Wir haben die Gemeinsamkeiten und Unterschiede beider Methoden dargelegt und den Beitrag analysiert, den Axiomatic Design und die Strukturierte Analyse von DeMarco zur Förderung ausgewählter Architekturziele leisten können. Wir konnten zeigen, dass Axiomatic Design die Ziele ausgewogene Granularität, lose Kopplung und hohe Autonomie stärker fördert als die Strukturierte Analyse von DeMarco. Aus diesem Grund empfehlen wir, für die Modellierung Serviceorientierter Architekturen eher Axiomatic Design als die Strukturierte Analyse von DeMarco einzusetzen. Wir konnten zwar zeigen, dass Axiomatic Design einen positiven Beitrag zur Modellierung von SOA leistet. Offen ist allerdings, wie groß dieser Beitrag in realen Entwicklungsprojekten tatsächlich ist. In einer Fallstudie, die auf einem realen SOAProjekt beruht, prüfen wir zurzeit, inwieweit die beschriebenen Vorteile zur Entwicklung einer SOA tatsächlich erreicht werden können. Axiomatic Design stellt Entwurfsund Prüfregeln zur Beurteilung der Entwurfsentscheidungen bereit (vgl. Abschnitt 4.1). Deshalb könnte Axiomatic Design auch als Hilfsmittel für die Qualitätssicherung von SOA verwendet werden. Es ist aber zu überprüfen, welchen Beitrag Axiomatic Design zur Beurteilung von SOA-Spezifikationen genau leisten kann.

108

René Fiege, Dirk Stelzer

In diesem Beitrag konnten wir aus Platzgründen Axiomatic Design nur mit einer ausgewählten Methode der Strukturierten Analyse vergleichen. Um eine repräsentative Aussage über den Beitrag von Axiomatic Design zur Förderung der Architekturziele zu erhalten, der über den Beitrag traditioneller Methoden hinausgeht, planen wir auch einen Vergleich mit Methoden des Strukturierten Design, der objektorientierten Analyse und dem objektorientierten Design. In Abschnitt 3.3 haben wir darauf hingewiesen, dass zurzeit verschiedene Methoden zur Entwicklung Serviceorientierter Architekturen erprobt werden. Diese Methoden befinden sich allerdings alle noch in einem frühen Entwicklungsstadium. Ihre Bewährung steht noch aus. Insbesondere wird zu prüfen sein, wie groß der Beitrag von Axiomatic Design im Vergleich zum Beitrag dieser Methoden zur Verfolgung wichtiger Architekturziele ist und ob durch eine kombinierte Anwendung mit Axiomatic Design der Beitrag dieser Methoden verbessert werden kann.

Literaturverzeichnis [Arsa2004] Arsanjani, A.: Service-oriented modeling and architecture: How to identify, specify, and realize services for your SOA. http://www-128.ibm.com/developerworks/ webservices/library/ws-soa-design1/, 2004, Abruf am 2007-07-25. [Balz2001] Balzert, H.: Lehrbuch der Software-Technik: Software-Entwicklung. 2. Aufl., Spektrum, Heidelberg et al. 2001. [Balz2005] Balzert, H.: Lehrbuch der Objektmodellierung: Analyse und Entwurf mit der UML 2. 2. Aufl., Spektrum, Heidelberg et al. 2005. [Balz1998] Balzert, H.: Lehrbuch der Software-Technik: Software-Management, Softwarequalitätssicherung, Unternehmensmodellierung. Spektrum, Heidelberg et al. 1998. [BBFJ2006] Bieberstein, N.; Bose, S.; Fiammante, M.; Jones, K.; Shah, R.: Service-oriented architecture (SOA) compass: business value, planning, and enterprise roadmap. IBM Press, Upper Saddle River 2006. [BiLi2006] Bichler, M.; Lin, K.-J.: Service-Oriented Computing. In: IEEE Computer 39 (2006) 3, S. 99-103. [Booc1994] Booch, G.: Object-Oriented Analysis and Design. 2. Aufl., The Benjamin/Cummings Publication Company, Redwood City 1994. [Brau1994] Braun, C. L.: Reuse. In: Marciniak, J. J. (Hrsg.): Encyclopedia of Software Engineering. Wiley, New York et al. 1994, S. 1055-1069. [BuGa2005] Buchmann, I.; Gamber, M.: Methoden zur Unterstützung der Entwicklung einer SOA. In: Cremers, A. B.; Manthey, R.; Martini, P.; Steinhage, V. (Hrsg.): Informatik 2005: Informatik live!, Bonn 2005, S. 601-605. [ClHi2000] Clapsis, P. J.; Hintersteiner, J. D.: Enhancing Object-Oriented Software Development through Axiomatic Design. In: First International Conference on Axiomatic Design (ICAD2000), Cambridge 2000, S. 272-277. [CoYo1991] Coad, P.; Yourdon, E.: Object-Oriented Analysis. Yourdon Press, Englewood Cliffs 1991. [DeMa1978] DeMarco, T.: Structured Analysis and System Specification. Yourdon, New York 1978.

Modellierung Serviceorientierter Architekturen

109

[Dijk1969] Dijkstra, E. W.: Structured Programming. In: Ercoli, P.; Bauer, F. L. (Hrsg.): Software Engineering Techniques. Scientific Affairs Division NATO, Brüssel 1969, S. 6568. [DJMZ2005] Dostal, W.; Jeckel, M.; Melzer, I.; Zengler, B.: Service-Orientierte Architekturen mit Web Services: Konzepte - Standards - Praxis. Spektrum, München 2005. [DuHo2003] Dunkel, J.; Holitschke, A.: Softwarearchitektur für die Praxis. Springer, Berlin, Heidelberg, New York 2003. [EAAC2004] Endrei, M.; Ang, J.; Arsanjani, A.; Chua, S.; Comte, P.; Krogdahl, P.; Luo, M.; Newling, T.: Patterns: Service-Oriented Architecture and Web Services. http://www.redbooks.ibm.com, Abruf am 2007-07-25. [EKAP2005] Erradi, A.; Kulkarni, N.; Anand, S.; Padmanabhuni, S.: Designing Reusable Services: An Experimential Perspective for the Securities Trading Domain. In: Chung, J.Y.; Feuerlicht, G.; Webber, J. (Hrsg.): Proceedings of the First International Workshop on Design of Service-Oriented Applications (WDSOA'05). IBM Research Division, Amsterdam 2005, S. 25-32. [Erl2004] Erl, T.: Service-Oriented Architecture: a Field Guide to Integrating XML and Web Services. 5. Aufl., Prentice Hall PTR, New Jersey 2004. [Erl2005] Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR, Upper Saddle River et al. 2005. [FiSt2006] Fiege, R.; Stelzer, D.: Analyse des Beitrages von Axiomatic Design zum Entwurf Serviceorientierter Architekturen. In: Bankhofer, U.; Gmilkowsky, P.; Nissen, V.; Stelzer, D. (Hrsg.): Ilmenauer Beiträge zur Wirtschaftsinformatik Nr. 2006-07. Technische Universität Ilmenau, Ilmenau 2006. [FiSt2007] Fiege, R.; Stelzer, D.: Analyse des Beitrages von Axiomatic Design zum Entwurf Serviceorientierter Architekturen. In: Internationale Tagung Wirtschaftsinformatik Karlsruhe, 28. Februar - 2. März 2007, Bd. 2, Karlsruhe 2007, S. 909-926. [GaSa1979] Gane, C.; Sarson, T.: Structured Systems Analysis: Tools and Techniques. Prentice-Hall, Englewood Cliffs 1979. [GhJM2003] Ghezzi, C.; Jazayeri, M.; Mandrioli, D.: Fundamentals of Software Engineering. 2. Aufl., Prentice Hall, Upper Saddle River 2003. [HaPi1987] Hatley, D. J.; Pirbhai, I. A.: Strategies for real-time specification. Dorset House Publishing, New York 1987. [HaSc2006] Hagen, C.; Schwinn, A.: Measured Integration - Metriken für die Integrationsarchitektur. In: Schelp, J.; Winter, R. (Hrsg.): Integrationsmanagement. Planung, Bewertung und Steuerung von Applikationslandschaften. Springer, Berlin et al. 2006, S. 267292. [Häus2004] Häuslein, A.: Systemanalyse: Grundlagen, Techniken, Notierungen. VDE, Berlin, Offenbach 2004. [IEEE2000] IEEE(Hrsg.): ANSI/IEEE Std 1471-2000, Recommended Architectural Description of Software-Intensive Systems. o. O. 2000.

Practice

for

[Jack1975] Jackson, M. A.: Principles of program design. Academic Press, London et al. 1975.

110

René Fiege, Dirk Stelzer

[KiSK1991] Kim, S. J.; Suh, N. P.; Kim, S. G.: Design of Software Systems based on Axiomatic Design. In: Robotics & Computer-Integrated Manufacturing 8 (1991) 4, S. 243255. [MaBe2006] Marks, E. A.; Bell, M.: Service-Oriented Architecture: A Planning and Implementation Guide for Business and Technology. Wiley, Hoboken et al. 2006. [Myer1978] Myers, G. J.: Composite/Structured Design. van Nostrand Reinhold Company, New York 1978. [PaYa2002] Papazoglou, M. P.; Yang, J.: Design Methodology for Web Services and Business Processes. In: Lecture notes in computer science 2444 (2002), S. 54-64. [Raas1993] Raasch, J.: Systementwicklung mit strukturierten Methoden: ein Leitfaden für Praxis und Studium. 3. Aufl., Hanser, München et al. 1993. [RBPE1991] Rumbaugh, J.; Blaha, M.; Premerlani, W.; Eddy, F.; Lorensen, W.: ObjectOriented Modelling and Design. Prentice Hall, Englewood Cliffs 1991. [RoLi2004] Roock, S.; Lippert, M.: Refactoring in großen Softwareprojekten: Komplexe Restrukturierung erfolgreich durchführen. dpunkt, Heidelberg 2004. [Ross1985] Ross, D. T.: Applications and Extensions of SADT. In: IEEE Computer 18 (1985) 4, S. 25-34. [Same1997] Sametinger, J.: Software engineering with reusable components. Springer, Berlin, Heidelberg, New York, Barcelona, Budapest, Hong Kong, London, Milan, Paris, Santa Clara, Singapore, Tokyo 1997. [SiHu2005] Singh, M. P.; Huhns, M. N.: Service-Oriented Computing: Semantics, Processes, Agents. Wiley, Chichester et al. 2005. [StMC1974] Stevens, W. P.; Myers, G. J.; Constantine, L. L.: Structured Design. In: IBM Systems Journal (1974) 2, S. 115-139. [SuDo2000] Suh, N. P.; Do, S.-H.: Axiomatic Design of Software Systems. In: Annals of the CIRP 49 (2000) 1, S. 95. [Suh1990] Suh, N. P.: The Principles of Design. Oxford, New York et al. 1990. [Suh2001] Suh, N. P.: Axiomatic Design: Advances and Applications. Oxford, New York 2001. [VACI2005] Vogel, O.; Arnold, I.; Chughtai, A.; Ihler, E.; Mehlig, U.; Neumann, T.; Völter, M.; Zdun, U.: Software-Architektur: Grundlagen - Konzepte - Praxis. Spektrum, München 2005. [WaMe1985a] Ward, P. T.; Mellor, S. J.: Structured Development for Real-Time Systems, Volume 1: Introduction and Tools. Yourdon Press, Englewood Cliffs 1985a. [WaMe1985b] Ward, P. T.; Mellor, S. J.: Structured Development for Real-Time Systems, Volume 2: Essantial modeling techniques. Yourdon Press, Englewood Cliffs 1985b. [WaMe1986] Ward, P. T.; Mellor, S. J.: Structured Development for Real-Time Systems, Volume 3: Implementation modeling techniques. Yourdon Press, Englewood Cliffs 1986. [Warn1974] Warnier, J.-D.: Logical construction of programs. Stenfert Kroese, Leiden 1974. [Wein1978] Weinberg, V.: Structured Analysis. Yourdon Press, Englewood Cliffs 1978. [Wirt1971] Wirth, N.: Program Development by Stepwise Refinement. In: Communications of the ACM 14 (1971) 4, S. 221-227.

Modellierung Serviceorientierter Architekturen

111

[YiPa2004] Yi, J.-W.; Park, G.-J.: Software Development of a Sequential Algorithm with Orthogonal Arrays (SOA) using Axiomatic Design. In: Proceedings of ICAD2004, Seoul 2004. [YoCo1979] Yourdon, E.; Constantine, L. L.: Structured Design. Prentice Hall, Englewood Cliffs 1979. [Your1991] Yourdon, E.: Object-Oriented Design. Yourdon Press, Englewood Cliffs 1991. [Your1989] Yourdon, E.: Modern structured analysis. Prentice-Hall International, Englewood Cliffs et al. 1989. [ZiKG2004] Zimmermann, O.; Krogdahl, P.; Gee, C.: Elements of Service-Oriented Analysis and Design: An interdisciplinary modeling Approach for SOA Projects. http://www128.ibm.com/developerworks/webservices/library/ws-soad1/, 2004, Abruf am 2007-0725. [ZiTP2003] Zimmermann, O.; Tomlinson, M.; Peuser, S.: Perspectives on Web Services: Applying SOAP, WSDL and UDDI to Real-World Projects. Springer, Berlin et al. 2003. [ZSWP2005] Zimmermann, O.; Schlimm, N.; Waller, G.; Pestel, M.: Analysis and Design Techniques for Service-Oriented Development and Integration. In: Cremers, A. B.; Manthey, R.; Martini, P.; Steinhage, V. (Hrsg.): Informatik 2005: Informatik live!, Bonn 2005, S. 606-611.

Flexibilisierung von Unternehmensprozessen

Qualitätssicherung serviceorientierter Architekturen Ingo J. Timm, Arne Hormann, Thorsten Scholz Zusammenfassung: Serviceorientierte Architekturen ermöglichen durch ihre flexiblen Schnittstellen die dynamische Rekonfiguration von Softwaresystemen oder Geschäftsprozessen. Innerhalb dieses Beitrags werden Herausforderungen an die Qualitätssicherung bzw. an Prüfverfahren für diese Art dynamischer Systeme diskutiert und Ansätze zur automatisierten Gestaltung serviceorientierter Architekturen vorgeschlagen.

1

Einleitung

Die Globalisierung und damit einhergehende zunehmende Vernetzung der Fertigung, Abnahme der Fertigungstiefe und Outsourcing stellen hohe Anforderungen bezüglich Flexibilität und Wettbewerbsfähigkeit an Unternehmen. In diesem Rahmen ist die Integration von Informationssystemen innerhalb und zwischen Unternehmen essentiell. Eine besondere Herausforderung betrieblicher Anwendungssysteme ist es daher, ein hohes Maß an Flexibilität zu bieten, so dass eine Anpassung der IT-Infrastruktur, auf der Basis von Soft- und Hardware, zeitnah an neue Kooperations- und Fertigungsnetzwerke erfolgen kann. Vor diesem Hintergrund bieten serviceorientierte Architekturen einen vielversprechenden Ansatz zur flexiblen Kombination voneinander unabhängiger Systemkomponenten. Im Rahmen der Web Service Standardisierung wurde für die serviceorientierte Architektur verteilter Systeme eine Schnittstelle definiert, die sowohl die Beschreibung (UDDI), Recherche und Publikation (WSDL) als auch Nutzung (SOAP) von Web Services ermöglicht. Web Services kapseln Kernfunktionalität und bieten einen hohen Grad an Flexibilität und Skalierbarkeit. Serviceorientierung innerhalb von Unternehmen dient hierbei analog dazu, die Aufbereitung aller bzw. der wichtigsten Leistungen von Unternehmen in Anlehnung an Dienstleistungen in den Wirtschaftswissenschaften zu spezifizieren und somit eine flexible und insbesondere wiederverwendbare Unternehmensarchitektur zu entwickeln. Hieraus leitet sich unsere Vision – „Emergent Virtual Enterprises“ – für die Kombination von flexiblen Unternehmens- und Softwarearchitekturen ab, die darin gipfelt, dass ein Kunde ein Produkt spezifiziert und sich im Anschluss dynamisch Unternehmen zu einem Konsortium zusammenschließen, um die notwendigen Prozessschritte, Spezifikation, Fertigung und Disposition durchzuführen [TWTH2002]. Die Konfiguration des Konsortiums soll durch explizite Spezifikation der Dienste von Anbietern sowie Verhandlungen auf einem elektronischen Marktplatz erfolgen (vgl. Abb. 1-1). Diese Vision ist für solche Bereiche interessant, in denen eine intensive Koordination zwischen den Partnern erforderlich ist oder in denen sich die Zusammensetzung der Konsortien häufig ändert. Die vollständige Umsetzung von Konsortialzusammensetzung und Kundenspezifikation ist dabei selten realistisch; es lassen sich anhand dieser Vision interessante Forschungsfragen für die Gestaltung von Informationssystemen ableiten. Zum einen findet hier eine autonome Koordination auf der Basis von Dienstbeschreibungen und Verhandlungen statt. Eine solche Koordination von Fertigkeiten kann in der Praxis nur als Vorschlag angesehen werden, der die

116

Ingo J. Timm, Arne Hormann, Thorsten Scholz

technischen Aspekte wie Produktdesign, Logistik und Interoperabilität berücksichtigt. Aspekte wie Vertrauen und Erfahrungen sowie Emotionen bleiben außen vor – sind in der Entscheidungsfindung in Unternehmen jedoch nicht unwesentlich. Die wesentliche Forschungsfrage, die in dieser Vision enthalten ist, findet sich in der Möglichkeit, Logistiknetzwerke zu konfigurieren bzw. bestehende Konsortien zu modifizieren.

Abb. 1-1: Emergente Virtuelle Unternehmen Die (Re-) Konfiguration von Logistiknetzwerken erfordert eine Integration der Informationsflüsse, die auf der Basis von durch Dienste beschriebenen Informationssystemen erfolgen kann. Hierbei müssen insbesondere Fragen der Identifikation, Selektion, Kombination und Nutzung von Diensten gelöst werden. Diese Aspekte werden im Forschungsgebiet der Web Services und der Semantic Web Services untersucht. Hierbei ist die Bestimmung der Qualität bzw. die Bewertung eines Dienstes, der sogenannten Quality of Service (Dienstgüte) wesentlich. Die Quality of Service definiert eine multidimensionale Bewertungsmatrix, die sowohl objektive als auch subjektive Parameter enthält. Berbner et al. postulieren, dass diese Parameter manuell von einem Experten ermittelt werden müssen [Ber+2007]. Für das Management einer serviceorientierten Architektur werden darauf aufbauend Qualitätsebenen definiert, die eingehalten werden müssen (Service Level Agreements). Serviceorientierte Architekturen stellen besondere Anforderungen an das SoftwareEngineering. Hierbei muss zwischen der Entwicklung einzelner Dienste oder der Gestaltung eines Dienste-übergreifenden Informationssystems unterschieden werden. Für die Gestaltung einzelner Dienste lehnt sich das Softwareengineering an die Entwicklung von Komponenten oder Softwareagenten an. Hierbei ist es wichtig, auf die Fokussierung einer Funktionalität zu achten, die von der Granularität nicht zu klein und nicht zu groß ist. Da die Verknüpfung von Services immer einen Overhead

Qualitätssicherung serviceorientierter Architekturen

117

an Kommunikation- oder Koordinationskosten erzeugen wird, der größer ist, als der von Methodenaufrufen innerhalb eines Programms, würde eine zu geringe Granularität dazu führen, dass sich die Effizienz eines Systems verringert. Wird zu viel Funktionalität in einem Service gekapselt, so ist der Service nicht so universell einzusetzen. Dieses ist im Rahmen der geplanten Anwendungen zu berücksichtigen und entsprechend zu bewerten. Die Kopplung unterschiedlicher Dienste – ggf. auch unternehmensübergreifend – stellt eine vergleichbare Herausforderung zur Enterprise Application Integration (EAI) oder der Entwicklung von Multiagentensystemen dar. Für die Entwicklung von Multiagentensystemen wurde in [TiSK2006] ein abstraktes Vorgehensmodell entwickelt (s. Abb. 1-2), welches insbesondere eine Verstärkung des Design-Aufwands, eine Verringerung des eigentlichen Entwicklungsaufwands durch Kapselung und Wiederverwendung und eine Verstärkung der Qualitätssicherung vorschlägt. Die Spezifikation von Service Level Agreements ist hierbei eine der wesentlichen Aufgaben im Design von Systemen, die Services integrieren. Innerhalb dieses Beitrags fokussieren wir auf die Qualitätssicherung für Services.

Abb. 1-2: Softwareengineering für Multiagentensysteme [TiSK2006] Die Funktionalität und Zuverlässigkeit des Gesamtsystems hängt direkt von denen der individuellen Dienste ab. Im Gegensatz zu konventionellen Systemen muss die Qualität der Dienste zur Laufzeit nicht konstant sein. Ein Dienstanbieter kann z.B. einen Dienst entfernen oder den Algorithmus ändern ohne den Nutzer zu informieren. Daneben können natürlich auch Verfügbarkeit von Ressourcen (Internet, Speicher, Prozessor) und somit die aktuelle Auslastung einen Einfluss auf die Qualität haben. Daher schlagen wir einen Ansatz vor, mit dessen Hilfe automatisiert Dienste zertifiziert und somit diese Tests regelmäßig wiederholt werden können. Der Beitrag ist wie folgt gegliedert: Im zweiten Kapitel werden Web Services, Semantic Web Services und Quality of Service vorgestellt. Im Anschluss wird in Kapitel drei das Thema Prüfverfahren und insbesondere Testen für Services aufbereitet. Eine Architektur für Blackboard-Testen und Zertifizierung von Web Services wird in Kapitel 4 eingeführt. In Kapitel 5 wird ein Beispiel für die Nutzung dieser Architektur anhand von Suchalgorithmen als Services vorgestellt, evaluiert und die Ergebnisse interpretiert. Verwandte Arbeiten werden im Kapitel 6 diskutiert und im Kapitel 7 wird abschließend eine Zusammenfassung gegeben und die Ergebnisse diskutiert.

2

Grundlagen

Die oben angeführte Vision basierte auf der Nutzung von Agententechnologie zur Realisierung von Logistiknetzwerken, die sich ggf. Produkt- und Kunden-spezifisch

118

Ingo J. Timm, Arne Hormann, Thorsten Scholz

bilden und in Abhängigkeit konkreter Anforderungen von Fertigung zu Fertigung variieren können [TWTH2002]. Bei der Nutzung von Web Services an Stelle von Agenten scheint diese Vision realistischer, da nicht davon ausgegangen werden kann, dass jedes individuelle Unternehmen jeweils einen Intelligenten Agenten als Repräsentant des Unternehmens entwickelt und in einem solchen, marktbasierten Kontext zur Verfügung stellt. Die Nutzung innovativer Softwareansätze, die höchste Flexibilität ermöglichen, stellen ein aktuelles Forschungsthema dar; so wurden z.B. auf der „International Conference on Adaptive Business Systems“ Theorien, Methoden und Anwendungen von autonomen und adaptiven Geschäftsarchitekturen und Anwendungssystemen diskutiert [Tian2007]. Von 2000 bis 2006 wurde im Rahmen des DFG-Schwerpunktprogramms 1083 „Intelligente Softwareagenten und betriebswirtschaftliche Anwendungsszenarien“ u.a. untersucht, warum die flexiblen und adaptiven Ansätze der Agententechnologie sich noch nicht im Bereich der Anwendungsentwicklung etabliert haben. Im Ergebnis konnte gezeigt werden, dass Agententechnologie sich gegenüber konventionellen Ansätzen insbesondere durch eine Flexibilität in der Anwendung zur Laufzeit auszeichnen [KHLS2006]. Im DFG-Sonderforschungsbereich 637 werden für Logistikanwendungen Systeme untersucht, die über einen hohen Grad an Autonomie verfügen [FHSR2004]. Hierbei sollen insbesondere technische Innovationen in der Logistik (z.B. RFID, beinah überall verfügbare Netzwerke, automatische Umschlagsysteme) genutzt werden um selbststeuernde logistische Prozesse zu erzeugen. Andererseits wird von den Wirtschaftswissenschaften aus über neue Managementstrategien bereits seit 2004 geforscht. Diese Beispiele unterstützen den Trend in der Wissenschaftsgemeinschaft, flexible Architekturen für die Implementierung von Anwendungssystemen zu nutzen. Web Services sind eine mögliche Implementierung serviceorientierter Architekturen. Hierbei wird eine implizite Semantik für die Beschreibung der Funktionalität verwendet, so dass eine automatisierte Schlussfolgerung (Inferenz) über Funktionalitäten nicht möglich ist. Da die automatische Suche nach Diensten (service retrieval), die Verknüpfung von unterschiedlichen Diensten für die Lösung komplexer Aufgaben (service chaining) sowie die Ausführung von Diensten (service application) viel versprechende Forschungsthemen sind, werden im Rahmen des Semantic Webs Dienste (Semantic Web Services) untersucht, die explizite Beschreibungen mit einer formalen Semantik enthalten, die auch eine automatisierte Schlussfolgerung über Funktionalitäten erlauben [SoCZ2004], [MOGS2004]. Eine besondere Herausforderung hierbei ist die Repräsentation von Funktionalität und Fertigkeiten (capabilites) und mündet in der Frage: Wie kann sichergestellt werden, dass ein Dienst eine Aufgabe lösen kann und hierbei eine spezifische Dienstqualität einhält? [ScTS2005]. Cardoso identifiziert hierfür zwei wesentliche Aufgaben: das Matchmaking, also die Allokation von Dienstanbieter zu Dienstnachfrager und die Ordnung (ranking) von verschiedenen Web Services, die für die Lösung einer Aufgabe in Frage kommen. 2.1

Komposition von Web Services

Die Flexibilität und geringe Komplexität der Web Services haben in den letzten Jahren dazu geführt, dass sich Web Services zum de-facto Standard für die Schnittstellenddefinition und –implementierung entwickelt haben. Das Fehlen an Semantik im Web Service Bereich führt dazu, dass diese eher einzeln genutzt oder einfache Verkettungen von Web Services vorgenommen werden. Bei der Erwei-

Qualitätssicherung serviceorientierter Architekturen

119

terung durch Konzepte des Semantic Webs wird die Nutzung von diffizilen Algorithmen zur Verbindung bzw. Kombination mehrerer Dienste möglich. Shi et al. unterscheiden hierfür die Möglichkeiten der Komposition, welches im Wesentlichen der einfachen Verkettung entspricht, der Planung durch Methoden der Künstlichen Intelligenz, sowie die Schlussfolgerung über eine Wissensbasis. Diese Fragestellung findet sich analog bei der verteilten Planung von Aktionen und dem Capability Management in der Agententechnologie [TiWo2003], [Durf1996]. Insbesondere das „Model for Cooperation“ von Wooldridge stellt einen viel versprechenden Ansatz für die Strukturierung des Kompositionsprozesses dar [Wool2000]. Dieser kann analog zur Systematisierung von Service Chaining verwendet werden. Es finden sich hier vier Teilprozesse: Recognition, Team Formation, Plan Formation und Plan Execution. In dem ersten Schritt wird eine Kooperationsmöglichkeit identifiziert, welche im Rahmen der Web Services daraus bestehen würde, dass festgestellt wird, dass mehrere Services gemeinsam ein Problem lösen können. In der zweiten Stufe werden dann die Services ausgewählt, die an der Lösung beteiligt sind (Team Formation). Dieses kann auch die Verhandlung von Parametern zur Lösungserstellung beinhalten (Gewinnverteilung, Qualitätskriterien, etc.). Nach der Selektion der Services, die verbunden werden sollen, muss in einem Planungsschritt (Plan Formation) die Reihenfolge der Aktionen bzw. die Reihenfolge der Web Service Anwendungen festgelegt werden. Der vierte Schritt (Plan Execution) besteht in der Ausführung der einzelnen Web Services. In aktuellen Forschungsarbeiten werden zahlreiche Ansätze untersucht, um einen oder mehrere dieser Aufgaben zu lösen, z.B. [MOGS2004], [HSVV2004], [Lutz2004]. Für praktische Anwendungen sind Erweiterungen der Ansätze um die Aspekte Preisfindung und Ertragsverteilung (payoff-distribution) notwendig, vgl. [Sand1999]. Neben der einfachen Definition und Spezifikation von Schnittstellen tragen insbesondere solche weiterführenden Ansätze zur Etablierung von Web Services für die Anwendung in betrieblichen Anwendungssystemen bei. 2.2

Dienstgüte (Quality of Service) und Fertigkeiten (Capabilities)

Die Bewertung der Dienstgüte ist essentiell für die Selektion eines Dienstes, d.h., dass der Dienst gewählt bzw. in die Anwendung integriert werden sollte, der die beste Lösung für eine zu bearbeitende Aufgabe bietet. Wie bereits eingangs angeführt kann die Qualität von Diensten multidimensional beurteilt und daher in Quality of Service Modellen beschrieben werden (vgl. [LiNZ2004], [She+2002]). Diese Modelle unterscheiden zwischen solchen Kriterien, die domänenabhängig sind, z.B. spezifische betriebswirtschaftliche Kennzahlen, und generischen Kriterien, wie Ausführungspreis, Antwortzeit, Zuverlässigkeit und Reputation. Die Modelle sollten den organisatorischen Kontext berücksichtigen, (vgl. [Garv1988]). Spezifische Quality of Service Kriterien wurden in [Ran2003] identifiziert; die Autoren unterscheiden vier Dimensionen von Qualität für Web Services: Laufzeit, Transaktionsunterstützung, Konfigurationsmanagement & Kosten und Sicherheit. Im Rahmen dieses Beitrages wird das Konfigurationsmanagement in Hinsicht auf die Vollständigkeit definiert, also als Maß für die Distanz zwischen spezifizierten und zur Verfügung gestellten Fertigkeiten. Somit soll das wesentliche Kriterium des Konfigurationsmanagements, ob ein Dienst fähig ist, ein Problem zu lösen oder nicht bzw. bis zu welchem Grad, beurteilt werden.

120

Ingo J. Timm, Arne Hormann, Thorsten Scholz

Die Identifikation eines Dienstes, um ein spezifischen Problem zu lösen, erfordert (a) sowohl die formale Spezifikation des Dienstes als auch (b) die Formalisierung des gegebenen Problems. Soll die Allokation dynamisch und automatisiert erfolgen, ist darüber hinaus ein standardisiertes Protokoll notwendig. Das World Wide Web Konsortium (W3C) spezifiziert im Kontext von Web Services sowohl eine Architektur als auch Protokolle, um diese zu nutzen [W3C2002], z.B. die Beschreibungssprache WSDL [CCMW2001] zur Spezifikation eines Web Interfaces. Damit die Beschreibung der Fähigkeiten eines Dienstes dynamisch im Schlussfolgerungsprozess genutzt werden kann, ist es notwendig, hier eine formale Beschreibungssprache, wie DAML-S [Ank+2002] und OWL-S [Mar+2004] zu nutzen. Die Kombination von DAML-S und WSDL bietet einen formalen Rahmen an, um die Semantik von Web Services abzubilden. Diese Beschreibungen sind dennoch statisch und begrenzen dynamische Aspekte verteilten Problemlösens. Daher wird im Gebiet der Multiagentensysteme an einer Erweiterung des Service-zu-Problem Matchmakings gearbeitet, (vgl. [TiWo2003], [ScTW2004], [GuZu2004]). In [Maa+2007] wird auch die Notwendigkeit komplexer Matchmaking Ansätze für die Gestaltung serviceorientierter Architekturen betont. Die semantisch angereicherten Dienstbeschreibungen müssen in einer entsprechenden Infrastruktur, z.B. Katalogen oder Yellow-Pages eingebettet werden, so dass ein Matchmaking zwischen Anbieter und Nachfragern von Diensten realisiert werden kann. Im Bereich der Multiagentensysteme wurde durch die FIPA ein Dienstverzeichnis, der Director Facilitator (DF), als obligatorischer Teil einer Agentenplattform definiert [Fipa2003]. Der DF ist eine Implementierung eines Yellow Page Service für Agenten, welcher die Dienstbeschreibung von Agenten verwaltet. Im Bereich der Web Services wird die im Rahmen von Universal Description, Discovery, and Integration (UDDI) für die Gestaltung eines Katalogdienstes genutzt [Oasi2004]. 3

Qualitätssicherung und Prüfmethoden

Die Qualitätssicherung mit Prüfmethoden, wie Verifikation oder Validierung, ist ein wesentlicher Ansatz, um Softwaresysteme in industriellen Anwendungen einzusetzen. Hierbei soll überprüft werden, ob eine Software eine erwartete Reaktion in einer Situation zeigen wird, also ob eine Zusicherung von Eigenschaften erfolgen kann. Die Qualitätssicherung von verteilten Systemen ist bereits sehr komplex, da neben der Überprüfung der Funktionalität einer Software auch die Prüfung u.a. von Nebenläufigkeit erfolgen muss. Eine weitere Stufe der Komplexität wird erreicht, sobald die Subsysteme eines verteilten Systems nicht ausschließlich in der Kontrolle eines Eigners bzw. Unternehmens liegt. Dieses kann zu inhärenten Zielkonflikten bzw. Konflikten über Anforderungen an die Teilsysteme führen. Sind hierbei Konkurrenz- oder eingeschränkte Kooperationsbeziehungen involviert, so kann auch eine nicht transparente Anforderungsdefinition der Subsysteme der entsprechenden Partner dazu führen, dass eine Qualitätssicherung des gesamten Systems nicht möglich ist. Im konventionellen Softwareengineering wird die Qualitätssicherung vor dem Roll-Out durchgeführt, so dass zur Laufzeit ein gefordertes Systemverhalten sichergestellt ist. Im serviceorientierten Softwareengineering trifft diese Annahme nicht mehr zu; vielmehr wird nur die Qualitätssicherung eines Dienstes gefordert. Bei komplexeren Anwendungssystemen in serviceorientierten Architekturen wird die volle Funktionalität erst durch die Komposition von Services erreicht. Inwiefern eine solche Kom-

Qualitätssicherung serviceorientierter Architekturen

121

position dann die Anforderungen der unterschiedlichen Partner erfüllt, bleibt zunächst offen. Im Rahmen der eingangs eingeführten Vision für flexible und dynamische Anwendungssysteme soll eine Komposition von Diensten erst dynamisch zur Laufzeit erfolgen. Die Frage stellt sich also, inwieweit eine Qualitätssicherung erfolgen kann, oder wie ein Prozess der dynamischen Konfiguration von Anwendungen durch Aspekte der Qualitätssicherung verbessert werden kann. Im Folgenden sollen unterschiedliche Ansätze zur Qualitätssicherung, Testen, Laufzeit-Überwachung, statischen Analyse, Model Checking und Verifikation für die Anwendung bei serviceorientierten Architekturen diskutiert werden. Das Ziel der Qualitätssicherung im Softwareengineering ist die Einhaltung von vorher definierten Qualitätskriterien. Qualität wird in diesem Kontext definiert als die Summe aller Eigenschaften eines (Software-) Produktes oder einer Aktivität, welche im Zusammenhang zur Erfüllung aller im Vorfeld definierten Anforderungen stehen. Qualitätskriterien sind solche Eigenschaften, die es ermöglichen, Entitäten in qualitativer oder quantitativer Perspektive zu unterscheiden. Die Qualität von Software-Produkten wird nach Riedemann wie folgt definiert [Ried1997]: x

x

x

Funktionalität als Menge von Eigenschaften, die in Beziehung zur Existenz von Funktionen steht, die bestimmte Anforderungen implementieren: x

Adäquatheit indiziert die Existenz oder Anwendbarkeit der Software für eine spezifische Aufgabe,

x

Korrektheit wird genutzt, um zu entscheiden, ob die Ergebnisse oder Effekte einer Software korrekt sind,

x

Interoperabilität betrachtet die Anwendbarkeit, um mit im Vorfeld definierten Systemen zu interagieren,

x

Normative Adäquatheit wird genutzt, um zu abzuschätzen, in wieweit Anwendungs-spezifische Normen, Vereinbarungen, Vorschriften oder gesetzliche Regelungen von der Software erfüllt werden und

x

Sicherheit behandelt Aspekte des unauthorisierten Zugriffs zu Programm oder Daten.

Verlässlichkeit wird für die Performanz eines Systems unter im Vorfeld definierten Bedingungen genutzt und besteht aus den folgenden Eigenschaften: x

Reifegrad misst die Häufigkeit von Fehlern oder fehlerhaften Zuständen,

x

Fehlertoleranz beschreibt die Korrespondenz zu einem im Vorfeld definierten Performanz-Level eines Systems in Situationen, in denen entweder unspezifizierte Zugriffe über die Nutzerschnittstelle oder Software-Fehler eintreten,

x

Wiederherstellung behandelt die Möglichkeit, ein in einen undefinierten Zustand geratenes System in einen vorhergehenden, definierten Zustand zurückzuversetzen. Dieses beinhaltet auch die Wiederherstellung potentiell verlorener Daten in angemessener Zeit.

Benutzbarkeit ist die Eigenschaft, die den Aufwand bestimmt, mit dem eine Software genutzt werden kann bzw. eine individuelle Bewertung der Nutzung von Software bei einer im Vorfeld bestimmten Gruppe von Nutzern.

122

Ingo J. Timm, Arne Hormann, Thorsten Scholz

x

Effizienz ist eine Menge von Eigenschaften, welches das Verhältnis zwischen Performanz-Level einer Software und der Menge genutzter Ressourcen unter im Vorfeld definierten Bedingungen anzeigt.

x

Anpassbarkeit ist ein Kriterium, welches den Aufwand messen soll, der notwendig ist, um Änderungen durchzuführen (Korrekturen, Verbesserungen oder Anpassungen).

Riedemann unterscheidet zwei Arten von Aktivitäten im Qualitätsmanagement: konstruktive und analytische Aktivitäten [Ried1997]. Konstruktive Aktivitäten umfassen Methoden, Sprachen und Werkzeuge, die sicherstellen sollen, dass bestimmte Eigenschaften des Softwaresystems eingehalten werden, d.h., dass der konstruktive Ansatz während der Analyse, Design und Implementierung verfolgt wird. Der analytische Ansatz zum Qualitätsmanagement wird hingegen genutzt, um den Erfüllungsgrad von Qualitätseigenschaften zu diagnostizieren. Hierbei werden Methoden wie Verifikation, Validierung und Evaluation genutzt. Die Problematik der Qualitätssicherung serviceorientierter Architekturen ist vergleichbar zu der Qualitätssicherung von Softwaresystemen, die auf Künstlicher Intelligenz beruhen. Systeme der Künstlichen Intelligenz und insbesondere der Verteilten Künstlichen Intelligenz zeichnen sich durch eine Entkopplung von Zustand (Wissensbasis) und Verhalten (Inferenzmaschine) aus. Durch diese Trennung kann ein System in identischen Situationen sich unterschiedlich verhalten. Dieses scheinbar nicht-deterministische Verhalten ist in dem Horizont der Beobachtung begründet; wird die Vergangenheit einschließlich aller Ereignisse, Verhaltensweisen sowie aller beteiligten Akteure berücksichtigt, so bleibt das Systemverhalten deterministisch. Hier liegt auch die Ähnlichkeit zu den serviceorientierten Architekturen begründet. Es ist in einer heterogenen Systemlandschaft auf der Basis von serviceorientierten Architekturen nicht möglich, alle Dienste und deren interne Zustände zu erfassen und in einem Prüfverfahren zu analysieren. Die Terminologie für die Qualitätssicherung in der Künstlichen Intelligenz ist sehr heterogen und so wird z.B. ein Begriff wie formale Verifikation unterschiedlich genutzt [HoMe1993], [HaMS1987]. Im Bereich der Künstlichen Intelligenz haben Menzies und Pecheur eine differenzierte Analyse von Prüfverfahren vorgenommen, die insbesondere den Aspekt der Expertise berücksichtigt, die notwendig ist, um das Prüfverfahren anzuwenden. Menzies und Pecheur identifizieren fünf Ansätze zur Prüfung, die sich in der Beweiskraft unterscheiden: Testen (Testing), Laufzeit-Überwachung (Run-Time Monitoring), statische Analyse (Static Analysis), Modellprüfung (Model Checking) und Theorembeweis (Theorem Proving) (vgl. Abbildung 3-1, nach [MePe2004, 6]). Das Spektrum der Prüfverfahren reicht von dem formalen Ansatz des Theorembeweises, bei dem das korrekte Verhalten durch einen formalen Beweis der Korrektheit sichergestellt wird, bis hin zum Testen, bei dem spezifische Szenarien überprüft werden. Die Modellprüfung basiert auf der Verifikation von Modellerfüllung und formaler Spezifikation der Software. Daneben ist die Überprüfung der strukturellen Integrität Bestandteil der statischen Analyse. Im Gegensatz dazu ist die LaufzeitÜberprüfung ein Prüfverfahren, in dem das System in spezifischen Szenarien in seinem Laufzeitverhalten untersucht wird. Eine wesentliche Grundlage im Softwareengineering ist die Existenz einer detaillierten Spezifikation. Diese ermöglicht es, dass Kunden und Entwickler die Software validieren können. In sicherheitskritischen Applikationen ist es notwendig, formale Verifikation zum Beweis der Korrektheit anzuwenden. Da dieses Prüfverfahren einen

Qualitätssicherung serviceorientierter Architekturen

123

hohen Aufwand aufweist und daher nicht in jedem Fall einsetzbar ist (Komplexität), sollte dieses nur verwendet werden, falls es wirklich durch die Anwendung erforderlich ist. Wenn der Einsatz formaler Verifikation nicht notwendig oder möglich ist, werden andere Prüfmethoden eingesetzt, die die Qualität sicherstellen sollen. Neben der Komplexität der Überprüfung wird für die formale Verifikation, für die Modellüberprüfung und für die strukturelle Überprüfung ein tiefes Wissen über die interne Programmierung notwendig; diese Voraussetzung wird von serviceorientierten Architekturen – soweit sie sich über mehrere Eigner bzw. Unternehmen erstrecken – nicht erfüllt, da hier kein detailliertes Wissen über Implementierungsdetails vorhanden ist.

Abb. 3-1: Prüfverfahren in der Künstlichen Intelligenz [MePe2004] In diesem Rahmen wird der Begriff Governance verwendet, der einen breiteren Ansatz assoziieren soll als die individuelle Qualitätssicherung von Services. Die Governance-Modelle schließen insbesondere die sogenannten Service Level Agreements ein, die eine Spezifikation der Anforderungen darstellen, die von einem Dienst erfüllt werden müssen. Ein vergleichbarer Ansatz im Bereich der Qualitätsprüfung fand zu Beginn der objektorientierten Methodologie statt. So hat z.B. Booch keine explizite Integration von Prüfmethoden vorgeschlagen [Booc1994]. Rumbaugh et al. behaupten darüber hinaus, dass eine natürliche Reduktion von Prüfaufwand durch die Objektorientierung zu erwarten sei [Rum+1991]. Dieses wurde in späteren Studien widerlegt, und es konnte gezeigt werden, dass die konkrete Fehlerrate in Objektorientierten Implementierungen sogar noch höher ist als in konventioneller Software [Hatt1998]. Die erhöhte Modularisierung der Objektorientierung wird begleitet von einer erhöhten Interdependenz zwischen den Modulen, welche häufig nur indirekt bestehen [HaWi1994]. Zudem können Probleme bereits daraus resultieren, dass nicht alle Anwendungsfälle von Objekten oder Klassen bereits während des Entwurfs oder der Implementierung bekannt sind. Daher müssen Methoden mit beinahe universellen Eingaben umgehen können, welche nicht ausreichend vorhergesagt oder getestet werden können [SmRo1990]. Bereits 1993 haben Turner und Robson festgestellt, dass es nicht möglich ist, komplexe Objekte in jedem möglichen Zustand zu testen, welcher bei Objekten z.B. durch die Attribute determiniert ist

124

Ingo J. Timm, Arne Hormann, Thorsten Scholz

[TuRo1993]. Zusammenfassend stellen Sneed und Winter für die Objektorientierung fest, dass die Abdeckung der Tests verglichen mit konventioneller Software gering ist [SnWi2002]. Da serviceorientierte Architekturen eine konsequente Fortführung einiger elementarer Konzepte wie Information Hiding, Interaktion und Verteilung darstellen, beinhalten diese ähnlichen Probleme. Eine weitere Dimension der Komplexität entsteht durch die inhärente Flexibilität der serviceorientierten Architekturen, die es ermöglicht, zur Laufzeit Dienste zu binden oder auszutauschen. Solche Organisationsformen werden im Bereich der Agententechnologie als „Emergent Organization“ untersucht [Ferb1999] und führen somit zu vergleichbaren Herausforderungen in der Qualitätssicherung [TiSF2006]. Im Folgenden werden die fünf eingangs beschriebenen Prüfmethoden (Testen, Laufzeitüberwachung, statische Analyse, Modellprüfung und Theorembeweisen) für die Qualitätssicherung von serviceorientierten Architekturen diskutiert. 3.1

Testen (Testing)

Bislang gibt es noch keine spezifisch für serviceorientierte Architekturen ausgelegten Testverfahren. Dennoch sind einige der Methoden aus der konventionellen Softwareentwicklung übertragbar, deren Konzepte sich zur Anwendung in diesem Kontext eignen. Einer der verbreitetsten und besterforschten Ansätze ist dabei das Unit Testing, das zur Sicherung des Ausführungsverhaltens von – aus Schnittstellensicht – atomaren ausführbaren Einheiten im Programm verwendet wird (in der Objektorientierung Objekte oder Klassen mit einem Zustand, der durch die ausführbaren Methoden beeinflussbar ist). Der Vorteil dieser Tests liegt dabei in der Automatisierbarkeit; das Verhalten einer Implementierung wird durch Tests auch bei späteren Änderungen vorhersehbar und absicherbar, da durch die Tests eine wiederholbar ausführbare Spezifikation der Schnittstelle vorliegt. Tests stellen in der konventionellen Softwareentwicklung den am weitesten verbreiteten Ansatz zur zumindest partiellen Validierung und Verifikation dar. In Form des 1 maßgeblich von Kent Beck entwickelten xUnit Frameworks liegt auch für viele Sprachen ein ausgereiftes und gut dokumentiertes Werkzeug mit großem Anwenderkreis vor, das auch in viele Entwicklungswerkzeuge integriert ist. Wegen der Verbreitung ist vorrangig dabei JUnit in der Sprache Java zu nennen, das sowohl in vielen gängigen Entwicklungsumgebungen (z.B. Eclipse, Netbeans, JBuilder, IntelliJ), als auch in Buildtools wie ant, einem Java basierten make Ersatz, und dessen Nachfolger dem Deploymenttool maven, ohne zusätzliche Erweiterungen unterstützt wird. Dem Vorteil der leichten Erlern- und Anwendbarkeit des Testens steht der hohe Aufwand entgegen, der betrieben werden muss um eine vollständige Abdeckung aller Programmteile zu erreichen. Da Unittests auch ohne Kenntnisse der zu testenden Implementierung geschrieben werden können (Blackbox Test), ist dies auch nicht in jedem Fall möglich. Tests beschränken sich üblicherweise auf gängige Anwendungsszenarien oder die Überprüfung von Robustheit bei Fehleingaben. Basis aussagekräftiger Unittests ist dabei, dass die völlige Unabhängigkeit der getesteten Unit von anderen Programmteilen gewährleistet ist, um beim Testen false positives (also fehlgeschlagene Tests, die einem Testling fälschlich zugeordnet werden) und 1

http://en.wikipedia.org/wiki/XUnit

Qualitätssicherung serviceorientierter Architekturen

125

die daraus resultierende unnötige und oft langwierige Fehlersuche zu vermeiden. Um die Unabhängigkeit zu gewährleisten, wird daher oft eine Ersetzung vorgenommen: während des Testens werden Abhängigkeiten der getesteten Klasse (also genutzte andere Klassen) durch so genannte Mocks oder Dummies ersetzt, die die gleiche Schnittstelle anbieten, aber ein primitives und von der Testumgebung kontrollierbares Verhalten aufweisen. In Bezug auf serviceorientierte Architekturen lässt sich dabei die zugrunde liegende Idee verwenden, die Schnittstelle zu testen und dadurch das Verhalten einer Implementierung dieser Schnittstelle ausführbar zu spezifizieren. Durch diese Spezifikation wird es möglich, sichere Aussagen über einen Service (mindestens für die getesteten Fälle) zu treffen und dadurch auch dessen Nutzbarkeit durch Clients oder andere abhängige Services sicherzustellen. Die Überprüfung selbst erfolgt durch die Nutzung der Schnittstelle. Ein Unittest (Unit ist in diesem Fall der getestete Service) fungiert dabei als Client eines Services und überprüft, ob die Reaktionen des Services in den überprüften Szenarien mit erwarteten Reaktionen decken. Test cases Grammer

Test system Environment Validator

Sequence

Generator Service under Test Tester

Assignment

Abb. 3-2: Framework für Interaktionstests Unit Testing kann dabei auch auf unterster Ebene als ein Fundament zum strukturierten Testen eines Services dienen. In Abb. 3-2 wird ein Testsystem dargestellt, das zum Testen abstraktere Beschreibungen zulässt. Eine Grammatik schränkt dabei die Menge bestehbarer Tests ein und limitiert die erstellbaren Testfälle auf ein Interaktionsprotokoll zwischen einem Service und dessen Clients. Eine Sequenz von Interaktionen beschreibt die zu testenden Szenarien und unterschiedliche Assignments lassen die Durchführung identischer Interaktionsabfolgen mit unterschiedlichen Parametern zu. Das vorgestellte System wird in [Horm2006] für Agenten detaillierter beschrieben. 3.2

Laufzeitüberwachung (Runtime Monitoring)

Wie auch beim Testen wird bei der Laufzeitüberwachung eine kontrollierte Umgebung mit einem Modell gültigen Verhaltens geschaffen. Anders als beim Testen wird aber keine Aktion vom Testsystem durchgeführt (bei der reinen Überwachung), dafür ist das - hier formale - Modell wesentlich umfassender als bei den rein fallbasierten

126

Ingo J. Timm, Arne Hormann, Thorsten Scholz

Tests. Der Zustand des Systems wird in der Produktivumgebung permanent überwacht, im Fehlerfall können detaillierte Protokolle über die Zustandsänderungen auf der untersuchten Detailebene zuverlässige Rückschlüsse auf die Fehlerursachen geben. Die Entwicklung im SOA-Kontext stellt dabei – bedingt durch die inhärente Verteilung – eine besondere Herausforderung dar, da, wie in Abb. 3-3 dargestellt, eine Überwachung auf verschiedenen Ebenen möglich ist. Wenn man als zu überwachende Einheit nicht einen einzelnen Service sondern einen kompletten Anwendungskontext mehrerer Services wählt, steigt die Modellkomplexität im Überwachungssystem stark an. Zudem wird eine kommunikationsintensive Synchronisation des aktuellen Systemzustandes innerhalb des durch das Modell vorgegebenen Zustandsraumes zwischen den einzelnen Serviceprovidern nötig. Um diesen Aufwand auf ein vertretbares Maß zu reduzieren, muss in dem Modell stark von dem zu testenden System abstrahiert werden. Vom Ansatz her kommt daher nur ein black- oder greybox Ansatz in Frage, in dem man keine oder nur wenig Kenntnisse über die interne Funktionalität eines Services voraussetzt. Monitoring one Service

Monitoring a Service based Application

Runtime Monitoring System Monitored Service

Model

Monitored Service Clients, used Services

Monitored Service Clients Model

Monitored Service

Monitored Service

Abb. 3-3: Laufzeitüberwachungsebenen im SOA Kontext Von Vorteil ist, dass das Überwachungssystem ggf. selbst in Form eines Services in die Anwendung integriert werden kann. Durch die Integration auf Ebene der überwachten Elemente wird es dadurch unter anderem auch im Produktiveinsatz möglich, die Services als selbstkorrigierende Prozesse zu realisieren. Zudem wird eine Erfassung von Messwerten unterstützt, durch deren Analyse eine Optimierung des Durchsatzes oder der Robustheit der Anwendung im laufenden Betrieb ermöglicht wird. Diese Optimierung wird auf Basis von aus den Messwerten abgeleiteten Kennzahlen, die durch statistische Analyse (z.B. Zeitreihenanalyse, T-Test, Kruskal-Wallis-Test, ANOVA) ermittelt werden. Die Messung durch Laufzeitüberwachung und Erhebung von Kennzahlen sind für den verwandten Bereich der Agententechnologie in [Timm2004] ausführlicher beschrieben. 3.3

Statische Analyse (Static Analysis)

Statische Analyse basiert auf der Erkennung von “Fehlermustern” in kompilierten Programmen. Diese Analyse erfolgt direkt auf Basis des Codes (je nach Anwendung

Qualitätssicherung serviceorientierter Architekturen

127

Source-, Byte- oder Machinecode). Grundsätzlich wird dabei bei einer höheren Untersuchungsgenauigkeit, einem komplexeren untersuchten System oder komplexeren Fehlermustern die Anwendung zunehmend schwerer, da der Ressourcenbedarf und die Laufzeit schnell ansteigen. Zudem ist es nicht möglich, Fehler zu finden, für die keine entsprechenden Muster bekannt sind. Wo statische Analyse anwendbar ist, bringt sie aber nicht zu unterschätzende Vorteile mit sich. Durch die Suche nach bekannten Fehlermustern können Fehlerkorrekturmaßnahmen sofort vorgeschlagen und ggf. auch automatisch durchgeführt werden. Ebenso ist statische Analyse durch die gezielte Suche nach Mustern nicht gegen strukturelle Änderungen im Systemaufbau anfällig. Auch umfangreiche Änderungen erlauben noch eine Fehlersuche im durch die Muster vorgegebenen Umfang. Für serviceorientierte Architekturen bietet statische Analyse bei der Entwicklung und Überprüfung der internen Strukturen einzelner Services einen Mehrwert. Die Untersuchung der Interaktionsfähigkeit bzw. der Schnittstellen- und Spezifikationskonformität ist aber durch die auf dieser Ebene vergleichsweise große Anzahl und Komplexität möglicher Fehlermuster allenfalls eingeschränkt anwendbar. 3.4

Modellüberprüfung (Model Checking)

Bei der Modellüberprüfung wird ein (abstraktes) Modell des zu untersuchenden Systems erstellt und mit einem (ebenfalls abstrakten) Modell der gültigen Systemzustände verglichen. Diese – meist auf Temporallogik basierten – Modelle repräsentieren dabei das System und den gültigen Zustandsraum des Systems [HuDe2004]. Im Gegensatz zu den auf syntaktischen Beweisen basierenden axiomatischen Ansätzen, ist die Modellüberprüfung auf semantischer Ebene angesiedelt [Wool1998]. Die Erstellung der Modelle und deren eventuell nötige Synchronisation mit Änderungen in der Spezifikation erfordern eine hohe Sorgfalt und Disziplin. Die Entwicklungsabläufe müssen daher in einem stark strukturierten und organisierten Umfeld erfolgen. Eine Besonderheit beim Model Checking ist, dass die Modellierung des Systems auf der Basis der Spezifikation vor der eigentlichen Implementierung stattfinden muss. Die Implementierung entspricht dabei der detailgetreuen Übersetzung des Modells in den Quellcode der verwendeten Programmiersprache. Zu diesem Zweck können ggf. spezielle Compiler verwendet werden, die die Temporallogikbasierten Modellierungssprachen in Quellcode einer Programmiersprache oder direkt in Maschinen- oder Bytecode übersetzen. Der Abgleich erfolgt programmatisch, ein Programm sucht dabei in dem Systemmodell einen Zustand, der in dem Modell der gültigen Systemzustände nicht vorkommt. Eine erfolgreiche Suche bedeutet dabei einen Verstoß gegen die Spezifikation. Der Idealfall für den Einsatz von Modellüberprüfung ist, wenn die Spezifikation bereits in Form des Modells vorliegt. Wenn die Spezifikation textuell vorliegt, erschwert dies den Einsatz einer Modellüberprüfung, da zwei Modelle mit einer textuellen Beschreibung in Einklang gebracht werden müssen. Durch den hohen Aufwand und die sehr spezifische nötige Expertise bei der Modellentwicklung ist zudem der Aufwand ab einer gewissen Programmkomplexität nicht mehr tragbar. Dieser formale Ansatz ist daher stärker in sicherheitskritischen Anwendungsszena-

128

Ingo J. Timm, Arne Hormann, Thorsten Scholz

rien verbreitet. Auch die gezielte Überprüfung kritischer Programmelemente bietet sich an. Da Services eine extern veröffentlichte Schnittstelle anbieten, ist es gegebenenfalls möglich, nicht abschließend spezifizierte externe Kommunikationspartner zu berücksichtigen, wodurch der Umfang des dadurch möglichen Interaktionsraums sich stark vergrößert. Dies steigert die Modellkomplexität und erschwert die Anwendung von Modellüberprüfung als Verifikationsverfahren im Bereich serviceorientierter Architekturen. 3.5

Theorembeweis (Theorem Proving)

Theorembeweisen ist ein logikbasiertes Verfahren, in dem die Korrektheit eines Programms (bzw. Programmteils) vollständig bewiesen wird. Zu diesem Zweck wird das Programm befehlsweise auf die durch diesen Befehl möglichen Zustandsänderungen hin untersucht und der ursprüngliche mit dem abschließend möglichen Zustandsraum und der Spezifikation abgeglichen. Das Verfahren ist sehr arbeitsaufwendig und nicht vollautomatisiert durchführbar, wodurch sich der Einsatz in fast allen Anwendungskontexten verbietet – nur für hochgradig sicherheitskritische und sehr kurze Programme ist der Einsatz von Theorembeweisen zu empfehlen. Im SOA-Kontext ist durch die stärkere IO-Nutzung und die mögliche Verteilung die Anwendung von Theorembeweisen für eine vollständige Anwendung bis zur Verfügbarkeit automatischer Beweiser durch den hohen manuellen Arbeitsaufwand nur in absoluten Ausnahmefällen vorstellbar. 3.6

Zusammenfassung

Die Qualitätssicherung großer Softwaresysteme ist eine Herausforderung, insbesondere wenn die Entwicklung verteilt in Teams von Programmierern erfolgt. Während der Entwicklung werden hierbei mindestens die drei folgenden Modelle erstellt: Anforderungs-, Design- und Implementierungsmodell. Thaller fordert, dass diese Modelle evaluiert werden müssen, um eine hohe Qualität zu gewährleisten [Thal2002]. In den meisten Fällen wird ein Evaluationsprozess mit spezifischen Methoden für die einzelnen Modelle angewendet. In Abbildung 3-4 wird der minimale Evaluationsprozess im Softwareengineering illustriert. Die Evaluation der Modelle wird in entgegengesetzter Richtung ihrer Konstruktion durchgeführt. In einem ersten Schritt werden die Implementierungen der individuellen Module resp. Services unter Nutzung von Methoden des Testens, z.B. von Unittests, geprüft. Wenn das Implementierungsmodell korrekt erscheint, werden die Module integriert und das kompositionale Verhalten, also die Interaktion der Module, geprüft. Dieses ist im Rahmen von Software, die in einem Verantwortungsbereich entwickelt wird möglich. Im Rahmen von Anwendungen, die auf dynamisch gebundenen Services basieren, ist dies dagegen nur schwer zu realisieren. Nach erfolgreichem Abschluss der Integrationstests wird in der konventionellen Softwareentwicklung angenommen, dass die Software die Spezifikation des Design-Modells erfüllt. In einem letzten Schritt müssen Inkonsistenzen zwischen Design- und Anforderungsmodell identifiziert werden. Hierfür finden Akzeptanz-Tests statt.

Qualitätssicherung serviceorientierter Architekturen

129

Abb. 3-4: Evaluationsmodell für komplexes Softwareengineering [TiSF2006] Die Entwicklung einzelner Services richtet sich nach diesem Schema der Qualitätssicherung. Der initiale Aufbau einer servicebasierten Anwendung wird sich von dem hier vorgestellten Prüfkonzept nicht unterscheiden. Anders gestaltet sich hierbei die Rekonfiguration einer solchen Anwendung. Soll nur ein Service gegen einen vergleichbaren Service ausgetauscht werden, so ist weder die Überprüfung des Implementierungs- noch des Design- oder des Anforderungsmodells notwendig. Es ist aber notwendig, die Integration, also die Interaktion zwischen dem neuen Service und der Anwendung sowie deren grundlegende Eigenschaften zu validieren. Dabei muss davon ausgegangen werden, dass keine internen Informationen zu der Implementierung des Services vorliegen, so dass eine Überprüfung durch Black-boxTests stattfinden muss. Die Qualitätssicherung von Diensten sollte wiederholbar sein und sicherstellen, dass deren Funktionalität einer zuvor veröffentlichten Quality of Service entsprechen. In diesem Sinne, schlagen wir im Folgenden eine Zertifizierung von Diensten durch eine unabhängige Instanz vor. 4

Automatische Zertifizierung von Web Services

Die Ansätze zum Testen, die im vorigen Abschnitt diskutiert wurden, finden Anwendung, falls die Architektur und Implementierung während der Test-Spezifikation bekannt sind. Die flexible Bindung von Services führt zu einer konkreten Ausgestaltung des Anwendungssystems zur Laufzeit des Systems. Hierbei können einige der Dienste von Dritt-Anbietern angeboten werden, so dass kein Wissen über die Implementierung oder Architektur verfügbar ist. Dienste werden in eine serviceorientierte Anwendung auf der Basis von Dienstbeschreibungen, z.B. UDDI, eingebunden. Für solch eine Bindung ist es notwendig, relevante Dienste für die Problemlösung einer spezifischen Aufgabe zu identifizieren und ggf. eine Auswahl über potentiell verfügbare Dienste auf der Basis von explizierten Quality of Service Modellen durchzuführen. Die Identifikation basiert auf dem Matchmaking von Fertigkeiten (Capabilities) der Dienstbeschreibungen zu Aufgaben und kann im Rahmen semantischer Web Services in einem semantisch angereicherten Dienstverzeichnis eingetragen werden. Eine Bewertung ist hier noch nicht vorgesehen. Im Folgenden wird ein Ansatz zur Qualitätssicherung serviceorientierter Architekturen

130

Ingo J. Timm, Arne Hormann, Thorsten Scholz

vorgeschlagen, der auf der Einführung eines erweiterten Anmeldesystems für Web Services basiert, die unmittelbar nach Anmeldung eines Dienstes sowie regelmäßig danach eine Prüfung der Qualität vornimmt und entsprechend ein Quality of Service Profil des Dienstes erstellt und somit automatisch eine Laufzeitüberwachung vornimmt. Der Grundansatz ist hierbei die automatische Zertifizierung von Web Services durch eine unabhängige Instanz (Third Party). In diesem Ansatz wird ein konzeptionelles Framework vorgeschlagen, welches das Ziel hat, die Identifikation, Evaluation und Selektion von Diensten zu unterstützen, um ein zuverlässiges Verhalten von verteilten serviceorientierten Anwendungen zu gewährleisten. Auf konzeptioneller Ebene sind drei Komponenten notwendig: x

Fertigkeitsmanagement (Capability Management) für die Identifikation des am besten geeigneten Dienstes bzw. die Identifikation von Diensten auf der Basis ihrer Fertigkeiten. Die Herausforderung stellt sich hierbei in der Zuweisung einer gegebenen Aufgabe zu einer Fertigkeit. In realen Anwendungen beinhaltet dieses nicht nur die eindeutige Zuordnung sondern auch die unscharfe Zuordnung, z.B. auf der Basis von Fuzzy-Logik [ScTW2004].

x

Zertifizierungsmanagement (Certification Management) für die Evaluation von Diensten, d.h. die verfügbaren Dienste werden sowohl bezüglich der angebotenen Funktionalitäten als auch weiterer Qualitätsmerkmale überprüft und hieraus wird eine Quality of Service für den Dienst erstellt.

x

Katalogmanagement (Catalogue Management) für die Prozessunterstützung der Service-Recherche, d.h. die Integration von Capability und Certification Management als zentrale Explorationsschnittstelle für Dienste-Konsumenten.

Diese Komponenten stellen die Basis für die Verbindung von Service-Anbieter zu Service-Konsumenten dar. Der Prozess des Matchmakings beinhaltet drei Stufen: Registrierung, Validierung und Recherche. Für die Nutzung eines Dienstes durch einen Dienste-Konsumenten ist es zuvor notwendig, den Dienst bei dem Katalogsystem zu registrieren und zu veröffentlichen. Damit ein verlässliches Verhalten von Diensten in diesem Framework sichergestellt wird, ist es erforderlich, Dienste bezüglich ihrer Fertigkeiten vor Anmeldung zu zertifizieren, welches in diesem Prozess den Schritt zwei – Validierung – darstellt. Nach der Zertifizierung wird der Dienst mit einem Quality of Service Profil veröffentlicht, so dass Service-Konsumenten Anfragen an das Katalogsystem stellen können, um Dienste zu finden, die Qualitätskriterien erfüllt. Zusätzlich kann der Konsument Feedback über die erfahrene Qualität des Dienstes an das Katalogsystem melden. Sollten die Erwartungen an die Qualität nicht durch den Dienst erfüllt werden, so wird durch das Katalogsystem eine erneute Zertifizierung initiiert. 4.1

Architektur

Die grundlegende Idee des Frameworks ist eine agentenbasierte Integration von expliziter Fertigkeitenrepräsentation, Zertifizierung von Fertigkeiten und Veröffentlichung von zertifizierten Diensten. Dieser Ansatz verwendet zuerst nur ein Quality of Service Modell mit Fokus auf den Fertigkeiten; das Modell kann leicht auf weitere Qualitätsmerkmale, z.B. Verfügbarkeit, Kosten oder Dauer erweitert werden.

Qualitätssicherung serviceorientierter Architekturen

131

Abb. 4-1: Architektur für die dynamische Zertifizierung von Services In Abb. 4-1 ist die Architektur des Frameworks dargestellt, welche auf der Basis von Softwareagenten realisiert wird. Der Agent für das Katalogsystem (Catalogue Management) implementiert die Schlüsselrolle des Systems und ist verantwortlich für Anfragen zur Service Registrierung, Initiieren des Zertifizierungsprozesses und für die Exploration bzw. die Recherche nach registrierten Diensten. Für das Matchmaking von Service-Konsumenten und Service-Anbieter wird der Agent für das Capability Management beauftragt. Das Zertifizierungsmanagement wird ebenfalls durch einen Softwareagenten implementiert, der auf der Basis von Fertigkeiten unter Nutzung des Capability Managements Service-Anbieter zertifiziert. Hierbei wird der Service-Anbieter anhand einer Menge von Problemen und Standardlösungen getestet. Da Probleme domänenspezifisch sind, werden diese entweder aus der Problemdatenbank (PDB) oder dynamisch von einem Agenten generiert (problem generator agent). Diese Agenten müssen für jede Domäne angepasst werden, damit relevante Probleme für den Zertifizierungsprozess generiert werden. Das Ergebnis vom Service-Anbieter wird in Bezug zu der Standardlösung beurteilt. Hierbei kann z.B. ein Maß auf der Basis von Vollständigkeit, Korrektheit und Optimalität als Quality of Service Modell für die Fertigkeit abgeleitet werden. Die Quality of Services werden in einer Datenbank (QoS DB) gespeichert, welche in regelmäßigen Intervallen mit Hilfe von erneuter Zertifizierung aktualisiert wird. Das Fertigkeitsmanagement erlaubt ein dynamisches Matchmaking auf der Basis logischer Schlussfolgerungen über Fertigkeiten und Problembeschreibung. Die Schlussfolgerung basiert auf der Kombination und Rekombination von einzelnen oder mehreren kompositionellen Fertigkeiten [Scholz et al. 2004]. In den folgenden Abschnitten wird das Zertifikationsmanagement anhand der drei Phasen detaillierter beschrieben.

132

4.2

Ingo J. Timm, Arne Hormann, Thorsten Scholz

Registrierung und Validierung

Vor der Registrierung eines Dienstes werden die unterschiedlichen Fertigkeiten des Dienstes zertifiziert. Der Prozess ist in Abb. 4-2 illustriert: Der Service sendet eine Anfrage zur Registrierung (register) an das Katalogmanagement, welches den Namen des Service, seine physikalische Adresse und eine Liste seiner Fähigkeiten enthält. Das Katalogmanagement sendet im Anschluss eine Anfrage zur Zertifizierung der übermittelten Liste von Fähigkeiten an das Zertifikationsmanagment. Das Zertifizierungsmanagement nutzt implizit das Capability Management um die Problemdomäne zu identifizieren und eine Liste von Problemen von der Problemdatenbank oder dem Problemgenerator zu erhalten. Diese Liste wird dem Dienst zur Lösung präsentiert. Die Problemlösungen werden von dem Dienst an das Zertifizierungsmanagement gesendet, welches die Lösungen bewertet und auf dieser Basis eine Quality of Service für den Dienst bzw. die Fähigkeit berechnet. Abschließend wird der Dienst informiert, dass die Registrierung abgeschlossen wurde. Um die Zertifizierungsdatenbank der verfügbaren Dienste aktuell zu halten, wird in regelmäßigen Abständen eine erneute Initiierung angestoßen.

Abb. 4-2: Prozess der Registrierung und Validierung 4.3

Recherche

Die Suche nach einem Dienst (Recherche) wird durch die Explorationsschnittstelle des Katalogmanagements realisiert. Ein Dienste-Konsument ist insbesondere an solchen Diensten interessiert, die das Problem mit der besten Qualität lösen können. Der Prozess der Recherche ist in Abbildung 4-3 dargestellt. Der Prozess wird durch den Konsumenten gestartet, der eine Anfrage an das Katalogsystem absetzt (query services). Diese Anfrage besteht aus dem Namen des Konsumenten, der physikalischen Adresse und der Problembeschreibung. Auf dieser Basis wird ein Matchmaking im Katalogsystem unter Nutzung des Capability Managements gestartet. Die

Qualitätssicherung serviceorientierter Architekturen

133

Liste der verfügbaren Dienste gemeinsam mit der Information über deren Quality of Service wird genutzt, um die Suche zu verfeinern. Die gefundenen Dienste werden mit ihren individuellen Quality of Service Profilen an den Konsumenten übertragen (list of services). Falls der Service-Anbieter eine von dem Profil abweichende Qualität geliefert hat, so kann der Konsument diese Änderung als Feedback an das Katalogsystems liefern.

Abb. 4-3: Prozess der Recherche und des Feedbacks 4.4

Evaluation

Für die Evaluation dieses Ansatzes wurde eine erste Implementierung auf der Basis 2 von JADE 3.2 realisiert. Hierbei sollte insbesondere der Vorteil von Zertifizierung und Katalogsystem untersucht werden. Für die Experimente wurden sowohl der Registrierungs-, Validierungs- als auch Rechercheprozess implementiert und analysiert. Die Nutzung von Diensten sowie das Feedback von Konsumenten hingegen wurden ausgeblendet und sollte in künftigen Untersuchungen berücksichtigt werden. Die Experimente fokussieren auf die Routenplanung, bei der Dienste für die Berechnung des kürzesten Weges zwischen zwei Orten gesucht werden. Diese Beispieldomäne wurde gewählt, da das Problem theoretisch sehr gut verstanden ist und eine formale Spezifikation existiert. Darüber hinaus sind objektive Qualitätsmaße wie Vollständigkeit, Korrektheit, Optimalität und Komplexität bekannt. Die Evaluation der Zertifizierung erfolgt auf der Basis von vier Diensten, die jeweils einen sub-optimalen Suchalgorithmus implementieren: gierige Suche (greedy search), Breitensuche

2

http://jade.tilab.com

134

Ingo J. Timm, Arne Hormann, Thorsten Scholz

(breath-first search), Tiefensuche (depth-first search) und iterierte Tiefensuche (iterated depth-first search) [RuNo2003]. Die Implementierung des Zertifizierungsmanagement erfolgte analog zur oben stehenden Beschreibung. Hierbei realisiert es auch einen Problemgenerator, der zufällig Graphenprobleme mit einer steigenden Anzahl von Kanten und Knoten definiert; es werden auch nicht zusammenhängende Graphen generiert, die keine Lösungen enthalten. Für die Bewertung der Lösungsqualität der Dienste wird der optimale Suchalgorithmus A* genutzt; die Qualität ergibt sich aus dem Quotienten von den beiden Längen des Pfades, die zum einen von dem optimalen Algorithmus (A*) und zum anderen von dem zu zertifizierenden Dienst berechnet wurde. Das Katalogsystem wird auf der Basis eines Dienstverzeichnis der Agentenplattform implementiert; hierbei werden in sofern Modifikationen vorgenommen, als die Agenten, bevor sie dort eingetragen werden, zertifiziert werden. Nach der Zertifizierung werden die Suchagenten in das Verzeichnis mit einer Beschreibung ihrer Fertigkeiten (Suche in Graphen) und dem ermittelten Qualitätsmaß aufgenommen. Darüber hinaus werden zwei Service-Konsumenten generiert, von denen der eine Dienst auf der Basis des Katalogsystems (certified) und der andere auf der Basis von Zufall (random) auswählt.

Abb. 4-4a: Box-and-Whisker Diagramm

Abb. 4-4b: Quality of Service

Für die Evaluation erzeugen diese Konsumenten jeweils 2.500 Problemgraphen mit variierender Größe (5 bis 500 Knoten), suchen für jeden Problemgraphen jeweils einen Dienst für die Lösung des kürzesten-Wege-Problems auf der Basis ihres Selektionsmechanismus (Zufall, Zertifizierung) und senden den Problemgraphen an den entsprechenden Dienst. Die Ergebnisse werden dokumentiert und mit dem oben beschriebenen Maß evaluiert. Die Auswertung der Experimente führte zu eindeutig differenzierten Ergebnissen zwischen den beiden Konsumenten (vgl. Abb. 4-4a). Die Selektion auf der Basis von Zufall führt zu Ergebnissen, die im kompletten Intervall

Qualitätssicherung serviceorientierter Architekturen

135

3

[0,1] variieren. Der Mittelwert liegt bei 0,438 mit einer Standardabweichung von 0,444. Durch die Tiefensuche wird ein hoher Anteil von „kein Ergebnis gefunden“ erzeugt, so dass der Median für die zufällige Auswahl von Services bei 0 liegt. Im Gegensatz dazu zeigt der Konsument mit der Auswahl von Services auf der Basis von Quality of Service bzw. Zertifizierung differenziertere Ergebnisse. Die Varianz in den Ergebnissen beschränkt sich hier auf die obere Hälfte des Intervals [0,1]. Insbesondere wird das Resultat „Kein Ergebnis gefunden“ hier nicht erzielt. Der Mittelwert dieses Konsumenten liegt bei 0,880 mit einer Standardabweichung von 0,133. Die Absicherung dieser Ergebnisse, die einen Vorteil der Selektion auf der Basis von Zertifizierung erkennen lassen, wird durch statistische Tests verfolgt. Hierbei resultiert der t-Test in einem hoch signifikanten t-Wert von 47,620 (p-Wert < 0,001). Alternativ wurde noch ein nicht parametrischer Test (Kruskal-Wallis-Test) gerechnet, der ebenfalls zu einem hoch signifikanten Ergebnis führte (p < 0,001). Theoretische Überlegungen zu dem zu Grunde liegenden Problem der Suche führen zu der Vermutung, dass die Quality of Service mit zunehmender Knotenzahl abnimmt, da die verwendeten Algorithmen durchweg sub-optimal sind. Die Ergebnisse zeigen hier eine weitere Differenzierung zwischen den zertifizierten und zufälligen Selektionsansatz (s. Abb. 4-4b). Zusammenfassend kann festgestellt werden, dass diese Evaluation einen Hinweis darauf gibt, dass die Zertifizierung von Diensten vorteilhaft genutzt werden kann. Die sehr deutlichen Ergebnisse sind aber sicherlich in der Domäne begründet und lassen sich nicht auf beliebige andere Fragestellungen übertragen. 4.5

Verwandte Arbeiten

Die Zertifizierung und Bewertung der Qualität verfügbarer Dienste ist eine sehr relevante Fragestellung in aktuellen Forschungsarbeiten. Im Bereich der Web Services schlagen [She+2002] vor, eine serviceorientierte Middleware zu entwickeln, die ein integriertes Quality of Service Modell beinhaltet, um autonome Softwaresysteme zu unterstützen. Dieser Ansatz definiert ein Modell, welches keine explizite Repräsentation von Fertigkeiten vornimmt und auf den grundlegenden Qualitätsmerkmalen wie Zeit, Kosten und Zuverlässigkeit fokussiert. [LiNZ2004] verzichten ebenfalls auf eine explizite Repräsentation von Fertigkeiten. In dem Ansatz wird aber zwischen Domänen-spezifischen und Domänen-unabhängigen Kriterien unterschieden, welche beide auf Reputation und Nutzer-Feedback basieren. Der Ansatz von multiplen Quality of Service Maßen ist in unserem Framework berücksichtigt worden, z.B. wurde im Prototypen eine Domänen-spezifische Quality of Service implementiert. In [Ran2003] wird ein Modell für die Recherche von Web Services auf der Basis von Quality of Service eingeführt, welches eine Zertifizierungskomponente enthält. Die Autoren schlagen ein breites informelles Modell für die Quality of Service vor, welches auch ein Vollständigkeitsmerkmal analog zu dem in unserem Framework enthält. Die Zertifizierung wird jedoch nicht dynamisch sondern statisch definiert.

3

Kein Ergebnis (0) oder optimale Lösung (1).

136

5

Ingo J. Timm, Arne Hormann, Thorsten Scholz

Zusammenfassung und Ausblick

In diesem Beitrag wurde die Qualitätssicherung in serviceorientierten Architekturen diskutiert. Insbesondere wurde in diesem Rahmen die Besonderheit dynamisch rekonfigurierbarer Anwendungen betrachtet. Kann die Qualität von einzelnen Diensten noch mit Hilfe konventioneller Prüfmethoden sichergestellt werden, so ist bei heterogenen Anwendungen, die aus diversen Diensten unterschiedlicher Eigner bestehen, eine solche Überprüfung nicht mehr realistisch. Daher haben wir einen Ansatz zur automatischen Zertifizierung von Diensten präsentiert. Das Framework beinhaltet ein Quality of Service Modell und integriert Capability Management und Problemgenerator sowie –datenbank für eine dynamische Bewertung von Diensten. Die vorgeschlagene agentenbasierte Architektur, die dieses Framework implementiert, unterstützt Agenten für die Registrierung, Zertifizierung und Recherche von Diensten. Als einen ersten Schritt haben wir ein System für die Such-ProblemDomäne implementiert. Die Ergebnisse dieser Evaluation lassen vermuten, dass eine automatische Zertifizierung von Diensten bzw. deren Fertigkeiten die Performanz eines Systems in Bezug zur Qualität eines verteilten Problemlösens verbessern kann. Eine Besonderheit dieser eher künstlichen Domäne ist, dass die Relevanz der Zertifizierung mit der Größe des Problems zunimmt. Die Beobachtungen in dieser Domäne, die formal gut verstanden ist und über objektive Qualitätskriterien verfügt, sind sicher nicht auf beliebige Domänen übertragbar. In zukünftigen Arbeiten wollen wir diesen Ansatz auf die Domäne der Fertigungsplanung übertragen, da hier auch eine formale Repräsentation von Fertigkeiten und Problemen möglich ist. Dieses wurde bereits in abgeschlossenen Projekten an der Universität Bremen (z.B. IntaPS III [ScTW2004]) untersucht. Diese Domäne wird eine tiefergehende Bewertung des Ansatzes zulassen, da hier kein objektives Optimalitätskriterium vorhanden ist und ggf. multi-dimensionale Quality of Service Modelle integriert werden müssen.

Literaturverzeichnis [Ank+2002] Ankolekar, A.; Burstein, M.; Hobbs, J.R.; Lassila, O.; McDermott, D.; Martin, D.; McIlraith, S.A.; Narayanan, S.; Paolucci, M.; Payne, T.: DAML-S: Web Service Description for the Semantic Web. Proceedings of the International Semantic Web Conference (ISWC 02), Springer Verlag: Berlin, 2002. [Ber+2007] Berbner, R; Spahn, M; Repp, N; Heckmann, O; Steinmetz, R.: WSQoSX – A QoS architecture for Web Service workflows. In: Proceedings of the 5th International Conference on Serviceoriented Computing (ICSOC 2007), Demo Track ; Vienna, 2007. [Booc1994] Booch, G.: Objektorientierte Analyse und Design. Addison-Wesley: Paris, 1994. [CCMW2001] Christensen, E.; Curbera, F.; Meredith, G.; Weerawarana, S.: Web Services Description Language (WSDL). http://www.w3c.org/TR/2001/NOTE-wsdl-20010315 2001, 2001 (last visited 2005/01). [Durf1996] Durfee, E.H.: Planning in Distributed Artificial Intelligence. In: Foundations of Distributed Artificial Intelligence. John Wiley & Sons, 1996, S. 231-245. [Ferb1999] Ferber, J.: Multi-Agent Systems: An Introduction to Distributed Artificial Intelligence. Addison-Wesley, 1999.

Qualitätssicherung serviceorientierter Architekturen

137

[FHSR2004] Freitag, M.; Herzog, O.; Scholz-Reiter, B.: Selbststeuerung logistischer Prozesse – Ein Paradigmenwechsel und seine Grenzen. In: Industrie Management, 20(2004)1, S. 23-27. [Fipa2003] FIPA Agent Discovery Service Specification. Document Nr.: PC00095A, 2003. http://www.fipa.org/specs/fipa00095/ (last visited Jan. 2005). [Garv1988] Garvin, D.: Managing Quality: The strategic and Competitive Edge. Free Press: New York, 1988. [GuZu2004] Guttmann, C; Zukerman, I.: Towards Models of Incomplete and Uncertain Knowledge of Collaborators’ Internal Resources. In: Proc. of the 2nd German Conf. on Multiagent System Technologies (MATES 2004). Springer: Berlin, 2004, pp. 58-72. [HaMS1987] Hausen, HL; Müllerburg, M; Schmidt M: Über das Prüfen, Messen und Bewerten von Software (On the Examination, Measurement, and Assessment of Software). In: Informatik Spektrum, Vol. 10, no. 3, 1987, S. 123-144. [Hatt1998] Hatton, L.: Does OO Sync with How We Think? IEEE Software, Vol. 15, no. 3, May/June, 1998, S. 46-54. [HaWi1994] Halladay, S; Wiebel, M.: Object-oriented Software Engineering-Object Verification. R&D Publications: Lawrence, 1994. [HoMe1993] Hoppe, T; Mesegeur, P.: VVT Terminology: A Proposal. In: IEEE Expert, Vol. 8, no. 3, 1993, S. 48-55. [Horm2006] Hormann, A.: Testbasierte Spezifikation von Agenteninteraktionsverhalten. Diploma Thesis, University of Bremen, 2006. [HSVV2004] Hübner, S.; Spittel, R.; Visser, U.; Vögele, T.: Ontology-Based Search for Interactive Digital Maps. IEEE Intelligent Systems. 19(3), 2004, IEEE Computer Society Press, S. 80-86. [HuDe2004] Huget, M.P.; Demazeau, Y.: Evaluating Multiagent Systems: A Record/Replay Approach. In: Proceedings of the IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT04), IEEE Press, 2004. [KHLS2006] Kirn, S.; Herzog, O.; Lockemann, P.; Spaniol, O. (Eds.): Multiagent Engineering – Theory and Applications in Enterprises. Berlin: Springer, 2006. [LiNZ2004] Liu, Y.: Ngu, A.H.H.; Zeng, L.: QoS Computation and Policing in Dynamic Web Service Selection. Proc. of WWW2004 Vol. 2, ACM Press: New York, 2004, S. 66-73. [Lutz2004] Lutz, M.: Non-taxonomic Relations in Semantic Service Discovery and Composition. 1st "Ontology in Action" Workshop, in conjunction with 16th Conf. on Software Engineering and Knowledge Engineering (SEKE 2004), Banff, Canada, 2004, S. 482-485. [Maa+2007] Maamar, Z.; Benslimane, D.; Thiran, P.; Ghedira, C.; Dustdar, S.; Sattanathan, S.: Towards a context-based multi-type policy approach for Web services composition. Data and Knowledge Engineering. 62(2), 2007, S. 327-351. [Mar+2004] Martin, D.; Burstein, M.; Hobbs, J.; Lassila, O.; McDermott, D.; McIlraith, S.; Narayanan, S.; Paolucci, M.; Parsia, B.; Payne, T.; Sirin, E.; Srinivasan, N.; Sycara, K.: OWL Semantic Markup for Web Services, 2004. http://www.w3.org/Submission/ 2004/SUBM-OWL-S-20041122/ (last visited 2005/01) .

138

Ingo J. Timm, Arne Hormann, Thorsten Scholz

[MePe2004] Menzies, T; Pecheur, C.: Verification and Validation and Artificial Intelligence. In: Advances of Computers 65. Academic Press, expected Publication in 2005. [MOGS2004] Mika, P.; Oberle, D.; Gangemi, A.; Sabou, M.: Foundations for Service Ontologies: Aligning OWL-S to DOLCE. Proceedings of the WWW2004 Vol. 1, ACM Press: New York, 2004, S. 563-572. [Oasi2004] OASIS: UDDIv3 Specification. http://uddi.org/pubs/uddi_v3.htm, 2004 (last visited 2005/01). [Ran2003] Ran, S: A Model for Web Services Discovery With QoS. SIGecom Exch. Journal 4(1), ACM Press, New York, 2003, S. 1-10. [Ried1997] Riedemann, E.H.: Testmethoden für sequentielle und nebenläufige SoftwareSysteme. B.G. Teubner, Stuttgart, 1987. [Rum+1991] Rumbaugh, J; Blaha, M; Premerlani, W; Eddy, F; Lorensen: Object-Oriented Modelling and Design. Prentice Hall: Englewood Cliffs, New Jersey, 1991. [RuNo2003] Russel S.J.; Norvig P.: Artificial Intelligence – A modern Approach. (Second Edition). Pearson Education Inc.: New Jersey, 2003. [Sand1999] Sandholm, T. W.: Distributed rational decision making. In Weiss, G. (Edt.): Multiagent Systems - A Modern Approach to Distributed Artificial Intelligence, 1999, The MIT Press: Cambridge, Massachusetts, S. 201–258. [ScTS2005] Scholz, T; Timm, I.J.; Spittel, R.: An Agent Architecture for Ensuring Quality of Service by Dynamic Capability Certification. In: Proceedings of the Third German Conference on Multiagent Systems Technologies (MATES 2005). Lecture Notes in Artificial Intelligence (LNAI) 3550. Springer: Berlin, 2005, S. 130-140. [ScTW2004] Scholz, T.; Timm, I. J.; Woelk, P.-O.: Emerging Capabilities in Intelligent Agents for Flexible Production Control. In: Ueda, K.; Monostri, L.; Markus, A. (Eds.): Proceedings of the 5th Int. Workshop on Emergent Synthesis (IWES 2004), Budapest, S. 99105. [SCZ2004] Solanki, M.; Cau, A.; Zedan, H.: Augmenting Semantic Web Service Description with Compositional Specification. In: Proceedings of the WWW2004 Vol. 1, ACM Press: New York, 2004, S. 544-552. [She+2002] Sheth, A.; Cardoso, J.; Miller, J.; Kochut, K.; Kang, M.: QoS for Serviceoriented Middleware. Proceedings of the 6th World Multiconference on Systemics, Cybernetics and Informatics (SCI02), July 2002, S. 528-534. [SmRo1990] Smith, M; Robson, D.: Object-Oriented Programming – The Problems of Validation. In: Proceedings of the International Conference on Software Maintenance, IEEE Computer Society Press: San Diego, 1990. [SnWi2002] Sneed; H.M.; Winter, M.: Testen objektorientierter Software. Hanser: München Wien, 2002. [SoCZ2004] Solanki, M.; Cau, A.; Zedan, H.: Augmenting Semantic Web Service Description with Compositional Specification. Proceedings of the WWW2004 Vol. 1, ACM Press: New York, 2004, S. 544-552. [Thal2002] Thaller GE.: Software-Test - Verifikation und Validation 2. Verlag Heinz Heise GmbH & Co KG: Hannover, 2002.

Qualitätssicherung serviceorientierter Architekturen

139

[Tian2007] Tianfield, H. (Edt.): International Journal on System and Information Sciences Notes (SISN). Vol. 1, No. 1-4, July 2007. [Timm2004] Timm, IJ: Dynamisches Konfliktmanagement als Verhaltenssteuerung Intelligenter Agenten. DISKI 283, infix: Köln, 2004. [TiSF2006] Timm, I. J.; Scholz, T.; Fürstenau, H.: From Testing to Theorem Proving. In: Kirn, S.; Herzog, O.; Lockemann, P.; Spaniol, O. (Eds.): Multiagent Engineering – Theory and Applications in Enterprises. Berlin: Springer, 2006, S. 531–554. [TiSK2006] Timm, I.J.; Scholz, T.; Knublauch, H.: The Engineering Process. In: Kirn, S.; Herzog, O.; Lockemann, P.; Spaniol, O. (Eds.): Multiagent Engineering – Theory and Applications in Enterprises. Berlin: Springer, 2006, S. 341–358. [TiWo2003] Timm, I. J.; Woelk, P.-O.: Ontology-based Capability Management for Distributed Problem Solving in the Manufacturing Domain. In: Schillo, M. et al. (Eds.): Proceedings of the first German Conference on Multi-Agent System Technologies (MATES 2003), Erfurt. LNAI 2831, 2003. Springer: Berlin, S. 168-179. [TuRo1993] Turner, C; Robson, D.: State-Based Testing of object-oriented Programs. In: Proceedings of the International Conference on Software Maintenance. IEEE Computer Society Press: Montreal, 1993. [TWTH2002] Tönshoff, HK; Woelk, P.-O.; Timm, I.J.; Herzog, O.: Emergent Virtual Enterprises. In: Ueada, K. (Edt.): Proceedings of the 4th International Workshop on Emergent Synthesis (IWES-02), May 9-10, Kobe University, Japan, 2002, S. 217-224. [W3C2002] W3C Web Services Architecture Working Group: Web services Glossary. http://www.w3c.org/TR/2002/WD-ws-gloss-20021114/ (last visited 2005/01). [Wool1998] Wooldridge, M.J.: Agents and Software Engineering. Journal AI*IA Notizie XI no. 3, 1998, S. 31-37. [Wool2000] Wooldridge M. J.: Reasoning about Rational Agents. The MIT Press: Cambridge, Massachusetts, 2000.

Modellgetriebene Ableitung semantischer Aspekte in serviceorientierten Architekturen Denis Heinemann, Andreas Schmietendorf, Tilmann Walther Zusammenfassung: Den Elementen von SOAP-Nachrichten innerhalb von serviceorientierten Architekturen fehlt den meisten Fällen die Zuordnung ihrer eindeutigen Semantik. Mit Hilfe von Informationsobjektmodellen (oder auch Business-Object-Models) können semantische Informationen mit Informationsobjekten verknüpft werden. Am Beispiel der Telekommunikationsbrache werden die zwei Modelle SID (Shared Information Datamodel) und BOM (Business Object Model) kurz vorgestellt und eingeordnet. Weiterhin wird das durchgängig integrierte Konzept der DataXtend-Software anhand eines prototypischen Beispiels vorgestellt.

1

Motivation zum Thema

Die Etablierung serviceorientierter Architekturen erfordert die Gewährleistung der semantischen Interoperabilität der Daten, die zwischen den verschiedenen Systemen bzw. Services ausgetauscht werden. In Unternehmen existieren oft verschiedene Definitionen und Darstellungsformen für z.B. einen Kunden, ein Produkt oder eine Bestellung. Solche Begriffe des Alltags sind nicht immer eindeutig abzugrenzen und meist kontextabhängig. Es stellt sich die Frage, wie im Rahmen einer serviceorientierten Architektur (kurz SOA) mit einer derartigen Mehrdeutigkeit umgegangen werden kann. Der in einer SOA im Allgemeinen verwendeten Kommunikation mit Hilfe XMLbasierter SOAP-Nachrichten fehlt es zumeist an semantischen Informationen. Dementsprechend kann aus diesen Nachrichten nicht auf den Sinn bzw. die Bedeutung der enthaltenen Daten geschlossen werden. Dieser Sachverhalt steht im Widerspruch zur grundlegenden Idee einer SOA, Serviceangebote einfach und vor allem kontextfrei (d.h. lose gekoppelt) wiederverwenden zu können. Auch die WSDL-konforme Beschreibung eines Serviceangebotes lässt zumeist keine Rückschlüsse auf die semantische Interpretation der angebotenen Daten bzw. Funktionen zu. Insbesondere bei großen IT-Organisationen, wo eine SOA die Grundlage für eine unternehmensübergreifende Daten- und Funktionsintegration darstellt, führt dieser Sachverhalt zu den klassischen Integrationsproblemen, wie sie bereits unter [Conr1997, 79] im Zusammenhang mit dem föderierten Datenbankentwurf aufgezeigt wurden. Sowohl die dort aufgezeigten semantischen Konflikte als auch potenzielle Beschreibungskonflikte finden sich bei der Implementierung serviceorientierter Architekturen wieder. Für den Transport von semantischen Informationen bedarf es in Anlehnung an [Dost 2005, 285] und unter Berücksichtigung von [Conr1997, 80] der folgenden Rahmenbedingungen: x

Vermeidung von Beschreibungskonflikten, wie die homonyme und synonyme Bezeichnung von Eigenschaften, potenzielle Wertebereichs- und Skalierungskonflikte oder auch Konflikte mit Integritätsbedingungen.

142

x

Denis Heinemann, Andreas Schmietendorf, Tilmann Walther

Vermeidung unterschiedlicher Interpretationen durch die eindeutige Zuordnung von Symbolen zu Konzepten. Es gilt, für Symbole eine global eindeutige Bedeutung herauszuarbeiten und diese im Rahmen einer formalen Notation zu hinterlegen, um so die rechnergestützte Verarbeitung sicherzustellen.

Ohne die Bereitstellung semantischer Informationen im Kontext der durch Serviceangebote bereitgestellten Funktionalitäten kann eine automatische Suche und das anschließende Einbinden, unabhängig ob statisch oder dynamisch, in die Applikation nicht bzw. nur mit einem hohen Risiko durchgeführt werden. Für die Definition von Begriffen für Datenobjekte in serviceorientierten Architekturen sind daher eineindeutige, kontextbezogene Begriffsdefinitionen notwendig. [Alst2004] spricht im Zusammenhang mit der ungenügenden Berücksichtigung von Konsistenzbedingungen und semantischen Aspekten geschäftsrelevanter Daten sogar von der „Achillesferse“ einer serviceorientierten Architektur. Ziel muss es daher zukünftig für Unternehmen sein, eine zentrale, einheitliche und strukturierte Definitionssammlung für alle Geschäftsobjekte (Kunde, Produkt, Bestellung, usw.) zu erstellen.

2

Analyse möglicher Modelle für Informationsobjekte

2.1

Modellierung von Geschäftsobjekten

In Unternehmensdatenmodellen (engl. Business Object Model - BOM) werden alle Informationsobjekte (Business Objects) in einem Unternehmen zentral spezifiziert, beschrieben und die Beziehungen zwischen den einzelnen Business Objects hinterlegt. Ziel eines Business Object Models ist es, eine gemeinsame, allgemein gültige Sichtweise auf die Informationsobjekte in einem Unternehmen zu erhalten. Dies ermöglicht eine klare Kommunikation zwischen Softwarearchitekten, Entwicklern und Anwendern.

Abb. 2-1: Business Object im ARIS Fachbegriffsmodell

Modellgetriebene Ableitung semantischer Aspekte in serviceorientierten Architekturen

143

Abb. 2-1 zeigt beispielhaft einen Auszug eines Business-Object-Models in Form eines Fachbegriffsmodells im ARIS-Toolset. Die oberste Ebene in ARIS-Fachbegriffsmodellen bilden die Business Objects (grau dargestellt), die einfache Fachbegriffe bzw. Attribute (weiß oder gelb dargestellt) oder komplexe Fachbegriffe bzw. Attribute (grün dargestellt mit entsprechendem Verweis auf das Untermodell) besitzen können. Die Business Objects der obersten Ebene sind von abstrakter Natur und besitzen somit keine konkreten Instanzen, sondern dienen lediglich als „Container“ und definieren einen (Daten) Kontext. 2.2

Shared Information Data Model

Ein Industriestandard der Telekommunikationsbranche für ein Business Object Model stellt das „Shared Information Data Model“ (SID) dar, welches vom Telemana1 gementforum im Rahmen des Projektes „New Generation Operations Systems and Software“ (NGOSS) entwickelt wurde. NGOSS stellt ebenfalls einen Industriestandard bestehend aus Richtlinien und Spezifikationen zur Umsetzung von serviceorientierten Architekturen in Unternehmen der Informations- und Telekommunikationstechnologie (IKT; engl. Information and communications technology, ICT) dar. Ein NGOSS besteht derzeit aus folgenden Bestandteilen: x

Technologie-neutrale Architektur (TNA)

x

Enhanced Telecom Operations Map (eTOM)

x

Shared Information Data Model (SID) sowie

x

Kriterien zur Überprüfung der Einhaltung und Konformität mit dem Standard.

Abb. 2-2: Auszug aus dem SID 1

http://www.tmforum.org

144

Denis Heinemann, Andreas Schmietendorf, Tilmann Walther

Das Shared Information Data Model stellt ein komplexes Datenmodell für Informationsobjekte innerhalb eines IKT-Unternehmens dar. Es kann für spezielle Bedürfnisse durch Erweiterungen angepasst werden. Abb. 2-2 zeigt exemplarisch einen Ausschnitt aus dem SID für das Business Object „Customer“ in UML (Klassendiagramm) Darstellung. Unternehmen der Telekommunikationsbranche können das SID für ihre Informationsobjektmodellierung nutzen und es – soweit erforderlich – durch Erweiterungen an ihre Bedürfnisse anpassen. Alternativ dazu können Unternehmen jedoch auch auf die Nutzung des SID verzichten und ein eigenes Modell entwickeln. 2.3

Business Object Model

Abb. 2-3: ein Business Object in einem ARIS-Fachbegriffsmodell Ein Business Object Model (BOM) stellt ein eigens für dieses Unternehmen entwickeltes Unternehmensdatenmodell dar. Die grafische Modellierung kann z.B. mittels ARIS-Fachbegriffsmodellen erfolgen.

Abb. 2-4: Hinterlegte Attribute eines Fachbegriffes im ARIS-Toolset

Modellgetriebene Ableitung semantischer Aspekte in serviceorientierten Architekturen

145

Die Fachbegriffsmodellierung umfasst die grafische Modellierung der identifizierten Business Objects im Unternehmen (Abb. 2-3) und die Hinterlegung von semantischen Informationen (Abb. 2-4) zu den korrespondierenden Attributen. Aus dem Business Object Model in Form des ARIS-Fachbegriffsmodells wird das BOM in Form von XML-Schema Definitionen (XSD-Dateien) für die später durchzuführenden Mappings generiert. Listing 1 auf der folgenden Seite zeigt einen Auszug aus einer der XSD-Dateien für das Business Object „Zahlweg“.

Listing 2-1: Auszug BOM-XSD-Schema Die in Abb. 2-1 und Abb. 2-3 gewählte Darstellung eines BOM als ARIS-Fachbegriffsmodell stellt einen unzureichenden und proprietären Standard dar. Mit der ARIS Fachbegriffsmodell-Notation lassen sich nicht alle Gegebenheiten in Unternehmen eindeutig spezifizieren und somit automatisiert in XML-Schemata überführen. So können z.B. Alternativen, wie in Abb. 2-3 dargestellt, nicht eindeutig, sondern nur

146

Denis Heinemann, Andreas Schmietendorf, Tilmann Walther

durch Textkommentare o.ä. abgebildet werden. Eine Darstellung des BOM in der UML-Notation wäre auch in Bezug auf durchzuführende automatisierte Modelltransformationen in XML-Schemata sinnvoller. 2.4

Modellierung von Geschäftsobjektmodellen in UML

UML bietet im Vergleich zur ARIS-Fachbegriffsmodellierung zahlreiche Vorteile. Im Hinblick auf eine automatisierte Erzeugung der BOM-Schemata besitzen die UMLNotation und die XSD-Spezifikation viele essenzielle Gemeinsamkeiten: (nach [Ayes2003]) x

Datentypen: Es sind Standarddatentypen vorhanden und es können eigene definiert werden

x

Attribute: UML-Klassenattribute können auch in XSD-Dateien verwendet werden, um zum einen um z.B. die Kardinalitäten von Assoziationen darzustellen und zum anderen um Informationen für ein Objekt aufzunehmen

x

Namensräume: Das Konzept von XSD-Namensräumen wird in UML mit Paket(engl. Package)-Definitionen umgesetzt.

x

Generalisierung / Ableitung: Ableitungen lassen sich in UML und XSD darstellen

UML kann jedoch nicht die volle Komplexität der XML-Schema-Spezifikation abbilden. Dabei sind folgende Probleme zu beachten: (nach [Ayesha 2003]) x

Reihenfolge: In XML-Schemata kann die Reihenfolge von Objekte modelliert werden, in UML jedoch gibt es dafür keine explizite Möglichkeit.

x

Attribute: Attribute können in XSD entweder reine Attribute (wie in UML) oder Unter-Elemente (Childs) darstellen. Eine klare Trennung gibt es nicht.

x

Ableitung durch Einschränkung: In UML lassen sich abstrakte Klassen und deren Implementierung durch ableitende Klassen darstellen, jedoch existiert keine formale Definition für Einschränkungen des Wertebereiches, wie es in XSD möglich ist.

x

Schlüssel: In UML können Schlüssel(-attribute) nicht explizit dargestellt werden.

x

Logische Verknüpfungen: In UML lassen sich im Gegensatz zu XSD beispielsweise keine „Oder“ Verknüpfungen modellieren.

Die UML-Notation kann durch die Definition und Zuordnung von „Stereotypen“, „Tagged Values“ und „Constraints“, welche wiederum in einem UML-Profil zusammengefasst werden, erweitert werden. Dadurch können annähernd alle speziellen Sachverhalte abgebildet werden. Abb. 2-5 zeigt ein einen Ausschnitt des BOM als erweitertes UML-Modell. Durch die Erweiterungsmöglichkeit von UML ergibt sich folgende 3-stufige Vorgehensweise bei der UML-Modellierung und anschließender Modeltransformation,

Modellgetriebene Ableitung semantischer Aspekte in serviceorientierten Architekturen

147 2

welche weitgehend dem „Model Driven Architecture“ (MDA) - Ansatz der OMG entspricht: 1. reines UML-Design (konzeptionelles Modell) 2. spezifisches UML-Design mit UML-Erweiterungen (logisches Modell) 3. Generierung der XML-Schemata (physisches Modell)

UML-Diagramme bzw. die darin enthaltenen Informationen können aufgrund des offenen UML-Standards per XMI-Dateien zwischen verschiedenen ModellierungsTools ausgetauscht werden (vgl. Abb. 2-6). Das Austauschformat XMI stellt ein XMLDerivat dar, welches mittels XSLT Modelltransformationen ermöglicht. Aus diesem Wege kann mit Hilfe von XSLT-Dateien eine Modelltransformation beispielsweise von UML in XSD-Schemata erfolgen. Eine Modellierung des Business Object Models in Form von UML-(Klassen)Diagrammen bildet somit die Basis für die automatisierte Erzeugung der BOM-Schemata.

Abb. 2-5: BOM als UML-Klassendiagramm

2

Object Management Group http://www.omg.org

148

Denis Heinemann, Andreas Schmietendorf, Tilmann Walther

Die Modellierung ist aufgrund der Mächtigkeit von UML gegenüber der ARIS-Fachbegriffsmodell-Notation wesentlich genauer möglich. So können in UML beispielsweise Vererbungen modelliert werden. Durch die Erweiterungsmöglichkeiten von UML können auch XSD-Spezifika wie z.B. „“ oder „Enumerations“ (Auswahllisten) modelliert werden. Die UML-Notation ist ein weit verbreiteter, standardisierter Modellierungsstandard in der IT-Branche. Aus diesem Grunde gibt es eine Vielzahl von Softwaremodellierungstools, welche über das „XMI“-Format auch den Austausch von Modellen untereinander unterstützen. Es hat sich jedoch in der Praxis gezeigt, dass nicht alle in XMI-Format vorliegenden Modelle mit jedem XMI-fähigen Tool bearbeitet werden können. Dies stellt ins Besondere dann einen Nachteil dar, wenn komplexe Modelle aufwendig mit einem UML-Tool modelliert wurden und dann später in einem anderen Tool (weiter)verwendet werden sollen. Wenn möglich, sollten im Vorfeld Kompatibilitätstests durchgeführt werden.

Abb. 2-6: Modelltransformation UML2XSD via XMI 2.5

Einordnung der Modelle

Mit einem speziell auf die Belange eines Unternehmens angepassten Modell können die Spezifika des entsprechenden Unternehmens besser abgebildet werden – jedoch auf Kosten der Kompatibilität zu Modellen externer Geschäftspartner. Dies kann im Zeitalter der Globalisierung mittel bis langfristig zu erhöhten Aufwendungen für die Durchführung von Integrationsprojekten mit externen Partnern führen. Daher sollte die Entscheidung für eine Eigenentwicklung oder die Nutzung eines Industriestandards ausführlich analysiert und diskutiert werden.

Modellgetriebene Ableitung semantischer Aspekte in serviceorientierten Architekturen

3

149

Verwendung kanonischer Nachrichten

Kanonische Nachrichtenformate dienen dem strukturierten Nachrichtenaustausch zwischen Anwendungen, basierend auf dem etablierten Business Object Model eines Unternehmens. Mit solchen Referenznachrichten in Form von XML-Schema Definitionen können Informationsobjekte (Business Objects) des Unternehmens zwischen Serviceangeboten inklusive ihrer semantischen Informationen ausgetauscht und von den entsprechenden Partnersystemen semantisch „verstanden“ werden. Kanonische Nachrichtenformate definieren eindeutige Nachrichtenstrukturen, welche für die Kommunikation mit Anwendungen (Services) verbindlich sind. Durch die Verknüpfung (engl. mapping; z.B. durch XSLT) von kanonischen Nachrichten (XSD) mit den tatsächlich an einen Service gesandten (oder von einem Service erzeugten) XMLNachrichten können Inkonsistenzen vermieden werden. Durch den Einsatz von kanonischen Nachrichten-Definitionen basierend auf einem Business Object Model (BOM) ist es somit möglich, Informationen zusammen mit ihrer Semantik durch klar definierte Strukturen zwischen verschiedenen Webservices auszutauschen. (vgl. [Alst2004])

Abb. 3-1: Einsatz kanonischer Nachrichten Für jeden Service in einer serviceorientierten Architektur werden mindestens zwei kanonische Nachrichten benötigt. Jeweils eine für die Anfrage (Request) an den Service und eine für die Antwort (Response) des Service. Diese Nachrichten

150

Denis Heinemann, Andreas Schmietendorf, Tilmann Walther

enthalten eine Struktur, die aus den Elementen des BOM besteht. Die kanonischen Nachrichten werden dann vom Enterprise Service Bus (vgl. [Chap2004], [TErl2005], [Mark2006]) per XSLT mit den tatsächlichen XML-Nachrichten verknüpft. Das Resultat der stattfindenden Transformation ist eine BOM-konforme XML-Nachricht mit semantischen Inhalten. Nicht BOM-konforme Nachrichten werden auch ASBO (Applikations Spezifisches Business Object) – Nachrichten genannt, da die enthaltenen Datenstrukturen nur von der entsprechenden Anwendung interpretiert werden können (siehe Abb. 3-1).

4

Abbildung von Nachrichten auf ein Business Object Model (Mapping)

Für die innerhalb des ESB durchzuführende Transformation wird ein Mapping der vom Service-Provider erstellten ASBO (Applikationsspezifische Business Object)XSD-Dateien, welche die tatsächlichen Nachrichtenstrukturen (reale Nachrichtenstruktur) für die Kommunikation mit den Serviceimplementierungen darstellen, auf die BOM-konformen Referenznachrichten (virtuelle Nachrichtenstruktur) benötigt.

Abb. 4-1: Mapping mit der Software MapForce von Altova Beim Mapping werden die einzelnen Elemente der ASBO-XSD-Datei (siehe Abb. 4-1 linke Seite) mit den korrespondierenden Elementen innerhalb der Referenznachricht (siehe Abb. 4-1 rechte Seite) visuell verknüpft. Resultat dieses Vorganges sind XSLT-Dateien für die im ESB durchzuführende automatisierte Transformation.

5

Integrierte Lösung

Ein alternativer Ansatz zur Verknüpfung von (SOAP-)Nachrichten innerhalb von SOAs mit entsprechender Semantik bietet sich mit der Software „DataXtend“ (Vormals „Pantero“) von der Firma Progress Software. Bei diesem vollständig integrierten System handelt es sich um eine Kombination aus Modellierungs- und Laufzeitumgebung. Ziel ist es von einem so genannten „Common Model“ – also beispielsweise einem BOM oder dem SID – ausgehend, direkt auf die XML-Nachrichten von Webservices referenzieren zu können. Abb. 5-1 zeigt einen Screenshot der DataXtend -Software. Im Mittelpunkt ist das „Common Model“ (in diesem Fall das SID) zu erkennen. Weiterhin sind im linken Bereich die Webservices („Data Services“

Modellgetriebene Ableitung semantischer Aspekte in serviceorientierten Architekturen

151

genannt) und im rechten Bereich so genannte „Data Sources“ zu erkennen. Mittels dieser Datenquellen lassen sich direkte Verbindungen zu Datenbanken herstellen, um z.B. zur Laufzeit Validierungen unter Einbeziehung bestehender Daten vorzunehmen. Die Prüfung der Existenz einer übermittelten Kundennummer wäre ein Beispiel hierfür. Das DataXtend -Konzept bietet erweiterte Funktionalitäten bezogen auf das Mapping von Nachrichten auf Elemente eines „Common Models“, wie beispielsweise virtuelle Attribute (zur Laufzeit berechnet) oder Datenbankabfragen zur Laufzeit (um virtuelle Attribute zu füllen oder zur Validierung). Diese Funktionalitäten werden durch die Verwendung von Java-Klassen statt XSLT zur Umsetzung der Transformationsregeln ermöglicht. Daher bietet diese Lösung auch wesentlich mehr Möglichkeiten für Transformationsregeln, da Java-Klassen die Funktionalität und Flexibilität von XSLT übersteigen.

Abb. 5-1: Screenshot DataXtend Alle Informationen bezogen auf das „Common Model“, die Mappings und die damit verbundenen Transformationsregeln sind in der DataXtend -Software vorhanden. Daraus ergibt sich die Möglichkeit von „impact Analysen“, mit welchen Auswirkungen von Veränderungen, beispielsweise am „Common Model“, analysiert werden können. Dies erleichtert den Umgang mit Änderungen am zentralen Datenmodell („Common Model“ / BOM) im Rahmen des Change-Managements. Von Änderungen am Modell betroffene Mappings und Transformationsregeln werden aufgezeigt und können gezielt an das veränderte Modell angepasst werden. Somit ist es möglich, immer mit einer einzigen Version des zentralen Datenmodells im Wirkbetrieb zu arbeiten. Einen

152

Denis Heinemann, Andreas Schmietendorf, Tilmann Walther

weiteren Vorteil dieses Konzeptes bildet die Möglichkeit der Integration der DataXtend -Laufzeitumgebung in vorhandene ESB-Systeme wie z.B. IBM-Websphere. Abb. 5-2 und Abb. 5-3 veranschaulicht das DataXtend -Konzept im Vergleich zum bereits vorgestellten Ansatz mittels kanonischer Nachrichten. Die Erstellung der Referenznachrichten entfällt beim Einsatz der DataXtend -Software. Optional wird dieses Konzept jedoch auch unterstützt. Mit Hilfe des DataXtend -Konzeptes können die Bereitstellungszeiten von modellkonformen Webservices und die benötigten Zeiten für das Umsetzen von Änderungen am zentralen Datenmodell drastisch reduziert werden (laut Angaben von DataXtend um bis zu 30%). Die nachträgliche Einführung einer solchen Integrationslösung ist jedoch mit hohem Aufwand verbunden, da durch die DataXtend -Laufzeitumgebung Teilaufgaben, die derzeit im ESB bearbeitet werden, aus dem ESB übernommen werden. Die notwendige Umstrukturierung der Softwarearchitektur wäre sehr aufwendig. Der Einsatz einer durchgängig integrierten Gesamtlösung wie DataXtend stellt ein optimales, ganzheitliches Konzept dar. Bei einem kompletten Neuaufbau einer Systemarchitektur („green Field“-Ansatz) ist der Einsatz einer Softwarelösung wie „DataXtend“ denkbar.

Abb. 5-2: Übersicht DataXtend Für weiterführende Informationen zur „DataXtend“-Software sei auf die korrespon3 dierende Internetseite verwiesen.

3

http://www.progress.com/dataxtend/dataxtend_si/index.ssp

Modellgetriebene Ableitung semantischer Aspekte in serviceorientierten Architekturen

153

Abb. 5-3: DataXtend Konzept im Detail

6

Zusammenfassung und Ausblick

Daten, die zwischen Softwarekomponenten ausgetauscht werden, mit Semantik zu versehen ist ins Besondere im Rahmen von serviceorientierten Architekturen eine Notwendigkeit, um einen Überblick über die Vielzahl von verschiedenen Informationsobjekten in Unternehmen (Business Objects) zu behalten. Die Berücksichtigung semantischer Aspekte muss insbesondere bei serviceorientierten Architekturen zu einem festen Bestandteil werden. Nur so kann die Datennutzung von externen Partnern wie Kunden, Lieferanten und öffentliche Einrichtungen sinnvoll unterstützt werden. Der stetig steigende Automatisierungsgrad von betrieblichen Prozessen – bestärkt durch Technologien wie BPEL – trägt ebenso dazu bei, wie auch die steigende Nutzung des Internets als Kommunikationsplattform für B2B-, B2C- und B2A- (Business to Administration; e-Government) Anwendungen. Um Prozesse wirklich weitgehend automatisieren zu können, ist es notwendig, dass Anwendungen z.B. in Form von Webservices die Daten, die sie erhalten oder anfordern, interpretieren können. Nur so kann die Vision von serviceorientierten Architekturen, in der sich Softwarekomponenten zur Laufzeit Ihre Kommunikationspartner (ebenfalls Softwarekomponenten) aus mehreren Angeboten selbstständig auswählen, realisiert werden. Mit serviceorientierten Architekturen und Webservices als deren „Enabler“-Technologie ist es möglich geworden, komplexe Unternehmensanwendungen durch eine feingranulare Aufteilung in einzelne Komponenten (z.B. Webservices) überschaubar zu gestalten. Die historisch gewachsenen Probleme der Datenintegration bzw. der

154

Denis Heinemann, Andreas Schmietendorf, Tilmann Walther

Dateninterpretation bleiben jedoch erhalten. Die Notwendigkeit der Entwicklung eines standardisierten „Data-Exchange-Models“ zur Verbesserung der Dateninteroperabilität ist unumgänglich. Die hier vorgestellten Konzepte wie die Modellierung von Geschäftsobjekten in UML, verbunden mit der Hinterlegung von semantischen Informationen für jedes Datenelement und die somit ermöglichte automatisierte Erzeugung von maschinenlesbaren XML-Schemata stellen einen ersten, aber sicherlich wichtigen Schritt hin zu einer vollständigen semantischen serviceorienierten Architektur dar. Die Herausforderung für die Zukunft besteht darin, Daten aus verschiedensten Quellen (von Kunden, Geschäftspartnern, usw.) in einer standardisierten Form mit Hilfe von semantischen Informationen auf globaler Ebene zu integrieren.

Literaturverzeichnis [Alst2004] Alston, L.: SOA’s Achilles Heel – Data inconsistencies can undermine the bestplanned architectures, Fawcette Technical Publications – Enterprise Architect, 2004, URL: http://www.ftponline.com/ea/magazine/spring/online/lalston_05_06_04/. [Ayes2003] Ayesha, M.: Design XML schemas using UML - Translating business concepts into XML vocabularies, IBM developerWorks 2003, URL: http://www-128.ibm.com/ developerworks. [Chap2004] Cappell, D. A.: Theory in Practice - Enterprise Service Bus, O’Reilly Media, Sebastopol, CA, 2004. [Conr1997] Conrad, S.: Föderierte Datenbanksysteme – Konzepte der Datenintegration, Springer, Heidelberg, 1997. [Dost2004] Dostal, W.; Jeckle, M.: Semantik und Web Services. Java Spektrum 4/2004, SIGS-DATACOM, August/September 2004. [Dost2005] Dostal, W.; Jeckle, M.; Melzer, I.; Zengler, B.: Service-orientierte Architekturen mit Web Services (Konzepte – Standards – Praxis), Spektrum Akademischer Verlag, München, 2005. [TErl2005] Erl, T.: SOA – Concepts, Technology and Design, Prentice hall, Upper Saddle River, NJ, 2005. [Hein2006] Heinemann, D.: Modellgetriebene Berücksichtigung semantischer Aspekte in Service-orientierten Architekturen, Diplomarbeit Hochschule Harz, Wernigerode 2006. [Mark2006] Marks, E. A.; Bell, M.: Service Oriented Architecture – A Planning and Implementation Guide for Business Technology. John Wiley & Sons, Hoboken/NJ, 2006.

Elektronische Märkte in SOA-basierten Unternehmensprozessen Falk Kretzschmar, Ralf Peters Zusammenfassung: Die Software-Infrastruktur heutiger Unternehmen vollzieht eine zunehmende Transformation von monolithischen Anwendungssystemen hin zu modularen, komponentenorientierten Architekturen. Derzeit werden hierzu so genannte Service-orientierte Architekturen diskutiert, in denen die einzelnen Anwendungskomponenten miteinander über einen zentralen Verzeichnisdienst in Kontakt treten und Dienste austauschen. Der Austausch kostenpflichtiger Dienste hat insbesondere zwischen Unternehmen und damit wirtschaftlich unabhängigen Instanzen wachsende Bedeutung. Damit stellt sich, neben der im Bereich der verteilten Systeme der Informatik untersuchten technischen Koordination, zunehmend auch die Frage nach einer ökonomischen Koordination der beteiligten Akteure. Dieser Beitrag stellt Konzepte zur Umsetzung der ökonomischen Koordination in Service-orientierten Architekturen vor und beschreibt einen Ansatz zur Bewertung der vorgestellten Konzepte

1

Einleitung

In Service-orientierten Architekturen wird die Funktionalität einer Anwendung als Dienst bereitgestellt und einfacher Zugriff auf wiederverwendbare Komponenten mit Hilfe von Internet-Technologien ermöglicht. Ziele für den Einsatz einer Serviceorientierten Architektur sind Wiederverwendung, Interoperabilität, lose Kopplung und die Möglichkeit, Anwendungen flexibel an die Geschäftsprozesse im Unternehmen anzupassen. Gemäß der Spezifikation des W3C besteht eine Service-orientierte Architektur (SOA) aus drei Hauptkomponenten: Der Service Provider stellt Dienste zur Verfügung, der Service Broker unterstützt das Publizieren und Suchen von Diensten und der Service Requestor nutzt die publizierten Dienste [Alon2003], [ZTPe2003], [W3C2004]. Eine der am häufigsten verwendeten Technologien zur Umsetzung von SOA sind die Web Services Basisstandards SOAP, WSDL und UDDI. Zusätzlich zu den Web Services Basisstandards wurden zahlreiche Beschreibungssprachen entwickelt, die es ermöglichen Aspekte wie Sicherheit oder die Komposition von Diensten zu berücksichtigen. Eine aktuelle Forschungsfrage im Bereich Service-orientierte Architekturen ist die Untersuchung verschiedener Konzepte zur Umsetzung der ökonomischen Koordination in SOA [Bole2004], [ElLa2004]. Ziel einer ökonomischen Koordination in SOA ist die Abstimmung und Verhandlung von Service Provider und Service Requestor auf Basis ökonomisch relevanter Parameter. Wichtige Verhandlungsparameter sind in diesem Zusammenhang der Preis des Dienstes und weitere nichtfunktionale Eigenschaften, wie Ausfallwahrscheinlichkeit oder maximal zulässige Wartezeiten, die unter dem Begriff Quality of Service (QoS) zusammengefasst werden [Ludw03], [Sing05]. Innerhalb der Service-orientierten Architektur fehlt der Aspekt der ökonomischen Koordination jedoch bisher: Aus Sicht des Service Requestors bietet der Service Broker einen Verzeichnisdienst und damit eine Datenstruktur, die es ermöglicht Dienste entsprechend ihrer Funktionalität zu suchen. Andere Suchkriterien, wie der Preis und weitere Parameter der Dienstnutzung, spielen in gegenwärtigen Implementierungen des Service Brokers jedoch keine Rolle. Die Verhandlung über

156

Falk Kretzschmar, Ralf Peters

ökonomisch relevante Eigenschaften von Diensten findet im Moment außerhalb der Service-orientierten Architektur statt, d.h. der Preis der Dienste kann in einem Katalog eingesehen werden und weitere Parameter der Dienstnutzung können in separaten Verhandlungen festgelegt werden. Dies widerspricht dem On-Demand-Zugriff auf Komponenten und einer losen Kopplung von Service Provider und Service Requestor und steht damit im Widerspruch zu den Zielen des Einsatzes einer Serviceorientierten Architektur. Die Nutzung marktbasierter Koordinationsmechanismen in SOA ist eine Möglichkeit den Austausch kostenpflichtiger Dienste zu ermöglichen. Die Idee eines Elektronischen Marktes für Software-Komponenten ist nicht grundlegend neu. Dieser Idee folgend, kann für den Handel mit digitalen Diensten der Service Broker in SOA ähnliche Funktionen übernehmen wie ein Elektronischer Markt für den Handel mit physischen Gütern. Dazu gehört das Bereitstellen von Information über die gehandelten Dienste, aber auch die Unterstützung von Verhandlungen über die Eigenschaften der angebotenen Dienste. Zur Zuordnung von Angebot und Nachfrage auf einem Elektronischen Markt in SOA können verschiedene Koordinationsmechanismen genutzt werden. Dieser Beitrag beschreibt grundlegende Konzepte für marktbasierte Koordinationsmechanismen in SOA und stellt Technologien zur Umsetzung der beschrieben Konzepte vor. Darauf folgt die Darstellung eines Simulationsmodells zur Untersuchung verschiedener marktbasierter Koordinationsmechanismen.

2

Ökonomische Koordination in SOA

2.1

Konzepte zur Umsetzung der ökonomischen Koordination in SOA

Im Umfeld der Web Services Technologien existieren bereits einige Ansätze, die eine Verständigung über die Eigenschaften der ausgetauschten Dienste ermöglichen sollen. Stellvertretend dafür stehen WS-Policy, WS-Negotiation und WS-Agreement [Sing05], [Tian04]. Die genannten Ansätze haben Verhandlungen über technische Parameter zum Ziel. Beispiel für derartige Verhandlungen sind Vereinbarungen zwischen Service Provider und Service Requestor über Quality of Service oder über Sicherheitsrichtlinien bei der Dienstnutzung. Der Begriff der ökonomischen Koordination in SOA bezeichnet die Abstimmung und Verhandlung von Service Provider und Service Requestor bezüglich ökonomisch relevanter Parameter. Derartige Verhandlungen zwischen Service Provider und Service Requestor finden im Moment nicht automatisiert statt, sondern werden vor der eigentlichen Dienstnutzung durchgeführt. Die Verhandlungsparameter werden in diesem Fall in Verträgen, so genannten Service Level Agreements (SLAs), festgelegt. Tabelle 2-1 zeigt nicht-funktionale Eigenschaften von Diensten und damit grundlegende ökonomische Verhandlungsparameter in SOA.

Elektronische Märkte in SOA-basierten Unternehmensprozessen

157

Service-Preis Quality of Service:

Server Performance: Antwortzeiten, Wartezeiten, Durchsatz, durchschnittliche Verfügbarkeit, maximal tolerierte Ausfallwahrscheinlichkeit Network Performance: Bandwidth, Latency, Jitter

Sicherheitspolicies vereinbarter Verhandlungsmechanismus Anzahl der Verhandlungspartner Reputation der Verhandlungspartner Dauer der vertraglich geregelten Dienstnutzung Sanktionen im Falle der Nichteinhaltung des Service Level Agreement Tab. 2-1: Nicht-funktionale Eigenschaften von Diensten In der Verhandlungsphase werden die Parameter der Dienstnutzung zwischen den beteiligten Verhandlungspartnern ausgehandelt. Um die Verhandlungsphase zu automatisieren oder zumindest zu unterstützen existieren verschiedene Konzepte. Neben einfachen technischen Koordinationsformen ist eine wichtige Kategorie die der marktbasierten Koordinationsmechanismen. Hier können, unabhängig vom konkreten Verhandlungskontext, verschiedene Automatisierungskonzepte unterschieden werden [Sege1999], [Bich2001]. Dazu gehören, neben einfachen Auktionsverfahren, auch erweiterte Auktionsverfahren und agentenbasierte Verhandlungen. Tabelle 2-2 zeigt grundlegende Konzepte für Verhandlungen in SOA und nimmt eine einfache Kategorisierung der Konzepte nach Art des Service Brokers, Architektur, Verhandlungsmechanismus und Grad der Automatisierung vor.

Art des Service Brokers

Einfacher Katalog: Festpreis (“take it or leave it offer”) Erweiterter Katalog: Festpreis, Preisdifferenzierung Auktionsbroker: Dynamische Preisbildung

Architektur

1:1 Negotiation, m:n Marketplace, Brokered Marketplace

Verhandlungsmechanismus

Simple auction mechanisms: English, Dutch, Vickrey auction Extended auction mechanisms: Double, Multi-unit, Multi-attribute auction

Grad der Automatisierung

Negotiation Support Systems, Agentbased negotiations

Tab. 2-2: Konzepte für Verhandlungen in SOA

158

2.2

Falk Kretzschmar, Ralf Peters

Technologien zur Umsetzung der ökonomischen Koordination in SOA

Universal Description, Discovery and Integration (UDDI) ist der im Bereich Web Services bereits seit langem verfügbare, jedoch nur selten genutzte Standard zur Umsetzung des Service Brokers. UDDI wird oft als globaler Marktplatz für Web Services bezeichnet. Ein mit Hilfe von UDDI implementierter Service Broker stellt allerdings nur einen einfachen Katalog dar, in dem Web Services publiziert und gesucht werden können. Aufgrund der fehlenden Möglichkeit semantische Informationen zu den angebotenen Diensten zu hinterlegen, bietet UDDI keine ökonomische Koordination, keine semantische Suche nach Diensten und keine automatisierte Verhandlung zwischen Service Provider und Service Requestor. Für automatisierte Verhandlungen in SOA ist ein Service Broker, der im Wesentlichen nur die funktionalen Eigenschaften des Dienstes und eine Referenz auf die entsprechende Schnittstellenbeschreibung enthält, nicht ausreichend. Der Aspekt kostenpflichtiger Dienste bleibt in UDDI ebenfalls unberücksichtigt. Nichtsdestotrotz ist UDDI ein geeigneter Ausgangspunkt für die Erweiterung des Service Brokers um eine ökonomische Koordination. Es implementiert bereits eine einfache Datenstruktur, die es ermöglicht Metadaten zu den angebotenen Diensten zu speichern. Es werden dabei die Kategorien „white pages“ für Providerinformationen „yellow pages“ für Provider- und Service-Informationen und „green pages“ für technische Informationen z.B. zum Aufrufen des Dienstes unterschieden [SiHu2005], [BFMa2002]. Im Bereich der Semantic Web Technologien existieren bereits einige Ansätze, die den Service Broker um semantische Informationen und speziell auch um Preisinformationen erweitern [Shai2003], [Dan2004], [Srin2004], [Paol2002], [Gram2003]. Ein weiterer Ansatz besteht darin, ohne eine zentrale Instanz und damit ohne den Service Broker, ebenfalls semantische Informationen zu den ausgetauschten Diensten zu speichern. Dies kann über die Erweiterung der Schnittstellenbeschreibung um semantische Informationen zu den ausgetauschten Diensten erfolgen [PaTo2003], [Lama2003], [Verh2004], [Tian2004].

3

Ein agentenbasierter Ansatz zur Bewertung von marktbasierten Koordinationsmechanismen in SOA

3.1

Simulation der ökonomischen Koordination in SOA

Die in Abschnitt 2.1 aufgeführten Verhandlungskonzepte zeigen verschiedene Möglichkeiten einer ökonomischen Koordination in SOA. Zur Umsetzung der dargestellten Konzepte stehen die in Abschnitt 2.2 genannten Technologien zur Verfügung. Im folgenden Abschnitt steht die Frage im Mittelpunkt, welche Auswirkung die Nutzung der genannten Konzepte und Technologien auf das Ergebnis einer Verhandlung zwischen Service Provider und Service Requestor hat. Eine Möglichkeit verschiedene Formen der marktbasierten Koordination in SOA zu untersuchen und zu bewerten bietet die Modellierung und Simulation. Unser Ansatz zur vergleichenden Bewertung verschiedener Konzepte besteht aus einem agentenbasierten Modell und verschiedenen Simulationsszenarien. Der simulative Ansatz ermöglicht es, auch komplexe Systeme zu untersuchen, für die eine analytische

Elektronische Märkte in SOA-basierten Unternehmensprozessen

159

Lösung zur Bewertung der dargestellten Verhandlungskonzepte kaum möglich ist. Agentenbasierte Simulationsmodelle werden mittlerweile in vielen Gebieten eingesetzt, von denen zwei eng an die hier untersuchte Forschungsfrage angrenzen. Den ersten Bereich bilden Simulationen für die Untersuchung von ökonomischen Aspekten wie Allokationseffizienz oder für den Vergleich verschiedener Verhandlungsstrategien für eine gegebene Koordinationsform [Bich2001], [CMKa1996]. Den zweiten Bereich bilden Simulationen zur Untersuchung Service-orientierter Architekturen bezüglich der Einhaltung technischer Parameter bei der Dienstnutzung [NaMc2002], [Sava2005]. Unser Ansatz berücksichtigt sowohl technische als auch ökonomische Aspekte der Dienstnutzung in SOA. So wird im Modell beispielsweise die für den Handel mit digitalen Diensten übliche Kostenstruktur der Anbieter, die Komposition von feingranularen zu grobgranularen Diensten und die Koordination von Unternehmensprozessen über die Unternehmensgrenzen hinweg abgebildet. Zusätzlich zu der Annahme, dass vom Service Provider angebotene Dienste kostenpflichtig sind, wird die Verfügbarkeit der angebotenen Dienste als eine von verschiedenen Qualityof-Service-Größen berücksichtigt. Die Entscheidungen von Service Provider und Service Requestor werden im Modell mit Hilfe des Konzepts der autonomen Softwareagenten abgebildet [Nwan1996]. Die Implementierung des agentenbasierten Modells erfolgt unter Nutzung des Open-Source-Frameworks JADE (Java Agent Development Framework). 3.2

Basismodell

In diesem Abschnitt wird ein agentenbasiertes Modell vorgestellt, das die ökonomische Koordination von Service Provider und Service Requestor abbildet. Im Modell werden dabei zwei grundlegende Agententypen unterschieden: Der Typ des „Enterprise Agent“ modelliert die Entscheidungen eines Unternehmens, das Dienste nutzen oder anbieten möchte und der Typ des „Service Broker Agent“ modelliert verschiedene Koordinationsformen für den Austausch von Diensten zwischen Unternehmen. Abbildung 3-1 zeigt die genannten Agententypen und von ihnen abgeleitete Agententypen. Die von den Basistypen des „Enterprise Agent“ und „Service Broker Agent“ abgeleiteten Agententypen werden in verschiedenen Simulationsszenarien eingesetzt. Es handelt sich um ein Referenzszenario ohne ökonomische Koordination, ein Festpreisszenario, ein Auktionsszenario und ein Szenario ohne Service Broker zur Untersuchung von direkten Verhandlungen zwischen Service Provider und Service Requestor. Innerhalb dieser Szenarien verhalten sich die Agenten gemäß der für sie implementierten Strategie, reagieren auf Aktionen anderer Agenten und nutzen Parameter der Agentenumgebung für ihre Entscheidungen. Als zentrale Bewertungskriterien für den Vergleich verschiedener Koordinationsformen und Agentenstrategien werden der von den Agenten erzielte Gewinn und die erreichte Quality of Service verwendet. Die soeben dargestellte Infrastruktur aus Enterprise Agents und Service Broker Agents bildet ein internes System zur Bereitstellung digitaler Dienste, das einer externen Nachfrage gegenübersteht. Jeder Enterprise Agent Ui repräsentiert ein Unternehmen und produziert für den externen Markt genau einen Dienst WSi. Um einen externen Dienst WSi herzustellen, werden die internen Dienste A, B und Ci benötigt. Die internen Dienste A und B sind für alle Unternehmen identisch. Sie können von jedem Unternehmen sowohl für den Eigenbedarf produziert als auch

160

Falk Kretzschmar, Ralf Peters

über den Service Broker mit anderen Unternehmen gehandelt werden. Der interne Dienst Ci ist demgegenüber unternehmensspezifisch und kann nur vom jeweiligen Unternehmen selbst hergestellt werden.

Abb. 3-1: Agententypen im Basismodell In der Simulation liefert das externe System Informationen über die Nachfrage nach externen Diensten. Entsprechend der eintreffenden Nachfrage kann sich jedes Unternehmen dafür entscheiden externe Dienste anzubieten oder interne Dienste A und B an andere Unternehmen zu verkaufen. Für den Fall, dass sich ein Unternehmen für das Anbieten externer Dienste entscheidet, trifft es in einem zweiten Schritt die Entscheidung über das Zukaufen oder Herstellen von internen Diensten A und B. Die Interaktion der Agenten ist für die verschiedenen Szenarien ähnlich. Abbildung 3-2 zeigt die Agenteninteraktion für das Auktionsszenario. Der grau hinterlegte Teil der Interaktion von Service Broker und Enterprise-Agent ist für alle Simulationsszenarien identisch, während die darauf folgenden Aktionen spezifisch für das hier dargestellte Auktionsszenario sind. Ein Simulationslauf besteht aus einer gegebenen Anzahl von Runden. In jeder Runde findet die in Abbildung 3-2 dargestellte Interaktion von Service Broker und Enterprise-Agent statt. Für das Szenario zur Untersuchung von direkten Verhandlungen zwischen Service Provider und Service Requestor übernehmen die Enterprise-Agenten teilweise die Funktionalität des Service Brokers.

Elektronische Märkte in SOA-basierten Unternehmensprozessen

Service Broker

161

Enterprise Agent

send_RegisterMsg()

register_Enterprises()

send_External_MarketInfo() sellExternal_Decision()

sell_External() || sell_Internal() makeOrBuy_Decision()

make_InternalServices() || buy_InternalServices()

excecuting_auction() : collecting_bids() : determining_winners() : finish_auction() send_Internal_MarketInfo()

execute_ValueChain()

Abb. 3-2: Agenteninteraktion für das Auktionsszenario Eine Simulationsrunde beginnt mit einer Kontrollnachricht zum Registrieren aller Enterprise-Agenten beim Service Broker. Danach sendet der Service Broker die vom externen System erhaltene Nachfrage nach externen Diensten an alle Enterprise Agenten. Auf Basis dieser Marktinformation entscheiden sich die Enterprise-Agenten entweder externe Dienste anzubieten oder interne Dienste zu verkaufen (sellExternal_Decision). In einer zweiten Entscheidung (makeOrBuy_Decision) wird der Marktpreis für interne Dienste A und B mit dem Preis für den zur Herstellung von internen Diensten benötigten Ressourcenpool verglichen und die günstigere Alternative gewählt. In Abhängigkeit des vom Service Broker implementierten Koordinationsmechanismus kaufen Enterprise-Agenten interne Dienste für einen Festpreis, können den Preis verhandeln oder in einer einfachen Auktion (Vickrey Auktion) für interne Dienste A und B bieten. Am Ende einer Runde wird die Wertschöpfungskette entsprechend den bisher getroffenen Entscheidungen ausgeführt (execute_ValueChain) und der von den einzelnen Enterprise-Agenten erzielte Gewinn sowie die Verfügbarkeit für externe Dienste berechnet.

162

3.3

Falk Kretzschmar, Ralf Peters

Diskussion der Ergebnisse

Im Folgenden soll auf die von uns bisher durchgeführten Experimente eingegangen werden. Es wurden zwei Experimente zu den jeweils vier genannten Koordinationsformen durchgeführt, die erste Aussagen zu einer vergleichenden Bewertung ermöglichen. In beiden Experimenten wurden jeweils 20 Enterprise-Agenten mit identischen Eingangsdaten gestartet. Die Nachfrage nach externen Diensten WS1... WS20 ist für alle Szenarien normalverteilt. Die Ergebnisse stellen aggregierte Daten über alle Enterprise-Agenten und alle Runden eines Simulationslaufes dar. Im ersten Experiment wurde der durchschnittliche Agentengewinn für die vier Koordinationsformen untersucht. Es handelt sich um das Referenzszenario ohne ökonomische Koordination (Szenario-0), das Festpreisszenario (Szenario-1) und das Auktionsszenario (Szenario-2). Zusätzlich dazu wird in dem Szenario ohne Service Broker die direkte Verhandlung zwischen Service Provider und Service Requestor untersucht (Szenario-3).

Abb. 3-3: Durchschnittlicher Agentengewinn je Szenario In Abbildung 3-3 ist zu erkennen, dass der durchschnittliche Agentengewinn für das Referenzszenario ohne ökonomische Koordination mit etwa 1200 Geldeinheiten geringer als für alle anderen Szenarien ausfällt. Die fehlende Möglichkeit interne Dienste zwischen den Unternehmen auszutauschen führt zu einer deutlich schlechteren Koordination des Gesamtsystems. Das Festpreis- und das Auktionsszenario erzielen demgegenüber die besten Ergebnisse, wobei die Koordination über ein Auktionsverfahren geringe Vorteile gegenüber den Festpreisen bietet. Die dezentrale Koordination ohne Service Broker bietet mit einem durchschnittlichen Agentengewinn von etwa 1500 Geldeinheiten zwar eine Verbesserung gegenüber dem Referenzszenario ohne Koordination, liefert jedoch ein wesentlich schlechteres Ergebnis als die zentralen Koordinationsformen. Eine mögliche Ursache für den geringeren durchschnittlichen Gewinn bei dezentraler Koordination liegt in der Implementierung der direkten Agenteninteraktion: Ein Enterprise Agent, der sich für das Anbieten interner Dienste entscheidet (Typ „Provider“) gibt seinen Reservationspreis für interne Dienste A und B bekannt und wartet darauf, dass ein Enterprise-Agent (Typ „Requestor“) auf das Angebot eingeht. Hier kann der Fall auftreten, dass der Provider in der aktuellen

Elektronische Märkte in SOA-basierten Unternehmensprozessen

163

Runde keine internen Dienste verkaufen kann, was sich negativ auf den durchschnittlichen Gewinn auswirkt. Im zweiten Experiment wurde, anstelle des Agentengewinns, die vom System erreichte Verfügbarkeit der externen Dienste als eine einfache Quality-of-ServiceKennzahl für einen Vergleich der Koordinationsformen herangezogen. Die Verfügbarkeit der externen Dienste wird hier als Quotient aus tatsächlich hergestellten externen Diensten und aktuell nachgefragten externen Diensten gebildet. Abbildung 3-4 stellt die Quality of Service für die vier Szenarien dar.

Abb. 3-4: Quality of Service je Szenario Für das Referenzszenario ohne ökonomische Koordination ergibt sich mit einem Wert von 0,25 wie bereits im ersten Experiment das deutlich schlechteste Ergebnis. Alle anderen Koordinationsformen leisten mit einem Wert von etwa 0,8 eine deutlich bessere Quality of Service. Das mit geringem Abstand beste Ergebnis bietet das Auktionsszenario. Im Gegensatz zum ersten Experiment erzielt die dezentrale Koordination jedoch hinsichtlich der erzielten Quality of Service ein ähnliches Ergebnis wie die zentralen Koordinationsformen.

4

Zusammenfassung und Ausblick

Dieser Beitrag enthält einen Überblick über verschiedene marktbasierte Koordinationsmechanismen in SOA. Der im letzen Teil des Beitrags vorgestellte agentenbasierte Simulationsansatz erlaubt die vergleichende Bewertung verschiedener Koordinationsmechanismen in Bezug auf unterschiedliche Zielgrößen wie Agentengewinn und Quality of Service. Erste Simulationsergebnisse zeigen, dass der Gewinn und die erreichte Quality of Service der beteiligten Akteure stark vom gewählten Koordinationsmechanismus abhängen können. In beiden vorgestellten Experimenten zeigt die Koordination über ein Auktionsverfahren das beste Ergebnis. Weitere Experimente sollen Aufschluss darüber geben, inwieweit verschiedene Verteilungen der externen Nachfrage Einfluss auf das Ergebnis der Verhandlung haben. Ziel zukünftiger Arbeiten ist auch die Erweiterung des Simulationsmodells um zusätzliche Quality-of-Service-Größen und um komplexere Agentenstrategien zur Auswahl der internen Dienste.

164

Falk Kretzschmar, Ralf Peters

Literaturverzeichnis [Alon2003] Alonso, G.: Web Services: Concepts, Architectures and Applications. Springer: Berlin, 2003. [Bich2001] Bichler, M.: The Future of E-Markets: Multi-Dimensional Market Mechanisms. Cambridge University Press: Cambridge, 2001. [Bole2004] Boles, D.: Erlösformen für Web Content und Services. In: Informatik - Forschung und Entwicklung, 3-4 (2004) 18, S. 165-173. [BFMa2002] Bussler, C., Fensel, D., Maedche, A.: A conceptual architecture for semantic web enabled web services. In: ACM SIGMOD Record, 4 (2002) 31, 2002. [CMKa1996] Chavez, A., Maes, P.: Kasbah: An agent marketplace for buying and selling goods. Proceedings of First International Conference on the Practical Application of Inteligent Agents and Multi-Agent Technology, 1996. [Dan2004] Dan, A. et al.: Web services on demand: WSLA-driven automated management. In: IBM Systems Journal, 1 (2004) 43, S.136-158. [Gram2003] Gramm, A.: WS-QOS - Ein Rahmenwerk für Dienstgüteunterstützung in Web Services. Institut für Informatik, Freie Universität Berlin, 2003. [ElLa2004] Elfatatry, A., Layzell, P.: Negotiating in Service-oriented Environments. In: Communication of the ACM, 8 (2004) 47, S. 103-08. [Lama2003] Lamanna, D. et al.: SLAng: A language for Service Level Agreements. Departement of Computer Science, University College London, 2003. [Ludw2003] Ludwig, H.: Web Services QoS: External SLAs and Internal Policies Or: How do we deliver what we promise? Proceedings of First Web Services Quality Workshop, IEEE Computer Society, 2003. [NaMc2002] Narayanan, S., McIlraith, S.: Simulation, Verification and Automated Composition of Web Services. Proceedings of 11th International World Wide Web Conference, 2002. [Nwan1996] Nwana, H. S.: Software Agents: An Overview. In: Knowledge Engineering Review, 3 (1996) 11, S 205-244. [Paol2002] Paolucci, M. et al.: Importing the Semantic Web in UDDI. Proceedings of Web Services, E-business and Semantic Web Workshop, 2002. [PaTo2003] Patel, K., Tosic, V.: Web Service Offerings Language (WSOL): Characteristics, Applications, and Tools. 2003. [Sava2005] Savarimuthu et al.: Agent-based integration of Web Services with Workflow Management Systems. Proceedings of Fourth international Joint Conference on Autonomous Agents and Multiagent Systems. ACM Press: New York, 2005. [Shai2003] Shaikh A. et al.: UDDIe: An Extended Registry for Web Services. Department of Computer Science, Cardiff University, 2003. [Sege1999] Segev, A., et al.: On Negotiations and Deal Making in Electronic Markets. In: Information Systems Frontiers, 3 (1999) 1, S. 241-258. [SiHu2005] Singh, M., Huhns, M.: Service-Oriented Computing: Semantics, Processes, Agents. Wiley, 2005.

Elektronische Märkte in SOA-basierten Unternehmensprozessen

165

[Srin2004] Srinivasan, N. et al.: Adding OWL-S to UDDI, implementation and throughput. Proceedings of First International Workshop on Semantic Web Services and Web Process Composition, 2004. [Tian2004] Tian, M. et al.: A Survey of current Approaches towards Specification and Management of Quality of Service for Web Services. Institut für Informatik, Freie Universität Berlin, 2004. [Verh2004] Verheecke, B. et al.: AOP for Dynamic Configuration and Management of Web Services. In: International Journal of Web Services Research, 1 (2004) 3, S. 25-41. [W3C2004] Booth et al.: Web Services Architecture. W3C Working Group Note, 2004. http://www.w3.org/TR/ws-arch/. [ZTPe2003] Zimmermann, O., Tomlinson, M., Peuser, S.: Perspectives on web services: applying SOAP, WSDL, and UDDI to real-world projects. Springer: Berlin, 2003.

Anwendungspotenziale von Intelligenten Agenten in Service-orientierten Architekturen Mathias Petsch, Volker Nissen, Timo Traub Zusammenfassung: Services und Agenten weisen einige Gemeinsamkeiten auf. Nicht zuletzt aus diesem Grund haben sich in der letzten Zeit einige Veröffentlichungen mit Konzepten für den Einsatz von (Intelligenten) Softwareagenten in Service-orientierten Architekturen beschäftigt. In diesem Beitrag wird ein Überblick zum Stand der Forschung und zu den erkennbaren Anwendungspotenzialen von Softwareagenten in Service-orientierten Architekturen gegeben. Vor diesem Hintergrund wird auch der Frage nachgegangen, wie sich Geschäftsregeln (business rules) als Basis für Verhandlungen zwischen Agenten über die Nutzung von Diensten einsetzen lassen. Eine notwendige Voraussetzung dafür ist die semantische Beschreibung von Diensten, die beispielsweise deren Bedeutung, Nutzen, Qualitätsmerkmale und Kostenaspekte repräsentiert. Auch hierfür wird ein Lösungsvorschlag auf Basis des Ontologiegedankens entwickelt.

1

Grundlagen

1.1

Service-orientierte Architekturen

Der Begriff der Service-orientierten Architektur (SOA) unterliegt unterschiedlichen Deutungen. Hier soll SOA als komponentenorientierte Architektur verstanden werden, deren Bestandteile einer losen Kopplung unterliegen und eine ausgelagerte Steuerung aufweisen [Sied2007, 110]. Im Folgenden werden nach einer Erläuterung weiterer, grundlegender Begrifflichkeiten, die Potenziale von intelligenten Softwareagenten im Kontext von SOA strukturiert herausgearbeitet. Dabei kann festgestellt werden, dass SOA primär weder eine Technologie noch einen technologischen Standard repräsentieren, sondern vielmehr ein von der konkreten Technologie abstrahierendes organisatorisches high-level Konzept [KBSL2005, 60], aus dem neuartige IT-Architekturen zur Unterstützung flexibler und unternehmensübergreifender Geschäftsprozesse entwickelt werden können. Es geht daher vor allem um die Frage, welche Beiträge intelligente Agenten im Kontext solcher veränderten Architekturkonzepte leisten können. In der Agentenforschung haben sich in der Vergangenheit bereits andere Autoren mit Softwareagenten im Kontext von SOA auseinandergesetzt [DiWo2005; Huhn2006; ZBEF+2006]. Hierbei variierte ebenfalls das Verständnis davon, was unter einer SOA zu verstehen ist bzw. wo die Anwendungsschwerpunkte liegen. So beschreibt Huhns [Huhn2002; Huhn2006] SOA als Zukunft des Semantic Web, wohingegen Dickinson und Wooldridge [DiWo2005] SOA bezeichnen als „… an approach to building business application based on web services“. Ausdrücklich sei hervorgehoben, dass eine SOA jedoch nach unserem hier zugrunde gelegten, organisatorisch motivierten Verständnis nicht zwingend auf Web Services als technischer Realisierung beruhen muss.

168

1.2

Mathias Petsch, Volker Nissen, Timo Traub

Intelligente Agenten

Agenten repräsentieren eine neue Technologie bei der Entwicklung von Softwaresystemen. Die Agententechnologie erfährt durch ihr großes Potenzial bei der weitgehend autonomen Lösung komplexer Aufgaben eine zunehmend stärkere Bedeutung in der Entwicklung von Anwendungssystemen. Eine Vielzahl von Autoren haben sich mit der Frage beschäftigt, was die spezifischen Eigenschaften eines Intelligenten Agenten sind und was sie gegenüber herkömmlichen Programmen auszeichnet [FrGr1996]. Eine weithin akzeptierte Definition durch Wooldridge und Jennings [WoJe1995, 2] gibt folgende Eigenschaften als wesentlich für intelligente Agenten an: Autonomie:

Agenten agieren ohne direkten Eingriff eines Benutzers und haben Kontrolle über ihre eigenen Aktionen.

Soziale Fähigkeiten:

Agenten interagieren mit anderen Agenten (oder dem Benutzer) unter Verwendung einer spezifischen Kommunikationssprache (z.B. KQML)

Reaktivität:

Agenten nehmen ihre Umwelt sowie deren Dynamik wahr und reagieren auf dort eintretende Ereignisse oder Zustandsänderungen.

Proaktivität:

Agenten agieren zielgerichtet und reagieren nicht nur auf Veränderungen der Umwelt.

Tab. 1-1: Weitgehend akzeptierte Eigenschaften Intelligenter Agenten Rationales Verhalten der Agenten setzt voraus, dass diese über eigene Ziele verfügen, die sie zu erreichen streben. Die Abbildung und Implementierung dieser Ziele kommt eine entscheidende Bedeutung zu, da Ziele die Grundlage für proaktives Verhalten darstellen. Multiagentensysteme bestehen aus Agenten, die zum Zweck der Lösung einer gestellten Aufgabe, mit anderen Agenten im System kooperieren. Multiagentensysteme sind „... concerned with coordinating intelligent behavior among a collection of (possibly pre-existing) autonomous intelligent ‘agents’ how they can coordinate their knowledge, goals, skills, and plans jointly to take action or to solve problems. The agents in a multiagent system may be working toward a single global goal, or toward separate individual goals that interact” [BoGa1988, 3]. Es kann aus der Perspektive der Softwareentwicklung zwischen drei verschiedenen Arten von Agentenarchitekturen unterschieden werden. Reaktive Agenten reagieren nach einem einfachen Reiz-Reaktions-Schema, d.h. sie nehmen über Sensoren Veränderungen der Umwelt war. Entspricht die Wahrnehmung einem dem Agenten bekannten Muster, wird mittels eines festgelegten Skripts auf die Veränderung reagiert. Deliberative Agenten hingegen verfügen über Wissensbasen, in denen das anwendungs- und domänenspezifische Wissen repräsentiert ist. Mittels eines Umgebungsmodells kann er durch Interpretation und Schlussfolgerung auf Veränderungen der Umwelt reagieren. Hybride Agenten vereinen die Vorteile der reaktiven Architekturen (schnelle Reaktion auf sich verändernde Umweltbedingungen) mit denen der deliberativen (Reaktion auf nicht vorhergesehene bzw. nicht implemen-

Anwendungspotenziale von Intelligenten Agenten in Service-orientierten Architekturen

169

tierte Ereignisse und selbstständiges, zielgerichtetes Handeln). Der Agent reagiert je nach Art der Veränderung der Umwelt mit seinem reaktiven oder deliberativen Teil. Ist ein der Veränderung entsprechendes Muster implementiert, kann der reaktive Teil Verwendung finden, ist das nicht der Fall, kann per Wissensbasen und Umgebungsmodell ein geeignetes Agentenverhalten durch den deliberativen Teil erstellt werden. 1.3

Stand der Forschung zu Agenten in Service-orientierten Architekturen

Agenten und SOA, respektive (Web-)Services, zeigen einige Gemeinsamkeiten, die deren Verknüpfung in IT-Architekturen sinnvoll erscheinen lassen. Allerdings existieren auch Unterschiede, die deren Anwendungspotenzial und Verknüpfung limitieren. Dickinson und Wooldridge [DiWo2005] stellen Web Services und Agenten, mit der Betonung auf deliberative (intelligente) Agenten, gegenüber. Dabei stehen folgende Fragen im Vordergrund: Wie können Agenten Web Services nutzen? Welchen Nutzen können Web Services für Agenten haben? Wie könnten eventuell Agenten das Web Service Paradigma unterstützen? Gemeinsam ist beiden Technologien, dass sie lose gekoppelte, aktive Komponenten sind, deren Nutzen in der Regel aus der Komposition der Komponenten erwächst. Allerdings weisen Agenten spezifische Eigenschaften auf, vor allem die Repräsentation der Ziele des Nutzers und daraus folgend „absichtliches“ Verhalten, die sie klar von Web Services differenzieren. Eine Verknüpfung von Agenten und Web Services ist aus zwei Richtungen denkbar. Entweder ein Web Service wird von einem Agenten aufgerufen oder ein Web Service nutzt einen Agenten. Auch hierbei lässt sich ein wesentlicher Unterschied zwischen beiden Technologien dahin gehend erkennen, dass ein Web Service statischer Natur ist und daher ein deterministisches Verhalten aufweist, welches bei Agenten nicht der Fall ist. Diese sind aufgrund ihres zielgerichteten und „absichtsvollen“ Verhaltens nicht deterministisch, woraus folgt, dass der Aufruf eines Agenten durch einen Web Service sich schwierig, oder sogar unmöglich gestaltet. Web Services sind demzufolge „primitiver“. Huhns argumentiert sogar, dass „… SOC (Service Oriented Computing) presents several challenges that cannot be tackled without agent concepts and techniques.” [Huhn2006, 20]. Dabei verweist der Autor insbesondere darauf, dass SOA durch agentenbasierte Systeme autonom und adaptiv gebildet werden können, eine höhere Skalierbarkeit erzielt werden kann, offene Systeme mit offenen Interaktionsbeziehungen zwischen den Systemen gebildet werden können und die Robustheit und Verfügbarkeit der Systeme erhöht wird [Huhn2006, 21]. Es fällt auf, dass die Autoren, auch der nachfolgend dargestellten beispielhaften Ansätze, in der Regel auf die höhere Robustheit agentenbasierter SOA verweisen. Im Folgenden sollen ausgewählte Ansätze agentenbasierter SOA vorgestellt werden, die sich grundsätzlich in zwei Bereiche untergliedern lassen: x

Agenten selbst werden als Services genutzt oder

x

Agenten dienen der Steuerung, Verwaltung bzw. Orchestrierung von Services im Sinne von SOA.

Dem ersten Anwendungsfall, Agenten sind Services, wird aufgrund des nicht-deterministischen Verhaltens, zumindest von deliberativen Agenten, in der Literatur nur wenig Aufmerksamkeit zuteil (z.B. [GrCa2004; Huhn2006]), da sich durch die fehlende Statik der Agenten deren Aufruf und Ausführung im SOA-Kontext schwierig

170

Mathias Petsch, Volker Nissen, Timo Traub

gestaltet. Deutlich mehr Arbeiten widmen sich der Orchestrierung von Diensten durch agentenbasierte Werkzeuge (u.a. [BVVe2003; KiJi2006; MKBr2006]). Unter Orchestrierung wird die flexible Anpassung der Zusammenstellung von Services, z.B. in Folge der Änderung von Prozessen, verstanden [RLPB2007, 10]. Hierbei steht die dynamische Anpassung von SOA in Abhängigkeit von sich verändernden Umweltbedingungen bzw. die Suche und Eingliederung von Diensten im Vordergrund. So stellen Kim und Jin [KiJi2006] einen Ansatz vor, bei dem mit Hilfe von BDI1 Agenten Aufrufe semantischer Webservices koordiniert werden. Semantische Webservices werden hierbei als Dienste mit einer erweiterten formalen Beschreibung ihrer Fähigkeiten verstanden. Diese Beschreibungen erfolgen u.a. mit Hilfe von Onto2 logien, zum Beispiel mit OWL-S . Auf Basis dieser formalen Beschreibungen ist es einem BDI-Agenten möglich, existierende Webservices zu orchestrieren. In einem von den Autoren vorgestellten Prototyp konnte gezeigt werden, dass die Flexibilität und Robustheit semantischer Webservices erhöht wurde. Müller et al. [MKBr2006] versuchen ebenfalls, die Flexibilität und Robustheit von Services zu erhöhen, indem diesen jeweils ein Agent zugeordnet wird, der den Dienst repräsentiert. Ein s.g. User Agent hat die Aufgaben, im Auftrag eines Benutzers Dienste (respektive Agenten) über ein Blackboard auszuschreiben, zu identifizieren und anschließend zu orchestrieren. Das Wesentliche an diesem Ansatz ist, dass eine dezentrale Struktur mit verteilten Agenten für die Repräsentation der jeweiligen Dienste, mit relativ einfachen Regeln die Komposition von Diensten realisiert und nicht, wie z.B. in der Arbeit von [KiJi2006] eine zentrale komplexe Instanz für die Orchestrierung der Dienste verantwortlich ist. Durch Zinnikus et al. [ZBEF+2006] wird darauf verwiesen, dass die Business Process 3 Execution Language (BPEL) wenig geeignet ist, robuste und flexible Systeme zu entwerfen, die eventuell erst während der Laufzeit Dienste integrieren und auf Fehler reagieren. Dem stellen die Autoren einen Ansatz entgegen, der mit Hilfe von BDIAgenten die Orchestrierung sowohl existierender als auch neuer (noch nicht bekannter) Web Services unterstützt. Der wesentliche Vorteil des vorgestellten Frameworks liegt wiederum in der Robustheit des Systems bei der Fehlerbehandlung, z.B. von Aufrufen nicht mehr existenter Dienste und bei der Einbeziehung von Diensten, die während der Entwurfszeit noch nicht bekannt waren. Weitere Ansätze (so unter anderem [ADKK+2005; DjSa2006; NgKo2007; NPTT2006; RKKr2007]) widmen sich sehr ähnlichen Fragestellungen und fokussieren auf eine intelligente Komposition, respektive Orchestrierung von Diensten im SOA-Umfeld. Zusammengefasst lässt sich feststellen, dass bislang zwar eine nennenswerte Anzahl von Arbeiten im agentenbasierten Umfeld existieren, die sich jedoch vornehmlich auf die Komposition und Orchestrierung von Diensten fokussieren. Dickinson und Wooldridge [DiWo2005] argumentieren, dass die Umsetzung von Web Services 1

2

3

BDI – Belief, Desire, Intention. Dabei werden unter dem Begriff „Belief“ die Annahmen des Agenten über die Umwelt, unter „Desire“ die noch nicht in Absichten umgesetzten Wünsche des Agenten und unter „Intention“ die Absichten, zu denen der Agenten sich verpflichtet hat, zusammengefasst. OWL – Onology Web Language, OWL-S –Web Service Ontology, http://www.daml.org/services/owl-s/ http://www.ibm.com/developerworks/library/specification/ws-bpel/

Anwendungspotenziale von Intelligenten Agenten in Service-orientierten Architekturen

171

durch Agenten nicht möglich ist, ohne die Charakteristiken von Agenten nachhaltig zu beschränken. Allerdings setzen SOA nicht zwingend Web Services voraus, sondern der Dienstebegriff im Kontext von SOA ist allgemeiner und kann, wie durch Huhns [Huhn2006] vorgeschlagen, auch Agenten umfassen.

2

Einsatzmöglichkeiten von Agenten im SOA-Kontext

Neben der Orchestrierung, respektive dem dynamischen Einbinden und Verwalten von Diensten existieren weitere Einsatzbereiche für die Anwendung agentenbasierter Systeme. So wurden schon Agenten als Services diskutiert. Diesbezüglich existiert jedoch keine einhellige Meinung, ob Agenten überhaupt als Dienste genutzt werden können, ohne dass deren charakteristischen Merkmale, wie Autonomie und Proaktivität eingeschränkt werden. Im Folgenden sollen mögliche, sinnvolle Anwendungsbereiche von Agenten im SOA-Kontext kurz skizziert und deren Nutzenpotenzial kritisch bewertet werden.

Abb. 2-1: Einsatzmöglichkeiten von Agenten im Web Service Dreieck (in Anlehnung an [W3C2002]) Dabei wird bei der Betrachtung gemäß o.g. Unterscheidung differenziert zwischen Agenten als Diensten (in Abb.2-1 mit 1 gekennzeichnet) und Agenten zur Steuerung, Kontrolle und Orchestrierung von Diensten. Letztere lassen sich wiederum in drei Anwendungsklassen unterteilen: 1) Agenten agieren als Service Requestor (in Abb. 2-1 mit 2 gekennzeichnet) – agentenbasierte Systeme fragen Dienste nach, um diese zu nutzen, 2) Agenten dienen als Service Broker (in Abb. 2-1 mit 3 gekennzeichnet), sind demnach intelligente Intermediäre zwischen Nachfrager und Anbieter von Diensten und

172

Mathias Petsch, Volker Nissen, Timo Traub

3) Agenten fungieren als Schnittstelle (in Abb. 2-1 mit 4 gekennzeichnet), die quasi intelligent Konvertierungen für Aufrufe und daraus resultierende Ergebnisse übernehmen und somit die Aufrufmechanismen vereinfachen. 2.1

Agenten als Dienste

Wenn auch [DiWo2005] zu Recht darauf hingewiesen haben, dass Agenten nicht als Web Services Verwendung finden können und häufig SOA zu Unrecht mit Web Services gleich gesetzt werden (u.a. [DiWo2005]), so basieren SOA doch auf Diensten im Allgemeinen, die lose gekoppelt zu Prozessen zusammengesetzt werden. Dienste können generell durchaus durch Softwareagenten repräsentiert werden. Huhns [Huhn2006] vermutet, dass die Entwicklung von Web Services in den kommenden Jahren verschiedene Entwicklungsstufen durchlaufen wird, die in aktive Web Services münden werden, deren Charakteristiken sehr stark denen von Softwareagenten ähneln, z.B. indem die Qualitätsmerkmale oder Preise für die Nutzung eines Dienstes direkt durch diesen verhandelt werden. Laut Huhns wird die Entwicklung von Web Services in der Zukunft vier Phasen durchlaufen [Huhn2006, 10]: Phase 1: ist der gegenwärtige Stand der Technik. Web Services sind vor allem in Intranets verfügbar und weisen nur eine geringe oder keine semantisch klare Beschreibung ihrer Leistung und Eigenschaften auf. Daraus folgt, dass die Orchestrierung und Komposition manuell erfolgen muss. Bislang werden außerdem in der Regel keine Gebühren für die Nutzung von Diensten erhoben. Dies führt wiederum dazu, dass gegenwärtig kaum Bereitschaft vorliegt, Dienste auch öffentlich verfügbar zu machen. Phase 2: Web Services werden zunehmend über das Internet verfügbar. Die semantische Beschreibung der Dienste erfolgt über standardisierte Schlagwörter, die eine teilautonome Identifizierung von Diensten ermöglicht. Weiterhin erfolgt die Komposition manuell. Gebühren existieren, jedoch erfolgt deren Verhandlung in der Regel durch menschliche Akteure. Die dynamische und automatische Einbindung von Diensten beschränkt sich im Wesentlichen auf den Aspekt der Robustheit, um nicht funktionierende Dienste automatisch durch andere Dienste zu substituieren. Dies könnte in der Folge dazu führen, dass die Weiterentwicklung der semantischen Beschreibung von Diensten stärker forciert wird. Phase 3: Web Services weisen eine reiche semantische Beschreibung auf, die eine automatische Komposition und einen dynamischen Aufruf der Dienste ermöglicht. Phase 4: Web Services werden aktiv und weisen zunehmend Eigenschaften von Softwareagenten auf. Sie können über Eigenschaften und Funktionalitäten verhandeln und wären sogar theoretisch in der Lage, sich selbst zu organisieren, um aggregierte Funktionalitäten zur Verfügung zu stellen. Damit würden aktive Web Services sehr starke Parallelen zu Softwareagenten und Multiagentensystemen aufweisen. In der Agentenforschung sind seit geraumer Zeit Verhandlungsalgorithmen und Selbstorganisation viel diskutierte Themen [Ferb2001; Wool2002]. Es konnte dabei auch nachgewiesen werden, dass insbesondere Dynamik, Robustheit und Flexibilität durch agentenbasierte Anwendungen und Multiagentensysteme erhöht werden [KHLS2006]. Insofern scheinen Erkenntnisse der Agentenforschung auf die Weiterentwicklung hin zu aktiven Web Services übertragbar. Problematisch in diesem Zusammenhang ist allerdings, dass die Akzeptanz

Anwendungspotenziale von Intelligenten Agenten in Service-orientierten Architekturen

173

solcher Systeme in der praktischen Umsetzung auf Widerstände stößt. So ist zu vermuten, dass nur bei klar nachweisbaren Vorteilen aktiver, selbstorganisierender Systeme, diese auch in der betriebswirtschaftlichen Realität Anwendung finden werden. Um so genannte aktive Web Services zu ermöglichen, müssen allerdings einige Restriktionen gegenwärtig existierender Web Services aufgehoben werden [Huhn2006, 12]. So hat ein Web Service kein Wissen über seine Umwelt, Benutzer o.ä., wie es z.B. bei intelligenten Agenten in Umwelt- oder Domänenmodellen repräsentiert ist. Web Services sind bislang auch nicht dazu ausgelegt, Ontologien zu verwenden, um unterschiedlichen Domänen, Anforderungen oder Nutzern Rechnung zu tragen. Wieterhin sind Web Services passiver Natur, d.h. sie werden erst bei Aufruf aktiv, können folglich nicht selbstständig und proaktiv Aktionen auslösen, wie z.B. über Änderungen von Informationen zu informieren. Das heißt, Web Services sind bislang nicht so ausgerichtet, dass sie selbstorganisierendes und kooperatives Verhalten aufweisen können, welches für eine selbstständige, autonome und dynamische Komposition notwendig wäre. Um aktive Web Services zu gestalten, sind weitere Überlegungen notwendig, die im Umfeld von SOA angesiedelt sind. So müssen Strukturen geschaffen werden, die eindeutige Beschreibungen der Semantik von Diensten ermöglichen. Service Provider müssen zertifiziert werden können, um deren Integrität und Reputation zu gewährleisten. Weiterhin spielen Fragen der IT-Governance eine entscheidende Rolle, wie zum Beispiel Zuverlässigkeit und Robustheit von Systemen und Diensten überwacht und gesteuert werden können. Vorausgesetzt, die Annahmen über die Entwicklung der Rahmenbedingungen werden so vollzogen und die Idee der aktiven Web Service findet auch Akzeptanz, können SOA, Web Services und Agententechnologie eine fruchtbare und sinnvolle Synthese eingehen. 2.2

Agenten zur Steuerung, Kontrolle und Orchestrierung von Diensten

Grundsätzliche Überlegungen Folgt man den Argumenten von Dickinson und Wooldridge [DiWo2005], nachdem Agenten keine Web Services sein können, liegt ein aussichtsvoller Ansatz in der Komposition, Orchestrierung und Koordination von Diensten innerhalb von SOA. Diesem Szenario widmet sich bislang auch der überwiegende Teil der publizierten Ansätze zu Agenten in SOA (u.a. [BVVe2003; KiJi2006; MKBr2006]). Hierbei ist offensichtlich, dass eines der wesentlichen Probleme in der bisher unzureichenden semantischen Beschreibung der Dienste (z.B. Web Service Definition Language WSDL), bzw. unzureichender Verzeichnisdienste wie UDDI (Universal Description, Discovery and Integration) liegt. Diese bieten in der Regel zwar eine ausreichende technische Beschreibung, Aussagen über qualitative Aspekte wie Servicequalität, Kosten, Verfügbarkeit oder funktionale Eigenschaften (z.B. evtl. Einschränkungen des Dienstes, Art und Detaillierung des konkreten Ergebnisses) werden in diesem Rahmen nicht getroffen. Aus diesem Grund sind bis heute automatische Diensteinbindungen bzw. die Komposition von Diensten nicht, oder nur intern innerhalb einer Organisationsstruktur möglich.

174

Mathias Petsch, Volker Nissen, Timo Traub

Neben der direkten Orchestrierung der Dienste, ist auch ein Szenario denkbar, bei dem Agenten im Vorfeld der Komposition und Orchestrierung, Unternehmensprozesse eigenständig dahin gehend analysieren, wo der Einsatz von Diensten sinnvoll erscheint und in welcher Granularität eine Dienstgenerierung zweckmäßig ist. Hierbei hätten Agenten die Aufgabe, im Kontext des prozessorientierten Corporate Performance Measurement [Niss2006, 3], IT-gestützte Prozesse kontinuierlich zu überwachen. Dabei kann zum Beispiel die Häufigkeit der Änderung von Teilprozessen oder Prozessschritten je Zeiteinheit ermittelt, das Benutzerverhalten im IT-System analysiert oder Prozessmessungen hinsichtlich Durchlaufzeiten und Abbruchraten durchgeführt werden. Aus diesen Daten lassen sich im weiteren Verlauf gegebenenfalls automatisierte Vorschläge bezüglich einer sinnvollen Prozessrekonfiguration und Erstellung von Diensten generieren. Ein Agent wäre in diesem Bereich also ein intelligentes Assistenzsystem, verantwortlich für die kontinuierliche Überwachung und Analyse von Prozessen mit Blick auf zweckmäßige Anpassungen. Durch die Verteilung von intelligenten Agenten auf unterschiedliche Geschäftsprozesse sowie deren soziale und kooperative Eigenschaften, erscheint es technisch auch denkbar, dass diese Abstimmungen untereinander vornehmen und z.B. eventuelle Redundanzen in Prozessen ermitteln und gegebenenfalls eliminieren helfen. Agenten als Service Requestor Grundsätzlich unterscheidet sich das Szenario, einen Agenten als Service Requestor zu nutzen, nicht von konservativen Programmen in derselben Rolle. Der Unterschied liegt einzig in der Fähigkeit des Agenten, durch sein proaktives und vor allem autonomes Verhalten, robuster und eventuell dynamischer auf Ausfälle von Diensten zu reagieren, bzw. diese zu identifizieren und einzubinden. Insofern scheint Agententechnologie in diesem Einsatzszenario kein gänzlich neues Anwendungspotenzial und nur eine moderate Verbesserung gegenüber konventionellen Ansätzen zu besitzen. Agenten als Service Broker / Agenten als Interface Im Folgenden wird ein Szenario skizziert, welches sowohl den Einsatz von Agenten als Schnittstelle als auch den Einsatz als Service Broker umfasst. Wurde bisher das Thema der Agenten als Schnittstelle im Umfeld von SOA nur wenig thematisiert, war es jedoch in der breiteren Agentendiskussion in der Vergangenheit ein stark thematisierter Betrachtungsgegenstand (u.a. [Lieb1997; LMMa1994]). Insofern lassen sich 4 die dort erzielten Erkenntnisse zur Schnittstellenproblematik auf den Anwendungsbereich der service-orientierten Architekturen übertragen. Im vorgestellten Anwendungsfall ist besonders die Verknüpfung von Schnittstellenagent und Service Broker (Mediator) von Interesse, da der „lokale“ Interface-Agent die Grundlage für einen autonom handelnden, interoperablen Service Broker und damit überhaupt für die automatische und dynamische Komposition und Orchestrierung bietet. Wie schon dargelegt, liegt ein wesentliches Problem in der eindeutigen semantischen Beschreibung der Dienste. In Abbildung 2-2 wird ein Ansatz vorgeschlagen, bei dem ein Agent einer Domäne zugeordnet ist und Wissen über die in der Domäne vorhandenen Dienste besitzt. Eine Domäne kann in diesem Fall ein Service Provider oder ein Intranet eines Unternehmens sein und die Dienste dieses gesamten Bereichs beinhalten. 4

z.B. flexible und dynamisch anpassbare Schnittstellen, interaktive Mensch-Maschinen Schnittstellen, semantische Korrektheit durch Ontologien

Anwendungspotenziale von Intelligenten Agenten in Service-orientierten Architekturen

175

Abb. 2-2: Agenten als Mediatoren in einer SOA Die in der Abbildung 2-2 dargestellte Ebene der Dienstbeschreibung beinhaltet die herkömmlichen Instrumente der technischen Beschreibung, z.B. durch WSDL. Der Agent erweitert diese um funktionale und qualitative Aspekte. Er verfügt folglich über das technische Wissen über einen Dienst (Parameter, Aufrufmechanismen) und zusätzlich über qualitatives Wissen (Qualitätsmerkmale, Verfügbarkeit, eventuelle Gebühren). Ein Vorteil dieses Ansatzes liegt darin, dass der Domänenagent erforderliches Domänenwissen durch den Service Provider der Domäne erhält und somit keine komplexen Mechanismen zur Ermittlung von qualitativen Aspekten eines Dienstes notwendig sind. Darauf aufbauend sind die Agenten der einzelnen Domänen in der Lage, untereinander Dienstbeschreibungen auszutauschen und gegebenenfalls Nutzungsbedingungen und Gebühren zu verhandeln. In einem alternativen, zentralen Ansatz können die Dienstbeschreibungen auch einem zentralen Servicebroker (Mediator) zur Verfügung gestellt werden, der dann die Koordination übernimmt. Verhandlungen sind in der Agententechnologie ein viel untersuchtes Thema und werden 5 teilweise durch Standards der Foundation for Intelligent Physical Agents (FIPA) umgesetzt. Um eine eindeutige und angereicherte semantische Beschreibung von Diensten zu unterstützen, haben sich in den vergangenen Jahren für ähnliche Fragestellungen Ontologien bewährt [KoTo2006]. Eine Ontologie ist „…an explicit specification of a conceptualization…“ [Grub1993, 1], d.h., durch die Konzeptualisierung wird eine vereinfachte Sichtweise auf die Welt geschaffen, wobei mithilfe eines definierten 5

http://www.fipa.org/

176

Mathias Petsch, Volker Nissen, Timo Traub

Vokabulars eine Domäne oder ein Thema spezifiziert wird. Hierfür werden gegenwärtig auch erste Spezifikationen für Ontologien entworfen, z.B. Open SOA Onto6 logy , die eine Basis für einen automatisierten Austausch und Verhandlungen zwischen Agenten im SOA-Kontext darstellen könnten.

3

Geschäftsregeln für agentenbasierte Service-orientierte Architekturen

Um die Verhandlungen von Agenten über die Nutzung von Diensten und damit auch deren automatische Komposition zu unterstützen, respektive überhaupt erst zu ermöglichen, sind Regeln über die Verwendung von Diensten im Prozesskontext ebenso wie eventuelle Entgelte für die Dienstenutzung zu beschreiben, auszutauschen und gegebenenfalls zu überwachen. Für diese Aufgabenstellung scheint der Ansatz der Geschäftsregeln (Business Rules) geeignet. Bei Geschäftsregeln stehen vor allem die Darstellung von organisatorischen Strukturen, deren Abhängigkeiten sowie Möglichkeiten der Steuerung und Kontrolle von Geschäftsprozessen im Rahmen der Gestaltung von Informationssystemen im Vordergrund. Die Business Rules Group beschreibt Geschäftsregeln wie folgt: „...a business rule is a directive, intended to influence or guide business behavior, in support of business policy ...a business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure, or to control or influence the behavior of the business.” [BrGr2007]. Dabei dienen Business Rules vor allem als Erweiterung bei der Modellierung von Geschäftsprozessen für den späteren Entwurf von IVArchitekturen. Sie können jedoch auch als kodifizierte Handlungsanweisungen in der Business Software selbst verwendet werden. Hierzu existieren diverse Ansätze der formalisierten Beschreibung von Geschäftsregeln, von denen die Object Constraint Language (OCL), welche durch die Object Management Group (OMG) als Erweiterung der Unified Modeling Language (UML) in der Version 2.0 standardisiert wurde, in den letzten Jahren an Popularität gewonnen hat. Vorteil der OCL ist, dass die Sprache in UML integriert ist und somit eine verhältnismäßig einfache direkte Übertragung in Programmcode ermöglicht. Business Rules im SOA-Kontext können hierbei unterschiedliche Aufgaben zugewiesen werden. Einerseits können sie Anforderungen und Parameter an Dienste spezifizieren, wie zum Beispiel notwendige Verfügbarkeit, Ausführungsqualität etc. Andererseits können innerhalb der Regeln auch Commitments (im Sinne eines Vertrages) zwischen den Parteien (Service Provider und Service Requestor) verbindlich gemacht werden. Bei der Regelmodellierung wird unterschieden zwischen obligatorischen (unabdingbaren) und optionalen Regeln sowie zwischen statischen (domänenunabhängigen) und dynamischen (domänenabhängigen) Regeln.

6

http://www.opengroup.org/projects/soa-ontology/

Anwendungspotenziale von Intelligenten Agenten in Service-orientierten Architekturen

Statisch

Dynamisch

Obligatorisch

Kommunikationssprache, technische Dienstbeschreibung (z.B. WSDL), QoS

Rollen, Ontologien, Gebühren, funktionale Eigenschaften

Optional

Interaktionsprotokolle Verhandlungsstrategien

Zugriffsrechte, org. Regelungen, alternative Dienste

177

Tab. 3-1: Klassifizierung von Geschäftsregeln im Kontext von Multiagentensystemen und SOA In Tab. 3-1 sind Beispiele für Regeln eines Dienstanbieters bzw. –nachfragers aufgeführt. So könnte ein Dienstnachfrager Mindestanforderungen an die Servicequalität oder die Höhe der zu entrichteten Gebühren festgeschrieben haben. Oder ein Dienstanbieter hat eine festgelegte Verhandlungsstrategie über Gebührenhöhe und Restriktionen über Zugriffsrechte auf bestimmte Datenbestände. In OCL würde exemplarisch eine Regel eines Dienstanbieters wie folgt formuliert:

context ServiceProvider inv: RulesSet.CommunicationLanguage = FIPA.ACL RulesSet.CommunicationLanguage.necessary = true RulesSet.NegotiationPolicy = FIPA.EnglishAuction RulesSet.NegotiationPolicy.necessary = true RulesSet.QoS = high RulesSet.QoS.necessary = false Abb. 3-1: Beispielhafte Regeln eines ServiceProviders in OCL Im Beispiel ist aufgeführt, dass der Agent des ServiceProviders als Kommunikationssprache des Agenten eines ServiceRequestors die FIPA Agent Communication Language voraussetzt, er die Verhandlung über Gebühren über eine Englische Auktion führt und der angebotene Service eine hohe Servicequalität aufweist. Da Servicequalität im o.g. Beispiel als unscharfe Variable ausgedrückt wird und grundsätzlich Bedenken bestehen, wenn der Dienstanbieter seinen eigenen Dienst hinsichtlich dieser Eigenschaft selbst bestimmt, sind wiederum Mechanismen erforderlich, die einerseits unscharfe Angaben verarbeiten können (z.B. mittels FuzzyAnsätzen [Niss2007]) und andererseits Dienste zertifizieren und so die Unabhängigkeit der Bewertung, beispielsweise der Servicequalität, sicherstellen. Aufgrund des Umfangs allein dieser Problematik muss im vorliegenden Beitrag allerdings auf eine detaillierte Untersuchung dieser interessanten Problemstellungen verzichtet werden.

178

Mathias Petsch, Volker Nissen, Timo Traub

context ServiceRequestor inv: RulesSet.CommunicationLanguage = FIPA.ACL RulesSet.CommunicationLanguage.necessary = true RulesSet.NegotiationPolicy = FIPA.EnglishAuction RulesSet.NegotiationPolicy.necessary = false RulesSet.QoS = high RulesSet.QoS.necessary = true Abb. 3-2: Beispielhafte Regeln eines ServiceRequestors in OCL Entsprechend zum Dienstanbieter verfügt der Dienstnachfrager ebenfalls über eine Regelmenge (siehe Abbildung 3-2), welche die zusätzlichen Anforderungen (neben der reinen Funktionalität) an einen Dienst determinieren. Der Abgleich der Regelmenge (siehe Abbildung 3-3) zwischen Dienstanbieter und Dienstnachfrager, die Aushandlung eventueller Spielräume z.B. der Gebühren eines Dienstes in Abhängigkeit der verfügbaren Qualitätsmerkmale, können entweder auf stark vereinfachte Art durch Matching der Regelmengen erfolgen. Dabei müssten, vereinfacht ausgedrückt, die Regelmengen im günstigsten Fall deckungsgleich sein. Oder es kommen komplexere Algorithmen, wie zum Beispiel Ansätze des Constraint Satisfaction Problems (CSP), kommen zum Einsatz (siehe auch [Pets2007]).

MAS::joinAgent(ServiceProvider:RulesSet, ServiceRequestor: RulesSet):boolean pre: ServiceProvider = ServiceRequestor post: ServiceContract=true Abb. 3-3: Regeldefinition eines vereinfachten Regelmatching in OCL Hierbei muss wieder betont werden, dass eine Grundvoraussetzung für die Regelverhandlung und den Regelabgleich eine vorab definierte Ontologie ist. Es muss unterschieden werden zwischen einer Ontologie, die die Objekte und Begrifflichkeiten der Regelverhandlung als solches enthält (z.B. Regelmenge, Verhandlung) und einer Ontologie, die die Inhalte der Regelmenge definiert (z.B. Qualitätsmerkmale von Diensten, Verfügbarkeit). Die schon erwähnte Open SOA Ontology (siehe Abbildung 3-4) bietet eine erste Grundlage für die Inhalte der Regelmenge, also den Verhandlungsgegenstand.

Abb. 3-4: Ausschnitt Open SOA Ontology [OPEN2007] Eine Ontologie als Voraussetzung zur Verhandlung könnte wie in Abbildung 3-5 in einem Klassendiagramm dargestellt werden und wird ausführlich in [Pets2007, 213] beschrieben.

Anwendungspotenziale von Intelligenten Agenten in Service-orientierten Architekturen

179

Abb. 3-5: Regelontologie Man beachte, dass für ObligationType (Regelinhalt, Pflichten) als Paket die Open SOA Ontology angegeben ist, die praktisch den Verhandlungsgegenstand darstellt. Alle anderen Objekte und Klassen beziehen sich vor allem auf administrative, also zur Verhandlung notwendige Inhalte, wie Kommunikationssprache, Agentenbeschreibung, Plattformbeschreibung, auszuhandelnder Vertrag (Contract) oder eventuelle Sanktionen, die bei Nichteinhaltung des Vertrages vollzogen werden können. Die Überwachung von Regelverstößen kann u.a. durch soziale Ansätze, wie Reputationsmechanismen [Pado2000] erfolgen.

4

Zusammenfassung und Ausblick

In dieser Arbeit konnte gezeigt werden, dass (Intelligente) Softwareagenten einen Erfolg versprechenden Ansatz für die Orchestrierung und generell die Behandlung des Dynamikaspektes von Service-orientierten Architekturen darstellen können. Eine notwendige Voraussetzung ist, dass semantische Beschreibungen von Diensten verfügbar sind. In diesem Zusammenhang wurden Ontologien vorgestellt, welche die Grundlage einer eindeutigen und zweifelsfreien semantischen Charakterisierung von Services sicherstellen können. Außerdem wurde ein Ansatz entwickelt, der auf Basis von Geschäftsregeln die Verhandlungen zwischen Agenten über die Nutzung von Diensten sowie deren Leistungsparameter und Nutzungskosten unterstützt. Insbesondere für die Orchestrierung und Komposition von Diensten, auf der Grundlage standardisierter Verhandlungsprotokolle und eindeutiger semantischer Beschreibungen von Diensten, sehen wir das größte Potenzial für den Einsatz von Softwareagenten in einer Service-orientierten Umgebung. Abzuwarten bleibt hingegen, ob in

180

Mathias Petsch, Volker Nissen, Timo Traub

Unternehmen eine hinreichende Akzeptanz für (teil-)autonome Ansätze in diesem Anwendungsfeld erreicht wird.

Literaturverzeichnis [ADKK+2005] Agarwal, V.; Dasgupta, K.; Neeran, K.; Kumar, A.; Kundu, A.; Mittal, S.; Srivastava, B.: A Service Creation Environment Based on End to End Composition of Web Services. In: WWW ’05: Proceedings of the 14th International Conference on World Wide Web, ACM Press: New York, 2005, S. 128–137. [BoGa1988] Bond, A.H.; Gasser, L.: Readings in Distributed Artificial Intelligence. Morgan Kaufmann Publisher: San Mateo 1988. [BrGr2005] Business Rules Group, http://www.businessrulesgroup.org, Abruf am 01. August 2007. [BVVe2003] Buhler, P.; Vidal, J.; Verhagen, H.: Adaptive Workflow = Web Services + Agents. In: Zhang, L. (Hrsg.): Proceedings of the International Conference on Web Services (ICWS 2003), Las Vegas (USA), June 2003, CSREA Press 2003, S. 131–137. [DiWo2005] Dickinson, I.; Wooldridge, M.: Agents are Not (Just) Web Services: Considering BDI Agents and Web Services. In: Proceedings of the Workshop on Service-Oriented Computing and Web Services (SOCABE’05), http://www.csc.liv.ac.uk/~mjw/pubs/ socabe2005.pdf, 2005, Abruf am 01. August 2007. [DjSa2006] Charif-Djebbar, Y.; Sabouret, N.: Dynamic Web Service Selection and Composition: An Approach Based on Agent Dialogues. In: Dan, A.; Lamersdorf, W. (Hrsg.): Service-Oriented Computing – ICSOC 2006. Springer: Berlin, 2006, S. 515-521. [Ferb2001] Ferber, J.: Multiagentensysteme: eine Einführung in die Verteilte Künstliche Intelligenz. Addison-Wesley: München, 2001. [FrGr1996] Franklin, S.; Graesser, A.: Is It an Agent, or Just a Program?: A Taxonomy for Autonomous Agents. In: Müller, J.P.; Wooldridge, M.J.; Jennings, N.R. (Hrsg.): Intelligent Agents III. Springer: Berlin, 1996, S. 21-35. [GrCa2004] Greenwood, D.; Callisti, M.: Engineering Web Service Agent Integration. In: Proceedings of IEEE conference of Systems, Man and Cybernatics 2004, http://www.whitestein.com/resources/papers/ieeesmc04.pdf, Abruf am 01. August 2007. [Grub1993] Gruber, T.R.: A Translation Approach to Portable Ontology Specifications. In: Knowledge Acquisition 2 (1993) 5, S.199-220. [Huhn2002] Huhns, M.N.: Agents as Web Services. In: IEEE Internet Computing, 4 (2002) 6, S. 93–96. [Huhn2006] Huhns, M.N.: A Research Agenda for Agent-Based Service-Oriented Architectures. In: Klusch, M.; Rovatsos, M.; Payne, T. (Hrsg.): Cooperative Information Agents (CIA ’06), Springer: Berlin, 2006, S. 8–22. [KBSL2005] Krafzig, D.; Banke, K., Slama, D.: Enterprise SOA – Service-Oriented Architecture Best Practices. Prentice Hall: Upper Saddle River, NJ, 2005. [KHLS2006] Kirn, S.; Herzog, H.; Lockemann, P.; Spaniol, O.: Multiagent Engineering. Theory and Applications in Enterprises. Springer: Berlin, 2006.

Anwendungspotenziale von Intelligenten Agenten in Service-orientierten Architekturen

181

[KiJi2006] Kim, I.; Jin, H.: An Agent System for Automated Web Service Composition and Invocation. In: Meersman, R.; Tari, Z. et al. (Hrsg.): Proceedings of the International Workshop On The Move To Meaningful Internet Systems (OTM 2006), Montpellier (France), Springer-Verlag: Berlin, 2006, S. 90–96. [KoTo2006] Korotkiy, M. and L Top, J.L.: Designing a Document Retrieval Service with OntoSOA. In: Proceedings of the Semantic Web Enabled Software Engineering Workshop at ISWC 2006. Athens, GA, U.S.A., 2006, http://km.aifb.unikarlsruhe.de/ws/swese2006/final/korotkiy_full.pdf, Abruf am 01. August 2007. [Lieb1997] Lieberman, H.: Autonomous Interface Agents. In: Proceedings of the Conference on Computers and Human Interface. ACM Press: New York, 1997, S. 67-74. [LMMa1994] Lashkari, Y.; Metral, M.; Maes, P.: Collaborative Interface Agents. In: Proceedings of the Twelfth National Conference on Artificial Intelligence, AAAI Press: Seattle, 1994, S. 444-449. [MKBr2006] Müller, I.; Kowalczyk, R.; Braun, P.: Towards Agent-Based Coalition Formation for Service Composition. In: Proceedings of the IEEE/ WIC/ACM International Conference on Intelligent Agent Technology (IAT ’06), IEEE Computer Society, Washington, 2006, S. 73–80. [NgKo2007] Nguyen, X.; Kowalczyk, R.: WS2JADE: Integrating Web Service with Jade Agents. In: Huang; J.; Kowalczyk, R.; Maamar, Z.; Martin, D.; Müller, I.; Stoutenburg, S.; Sycara, K. (Hrsg.): Service-Oriented Computing: Agents, Semantics, and Engineering. Springer-Verlag, Berlin, 2007, S. 147-159. [Niss2006] Nissen, V.: Prozessorientiertes Corporate Performance Measurement. In: Nissen, V.; Schneider, H. (Hrsg.): Prozessorientiertes Corporate Performance Measurement. Tagungsband zur Veranstaltung „Prozessorientiertes Corporate Performance Measurement“, Ilmenau, 2006, S. 3-26. [Niss2007] Nissen, V.: Management Applications of Fuzzy Control. In: Mitschele-Thiel, A. (Hrsg.): Proceedings of the 52nd International Scientific Colloquium, Ilmenau 2007 (zur Veröffentlichung angenommen). [NPTT2006] Negri, A.; Poggi, A.; Tomaiuolo, M.; Turci, P.: Agents for e-Business Applications. In: Stone, P.; Weiss, G. (Hrsg.): Proceedings of the Fifth International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS ’06). ACM Press: New York, 2006, S. 907–914. [OPEN2007] Opengroup. http://www.opengroup.org/projects/soa-ontology/. Abruf am 01. August 2007. [Pado2000] Padovan, B.: Ein Vertrauens- und Reputationsmodell für Multi-Agenten Systeme. Dissertation, Albert-Ludwigs-Universität Freiburg, http://www.freidok.uni-freiburg.de/ volltexte/166/, 2000, Abruf am 01. August 2007. [Pets2007] Petsch, M.: Offenheit von Multiagentensystemen - Eine integrative Betrachtung unter Berücksichtigung technischer, systemischer, sozialer und organisatorischer Aspekte. Josef Eul: Lohmar, 2007. [RKKr2007] Roillan, C.; Kaabi, R.S.; Kraiem, N.: On ISOA: Intentional Service Oriented Architecture. In: Krogstie, J.; Opdahl, A.; Sindre, G. (Hrsg.): Advanced Information System Engineering. Springer: Berlin, 2007, S. 158-172.

182

Mathias Petsch, Volker Nissen, Timo Traub

RLPB2007] Reinheimer, S.; Lang, F; Purucker, J.; Brügmann, H.: 10 Antworten zu SOA. In: Fröschle, H.; Reinheimer, S. (Hrsg.): Serviceorientierte Architekturen. HMD 253 (2007), S. 7-17. [Sied2007] Siedersleben, J.: SOA revisited: Komponentenorientierung bei Systemlandschaften. In: Wirtschaftsinformatik, Sonderheft (2007) 49, S. 110-117. [WoJe1995] Wooldridge, M.; Jennings, N.R.: Intelligent Agents: Theory and Practice. In: Knowledge Engineering Review 10 (1995) 2, S. 115-152. [Wool2002] Wooldridge, M.: An Introduction to Multi Agent Systems. John Wiley & Sons: Chichester, 2002. [W3C2002] Web Services Architecture. W3C Working Draft 14 November 2002, http://www.w3.org/TR/2002/WD-ws-arch-20021114/, 2002, Abruf am 01. August 2007. [ZBEF+2006] Zinnikus, I.; Benguria, G.; Elvesæter, B.; Fischer, K.; Vayssière, J.: A Model Driven Approach to Agent-Based Service-Oriented Architectures. In: Fischer, K.; Timm, I. J.; Andrè, E.; Zhong, N. (Hrsg.): Proceedings of the Fourth German Conference on Multiagent System Technologies (MATES 2006), September 2006, Springer: Berlin, 2006, S. 110–122.

Prozesscontrolling und Monitoring

Serviceorientiertes Prozesscontrolling – Unternehmensindividuelle Wirtschaftlichkeitsrechnungen zur Nutzung serviceorientierter Architekturen bei der Prozessgestaltung Jan vom Brocke, Christian Sonnenberg Zusammenfassung: Bei der Entscheidung über die Einführung einer Serviceorientierten Architektur (SOA) in einem Unternehmen sind neben technischen Aspekten insbesondere organisatorische Fragestellungen relevant. In einer prozessorientierten Sichtweise auf die SOA-Nutzung ergeben sich neuartige Gestaltungsoptionen für bestehende Geschäftsprozesse, die hinsichtlich ihrer Wirtschaftlichkeit zu bewerten sind. Hierzu ist es allerdings erforderlich, die unternehmensindividuelle Entscheidungssituation zu berücksichtigen und adäquat in die Bewertung einzubeziehen.

1

Bedeutung Serviceorientierte Architekturen für die Prozessgestaltung

Mit der Entwicklung Serviceorientierter Architekturen (SOA) wird angestrebt, Anwendungssysteme aus Teilsystemen zusammenzusetzen, die eine spezifische Dienstleistung zur Verfügung stellen und lose miteinander gekoppelt werden [Leym2003, 20]. Die »lose Kopplung« kommt darin zum Ausdruck, dass die Teilsysteme nicht an einzelne Anwendungssysteme gebunden sind, sondern vielmehr zur Ausführung von Prozessen mehrerer Anwendungssysteme zur Verfügung stehen. Für den Dienstaustausch dienen Web Service-Standards. Als Basisstandards gelten WSDL zur Beschreibung von Services [W3C2006], UDDI zum Aufbau von Serviceverzeichnissen [BCEH2003] und SOAP für den Nachrichtenaustausch [GHMM2003]. Zur betrieblichen Nutzung von Web Services etablieren sich weitere Standards wie OWL-S für die Fachspezifikation von Services [BDEM2006] und WS-BPEL für deren prozessorientierte Komposition [AAAB2006]. Durch die Entwicklung serviceorientierter Produktvarianten von Anbietern betrieblicher Standardsoftwareprodukte wird SOA für Unternehmen entscheidungsrelevant. Beispiele für Systeme sind »e Business on demand« [IBM2004], »Oracle SOA Suite« [Orac2004] und »Sonic ESB« [Crag2003]. Auch bei SAP® vollzieht sich bereits die Ablösung des bislang in über zwei Millionen Installationen eingesetzten Produkts »R/3« durch die auf Basis der »Netweaver™Technologie« basierenden Lösung »Enterprise SOA« [SAP2006]. Die Prinzipien der Anwendungssystemgestaltung bei SOA sind in Abb. 1-1 durch Gegenüberstellung mit der nicht-serviceorientierten Situation veranschaulicht worden. In der herkömmlichen Situation werden bereits zur Entwicklungszeit des Anwendungssystems Annahmen über die zu unterstützenden Prozesse getroffen, die in der Applikationsschicht der Systeme implementiert werden [WeVo2002, 16-21]. Die realisierten Prozesse setzen zugleich einen Rahmen für die Gestaltung und Ausführung von Prozessen des Organisationssystems. Dieser Rahmen kann positiv wirken, sofern die Organisationsgestaltung von einer in den Anwendungssystemen implementierten „Best Practice“ profitiert [Scho1990, 31]. In dem damit verbundenen

186

Jan vom Brocke, Christian Sonnenberg

Reorganisationspotenzial wird mithin ein Vorteil für die Einführung betrieblicher Standardsoftwareprodukte gesehen [BeKa2005, 12].

Abb. 1-1: Einfluss von SOA auf die Informationssystementwicklung Um im Wechselspiel zugleich die spezifischen organisatorischen Anforderungen berücksichtigen zu können, werden in Standardsoftwareprodukten Möglichkeiten zum »Customizing« gegeben. Auf der Grundlage konfigurativer Referenzmodelle können vom Nutzer Auswahlentscheidungen über alternative Verfahren getroffen werden [vADG2005]. Aufgrund der zunehmenden Heterogenität situativer Anforderungen gelingt es aber immer seltener, eine für die spezifische Unternehmenssituation angemessene Variante des Anwendungssystems abzuleiten [vBro2003, 38]. Die durch das Anwendungssystem vorgegebenen Rahmenbedingungen können sich somit auch negativ auswirken, da ein zu geringer Abdeckungsgrad der organisatorischen Anforderungen gegeben ist. Durch SOA können die von Anwendungssystemen auf die Organisationsgestaltung ausgehenden Restriktionen aufgebrochen werden. Eine Trennung zwischen der Ablauflogik und der Ablaufsteuerung in Anwendungssystemen [Leym2003, 13] erlaubt es, Prozesse auch während der Systemnutzung sowohl strukturell als auch institutionell weiterzuentwickeln. Das Leitbild der SOA-Entwicklung besteht darin, das Anwendungssystem der Unternehmung geradezu erst zur Laufzeit zusammenzustellen, indem situationsgerechte Services über das Internet bezogen werden [Leym2003, 20; Reic2003, 100]. Die enorme Verbreitung von SOA versetzt Entscheidungsträger in Unternehmen heute in die Situation, zu beurteilen, ob eine derartige Systemarchitektur für sie von Vorteil ist, bzw. wie sie aus dieser Technologie Vorteile entwickeln können. Studien von ERP-Systemanbietern, aber auch von unabhängigen Forschungsinstitutionen, versprechen hohe Rentabilitäten. FORRESTER prognostiziert, dass Unternehmen durch die Einführung von SOA Kosteneinsparungen in Höhe von „wenigstens 30%“ realisieren können [VoGi2004]. IDC-Studien zu SOA-Projekten weisen einen ROI

Serviceorientiertes Prozesscontrolling

187

von 308% bei GOODYEAR [Wang2004b] sowie von 453% bei SASOL aus [Wang2004a]. NUCLEUS RESEARCH ermittelt einen „Annual ROI“ und bewertet SOA-Projekte bei VECTREN CORPORATION mit 141% p. a. [Nucl2004, 4] und beim MILTON KEYNES GENERAL HOSPITAL mit 61% p. a. [Nucl2005, 5]. Zu beachten ist jedoch, dass die Ergebnisse dieser Fallstudien nicht ohne weiteres auf andere Anwendungsgebiete übertragen werden können. Erschwerend kommt hinzu, dass die ROI-Berechnung teilweise nicht nachvollziehbar bzw. betriebswirtschaftlich problematisch ist. In gesonderten Forschungsarbeiten sind daher Methoden untersucht worden, mit denen die Wirtschaftlichkeit des SOA-Einsatzes im unternehmensindividuellen Kontext beurteilt werden kann [vBLi2004; vBro2006; vBro2007]. Während sich die bisherigen Beiträge vornehmlich auf die Konzeption und Spezifikation von Methoden konzentrieren, soll mit diesem Beitrag ein geschlossenes Demonstrationsbeispiel geliefert werden. Untersucht werden Methoden für ein Serviceorientiertes Prozesscontrolling (sog. SOPC-Methoden) [vBro2006]. Zielsetzung ist die Prüfung der Methoden im Sinne eines gestaltungsorientierten Forschungsprozesses [MaSm1995; Simo1996; HMPR2004]. Im folgenden Kapitel werden SOPC-Methoden zunächst in Grundzügen vorgestellt. Den Hauptteil des Beitrags nimmt die Darlegung der Berechnungen im Demonstrationsbeispiel ein. Schließlich können einige Erkenntnisse zur Weiterentwicklung des Methodensystems zusammengefasst werden.

2

Grundzüge von Methoden für das Serviceorientierte Prozesscontrolling

2.1

Ordnungsrahmen

Bei SOPC-Methoden wird von einer prozessorientierten Sichtweise auf die Nutzung von SOA ausgegangen, die in einem Serviceorientierten Prozessdesign zum Ausdruck kommt. Die Serviceorientierung macht es möglich, Prozesse als »Service Portfolios« zu entwerfen und situativ zu adaptieren. Dies bedeutet, Prozesse hinsichtlich ihrer abstrakten Struktur zu gestalten und für einzelne Aktivitäten alternative Formen der Institutionalisierung auszuwählen. Ein »Service Portfolio« bezeichnet die Menge an Services, die zu einer Zeit über eine spezifische Infrastruktur zur Ausführung von Aktivitäten in Prozessen zu verwenden sind. Die Bestandteile sind wie folgt zu konkretisieren. x

Aktivität: Teilschritt eines Prozesses, mit dem eine einzelne Zustandsveränderung beschrieben wird. Aktivitäten können ablauflogisch miteinander verbunden und selbst als Prozess verfeinert werden.

x

Service: Alternative zur Ausführung einer Aktivität, die unterschiedliche Institutionalisierungsformen aufweisen können. Insbesondere ein Vergleich zwischen internen und externen sowie automatisierten und nicht-automatisierten Services ist anzustellen.

x

Infrastruktur: Sämtliche institutionellen Voraussetzungen, die zur Integration der Services im Prozess erforderlich sind. Zu berücksichtigen sind auch nicht-technische Voraussetzungen, die z.B. organisatorische Aspekte der Serviceintegration betreffen.

188

Jan vom Brocke, Christian Sonnenberg

Die Gestaltung von Prozessen bei SOA erfolgt durch »Konfiguration des Service Portfolios«. Hiermit wird zum Ausdruck gebracht, dass die Gestaltung vornehmlich durch Auswahlentscheidungen vorgenommen wird [vADG2005]. Im Einzelnen kennzeichnet die Konfiguration die situative Zusammenstellung an »Aktivitäten« zur Erfüllung einer organisatorischen Aufgabe sowie die Auswahl an »Services« und relevanten Elementen einer »Infrastruktur« zu deren Ausführung. Als Idealtypen werden Anwendungsfälle des »Outsourcing«, »Integration« und »Networking« unterschieden [vBro2006]. Die zielgerichtete Ausnutzung dieser Möglichkeiten erfordert aber Kenntnisse über die wirtschaftlichen Konsequenzen einzelner Gestaltungsentscheidungen im unternehmensindividuellen Kontext. Hierzu dient ein Serviceorientiertes Prozesscontrolling (SOPC), das eine Entscheidungsunterstützung bei der Konfiguration von Service Portfolios liefern soll. Die Grundidee der methodischen Unterstützung besteht darin, Prozessmodelle als Grundlage der Bewertung heranzuziehen, die derart aufbereitet werden, dass einzelne Gestaltungsentscheidungen unmittelbar in ökonomischen Zielwerten gespiegelt werden. Hierzu werden Prozessmodelle um Gestaltungsoptionen bei SOA erweitert und hinsichtlich ihrer wertmäßigen Konsequenzen spezifiziert, die über ein Prozesskennzahlensystem zu Zielwerten verdichtet werden. Aufgrund der Langfristigkeit der ökonomischen Konsequenzen sind im Rechensystem Methoden des Investitionscontrollings verankert, mit denen finanzwirtschaftliche Zielwerte ermittelt werden können. Beispiele sind die »Total Cost of Ownership (TCO)« oder der »Return on Investment (ROI)« eines Service Portfolios. Auf diese Weise wird es möglich, experimentelle Rekonfigurationen von Service Portfolios vorzunehmen, die direkt in ihren wirtschaftlichen Konsequenzen in spezifischen Entscheidungssituationen nachvollzogen werden können. Ein Ordnungsrahmen für SOPC-Methoden ist in Abb. 2-1 dargestellt worden.

4 Prozessvergleich

1

2 nicht -monetäre Bewertung

3 monetäre Bewertung

Kennzahlenbildung

Aktivität

Infrastruktur

Service

Abb. 2-1: Ordnungsrahmen für SOPC-Methoden

Serviceorientiertes Prozesscontrolling

189

Der Ordnungsrahmen differenziert zwischen dem Objekt- und Zielsystem des Controllings, die in einer zweidimensionalen Struktur miteinander in Beziehung gesetzt werden. Als Controllingobjekt sind Prozesse zu untersuchen, die selektiv hinsichtlich relevanter Aktivitäten, Services und Infrastrukturen gestaltet werden können. Die Methode setzt hier auf vorhandenen Prozessmodellen auf, die in unterschiedlichen Sprachen vorliegen können. Sie werden im Hinblick auf spezifische Controllingziele untersucht, gegenüber denen die Prozesse zu bewerten sind. Folgende Teilbereiche werden unterschieden: x

Nicht-monetäre Bewertung: Die nicht-monetäre Bewertung dient der Abbildung relevanter Rahmenbedingungen der Prozessgestaltung. Berücksichtigt werden sowohl quantitative als auch qualitative Aspekte. In quantitativer Hinsicht sind die Ausführungshäufigkeiten einzelner Aktivitäten zu ermitteln, die das Mengengerüst der monetären Bewertung liefern. In qualitativer Hinsicht sind zudem fachliche Anforderungen an die Gestaltung zu erfassen. Auf der Grundlage der Fachspezifikation von Aktivitäten und Services kann eine Selektion von Services nach spezifischen Anspruchsniveaus erfolgen.

x

Monetäre Bewertung: In der monetären Bewertung sind die durch eine Prozessgestaltung verursachten Zahlungen zu erfassen. Hierzu findet eine monetäre Bewertung einzelner Gestaltungsoptionen auf Service-, Infrastruktur- und Aktivitätsebene statt, die über den Gesamtprozess zu aggregieren sind. Zahlungen für extern bezogene Services werden z.B. auf Basis von Konditionenmodellen bemessen, während interne Services nach Maßgabe der unternehmensspezifischen Ressourceninanspruchnahme berechnet werden. Aufgrund der Langfristigkeit der mit Gestaltungsentscheidungen verbundenen Konsequenzen erfolgt eine mehrperiodige Planung und Kalkulation der Zahlungen.

x

Kennzahlenbildung: Die erfassten Zahlungen sind zu aussagekräftigen Zielwerten zu verdichten. Anhand eines Prozesskennzahlensystems werden sowohl originäre als auch derivative Zahlungen analysiert. Die Analyse originärer Zahlungen zeigt relevante Zahlungstreiber einer serviceorientierten Gestaltung auf und stellt deren Einfluss auf die Gesamtzahlungsfolge eines Prozesses dar. Im Bereich der derivativen Zahlungen wird das Kennzahlensystem um finanzwirtschaftliche Konsequenzen erweitert. Auf Basis unternehmensindividueller Konditionen können die mit dem Zu- und Abfluss originärer Zahlungen verbundenen Zahlungswirkungen untersucht werden, in die auch steuerliche Aspekte einzubeziehen sind. Ausgewiesen werden finanzwirtschaftliche Zielwerte, wie die TCO und der ROI, die Spitzenkennzahlen des Prozesskennzahlensystems bilden.

x

Prozessvergleich: Auf Basis der Zielwerte können Prozessvarianten alternativer Service Portfolio-Konfigurationen miteinander verglichen werden. Durch diesen Vergleich wird der Wert einzelner Konfigurationen von Service Portfolios aus Sicht des Entscheidungsträgers quantifiziert. Zur Analyse können sowohl Optimierungsläufe durchgeführt als auch experimentelle Prozessvergleiche angestellt werden. Letztere ermöglichen es z.B., eine Modifikation des fachlichen Anspruchsniveaus vorzunehmen und die daraus resultierenden Konsequenzen auf die originären und derivativen Zahlungen zu analysieren. Hierdurch kann Transparenz über die monetären Konsequenzen von Gestaltungsentscheidungen gewonnen werden, die in eine ganzheitliche Planung der Prozessgestaltung einzubeziehen sind.

190

Jan vom Brocke, Christian Sonnenberg

Der Ordnungsrahmen liefert eine generelle Struktur für die Bewertung von Prozessen hinsichtlich der zu ihrer Gestaltung zu wählenden Service Portfolios. Die einzelnen Teilbereiche sind genauer zu spezifizieren, bevor Vorgehensmodelle zur Nutzung der Methode für spezifische Anwendungsfälle erarbeitet werden können. Für die Spezifikation stellen sich besondere Anforderungen aus Sicht der Methodenentwicklung.

3

Demonstrationsbeispiel zu den Methoden für das Serviceorientierte Prozesscontrolling

3.1

Ausgangssituation

Die skizzierten SOPC-Methoden sollen am Beispiel des Demonstrationsunternehmens DECIS, ein Akronym für »Demonstrating the Economic Impact of Service Orientation«, veranschaulicht werden. DECIS liefert eine Unternehmenssituation, die zur Analyse der Wirtschaftlichkeit des SOA-Einsatzes im Internet aufgebaut wird (www.decis.org). Organisatorisch ist DECIS ein Unternehmen der Touristikbranche, das kundenindividuelle Zusammenstellungen von Reisen anbietet. Der beschriebene Fall ist auf Basis von Projekterfahrungen rekonstruiert worden. Am Beispiel von DECIS sollen die SOPC-Methoden für den Anwendungsfall »Integration« nachvollzogen werden. Hierunter wird eine Form der Konfiguration des Service Portfolios verstanden, bei dem Dienste aus verschiedenartigen Informationssystemen in einem hybriden System miteinander zu verbinden [vBro2006]. Speziell wird ein Fall der innerbetrieblichen Integration betrachtet, bei der nach Prinzipien der »Enterprise Application Integration (EAI)«, die Integration heterogener Informationssysteme im Mittelpunkt steht [ScWi2002]. Empirische Untersuchungen zu Web Services zeigen, hierin über alle Branchen bislang die überwiegende Form der SOANutzung zu sehen ist [PrSa2005]. Bei DECIS sind auf Basis von Prozessmodellen an mehreren Stellen Integrationspotenziale durch den SOA-Einsatz identifiziert worden. Zur weiteren Fundierung der Entscheidung sollen jedoch die damit verbundenen monetären Konsequenzen genauer untersucht werden. Die Ergebnisse werden im Folgenden anhand des Prozesses der »Dialogmarketingplanung« vorgestellt. Dieser Prozess wurde bereits erhoben und liegt in Form von ereignisgesteuerten Prozessketten (EPK) vor (vgl. [KNSc1992]). Er ist in Abb. 3-1 dargestellt worden. Im Zuge der »Dialogmarketingplanung« werden ausgewählte Kunden durch individuelle Marketingmaßnahmen angesprochen [Meff2002]. Zur Abwicklung des Prozesses werden ein Data Warehouse-System (DWH-System) und ein Customer Relationship Management-System (CRM-System) eingesetzt. In beiden Systemen werden Kundendaten vorgehalten, die bislang unzureichend ineinander integriert sind. Die Kundendaten des DWH-Systems entstammen den operativen Systemen und werden aus den Kundentransaktionen gewonnen. Die Daten im CRM-System werden dagegen in Kundengesprächen aufgenommen und weisen keinen eindeutigen Bezug zu Kundentransaktionen auf.

Serviceorientiertes Prozesscontrolling

191

Abb. 3-1: Prozessmodell »Dialogmarketingplanung« bei DECIS Der Prozess beginnt mit der Selektion einer Kundengruppe, für die eine Marketingmaßnahme zu planen ist. Über das selbst entwickelte DWH-System werden hierzu Selektionskriterien erfasst, durch die geeignete Zielgruppen erstellt werden. Nach Auswahl der Adressaten ist die Aktualität und Validität der Kundendaten zu prüfen. Diese Prüfung ist notwendig, da Abweichungen zwischen den im DWH-System vorliegenden und den im CRM-System erfassten Daten vorliegen können. Für die Prüfung sind Abfragen über die Kundendaten im CRM-System vorzunehmen. Sie liefern Ergebnislisten, die mit den vom DWH-System ausgewiesenen Kundendaten zu vergleichen sind. Die Kundendaten sind in 70% der Prüfungen aktuell und können als Grundlage der weiteren Planung dienen. In 30% der Fälle, treten jedoch Inkonsistenzen auf, die korrektive Maßnahmen erfordern. Die wiederholte Prüfung fällt in den überwiegenden Fällen positiv aus, sodass keine bedingten Wahrscheinlichkeiten für die Berechnung zu berücksichtigen sind. Auf Basis der Kundendaten wird ein

192

Jan vom Brocke, Christian Sonnenberg

Kundenprofil erstellt, aus dem die für die Maßnahme relevanten Daten ersichtlich sind. Es umfasst insbesondere Umsätze, Reisezielpräferenzen sowie Hinweise von Mitarbeitern aus Beratungsgesprächen. Sobald ein Kundenprofil konzipiert wurde, kann der Kundenberater eine individuelle Werbemaßnahme erstellen. Das CRMSystem liefert hierzu Vorschläge auf Basis vergangener Planungen. Im Ergebnis entsteht ein kundenindividueller Maßnahmenplan, der konkrete Kommunikationsinhalte umfasst. Die Planung wird mit der Erstellung einer Dokumentation abgeschlossen. Sie enthält neben einem Zeitplan auch eine Kostenschätzung und wird zur weiteren Bearbeitung im CRM-System hinterlegt. Für Planungszwecke sind zudem die Kostenschätzungen in das DWH-System zu übertragen. Integrationspotenziale wurden für Prozessaktivitäten identifiziert, bei denen ein manueller Abgleich zwischen Datenbeständen des DHW-Systems und des CRMSystems erforderlich ist. Im Prozessmodell aus Abb. 3-1 wurden die Aktivitäten mit einem entsprechenden Integrationsdefizit farblich gesondert hervorgehoben. 3.2

Möglichkeiten für den Einsatz von SOA

Mit dem Einsatz von SOA wird erwogen, eine Integration des DWH- und CRMSystems auf Datenebene zu realisieren. Hierbei ist geplant, einen Web-Service zu entwickeln, der als Wrapper fungiert [Kell2002, 123; SnSn2003, 36 - 38] und eine integrierte Speicherung der Kundendaten im DWH- und CRM-System gewährleistet. Im Prozess »Dialogmarketingplanung« sollen auf diese Weise die im DWH-System selektierten Kundendaten automatisch dem CRM-System zur Verfügung gestellt werden. Hierdurch eröffnen sich für DECIS mehrere Reorganisationsmöglichkeiten im Prozess der »Dialogmarketingplanung«, die sowohl die Eliminierung wesensabhängiger Aktivitäten als auch die Effizienzsteigerung wertabhängiger Aktivitäten umfassen. Bei integrierter Datenhaltung erübrigen sich die beschriebenen Prüf- und Korrekturaufgaben, sodass die damit verbundenen Tätigkeiten eingespart werden können. Zudem ergeben sich Arbeitserleichterungen bei der Archivierung des Maßnahmenplans, da hier die manuelle Datenübertragung in das CRM-System entfällt. Nach Eliminierung der wesenabhängigen Aktivitäten »Kundendaten prüfen« und »Kundendaten korrigieren« ergibt sich das in Abb. 3-2 dargestellte Sollmodell des Planungsprozesses. Durch die Eliminierung der Aktivitäten »Kundendaten prüfen« und »Kundendaten korrigieren« sowie der Effizienzsteigerung in der Ausführung der Aktivität »Maßnahme archivieren« ergeben sich Einsparungsmöglichkeiten. Zur wirtschaftlichen Bewertung des Ersparnispotenzials wird, dem Differenzkalkül folgend, die Kalkulation auf die von Änderungen betroffenen Aktivitäten und die relevanten Infrastrukturmaßnahmen beschränkt. Dazu sind jedoch separate Untersuchungen der relevanten Aktivitäten in der bisherigen Organisationsform (Without-Fall) sowie in der SOAbasierten Prozessvariante (With-Fall) anzustellen.

Serviceorientiertes Prozesscontrolling

193

Abb. 3-2: Sollmodell »Dialogmarketingplanung« bei DECIS nach Integration 3.3

Bewertung relevanter Services im »Without-Fall«

Zur Bewertung der relevanten Prozessaktivitäten sind die zur Ausführung vorgesehenen internen Services zu untersuchen, die ressourcenorientiert zu kalkulieren sind. Die Untersuchung beinhaltet sowohl eine nicht-monetäre als auch eine monetäre Bewertung. Zunächst sind im Rahmen einer nicht-monetären Bewertung die Ausführungshäufigkeiten der am Prozess beteiligten Aktivitäten zu ermitteln, um so das Mengengerüst für die monetäre Bewertung zu erhalten. Der Prozess »Dialogmarketingplanung« findet vierteljährlich jeweils für eine ausgewählte Kundengruppe statt. Durchschnittlich werden 100 Kunden einer Kundengruppe für eine »Dialogmarketingplanung« berücksichtigt. Somit wird der hier betrachtete Prozess jährlich etwa 400 Mal ausgeführt. Angesichts einer geplanten Intensivierung der Kundenbindungsmaßnahmen ist von einer jährlichen Steigerungsrate von ca. 20% auszugehen. Die Prozess- und Aktivitätshäufigkeiten sind in Abb. 3-3 ausgewiesen worden.

194

Jan vom Brocke, Christian Sonnenberg

Abb. 3-3: Prozesshäufigkeit »Dialogmarketingplanung« im Planungshorizont Für die monetäre Bewertung der Ersparnis sind die Ausführungshäufigkeiten der Aktivitäten »Kundendaten prüfen«, »Kundendaten korrigieren« sowie »Maßnahme archivieren« relevant. Zu Beginn der monetären Bewertung sind die Verrechnungssätze der in Anspruch genommenen Ressourcen zu kalkulieren, um die Servicezahlungen im Status Quo bestimmen zu können. Anschließend werden weitere Zahlungen auf Infrastrukturebene erfasst. Zahlungen auf Aktivitätsebenen, die z.B. aus den Systemverfügbarkeiten resultieren könnten, erweisen sich nicht als entscheidungsrelevant, da die Integrationsentscheidung auf sie keinen Einfluss hat. x

Serviceebene

Zur Kalkulation der Services sind das DWH- und das CRM-System sowie die Stelle des Kundenbetreuers zu untersuchen, deren Verrechnungssätze angebotsorientiert kalkuliert werden sollen. Die Berechnung ist in Abb. 3-4 zusammengefasst worden.

Abb. 3-4: Ermittlung der Ressourcenverrechnungssätze für den Prozess »Dialogmarketingplanung« im Without-Fall Ein Kundenbetreuer bei DECIS hat ein Bruttoarbeitsvolumen von etwa 1.720 Stunden pro Jahr. Grundlage der Kalkulation ist eine Arbeitszeit von 40 Stunden pro Woche, von denen für die reine Arbeitstätigkeit (bspw. durch krankheitsbedingte Ausfälle) durchschnittlich jedoch nur 37 Stunden pro Woche angesetzt werden (1.920 Stunden/ Jahr = 37 Stunden/ Woche • 52 Wochen/Jahr). Vom Bruttoarbeitsvolumen sind die zu gewährenden Urlaubsstunden abzuziehen. Werden einem

Serviceorientiertes Prozesscontrolling

195

Kundenbetreuer fünf Urlaubswochen gewährt, so entspricht dies 200 Stunden (= 40 Stunden pro Woche • 5 Wochen). Somit steht ein Kundenbetreuer jährlich 1.720 Stunden (= 1.920 Stunden – 200 Stunden) zur Verfügung. Die jährlichen Lohnkosten für einen Kundenbetreuer betragen 90.000 €. Zu erwarten ist ein Anstieg der Lohnkosten um 1,5% pro Jahr. Für den Betrieb des DWH-Systems werden bislang jährlich Auszahlungen in Höhe von 20.000 € veranschlagt. Diese Auszahlungen leiten sich aus einer in der Vergangenheit durchgeführten TCO-Analyse ab. Der größte Anteil dieser Auszahlungen resultiert aus Lizenzzahlungen. Das DWH-System weist de facto eine Verfügbarkeit von 99% auf. Dies entspricht einer täglichen Verfügbarkeit von 23,76 Stunden und jährlichen Kapazität von rund 7.983 Stunden, sodass sich ein Verrechnungssatz von 2,51 € pro Stunde ergibt. Das CRM-System ist für DECIS von strategischer Bedeutung, da hierin eine Möglichkeit zur intensiven Kundenbetreuung gesehen wird. Das System ist daher ursprünglich als Individualsoftware entwickelt worden und wird mittlerweile in Eigenleistung erweitert und angepasst. Als repräsentative Zahlung für die damit verbundenen Kosten sind 40.000 € pro Jahr anzusetzen. Aufgrund der regelmäßigen Arbeiten am Softwaresystem weist das CRM-System lediglich eine Verfügbarkeit von 95% auf. Dies entspricht einer Verfügbarkeit von 22,8 Stunden pro Tag und 7.661 Stunden pro Jahr. Als Verrechnungssatz sind somit 5,22 € pro Stunde anzusetzen. Anhand der Aktivitäten »Kundendaten korrigieren« und »Maßnahme archivieren« soll im Folgenden die Kalkulation der Servicezahlungen detailliert veranschaulicht werden. Die Kalkulation für die Aktivität »Kundendaten prüfen« erfolgt analog. Die Prüfung der Kundendaten erfolgt durch den Kundenbetreuer, der hierzu das CRM-System nutzt. Die Arbeit nimmt durchschnittlich 45 Minuten in Anspruch, die vereinfachend sowohl zur Verrechnung der Mitarbeiterarbeitszeit als auch der Nutzungszeit des CRM-Systems anzusetzen sind. Unter Rückgriff auf die Ressourcenverrechnungssätze ergeben sich somit in der ersten Periode Zahlungen in Höhe von 39,24 € für die Arbeitskraft (= 0,75 Stunden • 52,33 € pro Stunde) und 3,92 € für die Systemnutzung (= 0,75 Stunden • 5,22 € pro Stunde). Insgesamt sind für die Korrektur der Kundendaten somit Zahlungen in Höhe von 43,16 € anzusetzen. Das Mengengerüst zur Ermittlung der Zahlungen in Form von Prozesshäufigkeiten wurde bereits im Rahmen der nicht-monetären Bewertung ermittelt (siehe Abb. 3-3). Die periodenindividuellen Ausführungshäufigkeiten der Aktivität »Kundendaten korrigieren« errechnen sich anhand einer multiplikativen Verknüpfung der relativen Aktivitätshäufigkeit und der periodenspezifischen Prozesshäufigkeiten. Aus dem Prozessmodell in Abb. 3-1 geht hervor, dass die Korrektur der Kundendaten in 30% der Prozessausführungen erforderlich ist. Dies stellt gleichzeitig die relative Aktivitätshäufigkeit für die Aktivität »Kundendaten korrigieren« dar. Für den betrachteten Service ergibt sich somit in der ersten Periode eine absolute Ausführungshäufigkeit von insgesamt 120 Transaktion (= 30% • 400 Prozessausführungen). Zur Archivierung einer Maßnahme benötigt ein Kundenbetreuer durchschnittlich 15 Minuten. Hierbei nutzt er das CRM-System etwa fünf Minuten und das DWH-System zehn Minuten. Insgesamt sind für die Archivierung eines Maßnahmenplans in Periode eins 13,94 € anzusetzen, von denen 13,08 € auf die Mitarbeiterzeit (= 0,25 Stunden • 52,33 € pro Stunde) sowie 0,43 € auf die Nutzung des CRM-Systems (= 0,083 Stunden • 5,22 € pro Stunde) und 0,43 € auf die Nutzung des DHW-Systems entfallen (= 0,17 Stunden • 2,51 € pro Stunde). Unter Berücksichtigung der

196

Jan vom Brocke, Christian Sonnenberg

Ausführungshäufigkeit der Aktivität pro Periode ergeben sich die in der Planung anzusetzenden Zahlungen im Planungshorizont, die in der ersten Periode –5.576 € betragen.

Abb. 3-5: Zahlungen auf Serviceebene über die relevanten Aktivitäten im Prozess »Dialogmarketingplanung« bei DECIS im Without-Fall x

Infrastrukturebene

In der bei DECIS untersuchten Entscheidungssituation sind auch auf Infrastrukturebene Zahlungen zu berücksichtigen, die bei Fortführung des Status Quo zu erwarten sind. Dabei handelt es sich um Zahlungen für die Adaption der Infrastruktur, die im Falle der SOA-Einführung obsolet wären. Die Adaptionen betreffen ein Konvertierprogramm, dessen Funktion kurz zu beschreiben ist. Um die Kundendaten zu verwalten, greift DECIS auf vorhandene Schnittstellen des DWH- und CRM-Systems zurück. So ist es möglich, selektierte Kundendaten aus dem DWH-System in verschiedenen Dateiformaten zu exportieren. Zudem existiert eine Schnittstelle für den Datenimport in das CRM-System, die sich jedoch auf eine

Serviceorientiertes Prozesscontrolling

197

geringe Anzahl weniger komplexer Dateiformate beschränkt (z.B. kommaseparierte Dateien). Während der Export von Kundendaten aus dem DWH mit anschließendem Import in das CRM-System gut funktioniert, gestaltet sich umgekehrt der Export von Kundendaten aus dem CRM-System mit anschließendem DWH-Import vergleichsweise schwierig. Dies liegt daran, dass die einfachen Dateiformate zwar gut strukturiert sind, jedoch kaum Möglichkeiten bieten, um die CRM-spezifischen Daten unmittelbar dem DWH-Kontext zuzuführen. Die Aufgabe des Konvertierungsprogramms besteht darin, die Exportdateien derart zu transformieren, dass sie in das DWH-Schema eingelesen werden können.

Abb. 3-6: Zahlungen auf Infrastrukturebene im Prozess »Dialogmarketingplanung« bei DECIS im Without-Fall Das Konvertierungsprogramm muss regelmäßig an Versionsänderungen des DWHoder CRM-Systems sowie an Schemaänderungen im DWH-System angepasst werden. Die mit diesen Anpassungen verbundenen Zahlungen in Höhe von 5000 € sind anhand einer in Abb. 3-6 dargestellten Infrastrukturschablone erfasst worden. Zahlungen für die Entwicklung des Programms sind bereits in der Vergangenheit angefallen und somit nicht entscheidungsrelevant. Zahlungen für den Betrieb, sowie die Desintegration sind aus Gründen der Geringfügigkeit zu vernachlässigen. 3.4 x

Bewertung relevanter Services im »With-Fall« Serviceebene

Hinsichtlich der wertabhängigen Aktivität »Maßnahme archivieren« ist zur Erfassung der Reorganisationsmöglichkeiten eine Neukalkulation des internen Services vorzunehmen. Die Kalkulation ist anhand von Abb. 3-7 nachzuvollziehen und wird nun erläutert. Ursprünglich benötigte ein Kundenbetreuer zur Archivierung einer Maßnahme durchschnittlich 15 Minuten. Da durch den Wrapper die im DWH-System selektierten Kundendaten automatisch im CRM-System zur Verfügung stehen, beschleunigt sich die Ausführung der Aktivität um durchschnittlich fünf Minuten. Die Auswirkungen betreffen sowohl die Arbeitszeit des Mitarbeiters als auch die Nutzungszeiten des CRM- und DWH-Systems. Insgesamt sind für die Archivierung einer Maßnahme in Periode eins jetzt 9,54 € anzusetzen, von denen 8,90 € auf die Mitarbeiterzeit (= 0,17 Stunden • 52,33 € pro Stunde) sowie 0,43 € auf die Nutzung des CRM-Systems (= 0,17 Stunden • 5,22 € pro Stunde) und 0,21 € auf die Nutzung des DHW-Systems (= 0,083 Stunden • 2,51 € pro Stunde) entfallen. Unter Berücksichtigung der Ausführungshäufigkeit der Aktivität pro Periode ergeben sich die in der Planung anzusetzenden Zahlungen im Planungshorizont, die z.B. in der ersten Periode jetzt – 3.815 € betragen.

198

Jan vom Brocke, Christian Sonnenberg

Abb. 3-7: Neuberechnung der Zahlungen auf Serviceebene zur Ausführung der Aktivität »Maßnahme archivieren« x

Infrastrukturebene

Zur Realisierung der Datenintegration sind spezifische Integrationsmaßnahmen in der Prozessgestaltung vorzusehen. Sie bestehen hier in der Entwicklung eines als Wrapper einzusetzenden Web Services sowie den damit verbundenen Reorganisationsmaßnahmen. Die einhergehenden Zahlungen sind anhand der von DECIS verwendeten Infrastrukturschablone geplant und in Abb. 3-8 dargestellt worden.

Abb. 3-8: Zahlungen auf Infrastrukturebene zur Integrationsförderung im Prozess »Dialogmarketingplanung« bei DECIS im With-Fall Um den als Wrapper fungierenden Webservice adäquat benutzen zu können, sind Schnittstellenerweiterungen zu implementieren, die sowohl das DWH- als auch das CRM-System betreffen. Zudem ist die Funktionalität beider Systeme derart anzupassen, dass die im DWH selektierten Kundendaten mit Hilfe des Wrappers automatisch dem CRM-System zur Verfügung gestellt werden. Auch ist es zu ermöglichen, Kundendaten direkt im CRM-System zu selektieren und die zusätzlich benötigten Informationen automatisch aus dem DWH-System zu laden.

Serviceorientiertes Prozesscontrolling

199

Zur Realisierung dieses Konzepts sind in der Entwicklungsphase mehrere Personentage für die Anforderungsanalyse, Implementierung und Tests zu kalkulieren, die mit 20.000 € veranschlagt worden sind. Ferner fallen in der Betriebsphase Koordinationskosten in Höhe von 200 € pro Jahr an, um Fehlerkorrekturen und Wartungsarbeiten zu berücksichtigen. Aufgrund regelmäßig durchzuführender Softwareupdates des DWH- und des CRM-Systems sind Anpassungsentwicklungen einzuplanen, die mit 500 € pro Periode bewertet wurden. Über die technischen Aspekte hinaus sind zur Einführung der neuen Prozessvariante zusätzlich Schulungen vorzusehen. Sie zielen darauf ab, dass die neuen technischen Möglichkeiten auch reibungslos in der Praxis umgesetzt werden. Für Anpassungen des Benutzerhandbuches fallen anfänglich 1.500 € an. In den Folgeperioden sind Schulungen durchzuführen, deren Umfang über den Planungszeitraum degressiv abnimmt. Ebenso wird davon ausgegangen, dass der Aufwand für zusätzliche Anpassungen des Benutzerhandbuches aufgrund von Rückmeldungen der Benutzer degressiv abnimmt. 3.5

Wirtschaftlichkeit des SOA-Einsatzes

Anhand der identifizierten Zahlungsfolgen im Without- sowie im With-Fall kann die mit dem Einsatz von SOA zu realisierende Ersparnis ermittelt und in einem letzten Schritt zu finanzwirtschaftlichen Zielwerten verdichtet werden. Zur Verdichtung der Zahlungsfolgen dienen Vollständige Finanzpläne (VOFI) [Grob2006], aus denen sich leicht relevante Kennzahlen ableiten lassen.

Abb. 3-9: Kalkulation der im Fall einer SOA-Einführung auf Serviceebene zu erzielenden Ersparnis bei DECIS Auf Serviceebene lässt sich die Ersparnis wie folgt herleiten. Die im Status quo auftretenden (Aus-) Zahlungen für die internen Services »Kundendaten prüfen« und »Kundendaten korrigieren« fallen bei Einsatz von SOA augrund der Eliminierung der korrespondierenden Aktivitäten nicht mehr an und werden somit eingespart. Bezüglich der Aktivität »Maßnahme archivieren« ergeben sich durch einen Rationalisierungseffekt ebenfalls Einsparungen. Sie lassen sich bestimmen, indem die Differenz aus der Zahlungsfolge für den With-Fall und der Zahlungsfolge für den Without-Fall gebildet wird. Die Kalkulation der Ersparnis auf Serviceebene wurde in Abb. 3-9 nachvollzogen. Auf Infrastrukturebene lässt sich die Ersparnis analog bestimmen. So entfallen im With-Fall die Auszahlungen von 5.000 € pro Periode für Anpassungen des Konvertie-

200

Jan vom Brocke, Christian Sonnenberg

rungsprogramms. Daher ergibt sich eine Ersparnis auf Infrastrukturebene bei Einsatz von SOA in Höhe von 5.000 € pro Periode. Den kalkulierten Ersparnissen auf Service- und Infrastrukturebene sind die zusätzlichen Auszahlungen für die Bereitstellung der Integrationsinfrastruktur (siehe Abb. 3-8) gegenüberzustellen. Die resultierende Zahlungsfolge ist dann in einem VOFI zu verdichten. Die in Abb. 3-10 dargestellte Berechnung liefert einen positiven zusätzlichen Endwert. Die Initiative zur Beseitigung von Integrationsdefiziten im Prozess »Dialogmarketingplanung« durch den Einsatz von SOA ist somit in monetärer Hinsicht zu empfehlen.

Abb. 3-10: Kalkulation des Endwerts der SOA-Einführung und Realisierung von Möglichkeiten der »Integration« bei DECIS.

Serviceorientiertes Prozesscontrolling

201

Parametrische Variationen können jedoch zu anderen Entscheidungsempfehlungen führen. So ist zu erwarten, dass sich mit einer Erhöhung der Auszahlungen für die Wrapper-Entwicklung ein Einstieg in SOA monetär nicht rechtfertigen lässt. Daneben kann auch die Höhe der Ersparnis auf Serviceebene für die wertabhängige Aktivität »Maßnahme archivieren« durch Variation der Prozesshäufigkeiten beeinflusst werden. Allgemein lässt sich im Rahmen von Sensitivitätsanalysen untersuchen, wie sich Entscheidungsergebnisse bei Variation zentraler Parameter verändern. Ferner sind Risiko-Chancen-Profile anwendbar, um die Verteilung der Zielwerte bei einem Einsatz von SOA herzuleiten. Hierzu müssen einzelne Planwerte (z.B. Prozesshäufigkeiten) mit Wahrscheinlichkeitsverteilungen belegt werden. Am RisikoChancen-Profil kann abgelesen werden, welcher Zielwert mit einer bestimmten Wahrscheinlichkeit höchstens oder mindestens zu erreichen ist. In Abb. 3-11 wurde ein Risiko-Chancen-Profil abgebildet, dass die Verteilung des ROI für die SOAEinführung wiedergibt.

Abb. 3-11: Risiko-Chancen-Profil der Einführung von SOA bei DECIS Alternativ lassen sich kritische Prozesshäufigkeiten identifizieren, um zu ermitteln, ab welcher Prozesshäufigkeit die zu erzielende Ersparnis derart gering ist, dass ein Einsatz von SOA nicht mehr wirtschaftlich erscheint.

202

4

Jan vom Brocke, Christian Sonnenberg

Zusammenfassung und Ausblick

Mit diesem Beitrag wurden Methoden für ein Serviceorientiertes Prozesscontrolling vorgestellt (SOPC-Methoden). Sie erlauben es, SOA-induzierte Gestaltungsoptionen in einem Unternehmen monetär zu bewerten. Gegenüber bisherigen Arbeiten wurde hier ein durchgängiges Rechenbeispiel für den in der Praxis vorrangig anzutreffenden Fall der SOA-basierten Prozessintegration dargelegt. Die präsentierten Ergebnisse bestätigen die Funktionsfähigkeit des Methodensystems. Sie zeigen aber auch, dass eine unternehmensindividuell einzustellende Berechnung leicht einen hohen Komplexitätsgrad erreichen kann, da neben individuellen Prozessstrukturen auch Prozesshäufigkeiten sowie spezifische Finanz- und Steuerkonditionen zu berücksichtigen sind. Zu erwarten ist, dass die am Demonstrationsbeispiel bereits deutlich gewordene Komplexität in praktischen Anwendungsfällen zumeist noch höherer ausfallen kann. Hier besteht Forschungsbedarf im Hinblick auf eine adäquate informationssystemseitige Unterstützung. Zu entwickeln sind Controllingwerkzeuge, die ein Serviceorientiertes Controlling von Unternehmensprozessen unterstützen. Der Umfang der zu planenden Daten kann reduziert werden, indem die Werkzeuge auf bereits bestehende Daten zugreifen. Daher ist eine Integration der Werkzeuge mit Produkten der Prozessmodellierung sowie mit Service Repositorien anzubieten. Die zu den Methoden vorliegenden Metamodelle liefern eine Vorlage, nach der zukünftig entsprechende Austauschformate entwickelt werden sollen.

Literaturverzeichnis [AAAB2006] Alves, A.; Arkin, A.; Askary, S.; Bloch, B.; Curbera, F.; Goland, Y.; Kartha, N.; Liu, C. K.; König, D.; Mehta, V.; Thatte, S.; van der Rijn, D.; Prasad, Y.; Yiu, A. H.: Web Services Business Process Execution Language Version 2.0. Committee Draft. OASIS, http://www.oasis-open.org/committees/download.php/18714/wsbpel-specification-draftMay17.htm [30.09.06]. [BCEH2003] Bellwood, T.; Clément, L.; Ehnebuske, D.; Hately, A.; Hondo, M.; Husband, Y. L.; Januszewski, K.; Lee, S. B.; Munter, J.; von Riegen, C.: UDDI Version 3.0.2, UDDI Spec Technical Committee Specification. http://uddi.org/pubs/uddi-v3.0.2-20041019.htm [30.09.06]. [BDEM2006] Burstein, M.; Denker, G.; Elenius, D.; McDermott, D.; McGuinness, D.; McIlraith, S.; Paolucci, M.; Parsia, B.; Payne, T.; Sirin, E.; Srinivasan, N.; Sycara, K.: OWL-S 1.2 Pre-Release. OWL-S Service Coalition. http://www.ai.sri.com/daml/services/ owl-s/1.2/ [30.09.06]. [BeKa2005] Becker, J.; Kahn, D.: Der Prozess im Fokus. In: J. Becker; M. Kugeler; M. Rosemann (Hrsg.): Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung. Berlin, 2005. [Crag2003] Craggs, S.: Best-of-Breed ESBs. Identifying Best-of-Breed Characteristics. Enterprise Services Buses (ESBs). http://www.sonicsoftware.com/products/whitepapers/ docs/best_of_breed_esbs.pdf [30.09.06]. [Grob2006] Grob, H. L.: Einführung in die Investitionsrechnung. Eine Fallstudiengeschichte. München, 2006.

Serviceorientiertes Prozesscontrolling

203

[GHMM2003] Gudgin, M.; Hadley, M.; Mendelsohn, N.; Moreau, J.-J.; Nielsen, H. F.: SOAP Version 1.2, W3C Recommendation, Stand 24. Juni 2003. http://www.w3.org/TR/ 2002/WD-soap12-part0-20020626/ [30.09.06]. [HMPR2004] Hevner, A. R.; March, S. T.; Park, J.; Ram, S.: Design Science in Information Systems Research. In: MIS Quarterly, 28. Jg., 2004, H. 1, S. 75-105. [IBM2004] IBM: E-Business on Demand. http://www-5.ibm.com/services/de/ondemand/ solutions_bizproc.html [30.09.06]. [Kell2002] Keller, W.: Enterprise Application Integration. Erfahrungen aus der Praxis. Heidelberg, 2002. [KNSc1992] Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozeßmodellierung auf der Grundlage „Ereignisgesteuerter Prozeßketten (EPK)". In: A.-W. Scheer (Hrsg.): Arbeitsbericht Nr. 89. Veröffentlichungen des Instituts für Wirtschaftsinformatik der Universität des Saarlandes: Saarbrücken, 1992. [Leymann 2003] Leymann, F.: Web Services. Distributed Applications without Limits. An Outline: 10th Conference on Database Systems for Business, Technology and Web. Springer: Berlin et. al., 2003. [MaSm1995] March, S. T.; Smith, G.: Design and Natural Science Research on Information Technology. In: Decision Support Systems, 15. Jg., 1995, H. 4, S. 251-266. [Meff2002] Meffert, H.: Direct Marketing und marktorientierte Unternehmensführung. In: Dallmer, H. (Hrsg.): Das Handbuch. Direct Marketing & More. 8. Aufl., Wiesbaden, 2002, S. 33 - 55. [Nucl2005] NucleusResearch: ROI Case Study. Microsoft Biztalk Server 2004. Milton Keynes General Hospital. Nucleus Research Inc., Corporate Headquarters, Wellesley MA, USA. http://download.microsoft.com/download/6/5/9/6597A975-C650-4A2A-9062106359209966/MiltonKeynes.pdf [30.09.06]. [Orac2004] Oracle: Oracle Application Server. An Oracle Technical White Paper. http://otn.oracle.com/products/integration/pdf/integration_tech_wp.pdf [30.09.06]. [PrSa2005] Prokein, O.; Sackmann, S.: Der Einsatz von Web Services in deutschen Unternehmen. Eine empirische Untersuchung. Freiburg, 2005. [Reic2003] Reichmayr, C.: Collaboration und WebServices. Architekturen, Portale, Techniken und Beispiele. Berlin, 2003, zugl. Diss. Univ. St. Gallen 2003. [SAP2006] SAP: SAP Enterprise Services Architecture. www.sap.com/solutions/esa/ [30.09.06]. [ScWi2002] Schelp, J.; Winter, R.: Enterprise Portals und Enterprise Application Integration. In: Praxis der Wirtschaftsinformatik (HMD), 38 (225), 2002, S. 6-20. [Scho1990] Scholz-Reiter, B.: CIM. Informations- und Kommunikationssysteme. Darstellung von Methoden und Konzeption eines rechnergestützten Werkzeugs für die Planung. München, 1990. [Simo1996] Simon, H.: The Sciences of the Artificial, Third Edition. Cambridge, MA. 1996. [SnSn2003] Sneed, H. M.; Sneed, S. H.: Web-basierte Systemintegration. Braunschweig, Wiesbaden, 2003.

204

Jan vom Brocke, Christian Sonnenberg

[vADG2005] van der Aalst, W. M. P.; Dreiling, A.; Gottschalk, F.; Rosemann, M.; JansenVullers, M. H.: Configurable Process Models as a Basis for Reference Modeling. Proceedings der First International Workshop on Business Process Reference Models, 2005, S. 76-82. [VoGi2004] Vollmer, K.; Gilpin, M.: Integration In A Service-Oriented World. http://www.forrester.com/Research/Document/Excerpt/0,7211,34742,00.html [30.09.06]. [vBLi2004] vom Brocke, J.; Lindner, M.: Service Portfolio Measurement. A Framework for Evaluating the Financial Consequences of Out-tasking Decisions. In: ACM SIG Proceedings of the ICSOC04, 2nd International Conference on Service Oriented Computing, New York City, NY, USA, Nov. 15-18, 2004, ACM Press, S. 203-211. [vBro2003] vom Brocke, J.: Referenzmodellierung. Gestaltung und Verteilung von Konstruktionsprozessen. Berlin, 2003, zugl. Diss. Univ. Münster 2002. [vBro2006] vom Brocke, J.: Serviceorientiertes Prozesscontrolling. Gestaltung von Organisations- und Informationssystemen bei Serviceorientierten Architekturen, Habil. Univ. Münster 2006. [vBro2007] vom Brocke, J.: Service Portfolio Measurement. Evaluating Financial Performance of Service-Oriented Business Processes. In: International Journal of Web Services Research (IJWSR), 4. Jg. 2007. [W3C2006] W3C: WSDL, Version 2.0, Part 1, Core Language, Candidate Recommendation vom 27.03.2006. http://www.w3.org/TR/wsdl20/ [30.09.06]. [Wang2004a] Wang, A.-L.: Fallstudie und Return on Investment. Einsatz von SAP NetWeaver bei Sasol. IDC Analyze the Future, Global Headquarters, Framingham, MA, USA. http://www.sap.com/germany/media/sasol.pdf [30.09.06]. [Wang2004b] Wang, A.-L.: SAP NetWeaver unterstützt das neue und profitable Geschäftsmodell bei Goodyear. IDC Analyze the Future, Global Headquarters, Framingham, MA, USA. http://www.sap.com/germany/media/Goodyear.pdf [30.09.06]. [WeVo2002] Weikum, G.; Vossen, G.: Transactional Information Systems. Theory, Algorithms and the Practice of Concurrency Control and Recovery. San Francisco, 2002.

Workflow Monitoring in Service-Orientierten Architekturen Jochen Müller, Florian Jostock, Joachim Götze, Paul Müller Zusammenfassung: Organisationen müssen ihre Geschäftsprozesse flexibel gestalten, um auf Veränderungen im Umfeld effizient reagieren zu können. Service-orientierte Architekturen (SOA) ermöglichen es Software-Funktionalitäten als Dienste bereitzustellen, diese nach Bedarf zu kombinieren und in Geschäftprozesse zu integrieren. Bei der Ausführung dieses Service-orientierten Workflows ergeben sich insbesondere durch die Verteiltheit der Dienste neue Anforderungen an das Monitoring. Die vorliegende Arbeit stellt ein Modell für ein solches Workflow Monitoring vor.

1

Einleitung

Der Einsatz von Service-orientierten Architekturen (SOA) hat sich in den letzten Jahren in den verschiedensten Anwendungsdomänen etabliert. Ein Grund für diesen Erfolg ist, dass durch SOA große und komplexe Anwendungen übersichtlich gestaltet und zusammengesetzt werden können. In einer SOA werden Applikationen aus mehreren voneinander unabhängigen Diensten zusammengestellt. Ein Dienst stellt jeweils eine spezifische Funktionalität zur Verfügung, welche die Lösung für ein Teilproblem darstellt. Da seine Schnittstelle genau beschrieben ist, kann er relativ einfach durch eine andere Implementierung mit der gleichen Schnittstelle ersetzt werden. Der zentrale Gedanke ist dabei die lose Kopplung, darunter versteht man eine möglichst technologieneutrale Definition der Schnittstellen und der Dienste [PTDL2006] mit möglichsten wenigen Abhängigkeiten. So sollen Daten nicht in einem binären Format, das nur von einer bestimmten Programmiersprache benutzt wird, bereitgestellt werden. In der Praxis kommt daher oft XML zum Einsatz. Im Rahmen unserer Forschungsarbeit untersuchen wir den gesamten Lebenszyklus eines Workflows, den man üblicherweise in die Haupt-Phasen Analyse, Design, Implementierung, Ausführung und Bewertung unterteilt [MZKM2007, 151]. Überträgt man diesen Ablauf auf Service-orientierte Workflows (SOW) ergeben sich neue Möglichkeiten, aber auch neue Anforderungen. Die vorliegende Arbeit beschäftigt sich mit der Ausführung und dem Monitoring. Insbesondere die Überwachung der Ausführung ist für viele Anwendungsszenarien von großer Bedeutung. Die vorliegende Arbeit beschäftigt sich mit dieser Thematik. In unserem Szenario werden die Implementierung des Workflows und die anschließende Ausführung von unterschiedlichen Rollen übernommen. Im Rahmen eines interdisziplinären Forschungsprojektes wurden die Prozesse der Flächennutzungsplanung untersucht. Die Akteure in dieser Anwendungsdomäne, meist kleine Gemeindeverwaltungen, haben nicht die notwendigen Ressourcen (Software, Hardware, aber auch Personal) um diese Prozesse abzubilden. Als Lösungsansatz schlagen wir eine Portal-Architektur vor, welche die benötigten Prozesse auf Dienste abbildet, und je nach Anforderungen dynamisch zusammenstellt. Dabei gehen wir davon aus, dass der zunehmende Wettbewerb auch im Internet und Web zu einer Fokussierung der Anbieter auf bestimmte Kernkompetenzen erfolgen wird. In unserem Szenario wären dies die Implementierung einerseits und die Ausführung / Monitoring andererseits. Zusätzlich ergeben sich noch Anforderungen aus den jeweiligen Anwendungsdomänen.

206

Jochen Müller, Florian Jostock, Joachim Götze, Paul Müller

Ziel dieser Arbeit ist es ein Modell zu entwickeln, um Service-orientierte Workflows auszuführen und zu überwachen. Für solch eine Komponente identifizieren wir die Anforderungen und beschreiben modellhaft unseren Realisierungsansatz. Im folgenden Kapitel werden die Grundlagen dargestellt. Das Kapitel 3 leitet aus den Anforderungen eine Komponente zum Workflow-Monitoring her. In Kapitel 4 werden einige verwandte Arbeiten beschrieben und von unserer Arbeit abgegrenzt. Kapitel 5 fasst die Arbeit zusammen.

2

Grundlagen

2.1

Komposition in SOA

Durch die Komposition mehrerer Dienste, bspw. durch ihren parallelen oder sequentiellen Aufruf, und eine Kombination der Rückgabewerte, entsteht ein neuer komplexerer Dienst. Werden solche komplexen Dienste zur Realisierung oder Unterstützung von Geschäftsprozessen eingesetzt, dann bezeichnet man diese auch als Serviceorientierten Workflow. Zunächst wird ein zusammengestellter Dienst durch eine geeignete Kompositionssprache spezifiziert. Dieses Spezifikationsdokument wird dann an einen Interpreter (Workflow-Engine) übergeben, welcher den zusammengestellten Dienst zur Verfügung stellt und eine Ausführung ermöglicht. Wenn eine Anfrage für diesen komplexen Dienst kommt, erstellt der Interpreter eine neue Instanz des Dienstes. Greifen mehrere Nutzer gleichzeitig auf den Dienst zu, laufen die Instanzen in der Regel unabhängig voneinander. Eine Sprache zur Spezifikation von zusammengestellten Diensten muss Lösungen für folgende Probleme bieten [ACKM2004]: Definition der verwendeten Dienste: Für die verwendeten Dienste müssen sowohl Interfaces, als auch die Adressen der Dienstanbieter spezifiziert werden. Es sollte die Möglichkeit bestehen, Dienste dynamisch zu binden, das bedeutet, die Adressen der Dienstanbieter müssen erst zur Laufzeit festgelegt werden. Behandlung der Daten: Die Spezifikationssprache muss die Daten behandeln, die als Parameter zum Aufruf der Dienste und als Rückgabewerte anfallen. Bei Verzweigungen in Abhängigkeit des Rückgabewertes eines Dienstes ist es notwendig die Struktur der Daten zu beschreiben. Viele Daten können jedoch auch einfach von einem Dienst zum nächstem weitergereicht werden, ohne sie zu dekodieren. Es werden zwei Ansätze unterschieden: Beim Blackboard-Ansatz werden den Daten, die ein Dienst zurückgibt, Namen zugewiesen, und unter diesem Namen auf einem „schwarzem Brett“ abgelegt. Anhand des Variablennamens kann man später auf die Daten zugreifen. x

Alternativ können die Datenflüsse explizit formuliert werden. Dabei wird genau angegeben, an welche Dienste die Rückgabewerte eines anderen Dienstes weitergereicht werden.

Das zweite Verfahren ist für den Programmierer des zusammengesetzten Dienstes aufwändiger. Allerdings ist es für die Workflow-Engine so einfacher zu erkennen, ob

Workflow Monitoring in Service-Orientierten Architekturen

207

sie Daten lokal speichern muss, oder diese von einem Dienst zum anderem durchgereicht werden. Dies ist gerade bei großen Datenmengen von Vorteil. Komposition der Dienste: Es gibt verschiedene Modelle zur Spezifikation von Prozessen. Diese reichen von Flussdiagrammen über UML-Zustandsdiagramme bis zu Aktivitätsbäumen. Die Sprache muss es ermöglichen, den Prozessablauf genau festzulegen. Ausnahmebehandlung: Die Sprache sollte eine Möglichkeit bieten, auf Fehler zu reagieren. Dabei wäre es von Vorteil, bestimmte vorherige Aktionen rückgängig machen zu können, wenn ein Fehler auftritt. Dies ist besonders kompliziert, da WebServices oft asynchron und zeitversetzt ablaufen. Transaktionen würden die Datenbanken viel zu lange blockieren, so dass Änderungen von den Dienstanbietern oft sofort dauerhaft gespeichert werden. Als Spezifikationssprache für die Zusammenstellung von Diensten hat sich die Business Prozess Execution Language (BPEL) etabliert [ACD+2003]. Der Prozessablauf wird hier auf ein hierarchisches Aktivitätsdiagramm abgebildet, das aus atomaren und strukturierten Aktivitäten aufgebaut wird. Zur Behandlung der Daten wird der oben beschriebene Blackboard-Ansatz verwendet. 2.2

Monitoring

Monitoring bezeichnet allgemein das Überwachen und Protokollieren des Verhaltens eines Systems. Häufig wird auch die Auswertung und Visualisierung der protokollierten Daten, sowie die Steuerung des überwachten Systems zum Monitoring gezählt. Der Begriff „Monitoring“ wird in sehr vielen Bereichen verwendet: So kann das überwachte System ein Softwaresystem sein [Klar1995], aber auch ein Geschäftsprozess in einem Unternehmen [Wild2004, S. 80] oder gar ein Ökosystem sein. In dieser Arbeit ist mit Monitoring die Überwachung eines Softwaresystems gemeint. Je nach Einsatzbereich hat das Monitoring eines Softwaresystems unterschiedliche Ziele [IBM2006], [Snod1984, 125], [GTJ+2002]: x

Während der Entwicklung dient das Monitoring vor allem dem Auffinden von Fehlern. Mit dem Debugger können die Werte der Variablen überwacht, und der aktuelle Zustand des Prozesses visualisiert werden.

x

Während der Testphase dient das Monitoring gleichermaßen dem Auffinden weiterer Fehler, als auch der Leistungsmessung und -verbesserung. Der Ablauf des Prozesses wird dazu in automatisierten Testläufen immer wieder protokolliert. Die Daten werden später zum Teil automatisch ausgewertet und visualisiert.

x

Während der Benutzung einer Software wird das Monitoring vor allem zur Leistungsmessung benutzt. So kann man sogenannte „Flaschenhälse“ entdecken und die dort verwandte Software optimieren.

In dieser Arbeit kommt das Monitoring während der regulären Ausführung von Geschäftsprozessen zum Einsatz. Die Ereignisse sollen dabei nicht visualisiert, sondern aufgezeichnet und automatisch ausgewertet werden. Neben dem reinen Protokollieren und Speichern von Daten kann das Monitoring auch weitere Funktionalitäten übernehmen. Beispielsweise kann es auf bestimmte Ereignisse reagieren, und einen Prozess abbrechen, oder bestimmte Aktionen zum

208

Jochen Müller, Florian Jostock, Joachim Götze, Paul Müller

Ausgleich eines vorher aufgetretenen Fehlers durchführen. Dabei kann und darf das Monitoring nicht die Fehlerbehandlung des Programms ersetzen. Robinson [Robi2002, 276] schreibt dazu, dass beim Monitoring das gesamte Programm und das Zusammenspiel aller Programmteile überwacht werden. Das wirkliche globale Verhalten zur Laufzeit wird dabei mit den spezifizierten Anforderungen an das Programm abgeglichen. Üblicherweise unterscheidet man beim Monitoring von Softwaresystemen einen aktiven und einen passiven Ansatz [Nitz2006]. Beim ereignisbasierten (aktiven) Monitoring stellt die Anwendung die gewünschten Informationen bereit, sobald sich ihr Zustand ändert [Klar1995], [Robi2002, 276]. Dies wird in der Regel erreicht, indem entsprechende Anweisungen in den Anwendungscode eingefügt werden (Instrumentierung). Um dies zu erreichen muss die Anwendung verändert werden. Dadurch kann es zu einem veränderten Verhalten der Anwendung kommen. Weiterhin kann es durch den zusätzlichen Code zu einer Beeinträchtigung der Performanz der Anwendung kommen. Beim passivem bzw. zeitbasiertem Monitoring [Nitz2006], [HKMQ2004, 587] stellt die überwachte Anwendung von sich aus keine Daten zur Verfügung. Stattdessen muss die Monitoring-Anwendung die gewünschten Informationen selbst abfragen. Da die Monitoring-Anwendung in der Regel keine Informationen über die Zustandsänderungen hat, wird die gesamte Statusinformation über eine periodische Abfrage ermittelt. Der Vorteil dieses Vorgehens ist, dass die Anwendung nicht verändert werden muss. Allerdings sind die periodischen Abfragen deutlich zeitaufwendiger, da mehr Daten übertragen werden als beim aktiven Monitoring. Zudem werden - je nach Abfrageintervall - möglicherweise nicht alle Zustandsänderungen erfasst. Das passive Monitoring bietet sich vor allem an, wenn der Status von sehr lang laufenden Prozessen in verhältnismäßig großen Intervallen überprüft werden soll. 2.3

Flächennutzungsplanung

Im Rahmen eines interdisziplinären Projektes haben wir die Prozesse der Flächennutzungsplanung untersucht. In einem Flächennutzungsplan (FNP), auch vorbereitender Bauleitplan genannt, wird festgelegt, wie die Flächen innerhalb einer Gemeinde genutzt werden sollen. Der Flächennutzungsplan soll die verschiedenen räumlichen Nutzungsansprüche, wie beispielsweise Wohnen, Verkehr, Gewerbe oder Grünflächen koordinieren und zu einem abgewogenen Gesamtkonzept zusammenzuführen. Die Flächennutzungsplanung als Prozess umfasst die Erstellung dieser vorbereitenden Bauleitpläne. In dem von uns untersuchten Szenario sollen bestimmte Prozesse durch Informations- und Kommunikationstechnologien unterstützt, bzw. automatisiert werden. Die dafür benötigten Software-Funktionalitäten sollen aber nicht in der Gemeinde integriert werden, sondern sollen als Dienste über das Internet genutzt werden können. Als Anwendungsfall wurde der Prozess „Beteiligung Träger öffentlicher Belange“ identifiziert. Während des Projektes wurden der Prozess und die benötigten Dienste beschrieben und entwickelt. In der vorliegenden Arbeit wird eine Ausführungs- und Monitorumgebung für den Prozess modellhaft beschrieben [MKM2005, 74].

Workflow Monitoring in Service-Orientierten Architekturen

3

Service-orientiertes Workflow Monitoring

3.1

Erweiterte Service-orientierte Architektur

209

In einer SOA unterschiedet man die folgenden drei Rollen: Dienstanbieter, Dienstnutzer und Makler (Broker). Zur Realisierung des Maklers, wurde der UDDI-Standard (Universal Description, Discovery and Integration) entwickelt. Dabei handelt es sich um ein datenbankbasiertes Verzeichnis, ähnlich den Gelben Seiten, in das die Anbieter sich eintragen und in dem die Nutzer nach einem Anbieter suchen können. Tatsächlich werden diese Verzeichnisse kaum zur automatischen Bindung von Prozessen an Dienstanbieter genutzt. Ein Grund dafür ist der Mangel an Informationen über die Dienste. Die technische Beschreibung des Dienstes (T-Modell) liegt zwar vor, diese genügt für den Nutzer aber nur im Idealfall um zu entscheiden, ob ein Dienstanbieter geeignet ist. In der Praxis spielen nicht-funktionale Eigenschaften, die Aussagen über die Qualität des Dienstes machen, wie Verfügbarkeit und Zuverlässigkeit eine Rolle. Außerdem hält sich möglicherweise nicht jeder Dienstanbieter exakt an die Dienstbeschreibung. Oft benötigt der Nutzer auch weitere funktionale Eigenschaften, die aus der Dienstbeschreibung nicht hervorgehen. Es besteht daher Bedarf für einen Makler, der die Anforderungen des Dienstnutzers entgegennimmt, sie mit seinem eigenem „Expertenwissen“ über die Dienstanbieter abgleicht, und den am besten geeigneten Dienst zur Erfüllung der Anforderungen findet. Unter Expertenwissen verstehen wir in diesem Zusammenhang die genauen Kenntnisse über die verschiedenen Akteure (Rollen) und über funktionale und nichtfunktionale Anforderungen innerhalb einer Anwendungsdomäne. Eine Lösung ist ein domänenspezifischer Ansatz (siehe Abbildung 3-1), in dem ein Makler nur Dienste zur Lösung von Aufgaben eines bestimmten Fachgebietes vermittelt [MZKM2007].

Abb. 3-1: Designing a Service Oriented Domain Architecture [MZKM2007]. Eine erweiterte Service-orientierte Architektur mit einem Domain-Manager, der für sein Fachgebiet spezifisches Expertenwissen besitzt. Der Domain-Manager stellt Workflows zusammen, wählt geeignete Dienstanbieter aus und überwacht die Ausführung der Workflows.

210

Jochen Müller, Florian Jostock, Joachim Götze, Paul Müller

Der Domain Manager nimmt Anfragen für bestimmte Dienste entgegen, stellt einen Workflow zusammen, der alle Anforderungen erfüllt, und führt ihn aus. Währenddessen wird überwacht, ob der Workflow und die externen Dienste alle Anforderungen erfüllen.

Abb. 3-2: Die Komponenten des Domain Managers. Zentrales Augenmerk liegt in dieser Arbeit auf dem Monitor, der während der Ausführung der Workflows Expertenwissen über die Dienstanbieter ableitet. Abbildung 3-2 zeigt den Aufbau des Domain Managers aus folgenden Komponenten: x

Der domainenspezifische Teil bindet Informationen über die Daten, die in diesem Fachgebiet verarbeitet werden, ein. Dieser Teil besitzt auch Informationen über Anforderungen, die für bestimmte, fachgebietsspezifische Aufgaben erfüllt werden müssen.

x

Außerdem speichert der Domain-Manager zusätzliche Informationen über die Dienstanbieter, welche nicht aus der technischen Beschreibung der Dienste hervorgehen. Dies sind vor allem Informationen über die Interoperabilität und Dienstgüte der Dienstanbieter.

x

Die Orchestrierungskomponente ist die zentrale Komponente des Domain Managers. Sie stellt auf eine Anfrage eines Dienstnutzers automatisch einen Workflow zusammen. Dazu muss sie auf die domainspezifischen Informationen, sowie auf die Datenbank mit Expertenwissen über die Anbieter zurückgreifen.

x

Der Monitor führt die Workflows aus und prüft, ob alle Anforderungen an den Workflow und an die externen Dienste erfüllt werden. Die Monitoring-Ergebnisse werden benutzt, um die Datenbank mit dem Expertenwissen zu füllen.

x

Zusätzlich wird eine Komponente für die Verwaltung und Authentifizierung benötigt. Mit deren Hilfe weisen sich die Komponenten des Domain-Manager untereinander und gegenüber den externen Dienstanbietern aus.

Workflow Monitoring in Service-Orientierten Architekturen

211

In den nächsten beiden Abschnitten wird die Komponente zur Ausführung und zum Monitoring des Workflows vorgestellt. Abschnitt 3.4 geht weiterhin auf den Mechanismus zur Authentifizierung ein, welcher auch in die Monitoring-Komponente integriert werden muss. 3.2

Anforderungen an den Monitor

In diesem Abschnitt werden die Anforderungen an den Monitor festgelegt. Dabei werden zunächst die Fähigkeiten des Monitors festgelegt. Weiterhin soll der Monitor den Prozess möglichst wenig beeinflussen. Der Monitor wird dann in Abschnitt 3.3 vorgestellt. 3.2.1

Spezifikation der Anforderungen an den Prozess

Es können Anforderungen an den Prozess spezifiziert werden, die überwacht werden sollen. Sie sollten möglichst getrennt von der Spezifikation des eigentlichen Workflows spezifiziert werden. Man kann zwischen zwei Typen von Anforderungen unterscheiden: a) Zum Einem sollen funktionale Anforderungen [Hün2005] an den Prozess und die aufgerufenen Dienste überwacht werden: x

Entsprechen die von einem Dienst übermittelten Daten der Schnittstellenbeschreibung?

x

Welche Vor- und Nachbedingungen gelten für einen Dienst? Während anhand der Schnittstellenbeschreibung die Syntax der Daten geprüft wird, kann so auch die Semantik geprüft werden. Zudem kann geprüft werden, ob nach Aufruf mehrerer Dienste bestimmte Daten vorliegen, während die anhand der Schnittstellenbeschreibung nur die Antwort eines einzelnen Dienstes geprüft werden kann.

x

Wie oft wird eine bestimmte Aktivität ausgeführt?

b) Weiterhin wird die Dienstgüte bzw. Quality-of-Service (QoS) überwacht. Dazu zählen folgende Merkmale: x x x x

3.2.2

Die Antwortzeit: Antwortet ein Dienst überhaupt und wieviel Zeit benötigt er? Die Gültigkeit der Antwort: Antwortet ein Dienst mit den angeforderten Daten oder mit einer Fehlermeldung? Die Reproduzierbarkeit einer Antwort bei einer bestimmten Anfrage. Die Genauigkeit der Antwort. Diese kann zum Beispiel vom Dienstanbieter selbst übermittelt werden. Alternativ kann die Monitoring-Anwendung Ergebnisse verschiedener Dienstanbieter vergleichen. Fehlerbehandlung

Wenn eine Zusicherung nicht erfüllt werden konnte, muss geeignet reagiert werden [BGG2004, 195]. Einerseits soll der Fehler für die spätere Auswertung gespeichert werden. Andererseits kann es viel Zeit sparen, wenn der Prozess nicht komplett abgebrochen und neu gestartet werden muss. Stattdessen kann zum Beispiel ein anderer Anbieter für den Dienst ausgewählt werden, der den Fehler verursacht hat.

212

Jochen Müller, Florian Jostock, Joachim Götze, Paul Müller

Dabei darf die Implementierung des Prozesses und der Fehlerbehandlung jedoch nicht in die Monitoring-Anwendung ausgelagert werden. 3.2.3

Statusabfrage

Außerdem soll es möglich sein, eine Statusabfrage durchzuführen, um zu überprüfen ob der Workflow noch läuft, welche Schritte noch abzuarbeiten sind und welche Aktionen bereits durchgeführt wurden. Diese Möglichkeit ist vor allem bei lang laufenden Prozessen wichtig. Zusätzlich zu den bereits aufgezeichneten Daten können dazu Statusinformationen von den Dienstanbietern eingeholt werden. 3.2.4

Geschwindigkeit

Das Monitoring soll den überwachten Prozess möglichst wenig bremsen und nicht verändern [BOH2002, 6]. Dies wird oft erreicht, indem nur die Daten erfasst werden, die zum Monitoring benötigt werden. Daher muss der Benutzer angeben, was genau überwacht werden soll. Der Workflow soll so wenig wie möglich durch das Monitoring beeinflusst werden. Insbesondere soll er nicht viel langsamer ablaufen. Da jede Datenerfassung Zeit kostet, ist es sinnvoll nur die Daten zu erfassen, die wirklich benötigt werden. Daher führen die meisten Frameworks eine eigene Sprache ein, mit der die zu erfassenden Daten spezifiziert werden. 3.3

Modell des Monitors

Der Monitor besteht aus 3 Komponenten: x

Der Instrumentierer nimmt den Workflow und die Zusicherungen, die vom Workflow zu erfüllen sind, vom Domain-Manager entgegen und instrumentiert ihn. Den instrumentierten Prozess stellt er einer Workflow-Engine (z.B. ActiveBPEL) zur Verfügung.

x

Die Workflow-Engine führt den instrumentierten Prozess aus. Soll eine Anforderung überprüft oder aufgezeichnet werden, sendet der instrumentierte Prozess ein Ereignis mit allen notwendigen Daten an den Ereignisempfänger.

x

Der Ereignisempfänger stellt einen Webservice zur Verfügung, der die geprüften oder zu prüfenden Zusicherungen von dem instrumentierten Prozess entgegennimmt.

Abbildung 3-3 zeigt die Komponenten und visualisiert den Monitoring-Prozess.

Bei der Instrumentierung sind vier Fälle zu unterscheiden: 1) Es soll nur eine Anforderung überwacht werden, aus deren Ergebnis später Rückschlüsse über die Eigenschaften des Prozess und eines Dienstanbieters gezogen werden. Der Prozessablauf wird aber nicht beeinflusst. a) Die Anforderung kann von der Workflow-Engine überwacht werden, in dem sie in BPEL-Quellcode umgewandelt wird.

Workflow Monitoring in Service-Orientierten Architekturen

213

b) Die Prüfung der Anforderung lässt sich nicht umwandeln. In diesem Fall müssen die zu prüfenden Daten an den Ereignisempfänger gesendet werden, welcher die Prüfung dann durchführt. 2) Der Prozess wird von der Anforderung beeinflusst. a) Die Prüfung kann von der Workflow-Engine durchgeführt werden. b) Die Prüfung kann nicht von der Workflow-Engine durchgeführt werden.

Abb. 3-3: Modell des Monitors. Der Domain Manager sendet Prozess und Anforderungen an den Instrumentierer, welcher sie in einer Datenbank ablegt und den instrumentierten Prozess der Workflow-Engine zur Verfügung stellt. Der Prozess prüft während der Ausführung die Anforderungen und sendet die Ergebnisse an den Ereignisempfänger. Dieser ordnet die Ereignisse in einer Datenbank ein, wo der Domain Manager sie beispielsweise mit Datamining-Verfahren auswerten kann. Folgende Überlegungen beziehen sich auf eine Realisierung. Für die vorgestellten Fälle 1a und 2a sind keine Auswirkungen auf die Performanz zu erwarten. Dazu wird der Prozess so instrumentiert, dass die Prüfung der Zusicherung und die Fortsetzung des Prozess gleichzeitig stattfinden. Für den Fall 1b wird die Performanz des Service-orientierten Workflows etwas verschlechtert, da die Zusicherung zunächst vom Workflow selbst geprüft werden muss. Auf Basis des Ergebnisses wird dann fallabhängig eine Fehlerbehandlung gestartet. Gleichzeitig wird das Ergebnis an den Ereignisempfänger gesendet. Lediglich im Fall 2b wird es zu deutlichen Performanzeinbußen kommen. Die Zusicherung muss an den Ereignisempfänger gesendet werden, welcher sie prüft und das Ergebnis an den Workflow zurücksendet (und speichert). Der Workflow muss auf diese Antwort warten, da der weitere Verlauf davon abhängig ist.

214

3.4

Jochen Müller, Florian Jostock, Joachim Götze, Paul Müller

Authentifizierung

Da der Domain Manager vollständig Service-orientiert aufgebaut ist, ist der Dienstanbieter für das Monitoring austauschbar. Allerdings muss der Dienstanbieter sich sowohl gegenüber dem Domain Manager als auch gegenüber den externen Diensten, authentifizieren und auch deren Identität prüfen. Venice [HGMM05, 210] ist ein nach service-orientierten Designaspekten entwickeltes Service Grid. Dieses Framework stellt neben den grundlegenden Funktionalitäten, z.B. Service-Management und Service-Brokering, auch einen Dienst zur Authentifizierung und Autorisierung in der Webservice-Umgebung bereit. Jede Organisationseinheit muss dazu zwei Dienste anbieten: x

Der Authentifizierungsdienst (Authentication Service) authentifiziert den anfragenden Dienstnutzer und sendet ihm eine nur für ihn lesbare Nachricht. Sie enthält ein Single-Sign-On-Token, das nur der Tokendienst lesen kann, und einem Sitzungsschlüssel für die weitere Kommunikation mit dem Tokendienst.

x

Mit dem Single-Sign-On-Token erhält der Dienstnutzer vom Tokendienst (Service Token Service) jederzeit Service-Token (enthält Autorisierungsinformationen) und temporäre Schlüssel zur Authentifzierung und Autorisierung bei registrierten Dienstanbietern.

Da das Service-Token nur vom Authentifizierungsdienst versendet wird, und zwar mit dem Schlüssel des Dienstes verschlüsselt, kann sich der Dienstnutzer damit authentifizieren und entsprechend seinen Autorisierungsinformationen den Dienst in Anspruch nehmen. Das Service-Token enthält außerdem den Sitzungsschlüssel und ist nur für den Dienst lesbar. So kann sich der Dienst gegenüber dem Dienstnutzer durch Entschlüsselung einer Nachricht, die mit dem Sitzungsschlüssel verschlüsselt ist, authentifizieren. Zur Integration der Authentifizierungsfunktionalität in den Domain Manager werden Authentifizierungs- und Tokendienst zum Verwaltungsdienst (vgl. Abbildung 3-2) hinzugefügt. Abbildung 3-4 zeigt an einem Beispiel, welche Nachrichten bei der Bearbeitung einer Anfrage an Domain Manager versendet werden. Da nur der Domainmanager ein Vertrauensverhältnis mit den Dienstanbietern hat, und diese nutzen darf, muss er seine Nutzungsrechte an den Monitor weitergeben, wenn dieser einen Workflow ausführen soll. Venice sieht dazu die Möglichkeit vor, die eigenen Nutzungsrechte für eine bestimmte Zeit an einen anderen Benutzer zu delegieren [HGMM05, 218].

Workflow Monitoring in Service-Orientierten Architekturen

215

Abb. 3-4: Die SSO-Token enthalten den temporären Schlüssel (TK1 bzw. TK2) sowie die Identität des Tokenbesitzers. Sie sind nur für den Tokendienst lesbar und werden vom Authentifizierungsdienst zusätzlich mit dem Schlüssel des Tokenbesitzers verschlüsselt (PKO und PKM). Token1 und Token2 sind genauso aufgebaut, aber nur für den Monitor bzw. Dienstanbieter lesbar.

4

Verwandte Arbeiten

Das folgende Kapitel stellt einige Frameworks zum Monitoring von Workflows dar und grenzt diese zu dem vorgeschlagenen Ansatz ab. Baresi et al. stellen in [BGG2004, 193] und [BG2005] Monitoring-Frameworks vor, die einen ähnlichen Ansatz verfolgen. In [BGG2004, 196] werden zu überwachenden Eigenschaften in Form von Kommentaren in den BPEL-Quellcode eingefügt. So ist zwar eine einfache Zuordnung der Zusicherungen zu den Anweisungen im BPELCode möglich, aber die Zusicherungen können nicht von der Workflow-Spezifikation getrennt werden. Dieser Nachteil wird in [BG2005] 270] aufgehoben. Weiterhin ist es in beiden Arbeiten zwar möglich auf Timeouts und auf Fehlermeldungen beim Aufruf externer Dienste zu reagieren. Weitere Dienstgüte-Eigenschaften können jedoch nicht überwacht werden. Fokus dieser Arbeit ist es eine Prüfung der funktionalen Korrektheit vorzunehmen, und im Fehlerfall adäquat zu reagieren. In [BGG2004, 200] werden zur Auswertung der Zusicherungen zwei mögliche Ansätze vorgestellt. Beim ersten Ansatz können die Zusicherungen als beliebiger C#-Code spezifiziert werden, welcher erst zur Laufzeit des Workflows an den Monitoring Service gesendet, und dort kompiliert und ausgeführt wird. Beim zweiten Ansatz kann der Monitoring-Service mit Hilfe von xLinkIt [NCEF2002, 152] prädikatenlogische Formeln erster Ordnung überprüfen. In beiden Fällen muss der Workflow auf die Antwort des Monitors warten, bevor er fortgesetzt werden kann. Diese Einschränkung wird von unserem in Abschnitt 3.3

216

Jochen Müller, Florian Jostock, Joachim Götze, Paul Müller

vorgestelltem Monitor aufgehoben. Der Workflow kann dort weiterlaufen, während Ereignisse übertragen werden. In [BG2005], 269] erweitern Baresi et al. ihr Framework. Der Workflow kommuniziert nun nicht mehr direkt mit den Dienstanbietern und dem Monitoring-Service, sondern über einen Proxy-Service, der zunächst die Zusicherungen prüft, und dann entsprechend der Monitoring Regeln Maßnahmen ergreift. Dieser Ablauf wird in Abbildung 4-1 visualisiert.

Abb. 4-1: Dynamic Monitoring of WS-BPEL Processes [BG2005], 275]. Der BPEL²-Präprozessor instrumentiert den Workflow. Dies ermöglicht zwar sehr komplexe Monitoring-Regeln und eine flexible Fehlerbehandlung. Die Ausführungsgeschwindigkeit des Prozesses ist jedoch abhängig von der Erreichbarkeit und Geschwindigkeit des Monitoring-Managers, da die Aktivität ohne ihn nicht ausgeführt werden kann. Weiterhin werden von Orchestrierungssprachen wie BPEL bereits ausreichende Möglichkeiten zur Fehlerbehandlung zur Verfügung gestellt. Unser Ansatz unterscheidet sich in zwei Punkten von diesem Ansatz. Zum einem wird die Performanz des Workflows kaum beeinflusst, da der Ablauf des Workflows nicht durch den Monitoring-Manager unterbrochen wird. Stattdessen kommuniziert der Workflow weiterhin direkt mit den Webservices, und sendet Statusinformationen gleichzeitig an den Ereignisempfänger. Nur bei komplexen Zusicherungen, die mit BPEL nicht ausgewertet werden können, muss er auf dessen Antwort warten. Die meisten Zusicherungen sind jedoch einfacher. Weiterhin müssen in unserem Ansatz nicht alle Informationen über die Instrumentierung in den Workflow integriert und an den Ereignisempfänger gesendet werden, da der Ereignisempfänger und der Instrumentierer auf eine gemeinsame Datenbasis zugreifen. Der Workflow muss dadurch nicht so stark verändert werden, wodurch das Risiko von ungewollten Verhaltensänderungen des Prozesses sinkt. Lazovik et al. [LAP2004, 99] stellen ein umfangreicheres Framework vor, dass neben dem Monitoring, auch die Zusammenstellung des Prozesses übernimmt. Dabei wird

Workflow Monitoring in Service-Orientierten Architekturen

217

die gesamte Fehlerbehandlung des Prozesses mit dem Monitoring kombiniert. Zur Spezifikation des Prozesses kommt daher nicht BPEL zum Einsatz. Der Benutzer übermittelt zunächst eine XSRL-Anfrage (XML Service Request Language, siehe [APY+2002, 80]), die den gewünschten Webservice beschreibt, an den Monitor. Die zu überwachenden Eigenschaften (Zusicherungen oder Assertions) werden mit der eigens eingeführten Sprache XSAL (XML Service Assertion Language) spezifiziert, die an XSRL angelehnt wurde. Der Monitor lässt sich dann, für das an ihn übermittelte Ziel, einen Plan vom Planer zusammenstellen. Entsprechend des Planes und der Zusicherungen ruft der Monitor dann die notwendigen Services mit Hilfe des Executors auf. Nachdem ein Service ausgeführt wurde, passt der Monitor das Ziel an die neue Situation an, indem die Zusicherungen überprüft werden, und erstellt einen neuen Plan. Abbildung 4-2 veranschaulicht die Struktur des Frameworks.

Abb. 4-2: Associating Assertions with Business Processes [LAP2004, 82]. Das Ziel und die Zusicherungen werden zunächst dem Monitor übergeben. Dieser holt sich die Schnittstellenbeschreibungen der Dienste und lässt einen Plan generieren, der die Zusicherungen und das Ziel erfüllt. Nach Ausführung eines Dienstes wird der Zustand des Prozesses aktualisiert und der Plan überprüft. Mahbub et al. [MS2004, 17] stellen ein weiteres Monitoring-Framework für BPELProzesse vor. In diesem Ansatz wird allerdings auf die Instrumentierung des Workflows verzichtet. Stattdessen sendet die Workflow-Engine alle potentiell relevanten Ereignisse an einen Ereignisempfänger von welchem die Ereignisse in einer Datenbank abgelegt werden. Der Monitor liest die Ereignisse dann aus der Datenbank aus, und leitet entsprechend der spezifizierten Anforderungen an den Monitor die relevanten Ereignisse ab. Leider kann bei diesem Ansatz nur eine Workflow-Engine zum Einsatz kommen, die Ereignisse versendet. Weiterhin können nur solche Ereignisse ausgewertet werden, die von der Workflow-Engine auch versendet werden.

218

Jochen Müller, Florian Jostock, Joachim Götze, Paul Müller

Es ist auch nicht möglich, den Prozess nach der Prüfung einer Zusicherung abzubrechen, oder eine Fehlerbehandlung durchzuführen, zum Beispiel indem ein anderer Dienstanbieter für einen fehlgeschlagenen Dienst ausgewählt wird.

5

Realisierung und Ausblick

Das Realisierungsszenario für die in Kapitel 2 angesprochenen Prozesse der Flächenutzungsplanung sieht folgendermaßen aus. Eine Gemeinde will das Beteiligungsverfahren der FNP durch Informations- und Kommunikationstechnologien unterstützen bzw. automatisieren. Die dafür benötigten Software-Funktionalitäten will die Gemeinde nicht selbst erstellen, sondern über Web Services von externen Anbietern beziehen. Die folgende Abbildung bildet das Zusammenspiel der verschiedenen Komponenten ab. Der Domain Manager wurde als Portal-Architektur realisiert, welche in [MKM2005, 74] beschrieben ist. In der vorliegenden Arbeit wird ein Kommunikationsmodell zwischen den Komponenten beschrieben und ein Architekturmodell für die Ausführungs- und Monitoring-Komponente vorgeschlagen.

Initial-Event

Workflow Ausführung und Monitoring

interagiert

Beauftragt und autorisiert

Service Provider Gemeinde (Service Requestor)

request

Domain Manager (Service Broker)

Service Provider

Service Provider

publish

compose

Abb. 5-1: Realisierungsszenario für die Flächennutzungsplanung. Die Gemeinde stellt eine Anfrage an den Domain Manager. Dieser komponiert den Workflow und beauftragt und autorisiert die Ausführungs- und Monitoring-Komponente. In dem von uns untersuchten Szenario, wollen wir die Komposition des Workflows unabhängig von dessen Ausführung realisieren. Vor diesem Hintergrund haben wir unsere bis hierhin angestellten Überlegungen präsentiert. Das hier vorgestellte Konzept stellen die Grundlage für einen von uns entwickelten Prototypen dar, welcher die Ausführung des Service-orientierten Workflows übernimmt und überwacht. Die in dem schon erwähnten Projekt gemachten Erfahrungen haben gezeigt, dass speziell im Bereich des E-Government die Nutzung von Service-orientierten Workflows große Einsatzpotentiale haben. Die Prozesse in unterschiedlichen Verwaltungen ähneln sich stark, so dass nach einer einmaligen Abbildung eine Wiederverwendung möglich ist. In unserem Architekturmodell geschieht die Abbildung durch

Workflow Monitoring in Service-Orientierten Architekturen

219

den Domain-Manager, da die begrenzten Ressourcen in öffentlichen Verwaltungen es notwendig machen, die Komposition und Ausführung der Workflows durch externe Service Provider zu erbringen.

Literaturverzeichnis [ACD+2003] Andrews, T.; Curbera, F.; Dholakia, H.; Goland, Y.; Klein, J.; Leymann, F.; Liu, K.; Roller, D.; Smith, D.; Thatte, S.; Trickovic, I.; Weerawarana, S.; Business Process Execution Language for Web Services Version 1.1. Mai 2003. http://www.ibm.com/developerworks/library/ws-bpel/. [ACKM2004] Alonso, Gustavo; Casati, Fabio; Kuno, Harumi; Mahiraja, Vijag: Web Services Concepts, Architectures and Applications. Springer, 2004. [APY+2002] Aiello, Marco; Papazoglou, Mike P.; Yang, Jian; Carman, M.; Pistore, Marco; Serafini, Luciano; Traverso, Paolo: A Request Language for Web-Services Based on Planning and Constraint Satisfaction. In: TES '02: Proceedings of the Third International Workshop on Technologies for E-Services. London, UK : Springer-Verlag, 2002, S. 7685. [BG2005] Baresi, Luciano; Guinea, Sam: Towards Dynamic Monitoring of WS-BPEL Processes. In: ICSOC '05: Proceedings of the 3th international conference on Service oriented computing, 2005, S. 269-282. [BGG2004] Baresi, L.; Guinea, S.; Ghezzi, C.: Smart Monitors for Composed Services. In: ICSOC '04: Proceedings of the 2nd International Conference on Service Oriented Computing, 2004, S. 193-202. [BOH2002] Bowring, Jim; Orso, Alessandro; Harrold, Mary J.: Monitoring deployed software using software tomography. In: PASTE '02: Proceedings of the 2002 ACM SIGPLANSIGSOFT workshop on program analysis for software tools and engineering, 2002, S. 29. [GTJ+2002] Gunter, Dan; Tierney, Brian; Jackson, Keith; Lee, Jason; Stoufer, Martin: Dynamic Monitoring of High-Performance Distributed Applications, 2002, S. 163 [HGMM05] Hillenbrand, Markus; Götze, Joachim; Müller, Jochen; Müller, Paul: Role-based AAA for Service Utilization in Federated Domains. In: DFN-Arbeitstagung über Kommunikationsnetze, 2005, S. 205-219. [HKMQ2004] Hofmann, R.; Klar, R.; Mohr, B.; Quick, A.; Siegle, M.: Distributed performance monitoring: Methods, tools, and applications. In: IEEE Transactions on Parallel and Distributed Systems 5 (1994), Nr. 6, S. 585-598. [Hün2005] Hündling, Jens: Modelling Properties of Services. - Hasso-Plattner-Institute for ITSystems-Engineering at the University of Potsdam, 2005. [IBM2006] IBM: WebSphere Process Server for Multiplatforms - Monitoring. 6.0.2. IBM, Dezember 2006. [Klar1995] Klar, Rainer u.a.: Messung und Modellierung paralleler und verteilter Rechensysteme. Stuttgart : B.G. Teubner, 1995. [LAP2004] Lazovik, Alexander; Aiello, Marco; Papazoglou, Mike P.: Associating assertions with business processes and monitoring their execution. In: ICSOC' 04, 2004, S. 94-104.

220

Jochen Müller, Florian Jostock, Joachim Götze, Paul Müller

[MS2004] Mahbub, Khaled; Spanoudakis, George: A Framework for Requirements Monitoring of Service Based Systems. In: ICSOC '04: Proceedings of the 2nd international conference on Service oriented computing. New York, NY, USA : ACM Press, 2004, S. 17-41. [MZKM2007] Müller, J. L.; Zhang, G.; Kahl, T.; Müller, P.: Designing a Service Oriented Domain Architecture. In I-ESA 2007: Proceeedings of the 3rd International Conference of Interoperability for Enterprise Software and Applications, iSTE 2007, S. 151-155. [MKM2005] Müller, Jochen; Kümpel, Andreas; Müller, Paul: Integration und Orchestrierung von Geschäftsprozessen in Web Applikationen - Ein Service-Orientierter Ansatz, in GMDS/GI Workshop Enterprise Application Integration 2005, Marburg, S. 74-81. [NCEF2002] Nentwich, Christian; Capra, Licia; Emmerich, Wolfgang; Finkelstein, Anthony: XLinkIt: A Consistency Checking and Smart Link Generation Service. In: ACM Trans. Inter. Tech. 2 (2002), Nr. 2, S. 151-185. [Nitz2006] Nitzsche, Jörg: Entwicklung eines Monitoring-Tools zur Unterstützung von parametrisierten Web Service Flows, Universität Stuttgart, Diplomarbeit, Januar 2006. [PTDL2006] Papazoglou, Michael P.; Traverso, Paolo; Dustdar, Schahram; Leymann, Frank; Krämer, Bernd J.: Service-Oriented Computing: A Research Roadmap. In: Service Oriented Computing (SOC), Internationales Begegnungs- und Forschungszentrum fuer Informatik (IBFI), Schloss Dagstuhl, Germany, 2006 (Dagstuhl Seminar Proceedings). [Robi2002] Robinson, W.: Monitoring software requirements using instrumented code. In: Proceedings of the 35th Annual Hawaii International Conference on Systems Sciences, 2002, S. 276. [Snod1984] Snodgrass, Richard: Monitoring in a software development environment: A relational approach. In: SIGPLAN Not. 19 (1984), Nr. 5, S. 124-131. [Wild2004] Wildemann, Horst: Monitoring von Geschäftsprozessen. In: VDI-Z 146 (2004), Oktober, S. 80.

Autorenverzeichnis

221

Autorenverzeichnis Prof. Dr. Jan vom Brocke ist Inhaber des HILTI Lehrstuhl für Wirtschaftsinformatik und Geschäftsprozessmanagement an der Hochschule Lichtenstein. Kontakt: [email protected] Dr. Thomas Deelmann ist Leiter der IT-Strategie und -Architektur GHS der Deutsche Telekom AG. Kontakt: [email protected] Florian Dreifus ist Gastwissenschaftler am Institut für Wirtschaftsinformatik im Deutschen Forschungszentrum für Künstliche Intelligenz (DFKI). Kontakt: [email protected] René Fiege ist wissenschaftlicher Mitarbeiter am Fachgebiet Informations- und Wissensmanagement an der TU Ilmenau. Kontakt: [email protected] Wolfgang Glock ist Berater bei der mgm technology GmbH. Kontakt: [email protected] Joachim Götze ist wissenschaftlicher Mitarbeiter der Arbeitsgruppe Integrierte Kommunikationssysteme an der Technischen Universität Kaiserslautern. Kontakt: [email protected] Denis Heinemann ist wissenschaftlicher Mitarbeiter der Arbeitsgruppe Softwaretechnik an der Universität Magdeburg. Kontakt: [email protected] Arne Hormann ist tätig bei xtp Transaction Partners. Kontakt: [email protected] Stefan Huth ist wissenschaftlicher Mitarbeiter der Fakultät Elektrotechnik und Information an der Hochschule Coburg. Kontakt: [email protected] Florian Jostock ist wissenschaftlicher Mitarbeiter der Arbeitsgruppe Integrierte Kommunikationssysteme an der Technischen Universität Kaiserslautern. Kontakt: [email protected] Falk Kretzschmar ist wissenschaftlicher Mitarbeiter am Lehrstuhl für Wirtschaftsinformatik, insbesondere E-Business der Martin-Luther-Universität Halle. Kontakt: [email protected] Katrina Leyking ist wissenschaftliche Mitarbeiterin am Institut für Wirtschaftsinformatik im Deutschen Forschungszentrum für Künstliche Intelligenz (DFKI). Kontakt: [email protected] Prof. Dr. Peter Loos ist Direktor des Instituts für Wirtschaftsinformatik im Deutschen Forschungszentrum für Künstliche Intelligenz (DFKI). Kontakt: [email protected]

222

Autorenverzeichnis

Jochen Müller ist wissenschaftlicher Mitarbeiter der Arbeitsgruppe Integrierte Kommunikationssysteme an der Technischen Universität Kaiserslautern. Kontakt: [email protected] Prof. Dr. Paul Müller ist Leiter der Arbeitsgruppe Integrierte Kommunikationssysteme an der Technischen Universität Kaiserslautern. Kontakt: [email protected] Prof. Dr. Volker Nissen ist Professor für Wirtschaftsinformatik an der Technischen Universität Ilmenau (Fachgebiet Wirtschaftsinformatik für Dienstleistungen). Kontakt: [email protected] Dr. Sven Overhage ist Post-Doktorand am Lehrstuhl für Wirtschaftsinformatik und Systems Engineering an der Universität Augsburg. Kontakt: [email protected] Prof. Dr. Ralf Peters ist Inhaber des Lehrstuhls für Wirtschaftsinformatik, insbesondere E-Business der Martin-Luther-Universität Halle. Kontakt: [email protected] Dr. Mathias Petsch ist wissenschaftlicher Mitarbeiter am Fachgebiet Wirtschaftsinformatik für Dienstleistungen an der TU Ilmenau. Kontakt: [email protected] Prof. Dr. Andreas Schmietendorf ist Professor für Wirtschaftsinformatik mit Schwerpunkt Systementwicklung an der FHW Berlin. Kontakt: [email protected] Thorsten Scholz ist wissenschaftlicher Mitarbeiter des Arbeitsbereichs Intelligente Systeme des Technologie Zentrum Informatik der Universität Bremen. Kontakt: [email protected] Christian Sonnenberg ist wissenschaftlicher Mitarbeiter am HILTI Lehrstuhl für Wirtschaftsinformatik und Geschäftsprozessmanagement an der Hochschule Lichtenstein. Kontakt: [email protected] Prof. Dr. Dirk Stelzer ist Professor für Wirtschaftsinformatik an der TU Ilmenau (Fachgebiet Informations- und Wissensmanagement). Kontakt: [email protected] Prof. Dr. Harald Störrle ist Leiter der Forschungsgruppe Large Scale Software Development an der Universität Innsbruck. Kontakt: [email protected] Prof. Dr. Ingo J. Timm ist Leiter des Fachgebiets Wirtschaftsinformatik und Simulation an der Universität Frankfurt. Kontakt: [email protected] Timo Traub ist Diplomand am Fachgebiet Wirtschaftsinformatik für Dienstleistungen an der Technischen Universität Ilmenau. Kontakt: [email protected]

Autorenverzeichnis

223

Prof. Dr. Klaus Turowski ist Leiter des Lehrstuhls für Wirtschaftsinformatik und Systems Engineering an der Universität Augsburg. Kontakt: [email protected] Tilmann Walther ist tätig bei der T-Systems Enterprise Services GmbH. Kontakt: [email protected] Prof. Dr. Thomas Wieland ist Professor der Fakultät Elektrotechnik und Informatik an der Hochschule Coburg. Kontakt: [email protected]

Index

225

Index A Ablauforganisation.........................................32 Agent ............................... Siehe Softwareagent Agentenbasierte SOA..................................169

D Datenflussoptimierung .................................. 87 Dienst.......................................... Siehe Service Dienstgüte................... Siehe Quality of Service

Amortisationsrechnung..................................24 Anwendungslandschaft .......................9, 25, 80 Aufbauorganisation..................................22, 32 Authentifizierung..........................................214 Automationsnutzen........................................28 Axiomatic Design...........................................95 Dekomposition ........................................101 Vergleich mit strukturierter Analyse 100, 103

B Balanced Scorecard ......................................24 Blackboard...........................................170, 206 BPEL.......... Siehe Business Process Execution Language BPMN ......... Siehe Business Process Modeling Notation

E eGovernment ...................................... 153, 218 Enterprise Application Integration (EAI) .... 117, 190 Enterprise Service Bus (ESB)......... 31, 65, 149 Enterprise SOA ..................................... 34, 185

F Foundation for Intelligent Physical Agents (FIPA) ............................................. 120, 175 Fuzzy-Logik......................................... 130, 177

G Geschäftsarchitektur ..................................... 49

Business Object Model........................142, 144 Mapping...................................................150

Geschäftsmodell ..................................... 40, 63 Gestaltung ................................................ 47 Informationstechnologie ..................... 47, 48 Strategie ............................................. 46, 48 Transition.................................................. 48

Business Process Execution Language .63, 86, 170, 185, 207, 215

Geschäftsprozess . 4, 21, 61, 83, 155, 167, 206 Definition................................................... 85

Business Process Modeling Notation63, 73, 82

Geschäftsprozessmanagement (GPM) . 21, 29, 73, 77

Business Driven SOA ....................................92 Business Object.....................................78, 142

Business Rules............... Siehe Geschäftsregel

C Capability Management...............................130 Constraint Satisfaction Problems ................178 CORBA ..............................................62, 78, 87 Corporate Performance Measurement........174

Geschäftsprozessmodellierung .............. 62, 84 ereignisgesteuerten Prozessketten (EPK) ..................................................... 63, 190 Methoden.................................................. 62 service-orientierte ereignisgesteuerte Prozessketten (sEPK) .......................... 65 Unified Modelling Language (UML).. 85, 146 Geschäftsregel Definition................................................. 176

226

Index

Klassifizierung .........................................177

Komponenten ......................................... 212

Governance .................................................123

Multiagentensystem ............................ 117, 168

I

N

Informationssystem Definition ...................................................95

Nutzenerhebung ........................................... 20

Informationstechnologie ..........................42, 61 Bewertung von Investitionen .....................20 Geschäftsmodell .................................47, 48 Infrastruktur .........................................31, 49 Kontextabhängigkeit..................................22 Nutzenkategorie ........................................42 Strategie ..............................................44, 48 Wettbewerbsstrategie ...............................45 Integration............... 3, 30, 49, 53, 79, 130, 187 Integrationsnutzen .........................................29 Investitionskosten ..........................................31 Investitionsrechnung......................................24 IT-Business-Alignment ............................41, 54 IT-Governance.............................................173

J Java Agent Development Framework (JADE) .........................................................133, 159

Nutzenpotenziale ...................... 20, 25, 79, 169 Praxisbeispiel ........................................... 34

O Object Constraint Language (OCL), ........... 176 Objektorientierung....................................... 124 Ontologie DAML-S .................................................. 120 Definition................................................. 175 Open SOA Ontology....................... 176, 178 Web Service Ontologie (OWL-S) .. 120, 170, 185 Orchestrierung ............................ 6, 77, 85, 210 Agenteneinsatz....................................... 173 Definition........................................... 61, 170 Methodik ................................................... 10 Organisationseinheit ..................................... 40 Organisationsgestaltung ....................... 33, 186 Organisationsstruktur.................................... 32

K

P

Komponente ............................. 5, 78, 155, 169

Projektrahmenbedingungen.......................... 80

M

Prozesscontrollling..... Siehe serviceorientiertes Prozesscontrolling

Middleware ............................................78, 135 Model Driven Architecture (MDA)....77, 85, 147 Modellierung ..................................................96 Geschäftsprozess ............................... Siehe Geschäftsprozessmodellierung Ist-Analyse.................................................81 Modellprüfung .................................122, 127 Service ......................................................83 Soll-Analyse ..............................................81

Prozesskennzahl................................... 21, 188 Prozessmodell ................................ 25, 86, 188 Prozessoptimierung ........................ 29, 72, 189 Prozessperspektive....................................... 27

Q Qualitätsmanagement................................. 122 Qualitätsprüfung.......................................... 123

Monitoring ............................................125, 207 Anforderungen ........................................211

Qualitätssicherung .......................... 82, 91, 120 Serviceorientierte Architektur ................. 122

Index

227

Software ..................................................121

Agenteneinsatz....................................... 174

Quality of Service (QoS).... 116, 119, 130, 155, 163, 209, 211

Serviceorientierte Architektur Abgrenzung .......................................... 4, 78 Agenteneinsatz............................... 169, 171 Autonomie ........................................ 97, 105 Bewertung von Investitionen .................... 21 Definition.. 4, 61, 77, 95, 141, 155, 167, 185, 205 Einsatzmöglichkeiten.......................... 3, 192 Enterprise Service Bus .......Siehe Enterprise Service Bus Funktionale Eigenschaften ..................... 173 Herausforderungen................. 3, 10, 21, 142 Infrastruktur ...................................... 84, 187 Kompatibilität ............................................ 34 Komposition.......... 6, 11, 118, 159, 170, 206 Konzept .................................................... 65 Koordination ........................................... 156 Lose Kopplung............................ 30, 97, 106 Modellierung ............................... 72, 81, 100 Modularisierung ........................................ 30 Monitoring....................................... 125, 209 Nicht-funktionale Eigenschaften..... 155, 209 Nutzenpotentiale..... Siehe Nutzenpotenziale Paradigma ...................................... 3, 70, 77 Testverfahren ......................................... 124 Verhandlung ........................... 119, 157, 178 Vorgehensmodell...................................... 82 Werkzeugkette.......................................... 72 Wiederverwendung............................... 3, 97 Wirtschaftlichkeit....................... 22, 186, 199 Ziele .................................... 83, 96, 105, 155

R Rational Unified Process (RUP) ....................82 Responsive Replenishment...........................34 Return on Investment (ROI) ..................25, 188 Robustheit .................................... 32, 126, 169

S Schnittstellen ................................ 83, 118, 205 Reduktion ..................................................34 Schnittstellenbeschreibung .................6, 158 Spezifikation ............................................206 Service Abgrenzung .................................................7 Aufrufarten.................................................64 Bewertung ...............................................193 Definition .................................6, 40, 77, 115 Granularität............. 28, 40, 78, 97, 106, 117 Kapselung ...............................................117 Katalogisierung .........................................11 Klassifikation .........................................8, 64 Kompatibilität.............................................12 Lebenszyklus.........................................5, 78 Leistungsverrechnung.................................8 Merkmale.......................................9, 79, 157 Programmierparadigma ............................10 Registrierung ...........................................132 Repository .................................................12 Semantische Beschreibung .... 11, 120, 141, 158, 175 Software Agent........................................172 Suche ......................... 12, 65, 118, 132, 142 Wiederverwendung ............ 5, 6, 30, 89, 117 Zertifizierung............................. 11, 129, 177 Service Broker .................... 155, 171, 209, 217 Agenteneinsatz .......................................174 Service Level Agreement (SLA) ..........116, 156 Service Portfolio ..........................................187 Service Provider ..........................................155 Service Requestor ...............................155, 171

Serviceorientierter Workflow (SOW)........... 205 Serviceorientiertes Prozesscontrolling (SOPC) .......................................................... 25, 187 Ziele ........................................................ 189 Serviceverzeichnis ......................... Siehe UDDI Shared Information Data Model (SID) ........ 143 Simulation ................................................... 158 SOA ..........Siehe Serviceorientierte Architektur SOAP .......................................... 115, 141, 185 Software Engineering ................... 96, 116, 122 Evaluationsmodell .................................. 129 objektorientierte Analyse .......................... 99 objektorientiertes Design .......................... 99 serviceorientierte Analyse ........................ 99

228 serviceorientiertes Design.................99, 120 strukturierte Analyse .........................98, 102 strukturiertes Design .................................98 Transformation ..........................................84 Softwareagent .............................118, 131, 158 Architekturen ...........................................168 BDI-Agenten............................................170 Definition .................................................168

Index Unternehmensdatenmodell...... Siehe Business Object Model

V Validierung .......................................... 120, 132 Verifikation .................................................. 120 Virtuelle Unternehmen ................................ 115

Standardisierung .............................24, 82, 115 Strategie ..................................................22, 41 Activity-System..........................................41 Geschäftsmodell .................................46, 48 Informationstechnologie ......................44, 48 Strategic Alignment Model ........................49 Strategieentwicklung .................................42 Teilstrategie...............................................50 Unternehmensstrategie.............................28 Strategy-Maps ...............................................25

W Wasserfallmodell........................................... 81 Web Service.............................. 9, 78, 115, 155 Agenteneinsatz............................... 118, 172 Qualität ................................................... 119 Vergleich mit Software Agenten ............. 169 Wirtschaftlichkeitsanalyse............................. 25 Workflow .... Siehe Serviceorientierter Workflow

T

WSDL.................................... 83, 115, 141, 173

Time To Market .............................................30

X

Total Cost of Ownership (TCO) .......21, 35, 188

U UDDI ........................... 115, 120, 158, 173, 209 Schwachstellen .......................................158 UML .........................................................62, 83

XML....................................................... 62, 145 Service Assertion Language (XSAL)...... 217 Service Request Language (XSRL) ....... 217

Z Zertifizierungsmanagement ........................ 131