Was Kritiker des SOA-Hypes schon immer vorhergesagt haben, wird in der Praxis zur traurigen Gewissheit: Viele SOA-Projekte wackeln oder kommen erst gar nicht in die Gänge, weil fundamentale organisatorische Voraussetzungen fehlen. Die computerwoche nennt die zehn schwersten SOA-Hürden und beschreibt, wie Unternehmen damit umgehen.

Alignment: Business- und IT-Ziele aufeinander abstimmen

"Es sind nicht technische Probleme, die SOA-Projekte scheitern lassen", berichtet Alexander Scherdin, Senior Vice President IT Architektur und Qualitätsmanagement bei der Deutschen Post. "Fehlende Sicht auf die Geschäftsprozesse, organisatorische Hürden und mangelnde Synchronisierung zwischen Business und IT spielen eine wesentlich größere Rolle." Florian Mösch, verantwortlich für die SOA-Initiativen von T-Mobile Deutschland, machte ähnliche Erfahrungen: "Die Schwierigkeiten liegen eindeutig im organisatorischen Bereich." Besonders die Auswirkungen der SOA-Vorhaben auf die Prozesse machten die Sache kompliziert. Das Abstimmen von Business- und IT-Zielen war deshalb von Beginn an ein großes Thema. Mösch: "Wir nähern uns schrittweise an. IT-Experten müssen den Fachabteilungen den Nutzen von SOA anhand von konkreten Beispielen erklären."

Doch das ist leichter gesagt als getan. Noch immer argumentieren die SOA-Protagonisten viel zu technisch, beobachtet IDC-Analyst Rüdiger Spies: "Für IT-Mitarbeiter kommt es darauf an, die richtige Sprache zu finden, um SOA dem Management plausibel zu machen." Auch Matthias Zacher, Berater bei der Experton Group, sieht die Herausforderungen eher auf der konzeptionellen und organisatorischen Seite. Dazu zähle in erster Linie die Zusammenarbeit zwischen Fachabteilungen und IT-Organisation. Letztere müsse beispielsweise beim Entwickeln fachlicher Konzepte ins Boot geholt werden. Nach seiner Einschätzung fehlen für SOA-Vorhaben zudem allgemein akzeptierte Einführungs- und Umsetzungsmethoden.

Know-how aufbauen

Das Alignment-Problem hängt eng mit der Qualifikation der Mitarbeiter zusammen. In einer Untersuchung der Experton Group aus dem vergangenen Jahr erklärte gut ein Drittel der befragten deutschen Unternehmen, keine oder fast keine SOA-Kenntnisse zu besitzen. Für IBM-Kunden ist der Mangel an qualifiziertem Personal das entscheidende Hindernis beim Aufbau einer SOA, wie der IT-Konzern auf seiner Kundenveranstaltung Impact 2007 in Orlando berichtete. Scherdin bestätigt diese Erfahrungen: "SOA-Skills sind immer noch knapp, vor allem an Architekten fehlt es." Diese heranzuziehen erfordere viel Coaching. Dabei sollten Architekten "als Grenzgänger zwischen Business und IT" unterwegs sein. Die Post bilde dazu beispielsweise technisch orientierte Architekten in Sachen Betriebswirtschaft weiter.

"SOA-Architekten sind auf dem Markt schwer zu bekommen", beobachtet auch Armin Büttner, Chief Technology Officer der Audi AG. Sein Unternehmen habe sich das Know-how in etlichen Projekten selbst erarbeitet, dabei aber auch Praxiserfahrungen von Softwareherstellern genutzt. Zu Beginn der SOA-Initiative im Jahr 2005 ging es für den Ingolstädter Automobilhersteller vor allem darum, "ein einheitliches SOA-Verständnis" zu erzielen, so Büttner: "Wir standen vor der Aufgabe, eine universitäre Vorstellung von SOA in eine Audi-spezifische zu übersetzen." Diese diene als Grundlage für alle weiteren Vorhaben. Auch für T-Mobile-Manager Mösch steht das Thema Know-how ganz oben auf der Prioritätenliste. "Für uns ist entscheidend, das Wissen zielgruppen- und prozessspezifisch aufzubauen, also beispielsweise Schulungen auf Architekten oder Softwaredesigner zuzuschneiden." Sein Team arbeite dazu an einem Kompendium für unterschiedlich qualifizierte Mitarbeiter. In einem Intensivtraining sollen die "SOA-Zielgruppen" im Unternehmen grundlegende Konzepte und Methoden lernen.

Wirtschaftlichen Nutzen der SOA erklären

