10 Antworten zu SOA. Stefan Reinheimer, Florian Lang, Jörg Purucker, Hinnerk Brügmann. Frage 1: Was ist SOA? Inhaltsübersicht

Transkript

1 Stefan Reinheimer, Florian Lang, Jörg Purucker, Hinnerk Brügmann 10 Antworten zu SOA Im Zentrum von serviceorientierten Architekturen (SOA) steht ein Architekturkonzept, das sowohl aus einer technologischen als auch einer geschäftsgetriebenen Perspektive betrachtet werden muss. Mit dem Thema werden hohe Erwartungen verbunden, die sich allerdings noch nicht in entsprechenden Erfahrungen widerspiegeln. Trotzdem lassen sich klare Zielsetzungen und Nutzenpotenziale identifizieren. Mit Antworten auf 10 Schlüsselfragen werden die zentralen Inhalte rund um SOA erörtert und die Zusammenhänge zu angrenzenden Themen aufgezeigt. Inhaltsübersicht Frage 1: Was ist SOA? Frage 2: Was ist SOA nicht? Frage 3: Was ist die Zielsetzung von SOA? Frage 4: Wer sollte in einem Unternehmen der Treiber von SOA sein? Frage 5: In welcher Beziehung stehen Web-Services zu SOA? Frage 6: Wie kann SOA technisch realisiert werden? Frage 7: In welcher Beziehung steht BPM zu SOA? Frage 8: Welche Erfahrungen gibt es bislang mit SOA? Frage 9: Was ist der Nutzen von SOA? Frage 10: Wie wird sich SOA entwickeln? Literatur Über SOA ist jüngst viel geschrieben worden, deshalb wollen wir mit dem hier gewählten Format versuchen, die zentralen Fragestellungen ohne Umschweife zu adressieren und sowohl dem Einsteiger als auch dem Erfahrenen einen als Ganzes oder selektiv lesbaren Grundlagenbeitrag bieten. Frage 1: Was ist SOA? Serviceorientierte Architekturen zielen darauf ab, Softwaresysteme flexibler zu gestalten, um diese auch nach der Ersteinführung schnell und adäquat an geänderte Bedürfnisse des Geschäftssystems anpassen zu können. Ein Schwerpunkt liegt dabei auf der Unterstützung von Geschäftsprozessen. Serviceorientierte Architekturen sind eine spezielle Form von Softwarearchitekturen. Eine Softwarearchitektur beschreibt die Komponenten eines Softwaresystems und deren Beziehungen untereinander. Anhand der Softwarearchitektur wird die Funktion der einzelnen Komponenten im Gesamtsystem bestimmt (vgl. [Krafzig et al. 2004, S. 40 ff.]). Kernprinzip serviceorientierter Architekturen ist der Aufbau von Softwaresystemen aus lose gekoppelten Funktionsbausteinen (Services) mit klar umrissenen fachlichen Aufgaben. Die Geschäftslogik eines Softwaresystems wird damit auf mehrere weitgehend voneinander unabhängige Services verteilt. Die Services kapseln Daten und Anwendungslogik. Durch die lose Kopplung der Services und die klare Aufgabentrennung sollen Softwarearchitekturen vor allem übersichtlicher und flexibler werden. Flexibilität entsteht dadurch, dass das Zusammenspiel der Komponenten leichter geändert werden kann. Neue Komponenten können einfacher hinzugefügt und bestehende leichter erweitert oder ausgetauscht werden (vgl. hierzu auch die Antwort auf Frage 3: Was ist die Zielsetzung von SOA?). Auf diese Weise kann ein Softwaresystem schneller angepasst werden, wenn sich die Anforderungen des Geschäftssystems ändern. Kernbestandteile serviceorientierter Architekturen sind Application Frontends, Services, HMD 253 7

