Statt eines Heilsbringers habe sich SOA in den meisten Organisationen zu einem “großen gescheiterten Projekt” entwickelt, konstatiert Manes. Angesichts der geballten öffentlichen Kritik sollten Unternehmen auf das Akronym verzichten und stattdessen eher über Begriffe wie Enterprise Service Bus (ESB) reden. Manes: “SOA ist zu einem Unwort geworden. Wir müssen es aus unserem Vokabular streichen.”

- “Ich habe es versäumt, unsere SOA-Initiativen mit unseren geschäftlichen Anforderungen in Einklang zu bringen”, steht in dem Brief. “Deshalb kann ich den vielen hundert Services, die wir entwickelt haben, keinerlei Wert zumessen.”

Weitere Kosproben:

- “Ich habe es versäumt, (…) ein SOA Center of Excellence, Steering Commitee oder Competence Center einzurichten.”

- “Ich habe es versäumt, das Topmanagement als Unterstützer und Evangelist für unsere SOA-Vorhaben ins Boot zu holen.”

- “Ich habe einen ESB gekauft, ohne unsere Anforderungen an eine SOA-Infrastruktur wirklich zu verstehen. (In Wahrheit war es nicht mein Fehler: Der Softwarehersteller sagte, das sei super duper wichtig)”

- “Ich habe es versäumt, meinen Entwicklern Anreize für eine Wiederverwendung von Softwareartefakten zu geben.”

- “Ich war nicht dafür zuständig, die Aktivitäten des BPM-Teams von nebenan mitzuverfolgen (…) Das sind doch zwei verschiedene Initiativen.”

- “Ich glaube fest daran, dass SOA nichts anderes als Corba oder COM ist.”

Die gute Nachricht, so lässt Kenney den imaginären Briefeschreiber formulieren, sei, dass ohnehin 70 Prozent der IT-Vorhaben scheiterten. Schuld an den Problemen sei nicht er, sondern das SOA-Konzept als solches. Das Schreiben endet mit der Bemerkung: “Im voraus möchte ich erklären, dass Cloud Computing, Virtualisierung und SaaS unter meiner Führung ebenfalls scheitern werden.”

Bei genauerem Hinsehen erweisen sich diese Argumente als Augenwischerei. Natürlich sind auch die selbsternannten neutralen Anbieter daran interessiert, möglichst viele ihrer Produkte zu verkaufen und damit Anwenderunternehmen stärker an sich zu binden. Die Mär von der beliebigen Austauschbarkeit von Infrastrukturkomponenten macht die Sache nicht besser. Es mag theoretisch möglich sein, einen Enterprise Service Bus (ESB) oder andere zentrale SOA-Komponenten gegen besser geeignete Produkte auszutauschen. In der Praxis aber rechnet sich der damit verbundene Aufwand in den allerwenigsten Fällen.

Und schließlich singen auch die großen SOA-Player vom Schlage IBM oder Oracle schon seit Jahren das hohe Lied der Offenheit und Interoperabilität. Offene Standards würden schon dafür sorgen, dass Systeme unterschiedlicher Anbieter “nahtlos” zusammenarbeiten. Unternehmen könnten, wenn sie es nur wollten, jederzeit eine Best-Practice-Strategie verfolgen und sich die für ihre Anforderungen passenden Produkte herauspicken. Leider zeigt die Praxis, dass Standards immer wieder durch proprietäre Erweiterungen “verbessert” und damit ad absurdum geführt werden. Fazit: Es gibt keine neutralen Anbieter im SOA-Markt. Wer sich eine Architektur vom (Software-)Hersteller zimmern lässt statt selbst Hand anzulegen, begibt sich in eine Abhängigkeit, die irgendwann teuer wird.

Dieser Eindruck trügt. IT-Verantwortliche sollten sich von den Abgesängen auf den SOA-Hype ebenso wenig blenden lassen wie von den Hochglanzbroschüren der Softwarehersteller. Denn es gibt sie, die erfolgreichen SOA-Initiativen, auch in Deutschland. Nicht nur Pionieranwender wie die Deutsche Post haben bewiesen, dass SOA mehr ist als ein technikgetriebenes Modethema. Als strategische Option steht das Konzept bei einer Vielzahl großer Unternehmen und Behörden weit oben auf der Agenda. Dazu gehören die Daimler AG ebenso wie die Deutsche Bank, der Volkswagen-Konzern, die Telekom, die Hypovereinsbank oder auch die Bundesagentur für Arbeit. Die Bewerbungen zum computerwoche-Wettbewerb “CIO des Jahres 2008″ belegen zudem, dass SOA nicht nur in Großunternehmen ein Thema ist.

