11
HMD 253 7 Stefan Reinheimer, Florian Lang, Jörg Purucker, Hinnerk Brügmann 10 Antworten zu SOA Im Zentrum von serviceorientierten Architektu- ren (SOA) steht ein Architekturkonzept, das so- wohl aus einer technologischen als auch einer geschäftsgetriebenen Perspektive betrachtet werden muss. Mit dem Thema werden hohe Er- wartungen verbunden, die sich allerdings noch nicht in entsprechenden Erfahrungen widerspie- geln. Trotzdem lassen sich klare Zielsetzungen und Nutzenpotenziale identifizieren. Mit Ant- worten auf 10 Schlüsselfragen werden die zentra- len Inhalte rund um SOA erörtert und die Zusam- menhä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 For- mat versuchen, die zentralen Fragestellungen ohne Umschweife zu adressieren und sowohl dem Einsteiger als auch dem Erfahrenen einen als Ganzes oder selektiv lesbaren Grundlagen- beitrag 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 Komponen- ten eines Softwaresystems und deren Bezie- hungen untereinander. Anhand der Software- architektur wird die Funktion der einzelnen Komponenten im Gesamtsystem bestimmt (vgl. [Krafzig et al. 2004, S. 40 ff.]). Kernprinzip serviceorientierter Architektu- ren ist der Aufbau von Softwaresystemen aus lose gekoppelten Funktionsbausteinen (Ser- vices) mit klar umrissenen fachlichen Aufgaben. Die Geschäftslogik eines Softwaresystems wird damit auf mehrere weitgehend voneinander unabhängige Services verteilt. Die Services kap- seln Daten und Anwendungslogik. Durch die lose Kopplung der Services und die klare Auf- gabentrennung sollen Softwarearchitekturen vor allem übersichtlicher und flexibler werden. Flexibilität entsteht dadurch, dass das Zusam- menspiel der Komponenten leichter geändert werden kann. Neue Komponenten können ein- facher hinzugefügt und bestehende leichter er- weitert oder ausgetauscht werden (vgl. hierzu auch die Antwort auf Frage 3: Was ist die Ziel- setzung von SOA?). Auf diese Weise kann ein Softwaresystem schneller angepasst werden, wenn sich die Anforderungen des Geschäfts- systems ändern. Kernbestandteile serviceorientierter Archi- tekturen sind Application Frontends, Services,

10 Antworten zu SOA

Embed Size (px)

Citation preview

Page 1: 10 Antworten zu SOA

HMD 253 7

Stefan Reinheimer, Florian Lang, Jörg Purucker, Hinnerk Brügmann

10 Antworten zu SOA

Im Zentrum von serviceorientierten Architektu-

ren (SOA) steht ein Architekturkonzept, das so-

wohl aus einer technologischen als auch einer

geschäftsgetriebenen Perspektive betrachtet

werden muss. Mit dem Thema werden hohe Er-

wartungen verbunden, die sich allerdings noch

nicht in entsprechenden Erfahrungen widerspie-

geln. Trotzdem lassen sich klare Zielsetzungen

und Nutzenpotenziale identifizieren. Mit Ant-

worten auf 10 Schlüsselfragen werden die zentra-

len Inhalte rund um SOA erörtert und die Zusam-

menhä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 For-mat versuchen, die zentralen Fragestellungenohne Umschweife zu adressieren und sowohldem Einsteiger als auch dem Erfahrenen einenals Ganzes oder selektiv lesbaren Grundlagen-beitrag bieten.

Frage 1: Was ist SOA?

Serviceorientierte Architekturen zielen daraufab, Softwaresysteme flexibler zu gestalten, umdiese auch nach der Ersteinführung schnellund adäquat an geänderte Bedürfnisse desGeschäftssystems anpassen zu können. EinSchwerpunkt liegt dabei auf der Unterstützungvon Geschäftsprozessen.

Serviceorientierte Architekturen sind einespezielle Form von Softwarearchitekturen. EineSoftwarearchitektur beschreibt die Komponen-ten eines Softwaresystems und deren Bezie-hungen untereinander. Anhand der Software-architektur wird die Funktion der einzelnenKomponenten im Gesamtsystem bestimmt(vgl. [Krafzig et al. 2004, S. 40 ff.]).

Kernprinzip serviceorientierter Architektu-ren ist der Aufbau von Softwaresystemen auslose gekoppelten Funktionsbausteinen (Ser-vices) mit klar umrissenen fachlichen Aufgaben.Die Geschäftslogik eines Softwaresystems wirddamit auf mehrere weitgehend voneinanderunabhängige Services verteilt. Die Services kap-seln Daten und Anwendungslogik. Durch dielose Kopplung der Services und die klare Auf-gabentrennung sollen Softwarearchitekturenvor allem übersichtlicher und flexibler werden.Flexibilität entsteht dadurch, dass das Zusam-menspiel der Komponenten leichter geändertwerden kann. Neue Komponenten können ein-facher hinzugefügt und bestehende leichter er-weitert oder ausgetauscht werden (vgl. hierzuauch die Antwort auf Frage 3: Was ist die Ziel-

setzung von SOA?). Auf diese Weise kann einSoftwaresystem schneller angepasst werden,wenn sich die Anforderungen des Geschäfts-systems ändern.

Kernbestandteile serviceorientierter Archi-tekturen sind Application Frontends, Services,

Page 2: 10 Antworten zu SOA

10 Antworten zu SOA

8 HMD 253

das Service-Repository und der Service-Bus (vgl.im Folgenden [Krafzig et al. 2004, S. 26 ff.]).

! Application Frontends bilden die Schnittstelledes Softwaresystems nach außen. Über siewerden Aktivitäten des Systems gestartetund Ergebnisse zurückgeliefert. Typische Bei-spiele für Application Frontends sind grafi-sche Oberflächen zur Interaktion mit Benut-zern oder Batch-Programmen.