2 das Service-Repository und der Service-Bus (vgl. im Folgenden [Krafzig et al. 2004, S. 26 ff.]).! Application Frontends bilden die Schnittstelle des Softwaresystems nach außen. Über sie werden Aktivitäten des Systems gestartet und Ergebnisse zurückgeliefert. Typische Beispiele für Application Frontends sind grafische Oberflächen zur Interaktion mit Benutzern oder Batch-Programmen.! Ein Service ist ein Dienst mit einer klar definierten Leistung. Services repräsentieren Geschäftslogik und sind tendenziell grobgranular. Für jeden Service gibt es eine oder mehrere Schnittstellen und einen Service- Contract. Der Service-Contract enthält normalerweise eine formale Beschreibung der Schnittstelle sowie eine Beschreibung der Funktionalität, der Nutzung und der Anwendungsbedingungen des Service. Die Implementierung, also die konkrete Verarbeitungslogik, und die Datenzugriffe werden vor dem Benutzer verborgen.! Im Service-Repository sind Informationen abgelegt, die zur Identifikation geeigneter Services sowie zu deren Nutzung benötigt werden. Dazu gehören z. B. Informationen zum Aufruf des Service, zum Anbieter, zur fachlichen Klassifikation, zur Bezahlung, zur Sicherheit und zu Service Level Agreements.! Der Service-Bus stellt die Verbindung zwischen den Services und zwischen Services und Application Frontends her. Der Service- Bus muss auch Verbindungen zwischen Komponenten ermöglichen, die mit unterschiedlichen Technologien entwickelt wurden. Dabei sind unterschiedliche Kommunikationsformen wie synchrone und asynchrone Kommunikation zu unterstützen. Frage 2: Was ist SOA nicht? SOA ist weder ein Produkt noch eine Technologie oder ein Technologiestandard. SOA ist ein technologieunabhängiges Architekturkonzept, das Softwarearchitekturen einfacher und flexibler machen soll und dabei die Wiederverwendung bestehender Komponenten unterstützt. SOA ist nicht an bestimmte Technologien wie etwa Web-Services gebunden. Vielmehr können serviceorientierte Architekturen aus Komponenten aufgebaut werden, die mit unterschiedlichen Technologien entwickelt wurden [Brabänder & Klückmann 2006, S. 1]. Frage 3: Was ist die Zielsetzung von SOA? Geschäftssysteme, insbesondere Geschäftsprozesse, ändern sich häufig. Dies liegt unter anderem an der erhöhten Marktdynamik, an kürzeren Entwicklungszeiten neuer Technologien und an Anpassungen der Unternehmensorganisationen (z. B. Unternehmenszusammenschlüsse, Outsourcing). Die Unternehmens-IT steht damit regelmäßig vor der Herausforderung, die Softwarelandschaft an die geänderte Ausgangssituation anzupassen. Serviceorientierte Architekturen sollen die Anpassung von Softwaresystemen an geänderte Bedürfnisse des Geschäftssystems vereinfachen. Durch die lose Kopplung der Services können diese bei Anpassungen oder Erweiterungen des Systems einfacher ausgetauscht oder neu zusammengestellt werden (vgl. [Krafzig et al. 2004, S. 6 f. und S. 239 ff.]). Auf diese Weise sollen Geschäftsprozesse flexibler werden, da Änderungen schneller umgesetzt werden können. Die einfachere Wiederverwendung bestehender Services soll serviceorientierte Architekturen flexibler machen als die bislang bekannten monolithischen Applikationen und Systeme. Darüber hinaus soll sie Kosteneinsparungen ermöglichen und das Entwicklungsrisiko senken. Kosteneinsparungspotenziale ergeben sich dadurch, dass bestimmte Funktionalitäten nicht mehrfach entwickelt werden müssen. Das Entwicklungsrisiko kann durch die Wiederverwendung bestehender Services gesenkt werden, weil diese im Unterschied zu Neuentwicklungen in der Regel bereits in der Praxis getestet wurden. Ein anderer wichtiger Aspekt der Wieder- 8 HMD 253

3 verwendung ist die Reduzierung von Funktionsbausteinen, die gleiche oder verwandte Inhalte in unterschiedlichen Datenspeichern ablegen. Die Wiederverwendung von Services soll dazu beitragen, redundante Datenhaltungen zu vermeiden (vgl. [Krafzig et al. 2004, S. 6 f.]). Eine weitere Zielsetzung serviceorientierter Architekturen besteht darin, die Technologieabhängigkeit der Anwendungen zu reduzieren. Ein wichtiger Aspekt der Technologieunabhängigkeit ist die technische Verknüpfung von Services, die auf unterschiedlichen Technologien basieren. Dazu wird der Service-Bus verwendet. Ein anderer Aspekt ist die Möglichkeit, eingesetzte Technologien im Zeitverlauf zu ändern. Dies soll dadurch erreicht werden, dass Services auf fachlicher Ebene definiert werden und die Implementierung der Services von der fachlichen Definition getrennt wird. Auf diese Weise kann die technische Umsetzung des Service einfacher geändert werden. Gleichwohl kann auch mit einer serviceorientierten Architektur keine vollständige Technologieunabhängigkeit erreicht werden. Zum einen basiert auch der Service-Bus auf einer bestimmten Technologie. Zum anderen ist die Konfiguration des Zusammenspiels der Services komplex und mit nicht unerheblichen Aufwendungen verbunden (vgl. [Krafzig et al. 2004, S. 6 f.]). Serviceorientierte Architekturen sollen auch dazu beitragen, Softwarearchitekturen übersichtlicher und verständlicher zu machen. An der Entwicklung von Softwarearchitekturen sind meist mehrere Personen mit unterschiedlichen Rollen, Perspektiven und Vorkenntnissen beteiligt, die alle mit der Architektur arbeiten müssen. Eine klare aufgabenbezogene Trennung der Komponenten, wie sie bei serviceorientierten Architekturen angestrebt wird, soll die Kommunikation der Softwarearchitektur vereinfachen (vgl. [Krafzig et al. 2004, S. 6 f.] und Antwort auf die Frage 9: Was ist der Nutzen von SOA?). Frage 4: Wer sollte in einem Unternehmen der Treiber von SOA sein? In einer Studie von Capgemini sind 38 % der Befragten der Ansicht, dass es sich bei SOA um ein Managementkonzept handle, für 27 % steht der technische Aspekt im Vordergrund [Capgemini 2006]. Die Zeiten, in denen IT-Lösungen um der Technik Willen eingeführt wurden, sind vorbei. Business-Anforderungen sind der Treiber für die IT. Dies gilt selbstverständlich auch für das Thema SOA (vgl. Beitrag von [Schelp & Stutz 2007] in diesem Heft). Das Management hängt von einer hohen Anpassungsfähigkeit der Organisation und des Geschäftsmodells ab. Anforderungen an die IT resultieren aus den Prozessbedarfen, in denen Agilität und Flexibilität einer Unternehmung implementiert sein müssen. Die Zusammenarbeit von Fachbereich und IT lässt sich über drei Ebenen hinweg beobachten (vgl. [Capgemini 2006]): 1. Die Identifikation (vgl. Beitrag von [Klose & Knackstedt 2007] in diesem Heft) und Komposition von erfolgversprechenden Services über sämtliche Produkte und Organisationseinheiten hinweg ist Aufgabe der Fachbereiche. Sie ist die Grundlage für SOE (Service Oriented Enterprise). 2. Die Vorgaben aus der fachlichen Prozesswelt greift die IT auf und realisiert bzw. komponiert die technische Umsetzung auf Basis von etablierten Standards. Ihre Verwaltung erfolgt im Rahmen von SOA (Service Oriented Architecture). 3. Die Grundlage für diese flexible Architektur bietet wie bei allen IT-Architekturen die technische Infrastruktur, die daher als Service Oriented Infrastructure (SOI) bezeichnet wird. Projekte zur Realisierung einer SOA im Unternehmen sollten daher nicht technisch, sondern Business-getrieben sein (vgl. [Röwekamp 2006]). Die Governance wechselt zwischen den Aufzählungspunkten 1 bis 3 vom Fachbereich hin zur IT. HMD 253 9