Eine gewisse Ernüchterung, manche Analysten sprechen von Abkühlung oder gar Desillusionierung, ist dennoch unverkennbar. Die zum Teil schlechten Erfahrungen in der Anfangsphase der SOA-Euphorie, aber auch überzogene Versprechen der IT-Hersteller, haben ihren Teil dazu beigetragen. CIOs, Projekt- und Prozessverantwortliche sollten diese Erkenntnisse als Chance begreifen, um ihre SOA-Pläne kritisch zu hinterfragen.

Die wichtigste Lektion: SOA ist, entgegen vielen Argumenten der Softwaregurus, kein reines IT-Thema. Wer SOA nur als Architekturparadigma für die Softwareentwicklung begreift, wird die erhofften Vorteile wie Flexibilität, Agilität und Effizienz kaum ernten können. Das volle Potenzial entwickelt eine SOA erst über die damit zu erzielenden Prozessverbesserungen. Dazu müssen die Fachabteilungen ins Boot, was direkt zur zweiten Lektion führt: Die Protagonisten müssen den wirtschaftlichen Nutzen einer SOA besser erklären. Das altbekannte Kommunikationsproblem der Techies wirkt sich in SOA-Vorhaben fatal aus.

Dazulernen müssen aber auch die Mitarbeiter in den Fachabteilungen, beispielsweise wenn es um den Umgang mit modernen Tools für die Prozessmodellierung- und -analyse geht. Eng damit zusammen hängt eine dritte Erkenntnis: Die mit SOA einhergehenden organisatorischen Veränderungen wirken nicht nur in den IT-Abteilungen, sondern potenziell in allen Unternehmensteilen und Führungsebenen. Ohne deren Unterstützung und Mitwirken bleibt SOA am Ende doch nur ein IT-Konzept.

Was CIOs vom Thema halten, sehen Sie im Video der COMPUTERWOCHE.

Gehören SOA und BPM wirklich zusammen, wie es Softwarehersteller und Analysten gerne propagieren? Spielt die Kombination in der Praxis überhaupt eine Rolle? In einer Diskussionsrunde auf der CeBIT prallten die Meinungen dazu aufeinander. “Mit SOA findet BPM endlich die vollständige Durchdringung in einem Unternehmen”, konstatierte etwa Daniel Liebhart vom Schweizer IT-Dienstleister Trivadis. Ganz anders Stefan Tilkov, Geschäftsführer der innoQ Deutschland GmbH: “Die Bedeutung der Synergie zwischen SOA und BPM wird überschätzt”, urteilte er. Die wenigsten Unternehmen hätten heute Prozessmodelle etabliert, die so formal sind, dass sie sich für die Ausführung eigneten. Tilkov: “Eine SOA, die sich als Rechtfertigung nur auf BPM verlässt, wird ihre Ziele kaum erreichen.”

Eine Zusammenfassung der Diskussion finden Sie hier.

Zum Autorenkreis stoßen vorerst vier ausgewiesene BPM-Experten, die auch die Brücke zum Thema SOA schlagen können: Sven Schnägelberger vom Kompetenzzentrum für Prozessmanagement, Jakob Freund, Gründer der Community BPM-Netzwerk.de, Dirk Stähler, Bereichsleiter Business Engineering bei Opitz Consulting, und Stefan Tilkov, Geschäftsführer der innoQ Deutschland GmbH.

Wir möchten Ihnen damit noch mehr Inhalte an der Schnittstelle zwischen SOA und BPM anbieten. Natürlich behandeln die Autoren auch weiterhin technisch orientierte SOA-Themen ohne den BPM-Aspekt. Zugleich aber gibt es Raum für klassische Prozessthemen. Ein neues Erscheinungsbild soll Ihnen das Navigieren in Beiträgen und weiteren Informationsangeboten erleichtern. Mit einem Mausklick gelangen Sie direkt zu passenden Fachartikeln und in das SOA Knowledge Center der COMPUTERWOCHE. Über die obere Navigationsleiste steht Ihnen eine SOA-FAQ und ein SOA-Glossar zur Verfügung.

