In eine ähnliche Richtung geht der Gedanke der Operationalisierung von Governance-Aspekten. Auch wenn es sich bei Web-Services (basierend auf Soap, WSDL und der Vielzahl der WS-*-Spezifikationen) nur um eine von vielen möglichen Umsetzungstechniken für SOA handelt, bietet gerade die formalisierte Beschreibung der Serviceverträge in funktionaler und nichtfunktionaler Sicht eine hervorragende Gelegenheit, das Einhalten von Richtlinien bereits im Entwurfs- und Entwicklungsprozess sicherzustellen. So können zum Beispiel in WSDL vorliegende Schnittstellenbeschreibungen einer zwingenden automatisierten Prüfung unterzogen werden, bevor sie in einem zentralen Verzeichnis veröffentlicht werden können.
Gleiches gilt für nichtfunktionale, in Form von WS-Policy-Dateien vorliegende Aspekte. Nicht zu automatisieren - zumindest nicht mit Hilfe aktueller Werkzeuge - ist indes die semantische Korrektheit. In Verbindung mit einer Richtlinie, die eine Lookup-Operation in der Registry zur Laufzeit vorschreibt, lässt sich sicherstellen, dass nur konforme Dienste veröffentlicht und genutzt werden. Die Governance-Regeln und -Richtlinien finden ihren Ausdruck somit nicht nur auf Papier, sondern in konkreten, sowohl während der Entwicklungs- als auch während der Laufzeit genutzten Werkzeugen.
Die Akzeptanz von Regeln und Richtlinien steigt deutlich, wenn für diejenigen, die ihnen unterliegen, erkennbar ist, dass sie auch verändert werden können. Zu einer erfolgreichen Governance-Strategie gehört deshalb eine kontinuierliche Fortschreibung nicht nur aufgrund externer Einflüsse, sondern auch wegen des Feedbacks aus den Projekten, in denen Dienste entwickelt und genutzt werden. Stellen sich Regeln als nicht praktikabel oder gar kontraproduktiv heraus, sollte man sie auch wieder fallen lassen oder sie durch Regeln ersetzen, die die ursprüngliche Absicht besser wiedergeben.
In vielen Unternehmen ist Governance - ganz unabhängig von SOA - formal noch nicht etabliert. Vielfach liegt der Grund dafür in der generellen Ablehnung einer Einmischung "von oben". In der Tat ist es nachvollziehbar, dass ein unter Druck stehender Projektverantwortlicher wenig Verständnis für Regeln aufbringt, die sich aus seiner Sicht als Einmischung aus dem Elfenbeinturm darstellen. Diesem Aspekt ist am besten dadurch Rechnung zu tragen, dass eine klare Abgrenzung in den Verantwortlichkeiten getroffen wird: SOA als Konzept bietet die Chance, sich aus Unternehmenssicht auf die Schnittstellenarchitektur zu konzentrieren, die Details der Serviceimplementierungen jedoch den jeweiligen Projekten zu überlassen. In manchen Fällen ist eine Art Tauschgeschäft denkbar: Mehr Freiheit in der Implementierung gegen stärkere Kontrolle im Bereich der Schnittstellen. Das Akzeptanzproblem lässt sich so nicht vollständig lösen, aber zumindest reduzieren.
Eine weitere Herausforderung besteht darin, dass viele der Begriffe und Zusammenhänge im SOA-Umfeld alles andere als klar definiert sind. So werden die Konzepte "Service" und "Service-Operation" oft synonym verwendet, oft aber auch klar gegeneinander abgegrenzt. Ähnlich verhält es sich mit zusammengesetzten oder orchestrierten Diensten: für die einen sind sie ein zentrales Konzept, für die anderen nur ein Implementierungsdetail. Eine klare, zumindest unternehmensintern akzeptierte Definition ist eine unabdingbare Voraussetzung für die erfolgreiche Kommunikation im Kontext eines SOA-Vorhabens und insbesondere für das Thema Governance kritisch. Es sollte zudem früh genug definiert werden, ob und bis zu welchem Grad auch extern genutzte Dienste der Governance unterliegen. Der Einfluss auf Dritte ist in der Regel begrenzt, insbesondere bei ungleichgewichtigen Partnerbeziehungen.
Die vielleicht größte Herausforderung liegt in der Durchsetzbarkeit einer SOA-Governance-Initiative. In gewisser Weise steht man hier vor einer Art Henne-Ei-Problem: SOA-Governance ist im Grunde erst dann gerechtfertigt, wenn es auch eine SOA gibt - und eben diese entsteht nicht zuletzt deshalb, weil SOA-Governance betrieben wird. Die Investition in das Thema Governance und unter Umständen eine komplexe IT-Unterstützung dafür ist kaum zu rechtfertigen, wenn es nur eine Handvoll zu verwaltender Dienste gibt. Selbst wenn die Serviceorientierung im Unternehmen bereits in größerem Umfang Einzug gehalten hat, ist damit noch lange nicht gesagt, dass alle relevanten Geschäftsfunktionen bereits konform zu diesem Architekturparadigma umgesetzt wurden. Die gewählte Strategie muss daher insbesondere die mehrjährige Übergangsphase unterstützen, vom ersten SOA-Projekt bis zur unternehmensweiten, schließlich sogar unternehmensübergreifenden Servicelandschaft.
Neben den konzeptionellen und organisatorischen Herausforderungen gibt es auch noch eine Reihe technischer Aspekte, die von existierenden Governance-Werkzeugen unterschiedlich oder auch gar nicht beantwortet werden. Der Idee einer lose gekoppelten Landschaft aus dezentralen, eventuell sogar unternehmensexternen Diensten steht eine zentrale Informationsplattform prinzipiell entgegen: Das Risiko eines zentralen Flaschenhalses legt zunächst eine ebenfalls dezentrale Lösung nahe. In einer solchen ergeben sich jedoch unmittelbar Fragen in Bezug auf Datenkonsistenz, Aktualität und Replikation. Selbst bei einer zentralen Lösung stellt sich die Frage, wie sichergestellt wird, dass die Informationen in der Registry oder dem Repository mit den tatsächlichen Verhältnissen des Diensterbringers (des "Endpoints") übereinstimmen. Ein Lösungsansatz ist, die Registry/Repository-Lösung als eine Art "Cache" für die Informationen von den Endpoints zu betrachten - was wiederum Fragen zur Aktualität aufwirft.
Viele der Produkte auf dem Markt konzentrieren sich ausschließlich auf Web-Services. Ob dies als Problem empfunden wird oder nicht, hängt von der gewählten SOA-Strategie insgesamt ab. Services müssen nicht nur entwickelt, sondern auch betrieben werden - dementsprechend sollte die technische Lösung betriebliche Aspekte unterstützen. Dazu gehört zum Beispiel das Schließen der "Feedback-Schleife", indem im Betrieb empirisch ermittelte Informationen in die Governance-Informationsbasis integriert werden.
Neben aller Technik sind für eine erfolgreiche Governance auch im SOA-Umfeld weiche Faktoren besonders wichtig. Regeln und Richtlinien werden selten geliebt - wer hier zu große Erwartungen hat, wird sicher enttäuscht. Den Verantwortlichen für die Einführung eines SOA-Governance-Programmes muss es gelingen, den Abteilungen und Bereichen, in deren Arbeit durch die Regeln und Richtlinien eingegriffen wird, den Nutzen zu vermitteln: eine nicht nur technische, sondern vor allem eine diplomatische Aufgabe, die durch aktives Einbinden erleichtert wird.
