Die Eigenschaften einer SOA wurden in den letzten Jahren immer häufiger hoch gelobt und zum Nonplusultra erklärt. Aber was daran ist Wirklichkeit und was Wunschdenken? Die erste Idee von SOA stammt aus einem Papier der Gartner Group aus dem Jahr 1996. Das Konzept war als eine Maßnahme zur Strukturierung von Organisationen gedacht, damit diese ihre Prozesse effektiver gestalten können. In den allgemeinen IT-Jargon wurde der Begriff erst nach dem Jahr 2000 übernommen; bis dahin war die IT-Branche mit Themen wie dem Y2K-Problem oder Offshoring beschäftigt.

Heute wird SOA primär aus dem Blickwinkel der Technik propagiert, obwohl alle Beteiligten nicht müde werden, den Wert einer SOA für das Business zu postulieren. Der Hauptgrund für dieses Interesse liegt nicht darin, dass Unternehmen dringenden Handlungsbedarf im Umfeld von SOA sehen. Vielmehr erhoffen sich einige davon ein Milliardengeschäft. Die Versprechungen im Zusammenhang mit Service-orientierten Architekturen sind immens. Besonders gefördert werden sie durch die implizite Allianz aus Werkzeugherstellern und Beratern: Beide haben ein großes Interesse, am SOA-Hype zu partizipieren. Wie schon bei vergangenen IT-Hypes üblich, versprechen Hersteller und Consulting-Unternehmen stets, dass mit einer SOA alles besser wird. Die Rede ist von einer Revolution mit immensen Einsparungen. Dabei liest sich die Liste der Versprechungen wie ein Wunschzettel jeder Organisation, die in großem Umfang IT einsetzt:

• SOA ermöglicht es, einfach und schnell auf Veränderungen zu reagieren, nicht nur funktional sondern auch geographisch und in Bezug auf die gewählte Plattform oder den Lieferanten. (Mythos 1: Agilität)

• SOA unterstützt kurze Produktlebenszyklen. (Mythos 1: Agilität)

• Die Integration mit internen und externen Partnern wird einfacher. (Mythos 2: Integration)

• Das Benutzen von Standards sichert Interoperabilität. (Mythos 2: Integration)

• Der Return on Investment verbessert sich durch den Einsatz von austauschbaren Services. (Mythos 3: Kostenersparnis)

• Entwicklungskosten sinken. (Mythos 3: Kostenersparnis)

• Geschäftsprozesse werden direkt in die IT abgebildet. Mythos 4: Alignment)

• Durch die Einführung von SOA und Services erhöht sich die Datenqualität. (Mythos 5: Qualität)

• Die Wiederverwendung wird vereinfacht. (Mythos 6: Wiederverwendung)

• IT-Governance wird einfacher. (Mythos 7: Entwicklung)

• Services, speziell Webservices, benötigen keine Programmierung. (Mythos 7: Entwicklung)

Diese SOA-Mythen werden im Folgenden genauer betrachtet. Jeder der Punkte stellt ein Problem dar, mit dem IT-Organisationen auf die eine oder andere Art zu kämpfen haben. Es kann sich dabei auch um implizite Erwartungen handeln, die aus Kundensicht formuliert werden. Generell sind die meisten dieser Probleme weniger technisch als organisatorisch oder prozessbedingt. Das hat zur Folge, dass eine SOA in der Praxis nur in einem sehr engen Rahmen und nur unter ganz speziellen Bedingungen helfen kann.

Fazit: Am Ende bleibt festzustellen, dass keines dieser Versprechen wirklich gehalten werden kann!

Mythos 1: Agilität

Der Einsatz von SOA steigert die Agilität von Unternehmen und ermöglicht so sehr viel kürzere Produktzyklen. So oder so ähnlich lauten die Versprechen der SOA-Befürworter. Doch stimmt dies wirklich?

Die Agilität eines Unternehmens ist dessen Fähigkeit, schnell auf Veränderungen des Markts zu reagieren. Die Schlüsselelemente für diese Fähigkeit sind eine flexible Organisation und flexible Kernprozesse. Wenn ein Unternehmen nicht organisatorisch und prozessgetrieben in der Lage ist, sich auf Veränderungen einzustellen, so wird ihm auch eine SOA nicht helfen können. Wirklich flexible Unternehmen sind so konzipiert, dass sie viel stärker einer virtuellen Organisation ähneln als einem traditionellen hierarchischen Unternehmen. Erst dann kann eine Organisation wirklich agil sein.