Ein anderes Hindernis erkennt er im mangelnden Fachwissen: “Infrastrukturkomponenten für eine SOA sind extrem komplex. Sie werden oft nicht richtig verstanden und sind schlecht dokumentiert.” Hinter dem SOA-Konzept stecke die Idee, komplexe Monolithen in Module aufzubrechen, die sich relativ einfach wieder zusammensetzen lassen. Die Erfahrung zeige aber, “dass sich Unternehmen schwertun, solche Gebilde auseinanderzureißen”.

Softwarehersteller, die einfach bestehende Produkte mit einem SOA-Label versehen, sind an den Problemen nicht unschuldig, so der Experte: “Das lässt sich mit dem Hype um Green IT vergleichen. Ergibt es Sinn, wenn ein Hersteller von Bandspeichern seine Geräte mit einem Green-IT-Label schmückt und von einer neuen Produktkategorie spricht? Ähnlich verhält es sich mit SOA.”

Das komplette Interview finden Sie hier.

Eine Zusammenfassung von Linthicums Einlassungen finden Sie hier.

Und angesichts der inzwischen zahlreich verfügbaren Erfahrungsberichte und Best Practices ist die Hoffnung berechtigt, dass Unternehmen nicht mehr nur aus ihren eigenen Fehler lernen. Sie werden kleiner in die SOA einsteigen und frühzeitig versuchen, auch Fachabteilungen den Nutzen des Konzepts klar zu machen.

Wird der Graben zwischen Business und IT im neuen Jahr also kleiner? Zumindest scheint das Problem erkannt zu sein. Immer mehr Organisationen verbinden SOA mit Konzepten aus dem Business-Process-Management (BPM) und dem strategischen Rahmen einer Enterprise Architecture. Mit einer neuen Generation von Standardsoftware hält Service-Orientierung zudem auch in Unternehmen Einzug, die sich aus unterschiedlichen Gründen bislang kaum dafür interessierten.

Werden auch die Hersteller dazu lernen? Viele können ihre eigenen Produkte oder das damit gelöste Kernproblem nicht erklären, kritisiert der US-amerikanische SOA-Experte David Linthicum: “Sie wissen, wie man Buzzwords aneinander reiht, von denen sie glauben, dass sie Kunden beeindrucken.” Oftmals steigere das nur die Verwirrung der Kunden, schlimmer noch: Sie verständen nicht einmal das Konzept hinter dem Produkt, ganz zu schweigen von SOA.

Der Wettbewerbsdruck im überhitzten SOA-Markt wird 2008 jedenfalls eher zunehmen. Neben den Machtgelüsten der Branchenschwergewichte trägt dazu auch das wachsende Angebot ausgereifter Open-Source-Software für die benötigte Infrastruktur bei. Die Konsolidierung auf Anbieterseite dürfte sich fortsetzen. In seinen SOA Predictions für 2008 prognostiziert etwa Linthicum, dass IBM einen großen und einen kleineren Hersteller von SOA-Software kaufen werde. Nach der (vorerst) geplatzten Übernahme durch Oracle ist zudem das Schicksal von Bea Systems unsicherer denn je. Dass die Ellison-Company ihre Expansionsstrategie in 2008 zurückfährt glaubt kaum jemand in der Branche.

Linthicum erwartet darüber hinaus, dass die Presse und Blogger sich verstärkt auf gescheiterte oder zumindest problembehaftete SOA-Initiativen der Unternehmen stürzen werden. Dahinter steckt unter anderem der oft beobachtete Kardinalfehler, eine SOA gleichsam einzukaufen, statt eine eigene Architektur zu entwickeln. Dennoch sollten sich Projektverantwortliche von einschlägigen Berichten nicht abschrecken lassen. Schließlich gibt es auch zahlreiche positive Beispiele. Dabei lohnt etwa ein Blick auf Joe McKendricks Blog-Posting “Nine places where SOA is making a difference, right now.” Der Analyst nennt eine Reihe von Business-Problemen, die Unternehmen mit Hilfe von SOA-Konzepten angegangen sind. Natürlich werden auch die COMPUTERWOCHE und der SOA-Expertenrat im neuen Jahr über erfolgreiche Projekte berichten, dabei aber die Schattenseiten nicht außer Acht lassen.

Den Artikel finden Sie hier.

Das Video finden Sie hier.

Klar ist bisher nur, dass Oslo-Konzepte in künftige Versionen einiger Kernprodukte einfließen sollen, darunter der BizTalk Server 6, die BizTalk Services, das .NET-Framework 4, Visual Studio 10 und System Center 5. Konkrete Angaben zur Verfügbarkeit der SOA-Funktionen ließ Microsoft vermissen.