Für Wolfgang Beinhauer vom Fraunhofer-Institut ist die Sache klar: "Das Hauptproblem bei SOA ist der schwer darstellbare Return on Investment (RoI). Service-orientierte Architekturen werden sich erst dann durchsetzen, wenn sie als erfolgreichster Weg zur Integration anerkannt sind." Der Beweis dafür stehe aus, die verbreitete Skepsis sei deshalb berechtigt. Als wenig hilfreich erweisen sich dabei die Argumente der Softwareanbieter. "Die RoI-Fallstudien der Hersteller sind zu 90 Prozent Marketing", urteilt IDC-Experte Spies. "In den meisten Fällen sind die Ergebnisse nicht übertragbar." Der wirtschaftliche Nutzen einer Service-orientierten Architektur liege in anderen Bereichen wie einer erhöhten Flexibilität, ganz gleich wie diese gemessen werde.

Noch deutlicher formuliert es der unabhängige Analyst Wolfgang Martin: "Das Argument, eine SOA spare IT-Kosten, ist ein Ammenmärchen, genährt von einigen Anbietern". Service-orientierte Architekturen bildeten lediglich eine Infrastruktur für die Prozessorientierung in Unternehmen. Als solche müssten sie auch finanziert werden. Martin: "Das Geld liegt in den Prozessen." Auch Scherdin sieht die RoI-Argumente kritisch: "Die Diskussion um einen Business Case für SOA führt in die Irre. Welche Alternative zu SOA gibt es denn, um die überbordende Komplexität von gewachsenen, unflexiblen IT-Systemlandschaften in den Griff zu bekommen?" Ähnlich argumentiert Michael Herr, Geschäftsführer der Senacor Technologies Industrial Services Group und ehemaliger Chef des Post-eigenen IT-Dienstleisters Sopsolutions: "In vielen Unternehmen werden Geschäftsnutzen und IT-Integrität als Gegensatz erlebt." CIOs ständen daher vor der Herausforderung, ein Enterprise Architecture Management zu etablieren, das diesen vermeintlichen Widerspruch auflöse: "Erst die enge Verzahnung zwischen Geschäfts- und Architekturinitiativen ermöglicht Lösungen, die gleichzeitig kurzfristigen Nutzen und Nachhaltigkeit bringen."

Unterstützung durch das Topmanagement

Wer ein breit angelegtes SOA-Vorhaben umsetzen will, braucht Unterstützung von ganz oben, darin sind sich Experten einig. Die Realität sieht oft anders aus. Getrieben werden SOA-Projekte in den meisten Fällen von der IT-Abteilung, hat Martin in einer Umfrage unter deutschen und schweizerischen Unternehmen herausgefunden. "Die SOA-Botschaft ist in der Geschäftsführung noch nicht angekommen", kommentiert er die Ergebnisse. 58 Prozent der Interviewten nannten als "Sponsor" der SOA den CIO oder einen anderen IT-Manager, nur 13 Prozent die Geschäftsführung.

Büttner sieht die Unterstützung durch das Management als eine Grundvoraussetzung für die SOA-Roadmap der Audi AG, die bis ins Jahr 2015 reicht. Die IT-Strategie habe der Automobilbauer direkt aus der ambitionierten Unternehmensstrategie "Route 2015" abgeleitet. Nicht ganz so selbstverständlich erscheint der Rückhalt aus der Führungsriege von T-Mobile. "Das Topmanagement war durchaus an SOA interessiert und hat uns zugehört", berichtet Mösch. Doch die Beweise und Diskussionen über IT-Prioritäten müssten immer wieder neu geführt werden.

Governance sicherstellen

Läuft die SOA erst einmal, treten in schlecht geplanten Projekten oft Schwierigkeiten mit der Verwaltung auf, warnt das Marktforschungs- und Beratungshaus Gartner. Das vielzitierte Governance-Problem ist häufig nicht sofort erkennbar. "In der Anfangsphase entstehen viele Fehler durch eine schlechte technische Umsetzung", erläutert Gartner-Analyst Paolo Malinverno. Doch mit der Größe der Installation stiegen die durch mangelnde Governance-Mechanismen verursachten Risiken. Aktuelle Beispiele belegten, dass die meisten Unternehmen zu wenig in erprobte Verfahren für Governance und Anwendungsintegration investierten.

Zu einer ähnlichen Einschätzung kommen Marktforscher von Aberdeen Research in einer Studie, die der texanische Softwarehersteller iTKO mitfinanziert hat. Von den 950 weltweit befragten Unternehmen kämpfe fast die Hälfte mit Problemen, ihre SOA-Anwendungen in eine stabile Umgebung zu bringen, berichtet der Autor Peter Kastner. Die Hauptursache liege in der fehlenden Erfahrung mit derartigen Projekten. Verschärft würden die Schwierigkeiten durch mangelhafte Werkzeuge, die die wachsende Zahl von Web-Services und anderen SOA-Artefakten automatisiert verwalten könnten.

