Mythos 2: Integration und Standards
Eine SOA ermöglicht eine einfache Integration mit internen und externen Partnern, die Benutzung von Standards sichert Interoperabilität. Diese Aussage wird heute gebetsmühlenhaft wiedergegeben, mit der Absicht: Wenn man etwas nur oft genug behauptet, dann wird es wahr. Doch stimmt die Sache mit der Integration und den Standards wirklich?
Kernaussagen
.Standardisierung als Selbstzweck ist sinnlos.
Standards nützen nur beim Austausch von Daten, Personen oder Prozessen.
Standards versprechen "big Business" für den, der den Standard setzt.
Standards sind ambivalent, sie limitieren und befähigen zugleich.
Um den Komplex Integration und SOA näher zu betrachten, sollte man sich klar machen, was mit der Integration erreicht werden soll. Integration ist, außer für Hersteller von EAI-Werkzeugen (EAI = Enterprise Application Integration), kein Selbstzweck. Vielmehr dient sie dem Informationsaustausch zwischen Unternehmen oder innerhalb eines Unternehmens zwischen verschiedenen Anwendungen oder Services. Aus der Sicht einer SOA stellen sich bei der Integration in beiden Fällen Fragen nach der Prozessintegration, der Interoperabilität zwischen Services und der Interoperabilität zwischen Services und Altsystemen.
Bei der Prozessintegration ist die große Schwierigkeit die des Outtaskings. Beim Outtasking wird nicht der gesamte Prozess, sondern nur wenige Aktivitäten (Tasks) an ein anderes Unternehmen gegeben. Dieses erledigt die Aufgabe, danach kommt der Prozess wieder ins Unternehmen zurück und wird weiter abgearbeitet. Eine solche Form der unternehmensübergreifenden Prozessintegration setzt voraus, dass die Verantwortlichen in der Lage sind, Prozesse und Services übergreifend zu koordinieren. Da die Prozesskoordination aber selbst innerhalb von Unternehmen hinreichend schwierig ist, darf bezweifelt werden, dass SOA auf wundersame Art und Weise eine Prozessintegration spontan herbeiführt.
Die Integration auf Serviceebene setzt Interoperabilität voraus. Interoperabilität an sich ist nicht sichtbar. Aber das Fehlen von Interoperabilität äußert sich in Konflikten. Diese werden üblicherweise in aufsteigender Schwierigkeit klassifiziert:
technischer Konflikt - heterogene Hardware und Betriebssysteme.
syntaktischer Konflikt - unterschiedliche Repräsentation von Daten oder Funktionen, abweichende Protokolle.
struktureller Konflikt - heterogene Modellrepräsentationen.
semantischer Konflikt - unterschiedliche Bedeutungen derselben Ausdrücke.
Für die Lösung von technischen und syntaktischen Konflikten gibt es eine lange Tradition in der IT. Speziell mit dem Einsatz von hardware- und applikationsneutralen Protokollen wie XML und HTTP lassen sie sich in den Griff bekommen. Im Gegensatz dazu sind die strukturellen und semantischen Konflikte viel schwieriger. Durch die Mechanismen der öffentlichen und standardisierten Übertragungs- und Ausführungsprotokolle, welche die Konflikte auf technischer und syntaktischer Ebene gut unter Kontrolle bringen, treten die Probleme auf struktureller und semantischer Ebene stärker in den Vordergrund. Was die IT selbst so lange beschäftigt hat, nämlich die Tatsache, dass ihre eigenen technischen Aufrufe schief gehen, lässt sich mit einer SOA besser in den Griff bekommen. Doch die nächste Stufe der semantischen Interoperabilität wird dadurch überhaupt nicht erreicht. Da aber Services primär fachlich motiviert sein sollen, können sie auch nicht zusammenarbeiten, da sie sich fachlich nicht verstehen! Diese semantischen Konflikte können nur durch Methoden wie Ontologien oder semantische Services, nicht aber durch eine Architektur gelöst werden.
Die syntaktische Integration wird heute schon durch EAI-Systeme beherrscht. Hier sind die Hauptkostentreiber nicht der einfache Aufruf, sondern die semantischen Differenzen zwischen den Anwendungen. Wenn diese Erfahrungen auf Services extrapoliert werden, zeigt sich, dass Integration in einem SOA-Umfeld nur ein Schlagwort bleiben wird.
Der dritte Aspekt, der der Altsystemintegration, verhält ist ähnlich dem der EAI-Systeme: Auch hier können die Erfahrungen weitergegeben werden. SOA wird dies nicht einfacher machen, ganz im Gegenteil. Altsysteme haben neben reiner Funktionalität auch stets ein Modell des Prozesses wie der Kommunikation im Unternehmen codiert. Aus diesem Konglomerat einfach einen Service herauszulösen, ist genauso schwer oder einfach, wie eine Aufrufschnittstelle zu bauen. Dies war schon in der Vergangenheit aufwändig, da die Objekte oft den falschen Zustand hatten, oder der Kontext verloren ging. SOA wird dies nicht vereinfachen, da die Services auch nichts über die inneren Abläufe des Altsystems wissen.
Eng mit der SOA-Idee verbunden ist auch der Glaube, dass der Einsatz eines Standards die meisten Probleme in der Softwareentwicklung lösen würde. Standards sind insofern verlockend, als dass sie in Konfliktfällen Legitimität und Neutralität suggerieren. Außerdem scheinen sie auf "magische" Weise Interoperabilität zu erzeugen. Technische Standards sind mittlerweile nicht mehr nur die Domäne der Ingenieure und Softwareentwickler. Über sie wird nicht nach dem Kriterium des "besten" Standards entschieden. Stattdessen sind sie zu einem lukrativen und sehr profitablen Geschäft geworden. Insofern haben sich Standards zu einem strategischen Werkzeug von Organisationen entwickelt, die damit Wettbewerbsvorteile und eine gewisse Marktkontrolle erlangen. Inkompatibilitäten entstehen nicht durch das Fehlen von technischer Expertise, sondern auf Grund der Eigennützigkeit der Protagonisten.
Standardisierung ist zwar ein notwendiges, aber kein hinreichendes Kriterium. Außerdem bezieht sie sich in aller Regel auf die syntaktisch-technische Interoperabilität und nicht auf die semantische. Doch selbst wenn nur syntaktische Fragen betrachtet werden, ist es im SOA-Umfeld um die Standardisierung recht schlecht bestellt. Eine große Menge an Protokollen (BPEL, WSDL, WS-*…) wird von diversen Herstellern propagiert, die damit Marktvorteile gewinnen wollen. Auf welchen Standard sollen Anwender setzen? Diese Frage lässt sich guten Gewissens nicht beantworten, denn: Software development is betting on the future…
Fazit: Eine SOA erzwingt nicht von sich aus Integration; viele Aspekte der Integration werden überhaupt nicht durch SOA adressiert. Außerdem beherrschen EAI-Systeme die Integration genauso gut wie SOA, ohne gleich mit einer Lawine von "Standards" zu drohen.