Der US-amerikanische SOA-Experte Joe McKendrick etwa sieht denn auch andere Motive hinter der Ankündigung. Microsoft gehe es keineswegs darum, IBM, Bea oder Oracle SOA-Kunden wegzuschnappen. Stattdessen konzentriere sich die Windows-Company auf einen Markt, den die Branchenschwergewichte bislang vernachlässigt hätten – den der kleinen und mittleren Unternehmen (KMU). Diese Strategie sei schon mit anderen Infrastrukturprodukten wie Windows Server oder SQL Server aufgegangen. Im Gegensatz zu Großunternehmen könnten es sich die KMUs nicht leisten, hohe Beträge in eine SOA zu investieren und dabei monatelang Enterprise-Architekten und Entwickler zu beschäftigen, argumentiert McKendrick. Sie forderten schnelle und wirksame Lösungen für ihre Business-Probleme. An diesem Punkt setze Microsoft an.

Wie realistisch diese Prognose ist, wird sich zeigen. Gegenwärtig jedenfalls steht Oslo nur auf dem Papier. Mit konkreten Produkten ist wohl erst in der zweiten Jahreshälfte 2008 zu rechnen, ein Punkt den auch Gartner kritisch beurteilt: “Microsoft ist spät in den Markt für Composite Applications eingetreten. Falls nicht in kurzer Zeit weitere Details (…) veröffentlicht werden, besteht die Gefahr, dass Oslo entweder als Nachahmerprodukt oder unrealistischer Plan eingeschätzt wird.”

Im Middleware-Markt ergibt sich eine ähnliche Konstellation: Oracle konkurriert einerseits mit den kommerziellen Plattformanbietern, allen voran IBM, Bea und Sun Microsystems. Andererseits hat sich mit JBoss erneut eine Open-Source-Company in eine aussichtsreiche Position gebracht. Schon früh gab es Gerüchte, Oracle wolle JBoss übernehmen. Nachdem Red Hat den Middleware-Anbieter geschluckt hatte, stand der Linux-Distributor angeblich selbst auf Ellisons Einkaufsliste. JBoss ist zudem längst nicht die einzige Softwareschmiede aus der Open-Source-Community, die sich mit Middleware beschäftigt. Mit Iona, MuleSource oder auch der Post-Ausgründung Sopera basteln noch andere erfahrene Entwickler an Lösungen, die für IT-Verantwortliche eine Alternative sein könnten.

Vor diesem Hintergrund ergeben sich für Oracle zwei strategische Optionen: die Open-Source-Herausforderer aufzukaufen und sie damit aus dem Weg zu räumen oder die eigene kommerzielle Position zu stärken. Ellison hat sich augenscheinlich für letztere Variante entschieden. Mit Bea würde er einen starken kommerziellen Rivalen eliminieren und gleichzeitig den Abstand zum Marktführer IBM verringern: Nach Gartner-Erhebungen hielt Big Blue im vergangenen Jahr einen Anteil von 32 Prozent im Middleware-Markt, gefolgt von Bea mit zehn und Oracle mit neun Prozent. Der Kauf von Bea Systems würde die Ellison-Company auf Rang zwei katapultieren.

Viele Unternehmen und Behörden kommen bei Kaufentscheidungen immer wieder auf ihre Stammlieferanten zurück, beobachtet der Analyst. Das Ergebnis sind Lösungen, die er als “Comfort Technologies” bezeichnet. Nicht der Wert der technischen Lösung sondern die guten Beziehungen zu den Herstellern stehen dabei im Vordergrund. Viele dieser Käufer überlassen zudem das Design und die Ausgestaltung der SOA ihren Lieferanten. Das Problem: Die Interessen der Hersteller sind anders gelagert als die der Kunden.

Entsprechend sehen die daraus entstandenen Vendor Driven Architectures aus. Sie dienen den Herstellern in erster Linie dazu, noch mehr Produkte und Dienstleistungen zu verkaufen. Die Nachteile für die Käufer sind gravierend: Allzu oft entsprechen die Lösungen nicht den Anforderungen und sind womöglich auch noch zu teuer. Linthicum sieht nur einen Ausweg aus dieser Falle: Die grundsätzliche Architektur und daraus folgende Anforderungen müssen stehen, bevor ein Hersteller in Spiel kommt. Dazu gehört auch, alle technischen Möglichkeiten für die Implementierung zu bewerten. Wenn dann unterm Strich die Comfort Technology als beste Alternative erscheint – umso besser.