Trotzdem müssen auch herkömmliche Unternehmen sich verändern und tun dies auch, allerdings meist in längeren Zeitskalen als vergleichbare virtuelle Organisationen. Die Veränderung in den Unternehmen betrifft zunächst die Prozesse. Eigentlich sollten sich die Verantwortlichen auf den Kernprozess der Organisation konzentrieren, damit eine maximale Verbesserung erzielt werden kann. Allerdings sind solche Kernprozesse in aller Regel sehr komplex und stark durch manuelle Tätigkeiten bestimmt. Außerdem sind Kernprozesse fast immer sehr dynamisch. Sie haben wenig mit Technologie zu tun, aber viel mit Organisation! Insofern sollten alle Versprechen bezüglich Agilität und Effizienz, die auf Grund von Architekturen oder Werkzeugen gemacht werden, mit großer Vorsicht betrachtet werden.

Ein Ziel des heutigen Business Process Rengineering ist, dass Unternehmen unterschiedliche, aber ähnliche operative Prozesse in einer einzigen Umgebung zusammenbringen möchten. Damit soll die Effizienz steigen. Eine Konsequenz daraus ist die heute stark vorherrschende Sicht auf datenzentrische Systeme und geschlossene EAI-Systeme (EAI = Enterprise Application Integration). Die meisten "neueren" Applikationen in großen Organisationen haben sich auf die "harte Verdrahtung" von Transaktionen und Subprozessen konzentriert, mit der Folge, dass die Orchestrierung oder Choreographie sehr schwer geworden ist. Der Weg von einer herkömmlichen Architektur zu einer Service-basierenden ist schwer, da hier sehr viel stärker von konkreter Technologie abstrahiert werden muss und ein grobgranulareres System entsteht.

Es ist recht aufwändig zu bestimmen, ob eine bestimmte Implementierung eines Geschäftsprozesses angemessen ist: Trotzdem sollte man versuchen, dies zu bewerten. Je einfacher und einsichtiger eine Implementierung ist, desto besser. Auf der anderen Seite gilt aber auch: Je agiler die Servicelandschaft, desto besser. Agilität geht oft einher mit sehr feiner Granularität, die eine erhöhte Komplexität zur Folge hat. Umgekehrt führen grobgranulare Services zu geringerer Agilität. Daher hat der konsequente Einsatz einer SOA zur Folge, auf der Softwareseite entweder agil und sehr komplex zu sein - mit allen innewohnenden Risiken - oder einfach und weniger agil, damit aber auch weniger flexibel.

Agilität ist das Ergebnis einer Organisations- und Prozessform, nicht das Resultat einer Softwarearchitektur! Wenn ein Unternehmen die dafür nötige Struktur besitzt, dann macht der Einsatz einer entsprechenden Softwarearchitektur Sinn und nicht umgekehrt. Der zweite Weg, zuerst die Technik, dann die Organisation, ist für IT-Experten immer wieder verlockend, führt aber in die Irre. Software ist bis zu einem gewissen Grad ein Abbild der Kommunikationsstruktur und Verantwortlichkeiten in einem Unternehmen. In Legacysystemen werden diese beiden Strukturen "hart" codiert. Wenn aber die Struktur des Unternehmens hierarchisch ist, lässt es sich nur über eine Reinterpretation von Verantwortlichkeiten und Rollen in eine Software abbilden. Diese permanente geistige Leistung erzeugt jede Menge Stress und Konflikte, so dass schließlich die Organisation ein Abbild ihrer selbst in der Software erzwingt. Außerdem ist eine technisch konzipierte SOA keine wirkliche Abbildung der fachlich notwendigen Services. Es sind aber gerade diese fachlichen Services, die agil sein müssen. Folglich nützt eine technikgetrieben Implementierung nichts.