Dem ist entgegenzuhalten, dass inzwischen fast alle größeren Anbieter von SOA-Plattformen mächtige Governance-Produkte wie Registries, Repositories oder Policy Manager im Programm haben. Erfolgreiche SOA-Nutzer setzen laut der Aberdeen-Studie vor allem auf Governance-Systeme in der Designphase (Design-time Governance), hinzu kämen Policies für die Wiederverwendung von Softwareservices. Gartner empfiehlt Unternehmen darüber hinaus, Governance-Aufgaben zu institutionalisieren, beispielsweise in Form eines "SOA Centre of Excellence" oder eines "Integration Competency Centers".

Einstiegsprojekt richtig dimensionieren

In der Planungsphase stellt sich SOA-Verantwortlichen ein weiteres Problem: Wie groß oder wie klein darf das Einstiegsprojekt sein, von dem möglicherweise die weitere Akzeptanz der SOA-Strategie abhängt? "Think big, start small", lautet ein oft zitierter Ratschlag in diesem Kontext. Der US-amerikanische SOA-Experte David Linthicum drückt es so aus: "Focus holistically, act locally". Doch ganz so einfach lässt sich die Frage in der Praxis nicht beantworten, wie etwa Audi-Manager Büttner erfahren hat: "Es ist durchaus eine Herausforderung, geeignete Pilotprojekte für eine SOA zu identifizieren." Entscheidend sei, "dass die Vorhaben auch für die Business-Seite relevant sind und die Visibilität im Unternehmen gegeben ist".

Diese Sicht vertritt auch Scherdin. "Einstiegsprojekte müssen einen demonstrierbaren Business-Nutzen haben." Für kleinere Vorhaben sei dieser oft schwer zu erbringen. "Bei Service-orientierten Architekturen geht es um eine projektübergreifende Sicht", ergänzt Senacor-Experte Herr. Ausgangspunkt müsse daher eine SOA-Initiative sein, die erste Modelle und Ansätze zur Nutzung durch die Projekte bereitstelle. Bei der Deutschen Post habe sich ein Daumenwert von gut einem Jahr Laufzeit für die ersten SOA-Projekte als praktikabel erwiesen. Auch T-Mobile-Manager Mösch hält die Frage nach dem Einstiegsprojekt für kritisch. "SOA ist nicht die Antwort auf alle Fragen", gibt er zu bedenken. Einschlägige Projekte könnten sogar neue Probleme schaffen.

Semantische Integration bedenken

In der Diskussion um Organisationsstrukturen und Technik geht ein Aspekt häufig unter: die semantische Integration, sprich die genaue Klärung fachlicher Begriffe. Wer die Semantik seiner Anwendungen und damit die Bedeutung der Daten nicht versteht, hat keine Chance auf eine funktionierende SOA, argumentiert Linthicum. Frank Leymann von der Universität Stuttgart rät Unternehmen dringend, die "semantische Dimension von SOA" zu beachten.

So reiche beispielsweise eine Beschreibung von Web-Services mittels der Web Services Description Language (WSDL) nicht aus. Zur semantischen Einordnung der Services bedürfe es einer weitergehenden Bestimmung anhand von Taxonomien und Ontologien.

In den SOA-Initiativen der Deutschen Post stellte die semantische Harmonisierung eine weitere Herausforderung dar, berichtet Herr: "Es gibt derzeit keine verbindliche Notation, die unternehmensübergreifend einen semantischen Austausch zulassen würde." Als Beispiel nennt er eine einheitliche Klärung des Business-Objekts "Kunde", eine Aufgabe, die die Post zwischenzeitlich erledigt habe. Seit April 2006 arbeitet das World Wide Web Consortium (W3C) an einer Lösung. Mit dem Ziel, die Semantik auch auf Web-Services anzuwenden, entsteht dort der Standard "Semantic Annotations for WSDL" (SAWSDL). Damit sollen sich Schnittstellenbeschreibungen für Web-Services mit semantischen Annotationen versehen lassen.

Komplexität realistisch einschätzen

Trotz der vielfältigen organisatorischen SOA-Hürden sollten Projektverantwortliche technische Risiken keinesfalls unterschätzen, rät Gartner-Analyst Massimo Pezzini: "Die einfache Bedienbarkeit moderner SOA-Tools versteckt die technische Komplexität, die dem Aufbau einer verlässlichen SOA-Plattform innewohnt."

Um aber eine unternehmensweite SOA-Infrastruktur sicher, skalierbar, hochleistungsfähig und zugleich verwaltbar zu gestalten, bedürfe es technischen Sachverstands, den sich bislang nur wenige Unternehmen verschafft hätten. Er empfiehlt, die technische Infrastruktur der SOA nicht auf der Basis theoretischer Modelle zu entwickeln. Stattdessen sollten sich Unternehmen an den tatsächlichen funktionalen und nichtfunktionalen Anforderungen wie Verfügbarkeit oder Sicherheit orientieren.