Der wichtigste Grund dafür liegt nach seiner Einschätzung im fehlenden “Business Sponsorship”, einfacher ausgedrückt: Das Management versteht den Nutzen einer SOA nicht. Das klingt nach einer Binsenweisheit, die in der Diskussion um das Für und Wider von SOA immer wieder auf den Tisch kommt. Doch Hailstone ist überzeugt, dass darin das entscheidende Hindernis liegt. Abhilfe könne nur eine bessere Kommunikation der Ziele und Nutzenpotenziale schaffen. Wer SOA nur als IT-Thema betrachte, könne diese Hürde kaum nehmen: Als “Tool” für die IT biete SOA nicht mehr als einen kosteneffizienten Weg, um Integrationsprobleme zu lösen. Aus der Sicht des Managements liefere eine SOA-Strategie demgegenüber den Schlüssel zum vielzitierten “Business/IT-Alignment”, sprich, sie ermöglicht es, IT- und Geschäftsziele in Einklang zu bringen. Daraus ergäben sich sowohl kurz- als auch langfristige Vorteile, darunter beispielsweise die Optimierung von Geschäftsprozessen, die einfache Integration von Geschäftspartnern oder die schnelle Entwicklung mächtiger Composite Applications aus bestehenden Software-Services.

Das Zauberwort in all diesen Fällen heißt Agilität, erläutert der Analyst. Damit verbunden ist die Fähigkeit von Unternehmen, sich schneller als die Konkurrenz an veränderte Marktbedingungen anzupassen und ihr damit einen Schritt voraus zu sein. Diese Botschaft müssten die meisten IT-Organisationen dem Business-Management erst klar machen. Solange sie diese Aufgabe nicht meistern, bleibe SOA ein Konzept für eine Minderheit.

Kaum ein größeres Unternehmen berichtet von einem breit angelegten SOA-Konzept auf der Basis von quelloffenen Produkten. Auch von den Implementierungspartnern, sprich IT-Dienstleistern, ist diesbezüglich wenig zu hören. Beim Kampf um SOA-Kunden treffe er auf Plattformanbieter wie Bea, IBM oder Tibco, berichtet etwa Peter Kürpick, Vorstandsmitglied der Software AG. Open-Source-Projekte spielten für die Unternehmen keine Rolle.

Vor diesem Hintergrund stellt sich die Frage, wie relevant die (vermeintlichen) Vorzüge eines quelloffenen SOA-Stacks für IT-Verantwortliche wirklich sind. Kann man von Unabhängigkeit sprechen, wenn ein Unternehmen für eine quelloffene Plattform einen langfristigen Wartungs- und Supportvertrag mit Red Hat/JBoss oder einem anderen Open-Source-Dienstleister abschließt? Gibt es nennenswerte Einsparungen durch Open Source, wenn die Lizenzkosten in einem SOA-Projekt nur einen Bruchteil der Gesamtkosten ausmachen? Und warum sollte eine quelloffene Plattform flexibler sein, wenn doch – wie zumindest von den Herstellern propagiert – auch alle kommerziellen Komponenten auf akzeptierten Standards basieren und sich beliebig kombinieren lassen?

Viele IT-Profis verbänden mit SOA nicht mehr als Web-Services und standardisierte Middleware, kritisiert Schmlezer. Tatsächlich aber bedeute SOA einen grundlegenden Wandel in der Art und Weise wie IT-Systeme erstellt und betrieben werden. Das schüre Ängste unter den altgedienten IT-Managern; sie betrachteten die damit notwendigen Veränderungen als Bedrohung.

Die Abwehrhaltung gegen SOA erklärt der Analyst auch mit den vielen unbekannten Faktoren, die das Konzept mit sich bringe. Nur wenige IT-Spezialisten wüssten etwa, wie sie eine SOA budgetieren oder die erforderlichen Governance-Strukturen einziehen können. Wie lassen sich Sicherheitslücken schließen, wie Performance-Engpässe mit der Vielzahl an Softwareservices vermeiden? In den Augen der Skeptiker schaffe SOA so viele neue Probleme, dass sie lieber gleich die Finger davon ließen. Nicht wenige fürchteten zudem schlicht, dass ihre Fähigkeiten in einer SOA überflüssig werden.