4 Die Ausgestaltung der Zusammenarbeit für diesen neuen, gemeinsamen Verantwortungsbereich bedarf klarer Zuständigkeiten entlang des gesamten Service-Lifecycles vom Zuschnitt des Service, seiner technischen Realisierung, seiner Einführung, seiner laufenden Maintenance, seiner Wiederverwendung bis hin zur verursachungsgerechten Leistungsverrechnung, um politisch induzierte Ineffizienzen vermeiden zu können. Innerhalb der Fachbereiche ist eine wesentliche Unterstützung durch Kompetenzen aus dem Bereich des Prozessmanagements (vgl. hierzu auch die Antwort auf Frage 7: In welcher Beziehung steht BPM zu SOA? und den Beitrag von [Thomas et al. 2007] in diesem Heft) von herausragender Bedeutung, denn schließlich soll die IT die Vorgaben aus den fachspezifischen Prozessen umsetzen. Frage 5: In welcher Beziehung stehen Web-Services zu SOA? SOA ist ein abstraktes Konzept, das im Gegensatz zu klassischer Middleware eine tiefgehende fachliche Komponente besitzt und auch ohne technische Implementierung existieren kann. Web-Services stellen eine von mehreren Möglichkeiten einer solchen technischen Implementierung dieses Konzepts dar und sind nach [Krcmar 2004, S. 274] als konkrete Instanz der SOA zu verstehen (vgl. auch: HMD 234). Für die Zusammenarbeit der Rollen Service- Requestor, Service-Provider und Service-Broker ist eine Infrastruktur nötig, die die Veröffentlichung eines Dienstes durch den Service- Provider, das Suchen und Auffinden von Diensten durch den Service-Requestor und die Anbahnung des Kontakts sowie das dynamische Binden der Schnittstellen zwischen beiden durch den Service-Broker unterstützt. Entsprechend dieser Anforderungen müssen in der konkreten Implementierung sowohl Schnittstellen und Metabeschreibung der Web- Services selbst als auch ihre Repräsentation in einem Dienstverzeichnis standardisiert sein. Des Weiteren ist eine lose Kopplung zwischen den Web-Services erforderlich, damit diese dynamisch gesucht, gefunden und gebunden werden können. Hier kann weitergehend zwischen der Nutzung gänzlich unbekannter Serviceangebote und dem dynamischen Binden von Serviceangeboten, die über eine standardisierte Schnittstellenspezifikation verfügen, unterschieden werden. Lose Kopplung bezieht sich auf die Vermeidung von künstlichen Abhängigkeiten zwischen den kommunizierenden Parteien, wie sie beispielsweise aus der Verwendung von proprietären Schnittstellen entstehen können. Zur weiteren Vermeidung von Abhängigkeiten soll ein Web-Service keine Informationen darüber verwenden, in welchem Kontext er aufgerufen wurde, und somit zustandslos sein. Eine Kapselung der Implementierung als Blackbox erlaubt es, den Web-Service unabhängig von seiner Schnittstelle zu ändern, und erleichtert eine Wiederverwendbarkeit, die wiederum zur Verkürzung von Entwicklungszyklen und letztlich zu Kosteneinsparungen führt. Im Vergleich zu klassischen Middleware-Systemen ermöglichen Standardisierung und lose Kopplung darüber hinaus die flexible Anpassung der Zusammenstellung (Orchestrierung) von mehreren Web-Services, beispielsweise anlässlich der Änderung von unterstützten Prozessflüssen [Dostal et al. 2005, S. 9]. Der Einsatz von Web-Services bedeutet allerdings keinesfalls automatisch auch das Vorhandensein einer SOA. Hierzu bedarf es der strikten Ausrichtung an den Geschäftsprozessen und deren Abbildung durch Web-Services geeigneter Granularität mittels Orchestrierung. Frage 6: Wie kann SOA technisch realisiert werden? Da der SOA-Design-Ansatz technologieunabhängig ist, kann er durch unterschiedliche Technologien umgesetzt werden. Neben Web-Services ist eine Realisierung beispielsweise auch 10 HMD 253