In der Regel ist die Situation noch prekärer: Technische Services werden heute aus Sicht der Implementierung gebaut und dem Unternehmen wie auch dem Markt übergestülpt. Solche Services finden wenig Akzeptanz und sind nicht auf den Markt ausgerichtet. Gute Services sind stets kundenzentriert; das heißt, der Leistungsumfang und die Struktur entspricht den Problemen des Kunden und nicht der Phantasie des Providers. Veränderungen auf dem Markt werden durch geändertes Kundenverhalten ausgelöst. Das wiederum führt zur Forderung nach neuen Services. Wenn diese aber nicht aus Kundensicht konzipiert werden sondern wiederum nur aus der technischen Providersicht entstehen, ist es müßig, nach der Agilität zu fragen, da der Service de facto nicht angenommen wird.

Der heute oft gehörte Vorwurf, die IT sei nicht agil und könne sich nicht schnell genug auf Wünsche der Fachbereiche einstellen, hat andere Gründe als die Architektur. Die Entwicklung neuer Funktionen oder die Veränderung bestehender dauert einfach zu lange. Die Ursache dafür liegt neben veralteten und behäbigen Vorgehensmodellen in mangelnder Kenntnis der Fachlichkeit auf Seiten der IT. Dies soll durch SOA plötzlich besser werden? Nur weil es Services gibt, lassen diese sich schneller ändern? Wenn es so einfach wäre, könnten Entwicklungsabteilungen das heute schon. Denn es ist genauso einfach, an Stelle eines Services ein Unterprogramm zu ändern - und schon müsste es funktionieren. Die Praxis zeigt aber, dass es offensichtlich nicht so einfach ist.

Fazit: Eine SOA erzwingt keine Agilität. Wenn sie technikgetrieben entsteht, kann sie Agilität sogar massiv behindern.

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?

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.

Mythos 3: Kostenersparnis

Das "Standardverkaufsargument" diverser Beratungsunternehmen und Werkzeughersteller für den Einsatz einer SOA lautet: Eine SOA ermöglicht durch den Einsatz von austauschbaren Services eine massive Verbesserung des Return on Investment (RoI) bei gleichzeitig sinkenden Entwicklungskosten. Vorstände, speziell Finanzvorstände, hören so etwas gerne, schließlich bekommt man anscheinend mehr Wert für weniger Einsatz. Dieses Argument scheint durch die permanente Wiederholung in Gesprächen, Fachvorträgen und Artikeln diverser Zeitschriften durchaus glaubwürdig zu sein.

Aber spart eine SOA wirklich Geld? Und wenn ja, gegenüber was wird denn eingespart?

Kostenreduktion ist ein beliebtes Thema eines jeden Verkäufers, der eine neue Technik an ein Unternehmen liefern möchte. Einsparungen werden auch immer wieder gerne zitiert, um die Unternehmensleitung von Investitionen in Software oder Projekte zu überzeugen. Um die Kostenfrage wirklich zu klären, gilt es zu prüfen, was in den Softwareprojekten wirklich Kosten produziert. Typische Kostentreiber sind Entwicklungskosten, Wartungs- und Weiterentwicklungskosten sowie Betriebskosten. Wie beeinflusst eine SOA diese Faktoren?

Die Entwicklungskosten sind primär durch die Personalkosten bestimmt. In aller Regel machen eventuelle Hardware- und Lizenzkosten nur marginale Teile eines Softwareprojekts aus. Softwarevorhaben sind meist dadurch charakterisiert, dass sie Personalkosten verursachen. Die größten Kostenblöcke sind die Projektdauer und die Benutzeroberflächen. Letztere können bis zu 70 Prozent der Gesamtkosten (inklusive Test und Spezifikation) ausmachen. Die Ursache für diesen großen Anteil liegt in der Komplexität heutiger ereignisgetriebener Oberflächen, die auf diverse Kombinationen reagieren müssen. Beschäftigt sich SOA damit? Nein! In einer SOA erscheint die Oberfläche auf magische Weise in Form von Präsentations-Services oder Portalen, ohne dass das Komplexitätsproblem oder die Oberflächengestaltung angegangen wird. Nur, welche Ersparnis ist denn zu erwarten wenn bis zu 70 Prozent der Kosten ignoriert werden?

