Das Wichtigste zuerst: Die Vorstellung, dass eine SOA-Lösung per Zusammenfügen von herstellerfremden Funktionsbausteinen aufgebaut werden könnte, ist eine Illusion. Der Aufwand, der nötig ist, um die Heterogenität zu überwinden, ist in vielen Fällen zu groß für einen langfristig wirtschaftlichen Betrieb solcher Plattformen. (Siehe auch: "Was bleibt vom Hype?")

Die SOA-Architektur lässt sich mit Hilfe von Technologie-Sets, "SOA-Stacks" genannt, vollständig abbilden. Aber worum handelt es sich dabei eigentlich? Um installierbare Werkzeuge zur Anwendungsintegration, um Prozessmodellierungs-Tools mit Programmierschnittstellen oder doch eher um einen gedanklichen Architekturansatz zur Verknüpfung von Prozessmodellen mit realen Anwendungskomponenten? Die Unterscheidung fällt oft schwer.

Die erste Ebene der Integration

Viele Anbieter nennen den Enterprise Service Bus (ESB) als erste Integrationsebene für die unterschiedlichen Geschäftsapplikationen. Er soll die Interaktion der Anwendungsfunktionen in den bestehenden Systemen ermöglichen. Doch hier beginnt bereits das Problem mit der Heterogenität.

Betrachten wir einmal eine typische Situation - den Einsatz eines CRM- und eines ERP-Systems unterschiedlicher Anbieter bei einem Produktionsunternehmen: Die Funktionen zur Erfassung eines neuen Kunden sind sowohl im CRM- als auch im ERP-System abgebildet, aber auf unterschiedliche Weise. Das CRM-System verlangt Informationen über die Ansprechpartner des Kunden, das ERP-System Daten für die Debitorenbuchhaltung. Auch das Datenmodell ist nicht einheitlich ausgeprägt. Im CRM-System wird der Kunde zunächst im Stammdatenobjekt "Interessent" verwaltet; erst bei Auftragserteilung wird er zum "Kunden". Das Datenbankfeld für die Kundennummer ist im CRM-System ein numerisches Feld mit der Bezeichung "Cust-No", im ERP-System ist es alphanumerisch und heißt "Kd-Nr". Das CRM-System ist in einem .NET-Framework implementiert, das ERP-System auf RPG-Basis realisiert.

Autarke Dienste im Service-Layer

Um in Prozessmodellen autark verwendbare Dienstaufrufe bereitstellen zu können, bedarf es einer umfangreichen Harmonisierung der Applikationsbausteine für die Kundenverwaltung auf allen Ebenen:

• Applikationslogik ("Kunde erfassen"),

• Applikationsarchitektur (.NET versus RPG),

• semantisches Datenmodell ("Kunde" versus "Interessent") und

• Datenbanksyntax (Feld-"Mapping").

Erst wenn sie durchgängig standardisiert sind, können die Funktionsbausteine der verschiedenen Applikationen in der nächsten Ebene, dem Service-Layer, als autark aufrufbare Dienste mit folgenden Komponenten hinterlegt werden:

• Schnittstellen für den Zugriff auf Funktionen und Daten,

• ein Service-Contract, der Berechtigungen und Ablaufbedingungen des Dienstes spezifiziert, und

• eine Service-Implementierung mit der technischen Realisierung des Dienstes.

Prozesse im Orchestration-Layer

Die nächste Ebene, der Orchestration-Layer, bildet die Geschäftsprozesse ab. Eine Anwendung wird dabei als Sequenz von Dienstaufrufen modelliert. Steuern lässt sie sich über den auf dieser Ebene abgebildeten Prozessfluss sowie mit Hilfe der unterschiedlichen Schritte, Entscheidungspunkte und Verzweigungen in den definierten Workflows.

Eine SOA-Plattform lässt sich nur dauerhaft wirtschaftlich betreiben, wenn sie eine flexible Abbildung der Geschäftsprozesse im Hinblick auf die bestehenden Applikationen erlaubt. Der Orchestration-Layer braucht ein standardisiertes Set von Funktionsbausteinen, die über Applikationsgrenzen hinwegreichen. Sonst entspräche er einem Orchester, in dem alle Musiker mit unterschiedlichen Partituren arbeiteten.

Wiederverwendung ist der Schlüssel

Die Wiederverwendbarkeit der Services erleichtert die SOA-Praxis. Ohne sie müsste die Ablaufsteuerung der eingesetzten Applikationen bei jeder Geschäftsprozessänderung durch alle Ebenen der SOA-Plattform hindurch angepasst oder zumindest vollständig überprüft werden - oft bis hinunter auf die Feldebene aller beteiligten Anwendungen.

Doch in Bezug auf Prozessmodelle, Datenlogik und Funktionsbausteine sind derzeit keinerlei Standardisierungsansätze im Markt für Geschäftsanwendungen erkennbar. Folglich werden die beschriebenen Hürden nicht nur weiter bestehen, sondern im Sinne fortschreitender Differenzierungsbemühungen der Hersteller sogar zunehmen.