5 mittels traditioneller Middleware-Lösungen wie OMG CORBA (Common Object Request Broker Architecture) oder Microsoft COM (Component Object Model) möglich. Allerdings scheint die Implementierung mittels Web-Services zurzeit von Analysten und Softwareherstellern am stärksten favorisiert und wird daher detaillierter ausgeführt. Der Unterschied zwischen Web-Services und traditionellen Middleware-Ansätzen besteht im Grad der Kopplung zwischen den Komponenten [Weerawarana et al. 2005, S. 32 f.]. Durch eine Trennung der Web-Service-Bestandteile in Schichten, die standardisierte Schnittstellen anbieten, entsteht eine lose Kopplung, in der einzelne Komponenten dynamisch austauschbar sind. Das Zwiebelschalenmodell nach [Burghardt & Hagenhoff 2003] illustriert die aufeinander aufbauenden Funktionalschichten. Die fachliche Komplexität nimmt hierbei von innen nach außen zu. Abbildung 1 illustriert die verbreitete SOAP-Architektur (Simple Object Access Protocol), allerdings existieren teilweise für die Implementierung einer Schicht alternative Technologien. Im Kern steht die zu erbringende Dienstleistung. Der diese Dienstleistung implementierende und über ein Netzwerk anbietende Web- Service ist entweder neu zu erstellen, oder es wird für eine bestehende Applikation ein UDDI»Wrapper«geschaffen. Dieser stellt standardisierte Schnittstellen nach außen zur Verfügung und implementiert gegebenenfalls zusätzliche Funktionalitäten, wie beispielsweise Sicherheitsmechanismen [Hohpe 2002]. Die zur Durchführung der Dienstleistung notwendigen Informationen werden zwischen Web-Service und Service-Requestor durch Nachrichten in der Metasprache XML ausgetauscht. Zum Transport dieser Informationen dient der Rumpf einer SOAP-Nachricht. SOAP- Nachrichten besitzen darüber hinaus zur generischen Erweiterbarkeit ein optionales Kopfelement, in dem zusätzliche Informationen wie beispielsweise Authentifizierungsdaten enthalten sein können. Das Trägerprotokoll für SOAP ist nicht festgelegt. Während die Vorreiter unter den größeren Softwareherstellern den HTTP-Standard favorisieren, finden im industriellen Umfeld häufig klassische EAI-Frameworks und deren interne Protokolle Verwendung. Allerdings wäre auch ein Transport über weitere Trägerprotokolle wie beispielsweise SMTP (Simple Mail Transfer Protocol) denkbar. Beschrieben werden Web-Services durch die Web Service Description Language (WSDL). Diese XML-Sprache definiert das Kommunikationsprotokoll, also Aufrufmechanismen und Nachrichtensemantik, der öffentlichen Schnittstelle eines Web-Service. Die Definition ist ab- WSDL SOAP XML Web-Service Dienstleistung Verzeichnis Beschreibung Transport Inhalt Schnittstelle Abb. 1: Zwiebelschalenmodell der Web-Service-Architektur nach [Burghardt & Hagenhoff 2003] HMD

6 strakt und wird erst bei Verwendung durch einen Service-Requestor an ein Netzwerkprotokoll gebunden, sodass der Zugriff plattformunabhängig erfolgen kann. [Keen et al. 2004] nennen als Beispiel einen.net-entwickler, der das WSDL-Dokument eines Java-basierten Web- Service, der in einer Websphere-Umgebung läuft, anfordert und hieraus automatisiert den benötigten.net-zugriffscode erzeugt. Ebenso wie der Kopf einer SOAP-Nachricht ist WSDL um zusätzliche Informationen, beispielsweise bezüglich Sicherheitsmechanismen, erweiterbar [Keen et al. 2004, S. 55]. Als Spezifikation für Verzeichnisse zum Anbieten und Auffinden von Web-Services existiert die UDDI (Universal Description, Discovery and Integration). Mittels SOAP-Anfragen an die UDDI können Web-Services über ihre Metadaten im WSDL-Format im Verzeichnis gefunden werden. Generell als Standard zur Möglichkeit einer öffentlichen, internetweiten Bereitstellung von Web-Services konzipiert, finden UDDI- Verzeichnisse zurzeit vor allem isolierte Verwendung im unternehmensinternen oder Inter- Enterprise-Bereich zwischen kooperierenden Unternehmen. Ein öffentlicher Marktplatz für Serviceangebote findet sich z. B. unter www. strikeiron.com. Frage 7: In welcher Beziehung steht BPM zu SOA? Bei der Neugestaltung und Implementierung von Geschäftsprozessen kommen häufig Methoden und Instrumente des Business Process Management (BPM) zum Einsatz. Serviceorientierte Architekturen (SOA) werden entwickelt, um Anpassungen an Geschäftsprozesse leichter umsetzen zu können. BPM ist ein Ansatz zum Management von Geschäftsprozessen zur Umsetzung strategischer und operativer Ziele einer Unternehmung. Zu den Aufgaben des BPM gehören neben der technischen Ausführung von Prozessen vor allem Analyse, Design und Implementierung sowie ein Monitoring von Prozessen (vgl. [Brabänder & Klückmann 2006, S. 2]). Business- Process-Management-Systeme (BPMS) werden zur technischen Umsetzung von BPM eingesetzt. Abbildung 2 zeigt die Architektur eines BPMS im Überblick. Die Prozessdefinitionen und Prozessinstanzen werden in einer fachlichen Beschreibungssprache wie z. B. Business Process Modeling Language (BPML) modelliert und im Prozess-Repository abgelegt. Ausgeführt werden die Prozessinstanzen über die Prozess- Engine, die dazu über eine Middleware auf die Anwendungssysteme des Unternehmens zugreift. Über den Prozessmanager können Ober- Prozessmanager Prozess-Engine (interpretiert z.b. BPML) Transaktions- Manager Design Administration Monitoring Prozessdefinitionen Prozessinstanzen Konnektor- Framework Abb. 2: Architektur eines BPM-Systems [Krafzig et al. 2004] Middleware Anwendungssysteme 12 HMD 253