Die besten Unternehmen in diesem Kontext hätten in der Regel bereits mehr als zwei Jahre lang Erfahrungen mit SOA-Techniken gesammelt. 68 Prozent dieser Gruppe erreichen eigenen Angaben zufolge einen Return on Investment (RoI) ihrer SOA-Investitionen und haben die Kosten für die Anwendungsentwicklung gesenkt. Demgegenüber hat sich für 77 Prozent aller Befragten die SOA-Strategie bislang nicht ausgezahlt. Erfolgreiche SOA-Nutzer setzen laut der Studie vor allem auf Governance-Systeme in der Designphase (Design-time Governance), hinzu kommen Policies für die Wiederverwendung von Softwareservices. Fast die Hälfte der führenden Anwender hat eine Senkung der Lebenszykluskosten für Anwendungssoftware als messbares Management-Ziel ins Auge gefasst. Dabei helfen in den meisten Fällen automatisierte Lösungen, die die Unternehmen überwiegend zukaufen.

Auch wenn die Untersuchung nicht frei von Herstellerinteressen ist, wirft sie doch ein Licht auf die vielfältigen Hürden auf dem Weg zu einer Service-orientierten Architektur. Nicht zu Unrecht verweist Kastner auf die Gefahren, die aus mangelhaften Governance-Strukturen entstehen können. Statt die Unternehmen agiler und flexibler zu machen, könne eine wuchernde SOA-Landschaft die IT-Performance reduzieren und die operativen Kosten erhöhen. Im schlimmsten Fall drohten hohe Wartungskosten, mit denen Unternehmen jahrzehntelang zu kämpfen hätten.

Die wenigsten Hersteller dürften den zum Teil provokanten Wertungen in allen Punkten zustimmen. Für Projektverantwortliche in Unternehmen und solche, die eine SOA-Strategie gerade erst planen, bieten sie gerade deshalb eine Menge nützlicher Denkanstöße.

Hier einige Auszüge:

Über Bea:

“Well they’ve bought a few more companies and the Aqualogic and Weblogic brands are really beginning to take shape. They still don’t have anything in terms of methodology at the business service level and this really is going to be an issue in the coming years.”
…
“Great product suite, great stack, good split of business and technology, but they need to focus more around the operationals for SOA in the same way as they have previously done around the application server.”

Über IBM:

“I don’t buy the Advanced ESB line, and I don’t buy the “you’ve got to use a proprietary product that is a bugger to install” rather than a single standards based platform and I really don’t buy the “There are things that MQSI^H^H^H^HAdvanced ESB does that just can’t be done in J2EE”.
…
“Good suite, good for applications, good vision (where it isn’t subverted) but they are a bit weak across the enterprise they really need to start being honest around their roadmap so people can start planning for the Java based solution that is bound to come.”

Über Microsoft:

“Microsoft’s progression around SOA since last May? Well they’ve released an operating system which has a proprietary async process model in it and they have a decent client side development model for web services….”
…
” BizTalk remains the “heart” of much of the SOA messaging but its essentially the same product as 2004, which isn’t great.”

Über Oracle:

“A good stack, an amazing rate of acceleration but its fair to say that there are still plenty of areas for improvement for the 11 AS release.”

Über SAP:

“Basically if you are doing SAP then its worth doing, and indeed its probably the only way, but if its a choice as a broad technology stack across the enterprise then this probably isn’t the one you are looking for.”

Über Sun:

“Will Sun deliver on the vision that was put forward last year, or will an EAI centric view of SOA emerge?”
…
“Great integration stack, really good for doing interfaces onto systems, needs to broaden out (using the tools that they actually have) into being an application stack and from there on towards the business.”

“Der Treiber für SOA ist immer noch die IT”, kommentiert Studienautor Wolfgang Martin denn auch. “Die SOA-Botschaft ist noch nicht in der Geschäftsführung angekommen.”

Diese Einschätzung passt zu anderen SOA-Studien. Immer wieder kommen Marktforscher zu der Erkenntnis, dass Unternehmen mit ihren SOA-Projekten vorrangig (IT-)Integrationsprobleme in den Griff bekommen wollen – das einstige Hype-Thema Enterprise Application Integration (EAI) lässt grüßen. Auch die Vorzeigeprojekte von SOA-Pionieren wie der Credit Suisse deuten in diese Richtung. Bei genauerem Hinsehen entpuppt sich so manche von IT-Herstellern lancierte “SOA Case Study” als klassisches Integrationsprojekt.