Das Lehrgeld ist hoch

Eine vom SOA-Anbieter Progress Software bei Vanson Bourne in Auftrag gegebene Studie belegt, dass sich im Durchschnitt nur etwa 30 Prozent der in Anwenderunternehmen entwickelten Services wiederverwenden lassen. 25 Prozent der befragten Unternehmen gaben die Wiederverwendungsrate sogar mit weniger als einem Zehntel an.

Das US-amerikanische Beratungsunternehmen Burton Group untersuchte SOA-Initiativen auf ihre Erfolgsquote. Es qualifizierte 50 Prozent der Vorhaben als gescheitert und weitere 30 Prozent als zumindest nicht erfolgreich.In der Praxis sehen die Ergebnisse tatsächlich bescheiden aus: Statt von einer durchgängigen Optimierung der Geschäftsprozesskette auf Basis komplexer Anwendungsgebilde ist die Rede meist nur von vereinzelt erreichten Teilzielen in der Web-basierenden Bereitstellung von Funktionsbausteinen - oft außerhalb der Kernwertschöpfung des Unternehmens. Da wird zum Beispiel die Verbindung zwischen der Terminverfolgung aus dem Projekt-Management-Tool mit dem Aufgaben-Management im CRM-System als große Errungenschaft gefeiert, obwohl hierfür mehr Aufwand investiert wurde, als für die Implementierung eines neuen Gesamtsystems nötig gewesen wäre.

Außer Spesen nichts gewesen?

Das hinterlässt Wirkung bei den Anwenderunternehmen. Laut Gartner wollen derzeit nur noch 25 Prozent der Unternehmen ein SOA-Projekt starten, nachdem es 2007 immerhin 53 Prozent waren. Im selben Zeitraum hat sich die Zahl der Unternehmen, die SOA komplett ad acta gelegt haben, verdoppelt: Sie stieg von sieben auf 16 Prozent. In der Gartner-Studie nannten SOA-Verantwortliche auffallend häufig Entwicklungsumgebungen und Sprachen wie Java, .NET, Perl oder PHP als Schlüsseltechnologien. Das passt ins Bild von SOA-Projekten als Programmierbaustellen zur Überwindung heterogener Anwendungslandschaften.

Vorteil für die ERP-Anbieter

Wenn sich die Funktionsangebote in den einzelnen Applikationen einer historisch gewachsenen IT-Landschaft weitgehend überlappen, sind die notwendigen Investitionen für den Umbau zu einem Funktionsbaukasten meist zu hoch. Sind zusätzlich nicht kompatible Technologiewelten bis auf die Ebene der Programmiersprachen zu verbinden, ließe sich für dasselbe Geld im Allgemeinen auch eine neue Anwendung einführen. (Zum Thema siehe auch: "Rezession bricht SOA das Genick")

Hier sind die SOA-Stacks der Anbieter von kompletten betriebswirtschaftlichen Anwendungsplattformen klar im Vorteil - allerdings nur innerhalb ihrer eigenen Module. Sollen weitere Anwendungen aus fremden, nicht kompatiblen Technologieumgebungen eingezogen werden, erhebt sich wieder die Hürde hoher Anfangsinvestitionen. Darin lässt sich sogar eine Marktstrategie erkennen: Wenn es für ein Anwenderunternehmen effizienter ist, den eingesetzten ERP-Kernel um das CRM-Modul desselben Anbieters auszubauen als das vorhandene Kunden-Management-System im Rahmen einer SOA zu integrieren, so ist das für den Softwarelieferanten ein Wettbewerbsvorteil.

Für Web-Services sieht es anders aus

Ganz anders sieht es aus, wenn neue Techniken oder Standardkomponenten außerhalb der bestehenden Anwendungssysteme integriert werden sollen, beispielsweise der Zugriff von einem Web-basierenden CRM-System auf standardisierte Web-Services, etwa einen Routenplaner oder einen Hotelbuchungsservice. Hier ist keine Harmonisierung der eingesetzten Funktionsbausteine auf allen Ebenen der Applikationsarchitektur notwendig, sondern nur die Integration eines Add-on im Business-Kontext der Geschäftsprozesse.

Der Trend zur Bereitstellung von Web-basierenden Anwendungskomponenten im Zuge des SaaS-Wachstums (Software as a Service) dürfte vermehrt wirtschaftlich sinnvolle SOA-Szenarien in einem dauerhaft ausgewogenen Nutzen-Aufwand-Verhältnis mit sich bringen. Auf der anderen Seite wird die Marktentwicklung hin zu kompletten Anwendungsplattformen im SaaS-Anbietermarkt (Software as a Service) das Einsatzpotenzial von anwenderseitigen SOA-Systemen reduzieren. (qua)