Neben der Oberfläche bietet eine SOA keinerlei Kostenvorteile gegenüber einer modul- oder komponentenbasierten Entwicklung. Auch diese Konzepte setzen ja auf Zerlegung und Modularisierung; die langjährige Erfahrung hat gezeigt, dass eine komponentenbasierte Entwicklung nicht billiger ist als andere Arten. Die oft zitierte Argumentationskette, SOA bedeute Wiederverwendung, wodurch sich Kosten senken ließen, geht davon aus, dass Wiederverwendung durch SOA tastsächlich zum Tragen kommt. Nur, wie wir im sechsten Teil dieses Artikels sehen werden, findet Wiederverwendung nicht wirklich statt.

Der andere Kostentreiber in der Entwicklung ist die permanente Veränderung der fachlichen Spezifikationen. Wenn sich nur drei Prozent der Spezifikationen pro Monat verändern, dann hat sich nach zwei Jahren praktisch alles verändert. Diese wiederholten Änderungen schlagen sich in der Dauer und damit direkt in den Kosten nieder. Ändert eine SOA etwas daran? Nein!

Für den Kostentreiber Wartung ist der Wert einer SOA eher zweifelhaft. Ein Großteil des Wartungsaufwands liegt im Bereich der Fehlerbehebung oder deren Auffindung. In einer verteilten Umgebung Fehler zu finden, ist meist sehr viel schwerer als in einem Monolithen. Folglich dürften die Wartungskosten mit einer SOA sogar zunehmen.

Wird der Betrieb einer Software durch SOA billiger? Im Gegenteil: eine SOA wird auf Dauer Kosten erzeugen, denn sie braucht beispielsweise einen Enterprise Service Bus (ESB). Und dieser bedeutet eine massive Investition, wenn man die Erfahrungen aus dem EAI-Umfeld extrapoliert, ganz zu schweigen von den Kosten für das aufzubauende Wissen und die Mitarbeiterqualifikation. Außerdem gilt für den Betrieb das gleiche wie für die Wartung: Je verteilter und komplexer ein System ist, desto teurer wird sein Unterhalt.

Auch die Zahl der möglichen Fehlerquellen steigt durch eine SOA an, schließlich bildet ein ESB einen Single Point of Failure. Diese zusätzlichen Fehlerquellen spiegeln sich in einem erhöhten Betriebsrisiko und damit in einer niedrigeren Verfügbarkeit wieder.

Fazit: SOA reduziert keine Entwicklungs- und Betriebskosten! Im Gegenteil: eine SOA produziert vermehrt Kosten, selbst wenn man die hohen Aufwändungen für das Know-how nicht mit berücksichtigt.

Mythos 4: Alignment

Mit Hilfe einer SOA werden Geschäftsprozesse direkt in die IT abgebildet; Unternehmen erreichen ein nie gekanntes Alignment. Diese Nachricht begeistert alle Chief Operating Officers (COOs), denn Alignment ist die große Herausforderung in Organisationen - zumindest nach Ansicht der Berater, die Business Process Reengineering verkaufen. Bei diesem Problem soll eine SOA ja Wunder bewirken. Doch wie sieht dieses Wunder aus?

Das Alignment, verstanden als gemeinsame Ausrichtung von Business und IT, ist ein komplexes Thema mit vielen Facetten. Üblicherweise wird es unterteilt in die Bereiche:

• Kognitives Alignment - sprechen Fachbereiche und IT dieselbe Sprache?

• Strukturelles Alignment – passen die Strukturen der Geschäftsabläufe zur IT?

• Strategisches Alignment – haben die IT-Strategie und die Geschäftsstrategie das gleiche Ziel?

• Temporales Alignment – Wie gut passen die Prozesse in den Fachbereichen zu den Prozessen der IT?

• Systemisches Alignment – Erreicht die richtige Menge an Information den richtigen Empfänger und wie gut steuert die Software das Unternehmen?

Alle diese Problemkreise werden angeblich durch die mächtige SOA gelöst. Aber dem ist nicht so! Der einzige Beitrag, den eine SOA leisten kann, liegt in den Bereichen strukturelles und strategisches Alignment. Alle anderen Alignment-Formen verhalten sich indifferent gegenüber der SOA-Idee.