7 flächen zur Änderung, Verwaltung und Überwachung der Prozesse eingebunden werden. Für das Design von Geschäftprozessen gibt es eine Reihe von Tools, die die Dokumentation von Sollprozessen mit einer grafischen Notation, wie etwa BPMN (Business Process Modeling Notation), UML (Unified Modeling Language) oder EPK (ereignisgesteuerte Prozessketten) unterstützen. Dagegen stellt die Implementierung von Änderungen an Geschäftsprozessen in vielen Unternehmen eine Herausforderung dar, weil die Prozesslogik meist als integrierte Funktionalität fest in den Anwendungssystemen verankert ist, und die Systeme sowie deren Zusammenspiel in der Regel nur mit hohem Aufwand geändert werden können (vgl. [Brabänder & Klückmann 2006, S. 1]). SOA ist ein Konzept zum Aufbau von Softwarearchitekturen aus lose gekoppelten Services mit definierten Aufgaben, die zur Abbildung der Geschäftslogik eines Unternehmens flexibel zusammengesetzt werden können. Durch SOA sollen Softwarearchitekturen transparenter und flexibler werden (vgl. Antworten auf die Fragen 1: Was ist SOA? und 3: Was ist die Zielsetzung von SOA?). Innerhalb des Business Process Management können serviceorientierte Architekturen dazu beitragen, Anpassungen an Geschäftsprozesse schneller umzusetzen. Die Services dienen dabei als Anwendungsbausteine, die die Prozessausführung unterstützen und entsprechend der Prozesslogik, die im Rahmen von BPM-Aktivitäten definiert wird, zusammengesetzt werden. Damit können Prozesse flexibler gestaltet werden, weil die Prozesslogik nicht mehr unmittelbarer Teil der Anwendungssysteme ist, sondern systemübergreifend definiert und implementiert werden kann (vgl. [Brabänder & Klückmann 2006], S. 1). Eine intelligente Verzahnung von BPMS und serviceorientierten Architekturen kann erreicht werden, wenn bei der Gestaltung der Softwarearchitektur eine Prozessebene mit prozessorientierten Services eingezogen wird. In diesem Fall ist es Aufgabe des BPMS, die prozessorientierten Services auszuführen. Während die Services der darunterliegenden Ebenen die Basisgeschäftslogik eines Unternehmens abbilden, dienen die Services der Prozessebene zur Implementierung der Logik zur Prozesssteuerung. Diese Services sind nicht zustandslos, weil sie den Zustand eines Prozesses (z. B. Prozessfortschritt, Eingaben von Prozessbeteiligten) speichern müssen. Da die Geschäftsprozesse eines Unternehmens häufigen Änderungen unterliegen, haben die Services der Prozessebene in der Regel eine deutlich kürzere Lebenszeit als die Services der darunterliegenden Ebenen. Die Trennung der Logik zur Prozessteuerung von der Basisgeschäftslogik erhöht die Flexibilität der Architektur. Bei Anpassungen an einen Geschäftsprozess kann es in vielen Fällen ausreichen, die Logik zur Prozessteuerung zu ändern, ohne dass die Services der darunterliegenden Ebenen geändert werden müssen. In diesen Fällen werden andere Prozesse von den Änderungen nicht beeinträchtigt (vgl. [Krafzig et al. 2004, S. 112 ff.]). Serviceorientierte Architekturen unterstützen BPM, indem sie dazu beitragen, dass Geschäftsprozesse schneller und einfacher in den Anwendungssystemen umgesetzt werden. Allerdings muss beachtet werden, dass die Überführung einer bestehenden IT-Landschaft in serviceorientierte Architekturen in aller Regel eine ambitionierte Aufgabe ist, die sich über mehrere Jahre erstrecken kann (vgl. [Krafzig et al. 2004, S. 115]). Frage 8: Welche Erfahrungen gibt es bislang mit SOA? Umfassende Erfahrungen mit SOA liegen noch nicht vor das bekannteste Unternehmen, das eine konsequente Einführung von SOA vorgenommen hat, ist die Deutsche Post. Aus einem Report von [Berlecon Research 2006] geht hervor, dass Unternehmen, die zurzeit serviceorientierte Architekturen (SOA) ein- HMD