Insofern dürfte Martin mit seiner Einschätzung Recht haben, dass die Unternehmen mit SOA offensichtlich noch ganz am Anfang stehen. Dennoch gibt es einen Hoffnungsschimmer für all diejenigen, die in SOA vor allem ein Management-Konzept sehen, um Unternehmen agiler im Wettbewerb zu machen: Bei der Frage nach dem erhofften Nutzen der SOA-Einführung stand die Prozessoptimierung ganz oben auf der Liste. Als strategisches Ziel der SOA-Einführung nannten zwei Drittel der Befragten, sie wollten damit flexibler werden. Business Process Management (BPM) gilt ihnen als die Anwendung, für die sich eine SOA am meisten lohne. Warum nur kommt diese Botschaft nicht in den Führungsetagen an?

In der Praxis beherzigen längst nicht alle Unternehmen solche gut gemeinten Ratschläge – im Gegenteil: Allzu oft beginnen SOA-Vorhaben als kleine Projekte in der IT-Abteilung, völlig unabhängig von den strategischen Vision des Managements. Das mag mit einem anderen Phänomen zu tun haben, das nicht wenige vor dem großen Wurf zurückschrecken lässt: “Eine SOA ist immer ein hochkomplexes Projekt im Zusammenspiel von Prozesssicht, Fachebene und IT”, schreiben die Experton-Analysten. Unabdingbar sei deshalb eine genaue Analyse aller vorhandenen Assets. Dass erfolgreiche Projekte auch ohne den alles umfassenden Blueprint möglich sind, bleibt in der Diskussion leider meist unerwähnt.

Dass Service-orientierte Architekturen Unternehmen agiler und flexibler machen können, gehörte auch im abgelaufenen Jahr zur Standardargumentation der Protagonisten. Welchen Preis Kunden dafür zahlen müssen, lässt sich oft nur erahnen. Kaum einer der ohnehin raren Großanwender gab an, wie viel Geld tatsächlich in die so harmlos klingenden “upfront investments” geflossen ist. Viel besser hört sich da schon an, dass man in der Anwendungsentwicklung die Summe x gespart, oder den Entwicklungsprozess für neue Produkte um den Faktor y verkürzt habe. Schwer messbar ist der Erfolg insbesondere dann, wenn Unternehmen mit SOA vorrangig Integrationsziele verfolgen, wie dies etwa die Deutsche Post tut.

Eines aber zeichnete sich 2006 deutlich ab: Mit der Anzahl der installierten Softwareservices steigt die Komplexität der IT-Infrastruktur. Das erschwert umfassende Sicherheits- und Steuerungskonzepte. Wenn neben Services aus dem eigenen Haus auch solche aus externen Quellen eingebunden werden sollen, wird die Sache noch komplizierter. Und das ist nur eine von vielen zusätzlichen Herausforderungen an das IT-Management. Ganz allgemein wachsen mit einer SOA die Anforderungen an wirksame Governance-Mechanismen und -Werkzeuge. Wer schon mit der klassischen IT-Governance seine Probleme hatte, wird es mit SOA nicht leichter haben.

Die Softwarehersteller haben den Bedarf erkannt und ihre Portfolios systematisch um ausgefeilte Governance-Tools ergänzt. Vor allem Service-Registries und -Repositories spielten dabei eine zentrale Rolle. So richtete beispielsweise die Software AG ihre Wachstumsstrategie komplett auf die SOA-Produktpalette aus. Wie schon oft in der IT-Historie spricht vieles dafür, dass die Branche mit SOA eine Art Perpetuum mobile geschaffen hat: Einmal in Gang gesetzt, verursacht es stets neuen Bedarf an einschlägigen Produkten und Services. Auch die IT-Dienstleister springen auf den Zug auf. Accenture etwa steckt in den nächsten drei Jahren 450 Millionen Dollar in seine SOA-Bemühungen, HP will 500 Millionen Dollar investieren. IBM hat laut eigenen Angaben allein im Jahr 2006 eine Milliarde Dollar in die Entwicklung von SOA-Lösungen gepumpt.

