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.

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 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 dann 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 Bedingungen spezifiziert, sowie

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

Prozesse im Orchestration-Layer

Der Orchestrierungs-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 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 Orchestrierungs-Layer braucht ein standardisiertes Set von Funktionsbausteinen, die über Applikationsgrenzen hinwegreichen. Sonst entspräche er einem Orchester, in dem alle Musiker unterschiedliche Partituren spielten.

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 aufgrund der 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 sie mehr Aufwand erforderte als die Implementierung eines neuen Gesamtsystems.

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.

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 meist eine neue Anwendung einführen.

Vorteil für die ERP-Anbieter

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 einbezogen 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 zugehörige CRM-Modul 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 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 mit sich bringen. Auf der anderen Seite wird die Marktentwicklung hin zu kompletten Anwendungsplattformen im SaaS-Anbietermarkt das Einsatzpotenzial von anwenderseitigen SOA-Systemen reduzieren.

Fazit

Die SOA-Welle wird weiter abebben. Die Gründe liegen in den dauerhaft hohen Investitionen, die für eine flexible und wirtschaftliche Prozessplattform auf Basis heterogener Anwendungslandschaften notwendig sind. Übrig bleiben vor allem SOA-Anwendungsszenarien mit einzelnen, Web-basierenden Add-ons auf Basis von Kernapplikationen mit moderner Technik. Sie erfordern keine hohen Anfangsinvestitionen in eine Technologieharmonisierung. (qua)