Last Exit SOA

Boom oder Blase? An SOA, Akronym für „Service Oriented Architecture“ kommt kein Unternehmen vorbei. Zumindest suggeriert die Mehrzahl der einschlägigen Studien diesen Schluss. Laut einem Bericht der Aberdeen Group mit dem Titel „Enterprise Service Bus and SOA Middleware“ starteten neun von zehn Firmen spätestens im vergangenen Jahr mit entsprechenden Projekten. Die Analysten der Gartner Group rechnen damit, dass am Ende dieser Dekade bei mindestens 65 % der großen Organisationen mehr als 35 % des Anwendungsportfolios SOA-basiert sein wird. Der Vergleichswert aus dem Jahre 2005 lag noch bei 5 %.

Auch wenn nach einer Analyse der Experton Group die Firmen hierzulande bislang zögern, scheint die Entwicklung vorgezeichnet: „Spätestens 2010 dürften die meisten Unternehmen eine SOA-Initiative gestartet haben, vorausgesetzt, Standards können sich zumindest innerhalb bestimmter Industrien etablieren“, gibt sich Analyst Matthias Zacher überzeugt.

Was ist so revolutionär an dem Konzept, das zu solch optimistischen Prognosen verleitet? Wer Massimo Pezzini diese Frage stellt, erhält die trockene Antwort „Nichts!“ Für den Gartner-Analysten ist eine serviceorientierte Architektur letztlich eine moderne Fassung wohlbekannter Begriffe des verteilten Computing wie Modularisierung, Kapselung oder spätes Binden. Auslöser für die wachsende Akzeptanz sei der Durchbruch von Programmierumgebungen wie Java und .Net, des Geschäftsprozessmanagements sowie der Webservices-Technik. Gerade Letztere erachtet Pezzini als wichtig, da sie eine Standardplattform für die Zusammenarbeit von IT-Systemen bereitstellt. „Die SOA-Adaption in den Organisationen hat gerade erst begonnen und wird in Zukunft das normale Programmierkonzept für Anwendungen sein - vergleichbar mit der Rolle, die das Client-Server-Modell in den Neunzigern einnahm“, meint Pezzini.

Aus technischer Perspektive lässt sich SOA am einfachsten als ein Softwareentwicklungsansatz definieren, der auf den bekannten Vorgaben Modularität und Wiederverwendbarkeit beruht. Frei nach gängigen Definitionsversuchen werden bei serviceorientierten Architekturen die Anwendungssysteme nicht mehr als ein einziges Programm realisiert, sondern durch die Komposition voneinander unabhängiger, lose gekoppelter Dienste (Services). Sogenannte Service Provider stellen diese bereit, Service Consumer fordern sie an.

Software mit Kultur-Anstrich

Feinsinnig unterscheiden Fachleute noch zwischen Konversation, Choreografie und Orchestrierung von (Web-)Services. Allgemein ausgedrückt behandelt Konversation die konkrete Kommunikation zwischen den Diensten, die Choreografie (Koordination) befasst sich mit zulässigen Nachrichtenabfolgen, ist jedoch kein ausführbarer Prozess. Diese Aufgabe ist der Orchestrierung vorbehalten. Sie beschreibt, koordiniert und ruft die Geschäftsprozesse beziehungsweise die jeweiligen Services auf. Prinzipiell ließe sich eine SOA mit allen dienstebasierten Techniken (CORBA, EJB, RMI oder moderne Cobol-Versionen) umsetzen. In der Regel wird sie aber mittels der Webservices-Standards SOAP (Nachrichtenaustausch), WSDL (Web Services Definition Language, Dienstebeschreibung) und UDDI (Universal Discovery, Description and Integration, Verzeichnisdienst) konstruiert.

SOA liefert einen sauberen architektonischen Aufbau, da Prozesse von der Beschreibung und Umsetzung der Anwendungen getrennt sind. Eine gut eingestellte SOA sollte die Anzahl der benötigten Dienste klein halten. Das Grundprinzip lautet, Services so zu entwickeln, das sie sich in unterschiedlichen Anwendungen einsetzen lassen. Mehrfach nutzbare Dienste senken selbstredend die Entwicklungskosten und erleichtern die Wartung.

Die Technik ist jedoch nur die eine Seite der Medaille. Darüber hinaus kümmert sich das Konzept um die betriebswirtschaftlichen Belange der Fachabteilungen sowie deren Umsetzung in Software. In der Theorie bedient man sich dazu aus einem Pool von katalogisierten Geschäftsprozessbausteinen. Ändern sich die Abläufe, müssen die Unternehmen keine neuen großen Anwendungspakete installieren, sondern lediglich die benötigten Services anders zusammenstellen und gegebenenfalls ergänzen. Beispielsweise strebt SAP - in Zusammenarbeit mit IDS Scheer - an, ihre ERP-Software künftig direkt aus dem Prozessbeschreibungen heraus konfigurieren zu können. Aus Unternehmensperspektive zählen folglich größere Flexibilität der Anwendungen, schnellere Verfügbarkeit und eine bessere Sicht auf die Prozesse zu den Vorteilen von SOA.

Mit anderen Worten: Für viele Protagonisten ist SOA zunächst ein betriebswirtschaftliches Thema und erst in zweiter Linie eine technisches. Deshalb fällt in diesem Zusammenhang stets auch der Begriff „Geschäftsprozessmanagement“. SOA gibt es folglich nicht von der Stange zu kaufen, wie Philip Howard, Forschungsdirekter bei Bloor Research, in seinem Papier „What you don’t want to know about SOA“ feststellt. Ebenso wenig ist das Konzept kostenlos zu haben. Es fallen zwangsläufig Veränderungen auf organisatorischer Seite an, da zahlreiche Mitarbeiter aus IT- und Fachabteilungen bei der Definition der Serviceprozesse helfen müssen. Diese Kosten lassen sich nach Ansicht von Beratern gegenüber dem Management nicht einfach auf Basis technischer Überlegungen begründen, sondern hier sind handfeste Vorteile aus der geschäftlichen Perspektive gefragt.

Den kompletten Artikel finden Sie in der aktuellen Print-Ausgabe. (jd)