SOA wurde in den letzten Jahren zum Inbegriff wohldefinierter verteilter Architekturen und als die Lösung für die Entwicklung und Weiterentwicklung komplexer IT-Architekturen gehandelt. Zahlreiche Unternehmen haben SOA-Projekte initiiert und dabei teilweise gute, aber auch weniger gute Ergebnisse beziehungsweise Zwischenergebnisse erzielt. Im jüngsten Gartner Hype Cycle für Emerging Technologies ist der Begriff SOA nicht mehr zu finden. Hat sich das Konzept nun etabliert oder nicht? In der Gartner-Terminologie würde man fragen, ob sich SOA auf dem "Plateau of Productivity" befindet, oder ob das Konzept als "obsolete before Plateau" einzustufen ist.

Eines ist jedenfalls sicher: Es gibt keinen Königsweg für SOA, jedes Unternehmen muss unter Berücksichtigung der eigenen Anwendungslandschaft einen individuellen Weg finden, Service-orientierte Prinzipien einzuführen. Zwei Ansätze werden dabei diskutiert.

Die radikalste Einführungsvariante setzt eine umfassende Dekomposition der bestehenden Anwendungssysteme voraus. Services, die in verschiedenen Anwendungssystemen genutzt werden, stellt man zentral bereit und entwickelt sie in einer zentralen Organisationsinstanz weiter. Jedes einzelne Anwendungssystem muss dafür unter Beachtung einer Gesamtarchitektursicht genau analysiert werden. Das erwartete Ergebnis dieser sehr langwierigen Vorge-hensweise ist ein zentraler Service-Pool im Unternehmen sowie Anwendungssysteme, die weitgehend redundanzfrei sind und zentrale Services in der Regel über einen Service-Bus nutzen. Aufgrund des enormen Aufwands stellen sich natürlich mehrere Fragen zur Sinnhaftigkeit eines derart rigorosen Ansatzes: Kann man so lange im Voraus planen? Wie lässt sich eine Dekomposition alter Anwendungen am besten angehen? Wie soll der Service-Pool innerhalb des Unternehmens organisiert werden? Sind ein neuer Engpass und noch komplexere Abhängigkeiten zu befürchten? Fragen, die sich nicht ohne weiteres beantworten lassen.

Eine gemäßigtere Vorgehensweise ist die Einführung einer partiellen SOA. Hierbei erfolgt keine komplette Zerlegung der Anwendungssysteme in Komponenten, sondern nur eine partielle "Absenkung" von Services in einen zentralen Service-Pool. Nur die wichtigsten Services werden aus den Anwendungssystemen herausgezogen. Letztere bieten zudem bei Bedarf eine eigene Serviceschnittstelle für Funktionen, die nur wenige andere Anwendungssysteme benötigen. Die technische Kommunikation könnte ebenfalls auf einen Service-Bus umgestellt werden. Doch auch hier treten ähnliche Fragen wie in der ersten Variante auf, allerdings scheint das Ziel einer partiellen SOA-Einführung im Rahmen einer sanfteren Migration eher erreichbar zu sein.