Strategisches Alignment durch eine SOA ist nur dann gegeben, wenn die Geschäftsstrategie Services heißt. In diesem Fall passen beide Strategien gut aufeinander. Services als Geschäftsstrategie gibt es bei einem Dienstleister, was aber machen produzierende Unternehmen? Haben diese dann kein Alignment? Hier wiederholt sich, was schon in der Einleitung erwähnt wurde: Eine SOA macht nur Sinn, wenn das Unternehmen sich auf Services ausrichtet und nicht umgekehrt. In diesem Fall lässt sich Alignment auf strategischer und struktureller Ebene erreichen.

Ein ähnlicher Ansatz wird zurzeit von der Model Driven Architecture (MDA) forciert. Dabei geht es um die direkte Übersetzung fachlicher Anforderungen in Software, gleichgültig ob Services oder traditionelle Software. Diese direkte Verknüpfung ist jedoch zum Scheitern verurteilt wenn das kognitive, temporale und strategische Alignment nicht oder nur rudimentär vorhanden ist. Fehlt das kognitive Alignment, so sind für die Servicehersteller die Anforderungen des Fachbereichs unverständlich. Beim Ausbleiben des temporalen Alignments reagiert die IT viel zu langsam auf Veränderungen des Markts und der Domäne. Bei schlechtem strategischen Alignment wird auf Seiten der IT mit ihrer SOA die falsche Grundlage geschaffen.

Eine SOA birgt durch ihre inhärente Komplexität stets das Risiko, dass sich die IT alleine auf die SOA konzentriert und dabei jede Form des Alignments als sekundär einstuft. Dadurch wächst die Unzufriedenheit mit der IT-Lösung auf Seiten der Kunden.

Fazit: Eine SOA alleine erzeugt kein Alignment. Mit einer SOA zu starten, um Alignment zu erreichen, ist kontraproduktiv.

Mythos 5: Datenqualität

Der Traum aller Business-Intelligence- und Datawarehouse-Anhänger wird wahr: Durch die Einführung von SOA wird die Daten- und Informationsqualität deutlich erhöht. Das zumindest predigen SOA-Befürworter immer wieder. Mit SOA soll die Qualität steigen! Dabei ist die Qualitätsmisere im Datensektor mindestens so alt wie die IT. Wie will da eine SOA spontan die Wende bringen?

Nach der SOA-Idee erzwingt das Benützen von Interfaces eine hohe Datenqualität. Doch wo liegt der Unterschied zu gängiger Software, die nichts mit SOA zu tun hat? Ein einfacher Call in Java oder C# erzwingt auch, dass die Datentypen zueinander passen, sonst reagiert das System mit einem Fehler. Wieso haben wir dann heute trotzdem so eine schlechte Datenqualität?

Die aktuelle Situation hat zwei Gründe: Zum einen gibt es für die Erzeuger von Daten (die Personen, die die Daten eingeben) in den Unternehmen keine Anreize für eine hohe Qualität. Zum anderen hat die IT in der Vergangenheit stets Krücken gebaut, um doch noch in der Lage zu sein, schlechte Daten verarbeiten zu können.

Beide Ursachen werden nicht wirklich durch eine SOA adressiert. Die Qualität wird sich erst durch Verhaltensänderungen in den Fachbereichen und in der Entwicklung ändern und nicht durch eine Architektur. Datenqualität ist ein organisatorisches und zum Teil disziplinarisches Problem, aber kein originäres Architekturthema.

Dessen ungeachtet kann eine SOA die Qualität sogar implizit senken. Wenn ein Unternehmen SOA einsetzt, dann wissen die einzelnen Services nicht voneinander, die Objekte werden nicht mehr zentral gehalten und können durchaus redundant auftauchen. Jede Redundanz aber führt zum Risiko einer Qualitätsverschlechterung, denn es gibt jetzt die Möglichkeit widersprüchlicher Daten. Außerdem kann eine Software, die aus vielen zum Teil nicht zuverlässigen Services aufgebaut ist, schnell unvollständige Datensätze speichern. Auch dadurch sinkt die Datenqualität.

Auch sogenannte Datenqualitätswerkzeuge können die Misere nicht wirklich beseitigen, da sie primär auf syntaktische und nicht auf semantische Qualität ausgerichtet sind. Zwar ist die syntaktische Qualität eine der Voraussetzungen für den Einstieg in eine SOA; eine semantische Qualität wird dadurch aber nicht erreicht. Im Gegenteil: einfache syntaktische Korrekturen suggerieren eine Semantik, die eventuell gar nicht vorhanden ist!

