Wer mit einem kleinen SOA-Projekt startet, kommt in der ersten Phase vielleicht noch mit manuell erstellten Dokumenten und Excel-Tabellen aus, um die Services, ihre Artefakte und die Abhängigkeiten zu beschreiben. Schon ab zehn bis 20 Services aber ist die Verwaltung all dieser Komponenten manuell kaum mehr möglich. Denn eine SOA besteht aus mehr als nur Services: Prozessdefinitionen und Policies etwa sind fester Bestandteil einer solchen Architektur.

Bereits in der Konzeptions- und Implementierungsphase, aber auch während der Einführung von Softwarekomponenten entsteht eine Fülle von Dokumenten: Aus der Analyse stammen Geschäftsprozesse, Business-Cases und weitere Anforderungsdo- kumente; später kommen Architekturentwürfe, Implementierungsbeschreibungen, Test- und schließlich Betriebsdokumentation hinzu. Diese und andere Komponenten besitzen einen langfristigen Wert für Nutzer und Betreiber von Services. Sie sollten in jedem Fall für andere Beteiligte der SOA zur Verfügung stehen.

SOA-Governance

Ein übergreifender Ansatz für SOA-Governance ist vor diesem Hintergrund unerlässlich. Dazu müssen Unternehmen im ersten Schritt organisatorische Aspekte klären. Es bedarf Rollen wie die von Facharchitekten, Service-Architekten und Service-Entwicklern. Notwendig sind auch Organisationseinheiten wie ein SOA-Governance-Team, das Anlaufpunkt und Kontrollinstanz für SOA-Fragen ist. Solche Rollen und das Governance-Team können schrittweise wachsen. Sie sind aber frühzeitig zu definieren, damit die SOA zum wirtschaftlichen Erfolg wird.

Services und zugehörige Artefakte folgen einem spezifischen SOA-Service-Lebenszyklus (siehe Grafik: "Service-Lebenszyklus"). Ausgehend von der Geschäftsprozessanalyse und -optimierung entwerfen Unternehmen Schnittstelle und Implementierung für einen Service. Danach wird getestet und schließlich geht der Service in den produktiven Betrieb. Ergänzend finden in den Servicedesign-, Implementierungs- und Testphasen Architektur-Reviews statt. Am Design einer Serviceschnittstelle beteiligen sich typischerweise folgende Rollen: Ein Service-Champion aus der Fachabteilung, dem der Service fachlich "gehört". Außerdem ein Architekt, der für das fachliche Design des Service verantwortlich ist, damit dieser in die Servicelandschaft integrierbar ist. Weiterhin sind die technisch orientierten Rollen Service-Designer und Service-Entwickler zu besetzen, die den Entwurf und die Implementierung der Dienste übernehmen.

Registry und Repository im Duett

Werkzeuge, die bei der Steuerung und Kontrolle einer wachsenden SOA helfen, sind als SOA-Registry und Service-Repository bekannt. Während einfache Service-Registries nicht viel mehr als Schnittstellenbeschreibungen von Diensten speichern, erlauben Repositories die Verwaltung zahlreicher weiterer Serviceinformationen. Die für den Erfolg von SOA-Initiativen wichtige IT- und SOA-Governance benötigt beide Kategorien von Informationen. SOA-Registry und -Repository lassen sich daher zu einer integrierten Einheit zusammenfassen, die in Fachkreisen teilweise als "SOA Repistry" bezeichnet wird.

SOA-Registry und -Repository unterstützen den gesamten Lebenszyklus von Prozessen, Policies und Services. Facharchitekten, Service-Designer und Entwickler stellen während der Entwurfs- und Implementierungsphase - häufig Design-time genannt - immer wiederkehrende Fragen: Welche Services existieren bereits? Wie sehen deren Schnittstellen aus? Welches sind die zugehörigen Geschäftsprozesse oder verantwortlichen Organisationseinheiten? Besonders wichtig sind die Beziehungen zwischen Services und beteiligten Artefakten wie Serviceschnittstellen, Anforderungs-, Architektur- und Testdokumentation sowie Service Policies und Service Level Agreements (SLAs).