8 führen, die höhere Flexibilität der IT als entscheidenden Vorteil einer SOA ansehen. Wiederverwendung von Diensten spielt dagegen eine geringere Rolle. Im aktuellen Report»SOA in der Praxis Wie Unternehmen SOA erfolgreich einsetzen«stellen die Berliner Analysten SOA-Projektberichte von acht Unternehmen aus unterschiedlichen Branchen vor und werten diese aus. Dr. Joachim Quantz, Associated Senior Analyst bei Berlecon:»Die Anwender berichten, dass die SOA-Projekte ihre Erwartungen erfüllt oder sogar übertroffen haben. Die wesentlichen Herausforderungen werden auf der organisatorischen Ebene und im Mehraufwand in der Anfangsphase gesehen. Durch sorgfältige Planung lassen sich diese Herausforderungen aber erfolgreich meistern.«nutzeffekte werden nahezu von allen Befragten insbesondere in der höheren Flexibilität der IT und damit in der Agilität der Unternehmung gesehen. Die Wiederverwendung einzelner Services wird nur selten als Hauptnutzen von SOA angeführt. Allerdings muss man erwarten, dass dieser Nutzeffekt auch erst nach einer längeren Verwertung einer SOA im Unternehmen auftreten kann (vgl. [Berlecon Research 2006] und die Antwort auf Frage 9: Was ist der Nutzen von SOA?). Frage 9: Was ist der Nutzen von SOA? Aus der Untersuchung von [Berlecon Research 2006] geht hervor, dass der Hauptnutzen einer SOA in einer deutlich höheren Flexibilität der IT liegt: Neue Dienste und Produkte können schneller eingeführt und existierende Services effizienter an neue Anforderungen angepasst werden. Weitere Vorteile sind Kosteneinsparungen, höhere Transparenz und Qualität. Darüber hinaus können Dienste in unterschiedlichen Anwendungskontexten wiederverwendet werden. Diese ebenfalls kostensenkende Wiederverwendung ist aber nicht immer relevant oder realisierbar. Durch eine serviceorientierte Architektur erfolgt eine Komplexitätsreduktion. Business- Anforderungen, die sich in den Prozessen widerspiegeln, werden definiert und in einzelnen Services abgebildet. Diese Kapselung erlaubt eine Entkopplung von Business und IT monolithische IT-Systeme werden auseinandergebrochen und können in Abhängigkeit von (sich ändernden) Business-Anforderungen neu komponiert werden. Der Einfluss von IT-Kosten bei der Anpassung von Prozessen oder Partnerschaftskonstellationen reduziert sich erheblich die Barrieren zu Veränderungen im Unternehmen sinken. Besonders hervorzuheben ist die Möglichkeit der rollenspezifischen Zusammenstellung von Web-Services. Der Informations- und Handlungsbedarf ist bei verschiedenen Rollen eines Prozesses sehr unterschiedlich. Vom Mitarbeiter in einer Fachabteilung bis hin zum Topmanagement sind unterschiedliche Sichten auf Informationen und unterschiedliche Aktivitäten zur Abarbeitung von Prozessen notwendig. Dies wird in den Services berücksichtigt: So viel Information wie nötig, so wenig Information wie möglich. Auf der IT-Seite führt SOA zur Steigerung der Zukunftsfähigkeit und der Investitionssicherheit der Systemlandschaft (vgl. im Folgenden auch [Richter et al. 2005]). Selbst alternde Systeme (Legacy Systems) können durch das Einziehen eines Service-Layers lange über ihren eigentlichen Lebenszyklus hinaus verwendet werden das schafft technische und kaufmännische Spielräume für Ersatzinvestitionen. Die Aktualisierung von Systemen kann zum Teil in der Serviceschicht erfolgen. Die Projektkosten zur Umsetzung von Business-Anforderungen in der IT werden gesenkt, sobald eine SOA implementiert ist. Dies ist darauf zurückzuführen, dass die Granularität von IT-Projekten feiner gewählt werden kann es müssen nicht immer gleich ganze Systeme geändert oder neu eingeführt werden, sondern notwendige Intelligenz in der Prozessunterstützung kann von Web- Services übernommen werden. Die Planungssicherheit von Finanz- und Personenressourcen steigt bei abnehmender Größe und Komplexität 14 HMD 253

