SOA

Serviceorientierte Architekturen beschreiben einen Ansatz zur Gestal-tung von IT-Landschaften auf der Basis von Diensten (Services). Dies beinhaltet, dass Geschäftsprozesse in einzelne Komponenten bzw.

Services mit jeweils spezifischen Aufgaben zerlegt und flexibel orches-triert werden können. So lässt sich bspw. ein Bestellvorgang in die Teil-prozesse „Eingang der Bestellung“, „Versand einer Eingangsbestäti-gung“, „Prüfung auf offene Rechnungen des Kunden beim Unterneh-men“, „Prüfung der Bonität des Kunden“ und „Lagerbestandsabfrage“

zerlegen. Diese Teilprozesse können als einzelne Softwarekomponenten bzw. Services abgebildet und ihre Funktionalität über Schnittstellen auf-rufbar gemacht werden. Die einzelnen Services, z.B. die „Lagerbestands-abfrage“, stellen wiederholbare Teilfunktionalitäten bereit, die in unter-schiedlichen Prozessen genutzt werden können. Sie können sowohl vom Unternehmen selbst als auch von einem externen Anbieter zur Verfügung gestellt werden.

SOA stellt dabei – entgegen früheren, technisch orientierten Konzepten wie Enterprise Application Integration (EAI) – Geschäftsprozesse in den Vordergrund und ermöglicht deren IT-gestützte, agile und flexible Gestaltung. Dies gilt sowohl für unternehmensinterne, als auch für unter-nehmensübergreifende Prozesse. Entsprechende SOA-Lösungen helfen bei der Auswahl geeigneter externer webbasierter Dienste und ihrer flexiblen und bedarfsgerechten Integration in die eigenen Geschäfts-prozesse. Das Dienstemanagement wird dabei umso wichtiger, je mehr Geschäftspartner und externe Services eingebunden werden sollen.

Im Wesentlichen gliedert sich eine serviceorientierte Architektur in drei Teile:

 den Service-Provider, der den Dienst entwickelt und dessen Funktionalität zur Verfügung stellt,

 das Repository (oder die Registry), ein Verzeichnis in dem die Dienste registriert und beschrieben werden, sowie

 den Service-Requester, der den Dienst anfordert.

Erst die Registrierung und Beschreibung des Dienstes in einem Verzeich-nis ermöglicht es dem potenziellen Nutzer, den Dienst anhand

spezifi-Besondere Bedeutung von SOA, BPM und Webservices ...

... für die flexible Einbindung externer Dienste

Flexible Zerlegung und Orchestrierung von

Geschäftsprozessen anhand einzelner Services

Geschäftsprozesse stehen im Vordergrund

scher Kriterien (Funktionalität, Systemanforderungen) zu finden und aus-zuwählen.

Durch den Einsatz von Standards und standardisierten Schnittstellen wird gewährleitet, dass die Services verschiedener Anbieter miteinander vernetzt und lose und unabhängig miteinander gekoppelt werden kön-nen.⁴⁴ Zentrales Ziel ist dabei, dass die Services wiederverwendbar und plattformübergreifend einsetzbar sind. Die Services können damit so-wohl innerhalb eines Unternehmens, als auch extern von einem Service- Provider bereitgestellt werden.

Die Granularität der Services spielt bei Auswahl und Orchestrierung eine wichtige Rolle. Häufig beinhaltet ein Service nicht einen einzelnen, ex-trem feingranularen Teilprozess, wie bspw. die einmalige Abfrage eines Datensatzes in einer Datenbank, sondern eine bereits sinnvoll zusam-mengesetzte Funktionalität für einen Geschäftsvorgang, z.B. eine kom-plexe Lagerbestandsprüfung, die bereits die Neubestellungen mit einbe-zieht. Wird die Granularität eines Dienstes zu grob gewählt, schränkt dies jedoch seine Flexibilität und Wiederverwendbarkeit ein.⁴⁵

Enterprise Service Bus

Um die Servicesuche, das Monitoring und insbesondere die Bündelung und Integration der Services zu erleichtern, wird die serviceorientierte Architektur heute häufig um ein zentrales viertes Element ergänzt: den Service Bus. Ein Enterprise Service Bus (ESB) befindet sich innerhalb des Unternehmens und bildet, wenn er zum Einsatz kommt, den Kern der SOA. Als eine Art Middleware erfüllt er eine Vielzahl von Aufgaben.