! Ein Service ist ein Dienst mit einer klar defi-nierten Leistung. Services repräsentieren Ge-schäftslogik und sind tendenziell grobgranu-lar. Für jeden Service gibt es eine odermehrere Schnittstellen und einen Service-Contract. Der Service-Contract enthält nor-malerweise eine formale Beschreibung derSchnittstelle sowie eine Beschreibung derFunktionalität, der Nutzung und der Anwen-dungsbedingungen des Service. Die Imple-mentierung, also die konkrete Verarbeitungs-logik, und die Datenzugriffe werden vor demBenutzer verborgen.

! Im Service-Repository sind Informationen ab-gelegt, die zur Identifikation geeigneter Ser-vices sowie zu deren Nutzung benötigt wer-den. Dazu gehören z. B. Informationen zumAufruf des Service, zum Anbieter, zur fach-lichen Klassifikation, zur Bezahlung, zurSicherheit und zu Service Level Agreements.

! Der Service-Bus stellt die Verbindung zwi-schen den Services und zwischen Servicesund Application Frontends her. Der Service-Bus muss auch Verbindungen zwischen Kom-ponenten ermöglichen, die mit unterschiedli-chen Technologien entwickelt wurden. Dabeisind unterschiedliche Kommunikationsfor-men wie synchrone und asynchrone Kommu-nikation zu unterstützen.

Frage 2: Was ist SOA nicht?

SOA ist weder ein Produkt noch eine Technolo-gie oder ein Technologiestandard. SOA ist eintechnologieunabhängiges Architekturkonzept,das Softwarearchitekturen einfacher und flexib-

ler machen soll und dabei die Wiederverwen-dung bestehender Komponenten unterstützt.SOA ist nicht an bestimmte Technologien wieetwa Web-Services gebunden. Vielmehr könnenserviceorientierte Architekturen aus Kompo-nenten aufgebaut werden, die mit unter-schiedlichen Technologien entwickelt wurden[Brabänder & Klückmann 2006, S. 1].

Frage 3: Was ist die Zielsetzung von SOA?

Geschäftssysteme, insbesondere Geschäftspro-zesse, ändern sich häufig. Dies liegt unter an-derem an der erhöhten Marktdynamik, an kür-zeren Entwicklungszeiten neuer Technologienund an Anpassungen der Unternehmensor-ganisationen (z. B. Unternehmenszusammen-schlüsse, Outsourcing). Die Unternehmens-ITsteht damit regelmäßig vor der Herausforde-rung, die Softwarelandschaft an die geänderteAusgangssituation anzupassen. Serviceorien-tierte Architekturen sollen die Anpassung vonSoftwaresystemen an geänderte Bedürfnissedes Geschäftssystems vereinfachen. Durch dielose Kopplung der Services können diese bei An-passungen oder Erweiterungen des Systemseinfacher ausgetauscht oder neu zusammenge-stellt werden (vgl. [Krafzig et al. 2004, S. 6 f. undS. 239 ff.]). Auf diese Weise sollen Geschäftspro-zesse flexibler werden, da Änderungen schnel-ler umgesetzt werden können.

Die einfachere Wiederverwendung beste-hender Services soll serviceorientierte Architek-turen flexibler machen als die bislang bekann-ten monolithischen Applikationen und Systeme.Darüber hinaus soll sie Kosteneinsparungen er-möglichen und das Entwicklungsrisiko senken.Kosteneinsparungspotenziale ergeben sich da-durch, dass bestimmte Funktionalitäten nichtmehrfach entwickelt werden müssen. Das Ent-wicklungsrisiko kann durch die Wiederverwen-dung bestehender Services gesenkt werden,weil diese im Unterschied zu Neuentwicklungenin der Regel bereits in der Praxis getestet wur-den. Ein anderer wichtiger Aspekt der Wieder-

Page 3: 10 Antworten zu SOA

10 Antworten zu SOA

HMD 253 9

verwendung ist die Reduzierung von Funktions-bausteinen, die gleiche oder verwandte Inhaltein unterschiedlichen Datenspeichern ablegen.Die Wiederverwendung von Services soll dazubeitragen, redundante Datenhaltungen zu ver-meiden (vgl. [Krafzig et al. 2004, S. 6 f.]).

Eine weitere Zielsetzung serviceorientierterArchitekturen besteht darin, die Technologie-abhängigkeit der Anwendungen zu reduzieren.Ein wichtiger Aspekt der Technologieunabhän-gigkeit ist die technische Verknüpfung von Ser-vices, die auf unterschiedlichen Technologienbasieren. Dazu wird der Service-Bus verwendet.Ein anderer Aspekt ist die Möglichkeit, einge-setzte Technologien im Zeitverlauf zu ändern.Dies soll dadurch erreicht werden, dass Servicesauf fachlicher Ebene definiert werden und dieImplementierung der Services von der fach-lichen Definition getrennt wird. Auf diese Weisekann die technische Umsetzung des Serviceeinfacher geändert werden. Gleichwohl kannauch mit einer serviceorientierten Architekturkeine vollständige Technologieunabhängigkeiterreicht werden. Zum einen basiert auch derService-Bus auf einer bestimmten Technologie.Zum anderen ist die Konfiguration des Zusam-menspiels der Services komplex und mit nichtunerheblichen Aufwendungen verbunden (vgl.[Krafzig et al. 2004, S. 6 f.]).