Wenn Unternehmen künftig aus eigenentwickelten und zugekauften Services “Composite Applications” bauen wollen, dürften sie dabei verstärkt auf externe Hilfe zurückgreifen, lautet ein Kalkül der Servicelieferanten: Mit den Gestaltungsoptionen steige der Bedarf an Strategie- und Prozessberatung. Nach Erhebungen von IDC gaben Kunden im Jahr 2006 weltweit bereits rund 8,6 Milliarden Dollar für IT-Dienstleistungen in SOA-Projekten aus. Bis 2010 soll die Summe auf 33,8 Milliarden Dollar steigen. Das Umsatzpotenzial für SOA-Produkte und -Services schätzt IBM-Manager Ray Harishankar auf 160 Milliarden Dollar im Jahr 2008. Sind diese Zahlen auch nur halbwegs realistisch, dann entwickelt sich SOA zumindest für einige Anbieter zum tragfähigen Geschäftsmodell.

Experten empfehlen , bei SOA-Implementierungen die Security-Aspekte von Anfang an in alle Projektphasen einzubeziehen. Damit lasse sich der häufige Fehler vermeiden, dass Security erst nachträglich einer fast oder ganz fertigen Lösung aufgesetzt wird. Eine derartige Vorgehensweise berge Risiken: es könne sich herausstellen, dass eine Designänderung erforderlich wird, um Sicherheitslücken zu schließen. Oft werde darauf aus Zeitgründen verzichtet oder aber die Lösung nicht ausreichend getestet. So entständen nicht nur unsichere Systeme sondern auch zusätzliche Kosten.

Die angemahnte ganzheitliche Sicht auf die SOA verursacht indes zusätzlichen Aufwand: So sollten Projektveantwortliche beispielsweise schon im Vorfeld eine Grundsatzentscheidung darüber treffen, welche Security-Funktionen ihrerseits als Services der Infrastruktur realisiert werden sollen. Wegen der systemimmanenten Heterogenität einer SOA entstehen weitere Anforderungen; beispielsweise müssen Identitäten umgewandelt und Vertrauensbeziehungen definiert werden. Der “Dschungel der Security-Standards” (link!) macht das Leben der Projektleiter dabei nicht leichter. Im Gegenteil: Ebenso wie in anderen Bereichen der ohnehin schon umfangreichen Web-Services-Standards sind auch viele Security-Spezifikation noch im Fluss. Die großen (und kleineren) SOA-Protagonisten könnten vor diesem Hintergrund durchaus mehr Aufklärungsarbeit leisten.

Mehr zum Thema Sicherheit im Security-Expertenrat der COMPUTERWOCHE.

Technisch basiert Celtix auf Ionas kommerziellem ESB-Produkt “Artix”, das sich bei etlichen Großkunden bewährt hat. Deshalb tut sich der Hersteller leicht, mit der Interoperabilität zwischen dem quelloffenen System und dem Closed-Source-Produkt zu werben. Iona hatte das Celtix-Projekt im Juni 2005 selbst initiiert und nicht nur finanziell unterstützt. Natürlich verbirgt sich dahinter noch eine andere Absicht: Ähnlich wie IBM mit seinem quelloffenen Application Server “Websphere Community Edition” hoffen auch die Iren, Kunden eines Tages kommerzielle Produkte aus dem eigenen Haus schmackhaft machen zu können. Dem Kunden kann´s egal sein. Er kann mit der (lizenzkosten)-freien Variante starten und später entscheiden, ob er sich auf den Softwarelieferanten einlässt. Der Einstieg in die SOA dürfte damit leichter fallen.

Bloomberg fasst seine Vorhersagen unter dem Motto “Thinking Outside the SOA Box” zusammen. Nach seiner Einschätzung erreicht das Konzept gerade einen neuen Reifegrad: SOA werde immer weniger als ein Set von Aktivitäten und Best Practices gesehen, das vom Rest der IT abkoppelt ist. Zwar helfe das Denken “inside the box”, einen neuen Ansatz für die IT-Organisation zu verstehen, doch es berge erhebliche Nachteile: Business-Manager interessierten sich nicht dafür, was in der “SOA Box” steckt. Sie wollten ihre täglichen Probleme und Herausforderungen mit Hilfe von IT lösen, ganz gleich ob diese serviceorientiert ist oder nicht.

Immerhin räumt Bloomberg ein, dass diese Entwicklung erst am Anfang stehe. Für die meisten deutschen Anwender dürfte sie freilich noch in weiter Ferne liegen. Etliche Studien belegen, dass vielerorts noch das Verständnis für SOA und deren Auswirkungen auf die Organisation fehlt, geschweige denn größere Projekte in Angriff genommen werden. Ein bisschen mehr “Thinking inside the Box” könnte da nicht schaden.