Vor allem agiert er als Bindeglied zwischen unterschiedlichen Systemen und Anwendungen und sorgt für deren Interoperabilität. Er unterstützt verschiedene Protokolle, Kommunikationsmodi und Nachrichtenformate und verfügt über eine Vielzahl von Schnittstellen (Adapter). Darüber hi-naus bedient er sich der sog. Service-Virtualisierung. Diese ermöglicht die Bereitstellung einer Reihe allgemein benötigter Bausteine zum wie-derholten Gebrauch. Dazu zählt bspw. Programm-Code für Verfügbar-keits-, Performance- und Sicherheitsanforderungen. Entsprechender Code kann im ESB implementiert und bei Bedarf flexibel hinzugefügt werden. Daraus resultieren eine reduzierte Servicekomplexität sowie da-mit einhergehende Zeit- und Kostenersparnisse bei der Serviceentwick-lung. Dabei ermöglicht der ESB nicht zuletzt die Durchsetzung bestimm-ter Policies, da die SLA- und Security-Anforderungen von der eigent-lichen Servicefunktionalität abgekoppelt, zentral überwacht und gema-nagt werden können – ein Vorteil, der gerade in großen Unternehmen zum Tragen kommt.

Bisher kommt der Enterprise Service Bus vorwiegend für das Manage-ment der internen Dienste zum Einsatz. Jedoch bildet er insbesondere aufgrund seiner Fähigkeit, verschiedene Formate zu verstehen und zu verarbeiten, zugleich eine wichtige Basis, um auch die Services externer

44 Eine lose Kopplung reduziert die Abhängigkeit zwischen Softwarekomponenten auf ein Minimum. Dies bedeutet bspw., dass Änderungen im Code einer Komponente bzw. eines Dienstes nicht automatisch Änderungen in anderen Komponenten er-zwingen.

45Auer et al. (2007): „Marktstudie SOA und Web Services Produkte“.

Standards gewährleisten

Von Bedeutung vor allem für die Einbindung externer

Anbieter flexibel einbinden bzw. eigene Services extern anbieten zu können. Gerade vor dem Hintergrund noch mangelhafter Standardi-sierung leistet der ESB zentrale Arbeit, um Interoperabilität zu gewähr-leisten.

Internet Service Bus

Während der Enterprise Service Bus als zentrales SOA-Softwareelement für den Einsatz innerhalb von Unternehmen bereits von einer Vielzahl von Herstellern angeboten und mit diversen Zusatzfunktionen ausge-stattet wird, wurde der erste Internet Service Bus (ISB) erst im Jahr 2009 der Öffentlichkeit präsentiert.⁴⁶ Er zielt darauf ab, die Service-Bus-Funktionalität (Orchestrierung, Mapping, Monitoring) direkt ins Internet zu verlagern, wo die Services unterschiedlicher Hersteller in der Cloud direkt miteinander kommunizieren können. Für Softwarehersteller, Inte-gratoren und Hoster verspricht der ISB einen wichtigen Technologiebau-stein, der ihnen neue, Cloud-basierte Geschäftsmodelle ermöglicht. Er stellt mithin auch einen interessanten Ansatz für ein künftiges Internet der Dienste dar.

Aufgrund des noch sehr frühen Marktstadiums dieser Lösung lässt sich über seine Entwicklungschancen bisher wenig sagen. Einerseits liegt der Reiz des Internet Service Bus gerade für KMU darin, dass kein interner Service Bus implementiert und gepflegt werden muss. Auf der anderen Seite bedeutet die Nutzung des Internet Service Bus auch die Auslage-rung der gesamten ServiceorchestrieAuslage-rung und somit durchaus geschäfts-kritischer Bereiche.

Enterprise Mashups

Während über SOA die Integration von Softwarekomponenten auf tech-nischer Ebene realisiert wird, muss die Integration auch über eine ent-sprechende Benutzeroberfläche für Nutzer sichtbar gemacht. Eine Form, die sich aufgrund ihrer SOA-Basierung als geeignet zeigt und mehr und mehr zum Einsatz kommt, ist ein so genannter Enterprise Mashup.