9 von Projekten. Projektziele können klarer festgelegt und gesteuert werden, weil durch die Serviceorientierung die Zerlegung der Zielsetzung in Teilziele bereits vorgegeben ist. Der Aufwand für die Unterstützung dieser serviceorientierten IT-Projekte für die Begleitung durch Vertreter aus den Fachabteilungen sinkt es können mehr Fachspezialisten eingesetzt werden, die sich die Arbeit eines oder weniger Generalisten aufteilen und so effizienter zu effektiveren IT- Lösungen kommen. Die technologische Unabhängigkeit von Web-Services erlaubt eine einfache Kopplung unterschiedlicher Systemlandschaften (z. B. Betriebssystemplattformen). Dies kann relevant werden bei der Integration neuer Organisationseinheiten als Folge von Mergers und Acquisition (M&A) oder auch bei einer organisationsinternen Zusammenführung von historisch bedingt heterogenen Systemen. Die Standardisierung von Services erleichtert das Outsourcing ganzer Geschäftsprozesse oder einzelner Teile davon (vgl. [Richter et al. 2005]). SOA kann Aufwände für Systemarchitekten und Softwareentwickler einsparen helfen, da Entwickler in den von ihnen beherrschten Technologien implementieren können (Voraussetzung: Services müssen gut entworfen und dokumentiert werden. Darüber hinaus muss der Prozess der Konzeption, Dokumentation, Implementierung sowie des Rollouts standardisiert und dokumentiert sein; vgl. [Krafzig et al. 2004, S. 240 ff.]). [Richter et al. 2005] weisen allerdings darauf hin, dass den aufgeführten Nutzenpotenzialen diverse Herausforderungen gegenüberstehen, die hier nicht im Detail behandelt werden sollen und deren Begegnung Thema der vorliegenden Ausgabe der HMD ist. Insbesondere sind dabei anzuführen, dass der Methodenpool zur Konzeption und Umsetzung einer SOA im Unternehmen noch nicht etabliert ist entsprechende Projekte daher auf die Kreativität und Erfahrungen der Projektbeteiligten bauen müssen. Frage 10: Wie wird sich SOA entwickeln? Bei der Einführung und Nutzung serviceorientierter Architekturen stellen sich aktuell zwei dominante Herausforderungen. Erstens ist zu entscheiden, für welche Prozesse und Applikationen sich die Umstellung auf eine serviceorientierte Architektur lohnt. Der Nutzen einer SOA in Form von Qualitäts- und Flexibilitätsverbesserungen sowie Kosteneinsparungen muss den unternehmensindividuell zu bestimmenden Aufwand rechtfertigen. Da in vielen Anwendungsbereichen einschlägige Erfahrungen fehlen, ist diese Kosten-Nutzen-Bestimmung nur schwer durchzuführen. Die zweite Herausforderung besteht darin, dieses Nutzenpotenzial zu heben, indem durch die Integration von Lösungen für das Geschäftsprozessmanagement die flexible Orchestrierung von Diensten ermöglicht wird (vgl. Frage 7: In welcher Beziehung steht BPM zu SOA?). Angesichts zunehmender unternehmensübergreifender Abhängigkeiten von Geschäftsprozessen besteht der nächste logische Entwicklungsschritt serviceorientierter Architekturen in der Schaffung der Voraussetzungen für die flexible und zuverlässige Integration externer Dienste in bislang intern serviceorientiert abgebildete Prozesse. Outsourcing und Offshoring von Teilprozessen, die Integration wechselnder Zulieferer und die Anbindung von Kundenprozessen bringen große Flexibilisierungsbedarfe mit sich. Im Einzelnen ist die Zukunft serviceorientierter Architekturen in diesem Zusammenhang durch die folgenden Herausforderungen und Lösungsansätze geprägt:! Repräsentation von Service Level Agreements: Für den Austausch von Diensten über Unternehmensgrenzen hinweg müssen Mechanismen entwickelt werden, die eine Vereinbarung und Sicherstellung der Servicequalität ermöglichen, ohne manuellen Kontrollaufwand zu verursachen. Einen ersten Ansatz für die formale, maschinenlesbare Definition von Service Level Agreements für Web-Services HMD

10 bietet die XML-basierte WSLA Language Specification (Web Service Level Agreements) der IBM Corp. (vgl. [Dumke et al. 2005]).! Monitoring und Performance Measurement: Es werden Mechanismen zur vollautomatischen Kontrolle der Qualität eines Dienstes benötigt. Die Leistung eines Dienstes ist an den vereinbarten Qualitätskriterien zu messen. Neben formalen Qualitätskriterien, wie z. B. Antwortzeit, Uptime o.ä., wird hierbei auch die materielle Qualität eines Dienstes eine wichtige Rolle spielen (z. B. die Feststellung, ob eine Berechnung korrekt durchgeführt wird). Der WSLA-Standard sieht die Referenzierung von»supporting Parties«vor, die als unabhängige Dritte eine solche Qualitätskontrolle übernehmen können.! Abrechnung und Bezahlung: Der Austausch elektronischer Dienste als wirtschaftliche Leistungsbeziehung zwischen Unternehmen erfordert eine geeignete Abrechnungsarchitektur auf der Grundlage von Protokollen zur Inanspruchnahme der Dienste. Bezüglich des Abrechnungsmodells kommen verschiedene Gestaltungsansätze in Frage, so z. B. eine zeitoder aufrufproportionale Abrechnung. Auch muss die Abrechnung entsprechend des tatsächlichen gegenüber dem vereinbarten Service Level erfolgen, sodass die Ergebnisse der Qualitätskontrolle in die Abrechnung einfließen.! Controlling: In komplexen inner- und zwischenbetrieblichen Servicenetzen ist Kostenund Leistungstransparenz zu schaffen. Hierzu sind Informationen zur Inanspruchnahme, zur Qualität und zu den entstandenen finanziellen Forderungen bzw. Zahlungsströmen geeignet zu strukturieren und zu aggregieren. Als Instrument zur Aufbereitung und Integration Controlling-relevanter Daten in Servicenetzen bietet sich z. B. der XML-basierte Standard XBRL (Extensible Business Reporting Language) an (vgl. [Gehra & Hess 2004]).! Semantische Interoperabilität: Die flexible Rekonfiguration von Prozessen durch die Einbindung von Services erfordert kompatible Schnittstellen nicht nur auf syntaktischer, sondern auch auf semantischer Ebene. Bisher wird die inhaltliche, funktionale Kompatibilität von Services durch die Entwickler einer servicebasierten Anwendung sichergestellt. Die automatische Identifikation und Einbindung von Services mit einer bestimmten Funktionalität (z. B. beim Ausfall eines nicht redundanten Dienstes) ist nur mithilfe einer maschinenlesbar repräsentierten, semantischen Schnittstellenbeschreibung möglich (z. B. durch Referenzierung einer Ontologie). Insgesamt ist festzuhalten, dass auch mit der umfassenden Bereitstellung von Lösungen entlang der skizzierten Entwicklungslinien SOA nicht in jedem Anwendungsszenario ein angemessenes Kosten-Nutzen-Verhältnis aufweisen wird. Dennoch verspricht SOA als IT-strategische Stoßrichtung klare Wettbewerbsvorteile, wenn die zu unterstützenden Prozesse mit Bedacht gewählt werden und die sonstigen Erfolgsfaktoren Berücksichtigung finden (vgl. Beitrag von [Durst & Daum 2007] in diesem Heft). Literatur [Berlecon Research 2006] Berlecon Research: Pressemitteilung Berlecon: SOA: Unternehmen profitieren primär von höherer Flexibilität, www. berlecon.de/presse/index.php?we_objectid=272; Zugriff am [Brabänder & Klückmann 2006] Brabänder, E.; Klückmann, J.: Geschäftsprozessmanagement als Grundlage für SOA, ons/os/2006/bpm/brabaender_klueckmann_os_ BPM_06.pdf; Zugriff am [Burghardt & Hagenhoff 2003] Burghardt, M.; Hagenhoff, S.: Web Services Grundlagen und Kerntechnologien. Arbeitspapier, Institut für Wirtschaftsinformatik, Abteilung Wirtschaftsinformatik II, Universität Göttingen, [Capgemini 2006] Capgemini: Studie IT-Trends 2006, _2006.pdf; Zugriff am HMD 253