Serviceorientierte Architekturen sollen auchdazu beitragen, Softwarearchitekturen über-sichtlicher und verständlicher zu machen. Ander Entwicklung von Softwarearchitekturensind meist mehrere Personen mit unterschiedli-chen Rollen, Perspektiven und Vorkenntnissenbeteiligt, die alle mit der Architektur arbeitenmüssen. Eine klare aufgabenbezogene Tren-nung der Komponenten, wie sie bei service-orientierten Architekturen angestrebt wird, solldie Kommunikation der Softwarearchitekturvereinfachen (vgl. [Krafzig et al. 2004, S. 6 f.] undAntwort 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 % derBefragten der Ansicht, dass es sich bei SOA umein Managementkonzept handle, für 27 % stehtder technische Aspekt im Vordergrund [Cap-gemini 2006].

Die Zeiten, in denen IT-Lösungen um derTechnik Willen eingeführt wurden, sind vorbei.Business-Anforderungen sind der Treiber fürdie IT. Dies gilt selbstverständlich auch für dasThema SOA (vgl. Beitrag von [Schelp & Stutz2007] in diesem Heft). Das Management hängtvon einer hohen Anpassungsfähigkeit der Orga-nisation und des Geschäftsmodells ab. Anforde-rungen an die IT resultieren aus den Prozess-bedarfen, in denen Agilität und Flexibilität einerUnternehmung implementiert sein müssen.

Die Zusammenarbeit von Fachbereich undIT lässt sich über drei Ebenen hinweg beobach-ten (vgl. [Capgemini 2006]):

1. Die Identifikation (vgl. Beitrag von [Klose &Knackstedt 2007] in diesem Heft) und Kom-position von erfolgversprechenden Servicesüber sämtliche Produkte und Organisations-einheiten hinweg ist Aufgabe der Fachberei-che. Sie ist die Grundlage für SOE (Service

Oriented Enterprise).

2. Die Vorgaben aus der fachlichen Prozessweltgreift die IT auf und realisiert bzw. kompo-niert die technische Umsetzung auf Basisvon etablierten Standards. Ihre Verwaltungerfolgt im Rahmen von SOA (Service Oriented

Architecture).

3. Die Grundlage für diese flexible Architekturbietet – wie bei allen IT-Architekturen – dietechnische Infrastruktur, die daher als Ser-

vice Oriented Infrastructure (SOI) bezeichnetwird.

Projekte zur Realisierung einer SOA im Unter-nehmen sollten daher nicht technisch, sondernBusiness-getrieben sein (vgl. [Röwekamp 2006]).Die Governance wechselt zwischen den Aufzäh-lungspunkten 1 bis 3 vom Fachbereich hin zur IT.

Page 4: 10 Antworten zu SOA

10 Antworten zu SOA

10 HMD 253

Die Ausgestaltung der Zusammenarbeit für die-sen neuen, gemeinsamen Verantwortungsbe-reich bedarf klarer Zuständigkeiten entlang desgesamten Service-Lifecycles vom Zuschnitt desService, seiner technischen Realisierung, seinerEinführung, seiner laufenden Maintenance,seiner Wiederverwendung bis hin zur verur-sachungsgerechten Leistungsverrechnung, umpolitisch induzierte Ineffizienzen vermeiden zukönnen.

Innerhalb der Fachbereiche ist eine wesent-liche Unterstützung durch Kompetenzen ausdem Bereich des Prozessmanagements (vgl.hierzu auch die Antwort auf Frage 7: In welcher

Beziehung steht BPM zu SOA? und den Beitragvon [Thomas et al. 2007] in diesem Heft) vonherausragender Bedeutung, denn schließlichsoll die IT die Vorgaben aus den fachspezifi-schen Prozessen umsetzen.

Frage 5: In welcher Beziehung stehen Web-Services zu SOA?

SOA ist ein abstraktes Konzept, das im Gegen-satz zu klassischer Middleware eine tiefgehen-de fachliche Komponente besitzt und auchohne technische Implementierung existierenkann. Web-Services stellen eine von mehrerenMöglichkeiten einer solchen technischen Imple-mentierung dieses Konzepts dar und sind nach[Krcmar 2004, S. 274] als konkrete Instanz derSOA zu verstehen (vgl. auch: HMD 234).

Für die Zusammenarbeit der Rollen Service-Requestor, Service-Provider und Service-Brokerist eine Infrastruktur nötig, die die Veröffent-lichung eines Dienstes durch den Service-Provider, das Suchen und Auffinden vonDiensten durch den Service-Requestor und dieAnbahnung des Kontakts sowie das dynami-sche Binden der Schnittstellen zwischen beidendurch den Service-Broker unterstützt.

Entsprechend dieser Anforderungen müs-sen in der konkreten Implementierung sowohlSchnittstellen und Metabeschreibung der Web-Services selbst als auch ihre Repräsentation in

einem Dienstverzeichnis standardisiert sein.Des Weiteren ist eine lose Kopplung zwischenden Web-Services erforderlich, damit diesedynamisch gesucht, gefunden und gebundenwerden können. Hier kann weitergehend zwi-schen der Nutzung gänzlich unbekannter Ser-viceangebote und dem dynamischen Bindenvon Serviceangeboten, die über eine standardi-sierte Schnittstellenspezifikation verfügen, un-terschieden werden. Lose Kopplung bezieht sichauf die Vermeidung von künstlichen Abhängig-keiten zwischen den kommunizierenden Par-teien, wie sie beispielsweise aus der Verwen-dung von proprietären Schnittstellen entstehenkönnen. Zur weiteren Vermeidung von Abhän-gigkeiten soll ein Web-Service keine Informatio-nen darüber verwenden, in welchem Kontext eraufgerufen wurde, und somit zustandslos sein.Eine Kapselung der Implementierung als Black-box erlaubt es, den Web-Service unabhängigvon seiner Schnittstelle zu ändern, und erleich-tert eine Wiederverwendbarkeit, die wiederumzur Verkürzung von Entwicklungszyklen undletztlich zu Kosteneinsparungen führt. Im Ver-gleich zu klassischen Middleware-Systemen er-möglichen Standardisierung und lose Kopplungdarüber hinaus die flexible Anpassung der Zu-sammenstellung (Orchestrierung) von mehre-ren Web-Services, beispielsweise anlässlich derÄnderung von unterstützten Prozessflüssen[Dostal et al. 2005, S. 9].

Der Einsatz von Web-Services bedeutet al-lerdings keinesfalls automatisch auch das Vor-handensein einer SOA. Hierzu bedarf es derstrikten Ausrichtung an den Geschäftsprozes-sen und deren Abbildung durch Web-Servicesgeeigneter Granularität mittels Orchestrierung.

Frage 6: Wie kann SOA technisch realisiert werden?

Da der SOA-Design-Ansatz technologieunab-hängig ist, kann er durch unterschiedliche Tech-nologien umgesetzt werden. Neben Web-Ser-vices ist eine Realisierung beispielsweise auch

Page 5: 10 Antworten zu SOA

10 Antworten zu SOA

HMD 253 11

mittels traditioneller Middleware-Lösungenwie OMG CORBA (Common Object RequestBroker Architecture) oder Microsoft COM (Com-ponent Object Model) möglich. Allerdingsscheint die Implementierung mittels Web-Ser-vices zurzeit von Analysten und Softwareher-stellern am stärksten favorisiert und wird daherdetaillierter ausgeführt.

Der Unterschied zwischen Web-Servicesund traditionellen Middleware-Ansätzen be-steht im Grad der Kopplung zwischen den Kom-ponenten [Weerawarana et al. 2005, S. 32 f.].Durch eine Trennung der Web-Service-Bestand-teile in Schichten, die standardisierte Schnitt-stellen anbieten, entsteht eine lose Kopplung,in der einzelne Komponenten dynamisch aus-tauschbar sind.

Das Zwiebelschalenmodell nach [Burghardt& Hagenhoff 2003] illustriert die aufeinanderaufbauenden Funktionalschichten. Die fachli-che Komplexität nimmt hierbei von innen nachaußen zu. Abbildung 1 illustriert die verbreiteteSOAP-Architektur (Simple Object Access Proto-col), allerdings existieren teilweise für die Im-plementierung einer Schicht alternative Tech-nologien.

Im Kern steht die zu erbringende Dienstleis-tung. Der diese Dienstleistung implementieren-de und über ein Netzwerk anbietende Web-Service ist entweder neu zu erstellen, oder eswird für eine bestehende Applikation ein

»Wrapper« geschaffen. Dieser stellt standardi-sierte Schnittstellen nach außen zur Verfügungund implementiert gegebenenfalls zusätzlicheFunktionalitäten, wie beispielsweise Sicher-heitsmechanismen [Hohpe 2002].

Die zur Durchführung der Dienstleistungnotwendigen Informationen werden zwischenWeb-Service und Service-Requestor durchNachrichten in der Metasprache XML ausge-tauscht. Zum Transport dieser Informationendient der Rumpf einer SOAP-Nachricht. SOAP-Nachrichten besitzen darüber hinaus zur gene-rischen Erweiterbarkeit ein optionales Kopfele-ment, in dem zusätzliche Informationen wiebeispielsweise Authentifizierungsdaten enthal-ten sein können.

Das Trägerprotokoll für SOAP ist nicht fest-gelegt. Während die Vorreiter unter den grö-ßeren Softwareherstellern den HTTP-Standardfavorisieren, finden im industriellen Umfeldhäufig klassische EAI-Frameworks und deren in-terne Protokolle Verwendung. Allerdings wäreauch ein Transport über weitere Trägerproto-kolle wie beispielsweise SMTP (Simple MailTransfer Protocol) denkbar.

Beschrieben werden Web-Services durchdie Web Service Description Language (WSDL).Diese XML-Sprache definiert das Kommunika-tionsprotokoll, also Aufrufmechanismen undNachrichtensemantik, der öffentlichen Schnitt-stelle eines Web-Service. Die Definition ist ab-

Web-Service

SOAP

TransportXML

UDDI

WSDL

Dienst-leistung

Inhalt

Schnittstelle

Beschreibung

Verzeichnis

SOAP

TransportXML

UDDI

WSDL

Dienst-leistung

Inhalt

Schnittstelle

Beschreibung

Verzeichnis

Abb. 1: Zwiebelschalenmodell der Web-Service-Architektur nach [Burghardt & Hagenhoff 2003]

Page 6: 10 Antworten zu SOA

10 Antworten zu SOA

12 HMD 253

strakt und wird erst bei Verwendung durcheinen Service-Requestor an ein Netzwerkproto-koll gebunden, sodass der Zugriff plattform-unabhängig erfolgen kann. [Keen et al. 2004]nennen als Beispiel einen .NET-Entwickler, derdas WSDL-Dokument eines Java-basierten Web-Service, der in einer Websphere-Umgebungläuft, anfordert und hieraus automatisiert denbenötigten .NET-Zugriffscode erzeugt. Ebensowie der Kopf einer SOAP-Nachricht ist WSDL umzusätzliche Informationen, beispielsweise be-züglich Sicherheitsmechanismen, erweiterbar[Keen et al. 2004, S. 55].

Als Spezifikation für Verzeichnisse zum An-bieten und Auffinden von Web-Services exis-tiert die UDDI (Universal Description, Discoveryand Integration). Mittels SOAP-Anfragen an dieUDDI können Web-Services über ihre Metada-ten im WSDL-Format im Verzeichnis gefundenwerden. Generell als Standard zur Möglichkeiteiner öffentlichen, internetweiten Bereitstel-lung von Web-Services konzipiert, finden UDDI-Verzeichnisse zurzeit vor allem isolierte Ver-wendung im unternehmensinternen oder Inter-Enterprise-Bereich zwischen kooperierendenUnternehmen. Ein öffentlicher Marktplatz fürServiceangebote findet sich z. B. unter www.

strikeiron.com.

Frage 7: In welcher Beziehung steht BPM zu SOA?

Bei der Neugestaltung und Implementierungvon Geschäftsprozessen kommen häufig Me-thoden und Instrumente des Business ProcessManagement (BPM) zum Einsatz. Serviceorien-tierte Architekturen (SOA) werden entwickelt,um Anpassungen an Geschäftsprozesse leichterumsetzen zu können.

BPM ist ein Ansatz zum Management vonGeschäftsprozessen zur Umsetzung strategi-scher und operativer Ziele einer Unterneh-mung. Zu den Aufgaben des BPM gehören ne-ben der technischen Ausführung von Prozessenvor allem Analyse, Design und Implementie-rung sowie ein Monitoring von Prozessen (vgl.[Brabänder & Klückmann 2006, S. 2]). Business-Process-Management-Systeme (BPMS) werdenzur technischen Umsetzung von BPM einge-setzt. Abbildung 2 zeigt die Architektur einesBPMS im Überblick. Die Prozessdefinitionen undProzessinstanzen werden in einer fachlichenBeschreibungssprache wie z. B. Business ProcessModeling Language (BPML) modelliert und imProzess-Repository abgelegt. Ausgeführt wer-den die Prozessinstanzen über die Prozess-Engine, die dazu über eine Middleware auf dieAnwendungssysteme des Unternehmens zu-greift. Über den Prozessmanager können Ober-

Transaktions-Manager

Konnektor-Framework

Pro

zess

ma

na

ge

r Prozess-Engine(interpretiert z.B. BPML)Design

Adminis-tration

Monitoring

Design

Adminis-tration

Monitoring

Anwendungssysteme

Middleware

Prozess-definitionen

Prozess-instanzen

Abb. 2: Architektur eines BPM-Systems [Krafzig et al. 2004]

Page 7: 10 Antworten zu SOA

10 Antworten zu SOA

HMD 253 13

flächen zur Änderung, Verwaltung und Über-wachung der Prozesse eingebunden werden.

Für das Design von Geschäftprozessen gibtes eine Reihe von Tools, die die Dokumentationvon Sollprozessen mit einer grafischen Nota-tion, wie etwa BPMN (Business Process Mode-ling Notation), UML (Unified Modeling Langua-ge) oder EPK (ereignisgesteuerte Prozessketten)unterstützen. Dagegen stellt die Implementie-rung von Änderungen an Geschäftsprozessen invielen Unternehmen eine Herausforderung dar,weil die Prozesslogik meist als integrierte Funk-tionalität fest in den Anwendungssystemenverankert ist, und die Systeme sowie deren Zu-sammenspiel in der Regel nur mit hohem Auf-wand geändert werden können (vgl. [Brabänder& Klückmann 2006, S. 1]).

SOA ist ein Konzept zum Aufbau von Soft-warearchitekturen aus lose gekoppelten Ser-vices mit definierten Aufgaben, die zur Abbil-dung der Geschäftslogik eines Unternehmensflexibel zusammengesetzt werden können.Durch SOA sollen Softwarearchitekturen trans-parenter und flexibler werden (vgl. Antwortenauf die Fragen 1: Was ist SOA? und 3: Was ist die

Zielsetzung von SOA?).Innerhalb des Business Process Manage-

ment können serviceorientierte Architekturendazu beitragen, Anpassungen an Geschäftspro-zesse schneller umzusetzen. Die Services die-nen dabei als Anwendungsbausteine, die dieProzessausführung unterstützen und entspre-chend der Prozesslogik, die im Rahmen vonBPM-Aktivitäten definiert wird, zusammenge-setzt werden. Damit können Prozesse flexiblergestaltet werden, weil die Prozesslogik nichtmehr unmittelbarer Teil der Anwendungssyste-me ist, sondern systemübergreifend definiertund implementiert werden kann (vgl. [Brabän-der & Klückmann 2006], S. 1).

Eine intelligente Verzahnung von BPMS undserviceorientierten Architekturen kann erreichtwerden, wenn bei der Gestaltung der Software-architektur eine Prozessebene mit prozessori-entierten Services eingezogen wird. In diesem

Fall ist es Aufgabe des BPMS, die prozessorien-tierten Services auszuführen. Während die Ser-vices der darunterliegenden Ebenen die Basis-geschäftslogik eines Unternehmens abbilden,dienen die Services der Prozessebene zur Imple-mentierung der Logik zur Prozesssteuerung.Diese Services sind nicht zustandslos, weil sieden Zustand eines Prozesses (z. B. Prozessfort-schritt, Eingaben von Prozessbeteiligten) spei-chern müssen. Da die Geschäftsprozesse einesUnternehmens häufigen Änderungen unterlie-gen, haben die Services der Prozessebene in derRegel eine deutlich kürzere Lebenszeit als dieServices der darunterliegenden Ebenen. DieTrennung der Logik zur Prozessteuerung von derBasisgeschäftslogik erhöht die Flexibilität derArchitektur. Bei Anpassungen an einen Ge-schäftsprozess kann es in vielen Fällen ausrei-chen, die Logik zur Prozessteuerung zu ändern,ohne dass die Services der darunterliegendenEbenen geändert werden müssen. In diesenFällen werden andere Prozesse von den Ände-rungen nicht beeinträchtigt (vgl. [Krafzig et al.2004, S. 112 ff.]).

Serviceorientierte Architekturen unterstüt-zen BPM, indem sie dazu beitragen, dass Ge-schäftsprozesse schneller und einfacher in denAnwendungssystemen umgesetzt werden. Al-lerdings muss beachtet werden, dass die Über-führung einer bestehenden IT-Landschaft inserviceorientierte Architekturen in aller Regeleine ambitionierte Aufgabe ist, die sich übermehrere Jahre erstrecken kann (vgl. [Krafzig etal. 2004, S. 115]).

Frage 8: Welche Erfahrungen gibt es bislang mit SOA?

Umfassende Erfahrungen mit SOA liegen nochnicht vor – das bekannteste Unternehmen, daseine konsequente Einführung von SOA vorge-nommen hat, ist die Deutsche Post.

Aus einem Report von [Berlecon Research2006] geht hervor, dass Unternehmen, die zur-zeit serviceorientierte Architekturen (SOA) ein-

Page 8: 10 Antworten zu SOA

10 Antworten zu SOA

14 HMD 253

führen, die höhere Flexibilität der IT als ent-scheidenden Vorteil einer SOA ansehen. Wie-derverwendung von Diensten spielt dagegeneine geringere Rolle. Im aktuellen Report »SOAin der Praxis – Wie Unternehmen SOA erfolg-reich einsetzen« stellen die Berliner AnalystenSOA-Projektberichte von acht Unternehmenaus unterschiedlichen Branchen vor und wer-ten diese aus. Dr. Joachim Quantz, AssociatedSenior Analyst bei Berlecon: »Die Anwender be-richten, dass die SOA-Projekte ihre Erwartun-gen erfüllt oder sogar übertroffen haben. Diewesentlichen Herausforderungen werden aufder organisatorischen Ebene und im Mehrauf-wand in der Anfangsphase gesehen. Durchsorgfältige Planung lassen sich diese Heraus-forderungen aber erfolgreich meistern.«

Nutzeffekte werden nahezu von allen Be-fragten insbesondere in der höheren Flexibilitätder IT und damit in der Agilität der Unterneh-mung gesehen. Die Wiederverwendung einzel-ner Services wird nur selten als Hauptnutzenvon SOA angeführt. Allerdings muss man er-warten, dass dieser Nutzeffekt auch erst nacheiner längeren Verwertung einer SOA im Unter-nehmen auftreten kann (vgl. [Berlecon Research2006] 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 Research2006] geht hervor, dass der Hauptnutzen einerSOA in einer deutlich höheren Flexibilität derIT liegt: Neue Dienste und Produkte könnenschneller eingeführt und existierende Serviceseffizienter an neue Anforderungen angepasstwerden. Weitere Vorteile sind Kosteneinsparun-gen, höhere Transparenz und Qualität. Darüberhinaus können Dienste in unterschiedlichenAnwendungskontexten wiederverwendet wer-den. Diese ebenfalls kostensenkende Wieder-verwendung ist aber nicht immer relevant oderrealisierbar.

Durch eine serviceorientierte Architekturerfolgt eine Komplexitätsreduktion. Business-

Anforderungen, die sich in den Prozessen wider-spiegeln, werden definiert und in einzelnen Ser-vices abgebildet. Diese Kapselung erlaubt eineEntkopplung von Business und IT – monolithi-sche IT-Systeme werden auseinandergebrochenund können in Abhängigkeit von (sich ändern-den) Business-Anforderungen neu komponiertwerden. Der Einfluss von IT-Kosten bei derAnpassung von Prozessen oder Partnerschafts-konstellationen reduziert sich erheblich – dieBarrieren zu Veränderungen im Unternehmensinken. Besonders hervorzuheben ist die Mög-lichkeit der rollenspezifischen Zusammenstel-lung von Web-Services. Der Informations- undHandlungsbedarf ist bei verschiedenen Rolleneines Prozesses sehr unterschiedlich. Vom Mit-arbeiter in einer Fachabteilung bis hin zumTopmanagement sind unterschiedliche Sichtenauf Informationen und unterschiedliche Aktivi-täten zur Abarbeitung von Prozessen notwen-dig. Dies wird in den Services berücksichtigt: Soviel Information wie nötig, so wenig Informa-tion wie möglich.

Auf der IT-Seite führt SOA zur Steigerungder Zukunftsfähigkeit und der Investitions-sicherheit der Systemlandschaft (vgl. im Folgen-den auch [Richter et al. 2005]). Selbst alterndeSysteme (Legacy Systems) können durch dasEinziehen eines Service-Layers lange über ihreneigentlichen Lebenszyklus hinaus verwendetwerden – das schafft technische und kaufmän-nische Spielräume für Ersatzinvestitionen. DieAktualisierung von Systemen kann zum Teil inder Serviceschicht erfolgen. Die Projektkostenzur Umsetzung von Business-Anforderungen inder IT werden gesenkt, sobald eine SOA imple-mentiert ist. Dies ist darauf zurückzuführen,dass die Granularität von IT-Projekten feiner ge-wählt werden kann – es müssen nicht immergleich ganze Systeme geändert oder neu einge-führt werden, sondern notwendige Intelligenzin der Prozessunterstützung kann von Web-Services übernommen werden. Die Planungs-sicherheit von Finanz- und Personenressourcensteigt bei abnehmender Größe und Komplexität

Page 9: 10 Antworten zu SOA

10 Antworten zu SOA

HMD 253 15

von Projekten. Projektziele können klarer festge-legt und gesteuert werden, weil durch die Ser-viceorientierung die Zerlegung der Zielsetzungin Teilziele bereits vorgegeben ist. Der Aufwandfür die Unterstützung dieser serviceorientiertenIT-Projekte für die Begleitung durch Vertreteraus den Fachabteilungen sinkt – es könnenmehr Fachspezialisten eingesetzt werden, diesich die Arbeit eines oder weniger Generalistenaufteilen und so effizienter zu effektiveren IT-Lösungen kommen.

Die technologische Unabhängigkeit vonWeb-Services erlaubt eine einfache Kopplungunterschiedlicher Systemlandschaften (z. B. Be-triebssystemplattformen). Dies kann relevantwerden bei der Integration neuer Organisa-tionseinheiten als Folge von Mergers und Acqui-sition (M&A) oder auch bei einer organisations-internen Zusammenführung von – historischbedingt – heterogenen Systemen. Die Standar-disierung von Services erleichtert das Out-sourcing ganzer Geschäftsprozesse oder einzel-ner Teile davon (vgl. [Richter et al. 2005]).

SOA kann Aufwände für Systemarchitektenund Softwareentwickler einsparen helfen, daEntwickler in den von ihnen beherrschtenTechnologien implementieren können (Voraus-setzung: Services müssen gut entworfen unddokumentiert werden. Darüber hinaus mussder Prozess der Konzeption, Dokumentation,Implementierung sowie des Rollouts standardi-siert und dokumentiert sein; vgl. [Krafzig et al.2004, S. 240 ff.]).

[Richter et al. 2005] weisen allerdings dar-auf hin, dass den aufgeführten Nutzenpoten-zialen diverse Herausforderungen gegenüber-stehen, die hier nicht im Detail behandelt wer-den sollen und deren Begegnung Thema dervorliegenden Ausgabe der HMD ist. Insbeson-dere sind dabei anzuführen, dass der Metho-denpool zur Konzeption und Umsetzung einerSOA im Unternehmen noch nicht etabliert ist –entsprechende Projekte daher auf die Kreati-vität und Erfahrungen der Projektbeteiligtenbauen müssen.

Frage 10: Wie wird sich SOA entwickeln?

Bei der Einführung und Nutzung serviceorien-tierter Architekturen stellen sich aktuell zweidominante Herausforderungen. Erstens ist zuentscheiden, für welche Prozesse und Applika-tionen sich die Umstellung auf eine service-orientierte Architektur lohnt. Der Nutzen einerSOA in Form von Qualitäts- und Flexibilitätsver-besserungen sowie Kosteneinsparungen mussden unternehmensindividuell zu bestimmen-den Aufwand rechtfertigen. Da in vielen An-wendungsbereichen einschlägige Erfahrungenfehlen, ist diese Kosten-Nutzen-Bestimmungnur schwer durchzuführen. Die zweite Heraus-forderung besteht darin, dieses Nutzenpoten-zial zu heben, indem durch die Integration vonLösungen für das Geschäftsprozessmanage-ment die flexible Orchestrierung von Dienstenermöglicht wird (vgl. Frage 7: In welcher Bezie-

hung steht BPM zu SOA?).Angesichts zunehmender unternehmens-

übergreifender Abhängigkeiten von Geschäfts-prozessen besteht der nächste logische Ent-wicklungsschritt serviceorientierter Architektu-ren in der Schaffung der Voraussetzungen fürdie flexible und zuverlässige Integration exter-ner Dienste in bislang intern serviceorientiertabgebildete Prozesse. Outsourcing und Off-shoring von Teilprozessen, die Integrationwechselnder Zulieferer und die Anbindung vonKundenprozessen bringen große Flexibilisie-rungsbedarfe mit sich. Im Einzelnen ist die Zu-kunft serviceorientierter Architekturen in die-sem Zusammenhang durch die folgenden Her-ausforderungen und Lösungsansätze geprägt:

! Repräsentation von Service Level Agreements:

Für den Austausch von Diensten über Unter-nehmensgrenzen hinweg müssen Mechanis-men entwickelt werden, die eine Vereinba-rung und Sicherstellung der Servicequalitätermöglichen, ohne manuellen Kontrollauf-wand zu verursachen. Einen ersten Ansatz fürdie formale, maschinenlesbare Definition vonService Level Agreements für Web-Services

Page 10: 10 Antworten zu SOA

10 Antworten zu SOA

16 HMD 253

bietet die XML-basierte WSLA Language Spe-cification (Web Service Level Agreements) derIBM Corp. (vgl. [Dumke et al. 2005]).

! Monitoring und Performance Measurement:

Es werden Mechanismen zur vollautomati-schen Kontrolle der Qualität eines Dienstesbenötigt. Die Leistung eines Dienstes ist anden vereinbarten Qualitätskriterien zu mes-sen. Neben formalen Qualitätskriterien, wiez. B. Antwortzeit, Uptime o.Ä., wird hierbeiauch die materielle Qualität eines Diensteseine wichtige Rolle spielen (z. B. die Feststel-lung, ob eine Berechnung korrekt durch-geführt wird). Der WSLA-Standard sieht dieReferenzierung von »Supporting Parties« vor,die als unabhängige Dritte eine solche Quali-tätskontrolle übernehmen können.

! Abrechnung und Bezahlung: Der Austauschelektronischer Dienste als wirtschaftlicheLeistungsbeziehung zwischen Unternehmenerfordert eine geeignete Abrechnungsarchi-tektur auf der Grundlage von Protokollen zurInanspruchnahme der Dienste. Bezüglich desAbrechnungsmodells kommen verschiedeneGestaltungsansätze in Frage, so z. B. eine zeit-oder aufrufproportionale Abrechnung. Auchmuss die Abrechnung entsprechend des tat-sächlichen gegenüber dem vereinbarten Ser-vice Level erfolgen, sodass die Ergebnisse derQualitätskontrolle in die Abrechnung einflie-ßen.

! Controlling: In komplexen inner- und zwi-schenbetrieblichen Servicenetzen ist Kosten-und Leistungstransparenz zu schaffen. Hierzusind Informationen zur Inanspruchnahme,zur Qualität und zu den entstandenen finan-ziellen Forderungen bzw. Zahlungsströmengeeignet zu strukturieren und zu aggregie-ren. Als Instrument zur Aufbereitung und In-tegration Controlling-relevanter Daten in Ser-vicenetzen bietet sich z. B. der XML-basierteStandard XBRL (Extensible Business Repor-ting Language) an (vgl. [Gehra & Hess 2004]).

! Semantische Interoperabilität: Die flexible Re-konfiguration von Prozessen durch die Ein-

bindung von Services erfordert kompatibleSchnittstellen nicht nur auf syntaktischer,sondern auch auf semantischer Ebene. Bisherwird die inhaltliche, funktionale Kompatibili-tät von Services durch die Entwickler einerservicebasierten Anwendung sichergestellt.Die automatische Identifikation und Einbin-dung von Services mit einer bestimmtenFunktionalität (z. B. beim Ausfall eines nichtredundanten Dienstes) ist nur mithilfe einermaschinenlesbar repräsentierten, semanti-schen Schnittstellenbeschreibung möglich(z. B. durch Referenzierung einer Ontologie).

Insgesamt ist festzuhalten, dass auch mit derumfassenden Bereitstellung von Lösungen ent-lang der skizzierten Entwicklungslinien SOAnicht in jedem Anwendungsszenario ein ange-messenes Kosten-Nutzen-Verhältnis aufweisenwird. Dennoch verspricht SOA als IT-strategi-sche Stoßrichtung klare Wettbewerbsvorteile,wenn die zu unterstützenden Prozesse mitBedacht gewählt werden und die sonstigenErfolgsfaktoren Berücksichtigung finden (vgl.Beitrag von [Durst & Daum 2007] in diesemHeft).

Literatur

[Berlecon Research 2006] Berlecon Research: Pres-semitteilung Berlecon: SOA: Unternehmen pro-fitieren primär von höherer Flexibilität, www.

berlecon.de/presse/index.php?we_objectID=272;Zugriff am 15.09.2006.

[Brabänder & Klückmann 2006] Brabänder, E.;

Klückmann, J.: Geschäftsprozessmanagementals Grundlage für SOA, www.sigs.de/publicati

ons/os/2006/BPM/brabaender_klueckmann_OS_BPM_06.pdf; Zugriff am 15.10.2006.

[Burghardt & Hagenhoff 2003] Burghardt, M.; Ha-

genhoff, S.: Web Services – Grundlagen undKerntechnologien. Arbeitspapier, Institut fürWirtschaftsinformatik, Abteilung Wirtschafts-informatik II, Universität Göttingen, 2003.

[Capgemini 2006] Capgemini: Studie IT-Trends2006, www.de.capgemini.com/m/de/tl/IT-Trends

_2006.pdf; Zugriff am 15.09.2006.

Page 11: 10 Antworten zu SOA

10 Antworten zu SOA

HMD 253 17

[Dostal et al. 2005] Dostal, W.; Jeckle, M.; Melzer, I.:

Service-orientierte Architekturen mit Web Ser-vices. Konzepte – Standards – Praxis. SpektrumAkademischer Verlag, Heidelberg, 2005.

[Dumke et al. 2005] Dumke, R.; Bundschuh, M.;Schmietendorf, A.; Ebert, C.: Best Practices inSoftware Measurement. Springer-Verlag, Ber-lin, 2005.

[Durst & Daum 2007] Durst, M.; Daum, M.: Erfolgs-faktoren serviceorientierter Architekturen. In:HMD – Praxis der Wirtschaftsinformatik, Heft253, 2007, S. 18.

[Gehra und Hess 2004] Gehra, B.; Hess, T.: XBRL –Ein Kommunikationsstandard für das FinancialReporting. In: Zeitschrift für Management undControlling, 48 (6), S. 403-405.

[Hohpe 2002] Hohpe, G.: Web Services: Pathway toa Service-Oriented Architecture? Arbeitspapier,ThoughtWorks, Inc., 2002.

[Keen et al. 2004] Keen, M.; Bishop, S.; Hopkins, A.;Milinski, S.; Nott, C.; Robinson, R.; Adams, J.; Ver-

schueren, P.; Acharya, A.: Patterns: Implement-ing an SOA Using an Enterprise Service Bus. IBMCorporation, 2004.

[Klose & Knackstedt 2007] Klose, K.; Knackstedt, R.:

Serviceidentifikation für die Produktionspla-nung eines mittelständischen Auftragsferti-gers. In: HMD – Praxis der Wirtschaftsinforma-tik, Heft 253, 2007, S. 47.

[Krafzig et al. 2004] Krafzig, D.; Banke, K.; Slama, D.:

Enterprise SOA: Service-Oriented ArchitectureBest Practices. 2004.

[Krcmar 2004] Krcmar, H.: Informationsmanage-ment. 4. Aufl., Springer-Verlag, Heidelberg,2004.

[Richter et al. 2005] Richter, J.-P.; Haller, H.; Schrey, P.:

Serviceorientierte Architektur. Informatiklexi-kon der Gesellschaft für Informatik e.V. (GI),www.gi-ev.de/index.php?tx_ttnews%5Btt_news%5D=118&cHash=7d76cbc557&id=647&type=98;Zugriff am 15.09.2006.

[Röwekamp 2006] Röwekamp, R.: SOA brauchtstrikte Governance, www.cio.de/knowledgecen-ter/soa/820266/index2.html; Zugriff am 15. 09.2006.

[Schelp & Stutz 2007] Schelp, J.; Stutz, M.: SOA-Gov-ernance. In: HMD – Praxis der Wirtschaftsinfor-matik, Heft 253, 2007, S. 66.

[Thomas et al. 2007] Thomas, O.; Leyking, K.; Drei-fus, F.: Prozessmodellierung im Kontext service-orientierter Architekturen. In: HMD – Praxis derWirtschaftsinformatik, Heft 253, 2007, S. 37.

[Weerawarana et al. 2005] Weerawarana, S.; Curbe-

ra, F.; Leymann, F.; Storey, T.; Ferguson, D. F.: WebServices Platform Architecture: SOAP, WSDL,WS-Policy, WS-Addressing, WS-BPEL, WS-Reliab-le Messaging and More. Prentice Hall PTR, Up-per Saddle River, NJ, USA, 2005.

Dr. Stefan ReinheimerBIK – Beratungsgesellschaft fürInformations- und Kommunikationsmanagement mbHKersbacher Weg 690482 Nü[email protected]

Dipl.-Kfm. Florian LangDipl.-Wirtsch.-Inf. Jörg PuruckerDipl.-Wirtsch.-Inf. Hinnerk BrügmannUniversität Erlangen-NürnbergLehrstuhl für Wirtschaftsinformatik IILange Gasse 2090403 Nürnberg{florian.lang, Joerg.Purucker, hinnerk.bruegmann}@wiso.uni-erlangen.dewww.wi2.uni-erlangen.de