Hierbei werden mehrere Unternehmensanwendungen, die ihrerseits auf den Services unterschiedlicher (interner und externer) Anbieter basieren, auf einer Plattform zusammengestellt, mit Zusatzdaten ergänzt und als integrierter Dienst beispielsweise in Form von Echtzeitdiagrammen sicht-bar gemacht. Sie dienen vorwiegend der Sammlung, Bereitstellung, Wie-tergabe und Visualisierung von Informationen bzw. der Bereitstellung einer neuen Applikation anhand von bereits vorhandenen Daten und Informationen. So lassen sich z.B. in einem Call-Center-Mashup interne Bestellmanagement-Informationen und externe Informationen des Logis-tikdienstleisters über den Stand der Auslieferung von Produkten (Paket-verfolgung) bündeln. Somit sieht der Call-Center-Mitarbeiter auf einen Blick den Bestellstatus eines Kunden und den Fortschritt der Ausliefe-rung seiner Ware, ohne jedes Mal zwischen den Anwendungen wechseln zu müssen.⁴⁷ SOA bildet die Grundlage für die Einbindung und Weiterver-arbeitung derartiger Funktionalitäten.

46Annuscheit (2009): „SOA als Basis für Cloud-Computing“.

47Crupi/Warner (2009): „Enterprise Mashups: The New Face of Your SOA“.

ISB: Verlagerung der Service-Bus-Funktionalität ins Internet

Entwicklungschancen schwer absehbar

Visualisierung integrierter Dienste als Mashup

B2B-Integration

Während SOA bisher überwiegend innerhalb von Unternehmen zum Ein-satz kommt, zeigen sich besondere Vorteile gerade für unternehmens-übergreifende Prozesse im Rahmen von B2B-Geschäftsbeziehungen. Mit dem Ziel, global integrierte Wertschöpfungsketten zu schaffen bzw. sie zu beschleunigen und daraus Wettbewerbsvorteile zu generieren, rückt dabei für Unternehmen die Automatisierung von B2B-Geschäftsprozes-sen mehr und mehr in den Mittelpunkt. Manuelle Eingriffe, vor allem beim Transaktionsdatenaustausch und der Bereitstellung webbasierter Dienstleistungen, gilt es auf ein Mindestmaß zu beschränken.

Um diesem Ziel näher zu kommen, lag ein erster wichtiger Schritt im Ein-satz so genannter E-Business-Standards für den Daten- und Dokumen-tenaustausch zwischen Geschäftspartnern.⁴⁸ Dabei legen bspw. Trans-aktionsstandards wie EANCOM oder GS1 XML die Formate für die ver-schiedenen, elektronisch auszutauschenden Geschäftsnachrichten (z.B.

eine Bestellung oder eine Auftragsbestätigung) fest, um die automa-tische Weiterverarbeitung durch IT-Systeme zu ermöglichen.

SOA geht einen Schritt weiter und ermöglicht die Modellierung und auto-matisierte Durchführung gesamter Prozessabläufe, basierend auf dem Zusammenspiel externer und interner Applikationen. Unternehmen kön-nen bspw. ihren Geschäftskunden eikön-nen Webservice zur Bestandsabfra-ge über das Internet zur Verfügung stellen. Dieser Webservice kann schnell und flexibel für neue Kunden freigeschaltet und von diesen ge-nutzt werden, ohne dass jedes Mal kundenspezifischer Code generiert und entsprechende Abfragedokumente verschickt werden müssen. Beim Kunden kann der Webservice in die eigenen Systeme integriert werden, um bspw. den Bestellprozess zu optimieren. Anhand der automatischen Bestandsabfrage können Bestellungen entsprechend angepasst werden.

Diese umfassende Form der E-Business-Integration setzt jedoch nicht nur den Einsatz standardisierter Webservices voraus, sondern auch Standards zur Produktidentifikation. Sie gewährleisten, dass von den IT-Systemen der Geschäftspartner eindeutig erkannt werden kann, auf wel-che Produkte sich die Bestandsabfrage bzw. der anschließende Bestell-prozess bezieht.