Eigentlich bezeichnet der SOA-Begriff ein Phantom, denn eine verbindliche oder allgemein gültige Definition für eine Service-orientierte Architektur gibt es nicht. Gründe, warum man eine SOA implementieren sollte, werden dagegen zahlreich angeführt. Auch an Fürsprechern mangelt es der Idee nicht. Deshalb ist es kein Geheimnis, dass der Reiz einer SOA in der Möglichkeit liegt, Dienste flexibel zu koppeln. Das wiederum nährt die Hoffnung, die Kluft zwischen IT- und Fachabteilungen wirksam zu überbrücken. Denn immer wenn Fachabteilungen einen IT-basierenden Service zur Unterstützung des Tagesgeschäfts benötigen, ist das bislang mit umständlichen Tickets verbunden, die zumeist eine mühselige Abwicklungsprozedur bedeuten. Das eigentliche Ärgernis ist dabei nicht selten, dass sich beide Seiten einfach nicht richtig zu verstehen scheinen, so dass in langwierigen Sitzungen das tatsächliche Problem und die dazugehörige Lösung mühselig einzukreisen sind.

Und eben das scheint die SOA überflüssig zu machen. Denn man kann ja einfach bereits bestehende Dienste oder zumindest deren Komponenten heranziehen, um andere ähnliche Dienste bereitzustellen. So weit die Theorie, doch der Schein ist auch hier trügerisch. Zwar zeigen viele SOA-Modelle, wie man Komponenten flexibel koppeln oder austauschen kann, wie man jedoch Prozesse mit Geschäftslogiken und Regeln einbinden kann, bleibt ausgespart.

Wer darf wann welchen Dienst erstellen und zu welchem Zweck? Wer darf wann welchen Dienst mit welchem Ziel nutzen? Wie ist dabei vorzugehen? Wie erfolgt die Preisgestaltung der Dienste? Wie definiert und überwacht man Service-Levels? Hierzu bietet SOA keine Hilfe, kein Muster, keine Richtlinie. Zu allem Überfluss sind viele der vorgestellten Methoden auch nur bis zu einem gewissen Grad von den Fachabteilungen nutzbar, denn sie zwingen früher oder später zur Verwendung von Eclipse, Javascript oder sonstigen Software-Entwicklungssystemen zur Erzeugung von ausführbarem Code. Das aber verlangt Fachabteilungen schlicht zu viel ab.