Dass sich in einer SOA viele IT-Aufgaben quasi per Knopfdruck erledigen ließen, können Praktiker bislang kaum bestätigen. "Das alte Versprechen, ausführbaren Servicecode direkt aus den Geschäftsprozessen zu generieren, ist nach wie vor problematisch", nennt Herr als Beispiel. Fraunhofer-Experte Beinhauer verweist darauf, dass die Pflege der vielen technischen und betriebswirtschaftlichen Services in der Praxis erheblichen zusätzlichen Aufwand verursache. Diesen gelte es von Anfang an einzuplanen.

Standards: Es gibt zu viele!

Geht es um Komplexität und heterogene IT-Strukturen, haben IT-Hersteller stets die gleiche Antwort parat: Vereinheitlichen und Standardisieren. Im Umfeld von Service-orientierten Architekturen, die schon per Definition eine Vielzahl unterschiedlichster Komponenten integrieren müssen, gilt dies in besonderem Maß. Von einem Mangel an Standards, wie er in den Anfangszeiten des SOA-Booms oft beklagt wurde, kann heute indes keine Rede mehr sein. Linthicum beispielsweise verfolgt alleine 60 für SOA relevante Standards. Steve Craggs vom US-amerikanischen Beratungshaus Lustratus zählt mindestens 70 Standards oder Entwürfe für Web-Services und fordert: "Stoppt den WS-Wahnsinn." Niemand könne eine derart große Menge an Spezifikationen gleichzeitig im Auge behalten, urteilen die Consultants übereinstimmend.

Deutsche IT-Verantwortliche bestätigen diese Einschätzung. "Es gibt zu viele, teilweise sogar konkurrierende Standards", kritisiert Senacor-Berater Herr. Vor allem bei Web-Services fehle es an Verlässlichkeit, wie beispielsweise der Widerspruch zwischen WS-Reliable Messaging und WS-Reliability zeige. T-Mobile-Manager Mösch beklagt eine "wahre Inflation an Standards". Erschwerend komme hinzu, dass etliche Spezifikationen von den Herstellern unterschiedlich interpretiert würden. Mösch: "Eine Konsolidierung ist dringend erforderlich."

Ob die Anbieter daran Interesse haben, ist fraglich. "IT-Altlasten stellen nicht nur für die Anwender, sondern auch für die Softwarehersteller eine ernst zu nehmende Innovationshürde dar", erläutert Herr. "Die Folge sind Kompromisse bei der Verabschiedung von Standards." So komme es vor, dass auch sinnvolle Anpassungen zugunsten der Kompatibilität mit früheren Softwareversionen auf der Strecke blieben. "Die Standardisierungsgremien sind von den Herstellern dominiert", so Herr. Darin liege das eigentliche Problem. Ähnlich sieht es auch Büttner: "Die Herstellerinteressen liegen oft weit auseinander." Das erschwere es, praxistaugliche Spezifikationen zu verabschieden. Dagegen helfe nur eines: "Die Anwender müssen in die Standardisierungsgremien rein."

Um das Problem einzudämmen, rät Craggs Unternehmen zu Pragmatismus: "Ignorieren Sie alle Web-Services-Standards - bis auf die wichtigsten: Soap, WSDL, WS-Security und eventuell WS-Adresssing."

SOA-Komponenten testen

Was eigentlich für jedes Softwareprojekt gelten sollte, vernachlässigen Unternehmen mit SOA-Ambitionen offenbar immer wieder: das gründliche Testen sämtlicher Komponenten vor dem produktiven Betrieb. Gartner-Marktforscher führen dieses Versäumnis auf ihrer Hitliste der häufigsten technischen Fehler in SOA-Vorhaben. "Kein Proof-of-Concept, keine Belastungstests", wundert sich Pezzini. Dabei sei das Testing für ein reibungsloses Funktionieren absolut kritisch. Unternehmen sollten dafür mindestens 25 Prozent der für ein SOA-Projekt geplanten Ressourcen veranschlagen, lautet sein Rat.

Dass die Vielzahl an Services und unterschiedlichen Infrastrukturkomponenten diese Aufgabe komplex und aufwändig macht, liegt auf der Hand. Doch die Softwareanbieter trügen daran eine Mitschuld, urteilt Mösch: "Die Hersteller werfen so schnell wie irgend möglich SOA-Produkte auf den Markt, die sich später als unreif erweisen." Besonders nachteilig für Kunden wirkten sich die Expansionsstrategien der großen Player aus, die ihr Angebot durch Übernahmen vergrößern. Mösch: "Die Portfolios sind oft Stückwerk, Produkte passen nicht zusammen und sind entgegen den Ankündigungen nicht integriert."