Fazit: SOA wird die Datenqualität nicht erhöhen, sondern vielleicht sogar verschlechtern!

Mythos 6: Wiederverwendung

Zu den Standardargumenten für eine SOA gehört die mögliche Wiederverwendung schon bestehender Services. Unternehmen sollen damit langfristig Kosten sparen können.

Das SOA-Paradigma steht mit dieser Behauptung in einer langen Tradition in der Softwareentwicklung. Seit mehr als 30 Jahren dient die Wiederverwendung als Standardargument für jede neue Technik und Methodik, um daraus eine vermeintliche Kostenersparnis abzuleiten und das Thema besser verkaufen zu können:

• Die strukturierte Analyse versprach Wiederverwendung durch die Nutzung schon bestehender Funktionen (am besten durch ein Case-Tool), indem der alte Code nochmals genutzt wurde. Fand Wiederverwendung in großem Maße statt? Nein.

• Die Protagonisten einer unternehmensweiten Datenmodellierung sagten die Wiederverwendung durch Nutzung eines globalen Modells voraus. Fand sie statt? Nein.

• Die Objektorientierung wollte Wiederverwendung durch Vererbung und Interfaces sicherstellen. Gab es großflächige Wiederverwendung? Nein. Nur im Bereich der technischen Klassenbibliotheken taucht so etwas in der Praxis auf, nicht jedoch in der fachlichen Welt.

• Die komponentenbasierende Softwareentwicklung versprach ebenfalls eine hohe Wiederverwendung. Fand sie statt? Nein.

• Verteilte Systeme, speziell Corba, vermittelten das Bild eines ganzen Universums von öffentlich zugänglichen und damit wiederverwendbaren Objekten und Funktionen. Gibt es dieses Universum heute? Nein.

Die Verfechter der SOA-Idee behaupten in dieser langen Tradition das Gleiche: Mit SOA lasse sich eine massive Wiederverwendung erreichen. Erstaunlicherweise werden dabei, speziell im Umfeld der Web-Services, die alten Corba-Marketing-Argumente munter aufgewärmt. Ist vor diesem Hintergrund eine großflächige Wiederverwendung zu erwarten? Nein!

Aus technischer Sicht ist Wiederverwendung schon sehr lange möglich. Sowohl die Objektorientierung als auch die Komponentenbauweise haben sie stets als ihr hervorstechendes technisches Merkmal bezeichnet. Warum hat de facto trotzdem fast nie eine Wiederverwendung stattgefunden? Die Softwareentwickler haben sich nie bemüht, die Wiederverwendung zu ermöglichen! Der Aufwand zu bestimmen, was eine vorhandene Software leistet und wie sie eingesetzt werden kann, ist aus der subjektiven Sicht des Entwicklers deutlich größer als die erforderliche Energie, einfach ein neues System zu bauen. Verstärkt wird diese Annahme durch die modernen integrierten Entwicklungsumgebungen. Typischerweise unterschätzen Softwareentwickler stets die Größe einer völlig neuen Aufgabe und tendieren dazu, sich zu überschätzen - ein Verhaltensmuster ähnlich den Autofahrern: Laut einer Umfrage zählen sich 80 Prozent der schwedischen Autofahrer zu dem Drittel der besten Autofahrer. Das führt häufig zu einer großen Unterschätzung des nötigen Aufwands. Diese psychologische Barriere hat zur geringen Wiederverwendung in großen Softwaresystemen beigetragen.

Aus Sicht der heute implementierten Systeme dient die Serviceorientierung primär zur Wiederverwendung bestehender Applikationen. Dies wird sich in der Zukunft ändern, weil neue Systeme a priori aus Services ohne den Umweg über Applikationen entwickelt werden müssen. Nur so besitzen sie die notwendige Granularität und Stabilität, um langfristig einsatzfähig zu bleiben.