11 [Dostal et al. 2005] Dostal, W.; Jeckle, M.; Melzer, I.: Service-orientierte Architekturen mit Web Services. Konzepte Standards Praxis. Spektrum Akademischer Verlag, Heidelberg, [Dumke et al. 2005] Dumke, R.; Bundschuh, M.; Schmietendorf, A.; Ebert, C.: Best Practices in Software Measurement. Springer-Verlag, Berlin, [Durst & Daum 2007] Durst, M.; Daum, M.: Erfolgsfaktoren serviceorientierter Architekturen. In: HMD Praxis der Wirtschaftsinformatik, Heft 253, 2007, S. 18. [Gehra und Hess 2004] Gehra, B.; Hess, T.: XBRL Ein Kommunikationsstandard für das Financial Reporting. In: Zeitschrift für Management und Controlling, 48 (6), S [Hohpe 2002] Hohpe, G.: Web Services: Pathway to a Service-Oriented Architecture? Arbeitspapier, ThoughtWorks, Inc., [Keen et al. 2004] Keen, M.; Bishop, S.; Hopkins, A.; Milinski, S.; Nott, C.; Robinson, R.; Adams, J.; Verschueren, P.; Acharya, A.: Patterns: Implementing an SOA Using an Enterprise Service Bus. IBM Corporation, [Klose & Knackstedt 2007] Klose, K.; Knackstedt, R.: Serviceidentifikation für die Produktionsplanung eines mittelständischen Auftragsfertigers. In: HMD Praxis der Wirtschaftsinformatik, Heft 253, 2007, S. 47. [Krafzig et al. 2004] Krafzig, D.; Banke, K.; Slama, D.: Enterprise SOA: Service-Oriented Architecture Best Practices [Krcmar 2004] Krcmar, H.: Informationsmanagement. 4. Aufl., Springer-Verlag, Heidelberg, [Richter et al. 2005] Richter, J.-P.; Haller, H.; Schrey, P.: Serviceorientierte Architektur. Informatiklexikon der Gesellschaft für Informatik e.v. (GI), %5D=118&cHash=7d76cbc557&id=647&type=98; Zugriff am [Röwekamp 2006] Röwekamp, R.: SOA braucht strikte Governance, Zugriff am [Schelp & Stutz 2007] Schelp, J.; Stutz, M.: SOA-Governance. In: HMD Praxis der Wirtschaftsinformatik, Heft 253, 2007, S. 66. [Thomas et al. 2007] Thomas, O.; Leyking, K.; Dreifus, F.: Prozessmodellierung im Kontext serviceorientierter Architekturen. In: HMD Praxis der Wirtschaftsinformatik, Heft 253, 2007, S. 37. [Weerawarana et al. 2005] Weerawarana, S.; Curbera, F.; Leymann, F.; Storey, T.; Ferguson, D. F.: Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging and More. Prentice Hall PTR, Upper Saddle River, NJ, USA, Dr. Stefan Reinheimer BIK Beratungsgesellschaft für Informations- und Kommunikationsmanagement mbh Kersbacher Weg Nürnberg sr@bik.biz Dipl.-Kfm. Florian Lang Dipl.-Wirtsch.-Inf. Jörg Purucker Dipl.-Wirtsch.-Inf. Hinnerk Brügmann Universität Erlangen-Nürnberg Lehrstuhl für Wirtschaftsinformatik II Lange Gasse Nürnberg {florian.lang, Joerg.Purucker, hinnerk.bruegmann}@wiso.uni-erlangen.de HMD