Auf Services lässt sich das Prinzip des Softwaredarwinismus anwenden. Der Begriff ist der Darwinschen Evolutionstheorie entlehnt. Wird die gesamte Software einer Organisation als ein Pool von potenziell wiederverwendbaren Services angesehen, so lassen sich Beobachtungen ähnlich denen Darwins anstellen. Softwareentwickler müssen sich aus diesem Pool von Services einige zur Wiederverwendung aussuchen und andere dabei vernachlässigen. Ein mehrfach verwendeter Service kann sich selbst, dadurch dass er aktiv genutzt wird, "weitervererben" und damit seine Chancen auf zukünftige Wiederverwendung erhöhen. Die Folge dieses Softwaredarwinismus ist, dass Services, die der Softwareentwickler nicht attraktiv findet, nicht genutzt werden. Sie verschwinden in der Versenkung. Zu den treibenden Kräften hinter dem Softwaredarwinismus gehören:

• Verfügbarkeit - Ist ein Service nicht verfügbar, so wird er nie genutzt werden. Genutzte Services haben stets eine höhere Verfügbarkeit, weil sie offensichtlich vorhanden sind. Die mentale Verfügbarkeit oder die häufige Verwendung eines Services erhöht die Chancen, den Service wiederzufinden und damit auch die Chancen des Services, sich weiter im Gedächtnis zu erhalten. Außerdem bedarf es einer Anstrengung, aktive Services aus ihrem Kontext zu entfernen.

• Verständlichkeit - Ist ein Service unverständlich, so wird er auch nicht verwendet werden. Insofern ist Verständlichkeit eine treibende Kraft zur Wiederverwendung im Softwaredarwinismus.

Im Umkehrschluss aus dieser Betrachtung muss Wiederverwendung explizit den Softwaredarwinismus in Betracht ziehen: Die Services sind so zu entwickeln, dass Softwareentwickler sie wiederverwenden wollen. Daher müssen wiederverwendbare Services so konzipiert sein, dass sie sofort und ohne Veränderung einsetzbar sind.

Werden in der Softwareentwicklung bestehende Serviceimplementierungen wiederverwendet, so gibt es zwei grundsätzliche Vorgehensansätze:

• Development with Reuse - Einem Design der Softwarearchitektur folgt eine genaue Spezifikation der zur Entwicklung benötigten Services. Dann wird nach passenden Serviceimplementierungen gesucht, die - eventuell nach einiger Anpassung - ins System integriert werden.

• Reuse-driven Development - Hier wird die Spezifikation des zu entwickelnden Systems und das Design der Architektur bereits von den vorhandenen und wiederverwendbaren Services beeinflusst. Verglichen mit " Development with reuse" kann ein höherer Grad der Wiederverwendung erzielt werden.

Wenn das Softwaredesign auf bereits bestehenden Services basiert, dann folgt es eher dem Bottom-up als dem Top-down-Prinzip. Die bestehenden Services werden solange komponiert, bis weitere Komposition keine zusätzliche Übersicht schaffen würde. Mit dem Grad der Abstraktion eines wiederverwendeten Services nimmt das Maß an eingesparter Entwicklungsarbeit zu, jedoch nimmt die Häufigkeit der Wiederverwendung ab.

Grundvoraussetzung für eine effiziente Wiederverwendung sind Services, die in Bezug auf Allgemeingültigkeit, Qualität, Dokumentation und Zuverlässigkeit hohen Ansprüchen genügen. Der Einstieg in die Wiederverwendung setzt eine Managemententscheidung voraus. Denn bis die entwickelten Services wirklich wiederverwendbar sind, müssen sie, nach den Erfahrungen aus der Objektorientierung, etwa vier- bis fünfmal genutzt werden. Erst dann beginnen sich die Investitionen in die Wiederverwendung auszuzahlen. Ein solcher Grad ist in der Praxis aber vermutlich nie zu erreichen.

Das Prinzip des Softwaredarwinismus hat überhaupt nichts mit Serviceorientierung an sich zu tun, sondern greift bei jeder Form von Entwicklung. Daher liefert SOA keinen echten Beitrag zur Wiederverwendung, der über Corba oder Kompontenentwicklung auf magische Weise hinausgehen würde.

Fazit: Eine SOA braucht Wiederverwendung, erzwingt sie aber nicht!

Mythos 7: Entwicklung

Mit einer SOA wird die Governance zum Kinderspiel. Die Softwareentwicklung muss sich nicht mehr um das Kleinklein der Programmierung kümmern, sondern kann sich auf ihre schönen gemalten Modelle konzentrieren. Eine schöne neue Welt durch SOA?

Warum durch eine SOA die Governance der Softwareentwicklung einfacher werden soll, ist unklar. Mit der SOA entsteht ein Geflecht von vielen autonomen Services, die sich unabhängig voneinander entwickeln und verändern. Extrapoliert man die Erfahrungen aus den Problemen der Dynamic Link Libraries (DLLs) unter Windows auf das Gebiet der Services, wird schnell klar, dass völlig andere Formen von Governance in einem deutlich komplexeren Umfeld notwendig sind. Hinzu kommt, dass auch die Einführung einer SOA expliziter Governance-Mechanismen bedarf. Sonst ist ein derartiges Projekt von Anfang an zum Scheitern verurteilt.

Die Vorstellung, mit SOA sei keine Software mehr zu programmieren, setzt voraus, dass genügend Services schon vorhanden sind und dass diese alle möglichen fachlichen Gegebenheiten abdecken. Sind nicht genügend Services verfügbar, muss hingegen sehr wohl eine große Zahl an Diensten implementiert oder mittels Wrapping bestehender Systeme erzeugt werden. Beide Tätigkeiten benötigen ein hohes Maß an Programmierung.

Ist das Ziel des gefüllten Serviceuniversums durch eigene Anstrengungen oder den Zukauf von Services ermöglicht worden, dann braucht es weniger Programmierung. In dieser Vision der SOA-Anhänger wird die Wirtschaft durch große, allgemein zugängliche Servicelandschaften angekurbelt, in denen sich die Servicekonsumenten und –provider tummeln. Das gleiche Szenario wurde schon in den neunziger Jahren formuliert, nur dass sich damals ein Universum aus Corba-Objekten am Horizont abzeichnete. Das aber trat nie ein! Genauso wenig wird die aufgewärmte Idee mit Hilfe von Services greifen. Es ist keine Frage der Technik, sondern eine Frage des Markts und der Machtverhältnisse oder Vertrauensverhältnisse im Markt. Das oft zitierte Bild des Internets als alles durchdringendes Medium zieht nicht, da das Web wie es heute genutzt wird auf Visualisierung und passive Nutzung ausgelegt ist, Services aber Transaktionen und aktive Nutzung brauchen. Die Serviceuniversen unterliegen den gleichen Zwängen wie die Corba-Universen und werden genauso scheitern.

Die andere Option sieht vor, die Services selbst zu bauen. Hört dann die Entwicklung auf? Nein! Neben dem Problem, dass heute die Mechanismen und Vorgehensmodelle für echte Services fehlen, führt die Sättigung mit Services nicht zu einem Ende der Softwareentwicklung. Das Argument der Services lässt sich auf Unterprogramme übertragen: Wenn wir genügend Unterprogramme haben, die alles können, brauchen wird nur noch einen guten Linker und müssen nicht mehr entwickeln.

In der Welt der Services ist die Entwicklung komplizierter geworden. Neben der eigentlichen fachlichen Funktionalität müssen auch noch Servicequalitäten, Autonomie und Transaktionsverhalten berücksichtigt werden. Solche Eigenschaften verlangen zusätzliches Architektur- und Technikwissen.

Auch die Zahl der spezialisierten Tätigkeiten wird stark zunehmen. Beispielsweise sind Rollen wie Servicearchitekt, Application Builder, Systemintegrator, ESB-Spezialist und andere schon abzusehen. Was sich auch noch verändern wird, ist der Schwerpunkt der Entwicklung. Heute konzentrieren sich die meisten Entwickler auf die Abbildung der fachlichen Anforderungen entweder in Modelle oder in Quellcode. Innerhalb einer SOA muss der Code auch Quality of Services verarbeiten können. Außerdem ist im Gegensatz zu heutigen Applikationen nicht sichergestellt, ob ein Service in der gewünschten Version zur Laufzeit tatsächlich existiert. Daher rückt die Behandlung von Ausnahmen und die Suche nach interoperablen Services viel stärker in den Vordergrund als dies heute der Fall ist.

Fazit: Auch in Zukunft wird es Entwickler geben müssen! Und diese müssen noch mehr Detailwissen besitzen und werden in einer deutlich komplexeren Umgebung tätig sein. (wh)