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).

Wiederverwendung messen

Serviceentwurf und -Implementierung stellen indes nur einen Teil der SOA dar. Ist zum Beispiel ein Service in den produktiven Betrieb übergegangen (Run-time), so stellen Betreiber, Facharchitekten und Manager Fragen zur effektiven Nutzung der Softwaremodule. Voraussetzung hierfür ist ein Monitoring von Serviceaufrufen zur Laufzeit. Damit lassen sich Nutzungs- und Zugriffsmuster sowie die Einhaltung von SLAs feststellen. Aus der Häufigkeit der Nutzung eines Services ergibt sich der Grad der Wiederverwendung. Damit verbunden ist eine mögliche Verrechnung oder ein Provisioning von Services. Nicht oder wenig genutzte Dienste sind damit ebenfalls rasch identifizierbar und lassen sich von den Verantwortlichen aus dem Produktivbetrieb entfernen oder ersetzen. Die meistgenutzten Dienste können als Best-Practice-Lösung für die gesamte Organisation dienen.

RoI und Effizienz

Frühere Topdown-Ansätze der Softwareentwicklung, etwa mit Hilfe von CASE-Tools, können einzelne Services nur unzureichend bewerten. Diesen Ansätzen bleibt die Betriebs- und Laufzeit der Applikationen weitgehend verborgen. In Service-orientierten Architekturen besitzen Unternehmen mit Registry und Repository jedoch Instrumente, um auch Laufzeitaspekte in die IT- und SOA-Governance einzubeziehen. Das ermöglicht eine fundierte RoI- und Effizienzbetrachtung sowie die Chance, das Serviceportfolio-Management systematisch zu betreiben.

Moderne SOA-Registries und -Repositories integrieren zudem bestehende Metadaten, Policies und Dokumente aus heterogenen IT-Landschaften in einer SOA. Sie unterstützen damit insbesondere die SOA-typische Kombination aus Top-down-Neuentwicklung von Services und "Bottom-up-Harvesting", sprich die Nutzung bestehender IT-Anwendungen als Services im Rahmen einer übergreifenden Verwaltung von SOA-Artefakten.

Aufgaben des Repository

Zu den Aufgaben eines SOA-Registry- und Repository-Systems gehört zunächst die Katalogisierung aller Serviceinformationen. Weiterhin gilt es, alle Beziehungen zu erfassen, die zwischen den Services und SOA-Artefakten bestehen. Dazu zählen sowohl Design- als auch Run-time-Abhängigkeiten. Derartige Artefakte sind zum Beispiel in der Business Process Execution Language (BPEL) spezifizierte SOA-Prozesse, grafische Prozessdarstellungen mittels der Business Process Modeling Notation (BPMN), Geschäftsregeln, Servicebeschreibungen oder Serviceaufruf-Policies. Ein SOA-Registry und -Repository regelt darüber hinaus die Zusammenarbeit von Management- und Monitoring-Werkzeugen, um mit deren Hilfe Run-time-Policies oder SLAs überwachen zu können. Dazu werten die Systeme Run-time-Daten automatisch aus.

Entsprechend eng muss das Service-"Repistry" sowohl mit dem Enterprise Service Bus (ESB) als auch mit den SOA-Management- und Monitoring-Werkzeugen verzahnt sein. Ein konkretes technisches Szenario wäre das Folgende: Der ESB steuert die Kommunikation innerhalb der SOA, sendet also beispielsweise Serviceaufrufe als Nachrichten eines Web-Service-Konsumenten an einen passenden Serviceprovider. Vor der Auslieferung der Nachricht wird der Aufruf durch den ESB unterbrochen und über Management-Protokolle wie SNMP (Simple Network Management Protocol) oder JMX (Java Management Extension) an ein Verwaltungswerkzeug gesendet. Das Tool sammelt Informationen über die Aufrufe und speichert die Daten mit Hilfe des SOA-Registry und -Repository. Dieses kann dann wiederum Statistiken wie beispielsweise "Zahl der Aufrufe von Service ,HoleKundenDaten’ in den letzten vier Wochen" erstellen und mit anderen SOA-Daten verknüpfen.

Hinter einer Service-"Repistry" verbergen sich eine Reihe von Techniken, darunter Servicekataloge gemäß dem Registry-Standard UDDI (Universal Description, Discovery and Integration). In ihnen sind Service-Schnittstellenbeschreibungen abgelegt, die abgefragt werden können. Interessant ist die Möglichkeit, UDDI standardkonform um semantisch reichhaltige SOA-Artefaktbeschreibungen zu erweitern. Einen ähnlichen Weg zur Speicherung und Abfrage geht der Standard ebXML (Electronic Business XML), der einen technischen Rahmen zur Nutzung von XML für elektronische Geschäftsprozesse bildet.

Standards und Schnittstellen

Mit Schnittstellenbeschreibungen und standardkonformen Erweiterungen alleine ist es aber nicht getan. Wie erwähnt, muss ein SOA-Registry und -Repos- itory viele weitere Artefakte wie Policies oder Prozessbeschreibungen unterstützen. Hier kommen Standards wie WS-Policy zur Spezifikation von Quality- of-Service-Aspekten ins Spiel, darüber hinaus Prozessmodellierungs-Standards wie BPMN (Business Process Modeling Notation). IT-Hersteller kooperieren in verschiedenen Gremien, um die Interoperabilität im SOA-Bereich weiterzuentwickeln. ebXML wird in diesem Kontext beispielsweise von Sun und Infravio favorisiert; die stärker SOA-orientierte Registry der UDDI-Spezifikation unter anderem von der Software AG, Fujitsu und HP.

Business-Vorteile

Ist erst einmal ein gut gepflegtes SOA-Registry und -Repository im Einsatz, so bietet dies dem Unternehmen auf der Business-Ebene mehrere Vorteile. Beispielsweise ermöglicht es RoI-Berechnungen für die SOA. Grundlage dafür ist der Überblick über Status und Nutzung von Diensten. Zusätzlich werden Referenzinformationen, wie etwa eine Korrelation von Services zu Policies und Geschäftsprozessen, zur Verfügung gestellt. Weiterhin erhöht ein derartiges Governance-System die Sichtbarkeit von Daten, Prozessen und Compliance-Leveln: Ähnlich wie konventionelles Application-Monitoring liefert ein SOA-Registry und -Repository über die gesamte SOA-Architektur hinweg die für geschäftliche Entscheidungen wichtige Transparenz.

Erhöhte Sichtbarkeit führt zu verbesserten Kontroll- und Steuerungsmöglichkeiten für das Management und die Fachbereiche. Das wiederum führt direkt auf das Ziel jeglicher SOA-Initiativen zu, nämlich mehr Flexibilität und Agilität des Unternehmens. Auch die IT-Governance kann dadurch leistungsfähiger werden: SOA-Assets werden mit Hilfe von Governance-Strukturen zu Wirtschaftsgütern, jedoch erst ein SOA-Registry und -Repository macht diese Assets greifbar. Damit wird ihr Einfluss auf die wertschöpfenden Unternehmensprozesse transparent und regelbar.

Technische Vorteile

Das Konzept eines SOA-Registry und -Repository bietet auch der Technikebene Vorteile. So können Entwurf und Entwicklung von Services deutlich effizienter ablaufen, da alle relevanten Informationen zentral für die Entwickler abrufbar sind. Die Integration in Entwicklungsprozesse minimiert den Overhead für Entwickler und Architekten. Vorteilhaft ist hierbei eine Integration in klassische Entwicklungsumgebungen, wie beispielsweise Eclipse.

Die Einführung von Governance und eines damit verbundenen SOA-Registry und -Repository sollte beginnen, sobald erste Services produktiv im Einsatz sind. Typische Reifegradmodelle für SOA starten mit Pilotprojekten, in denen SOA zunächst auf Basis weniger Services eingeführt wird (siehe Grafik: "SOA-Reifegrad und Governance"). Oft geschieht dies zunächst durch die Integration existierender Anwendungen, wie beispielsweise produktiver Mainframe-Applikationen. Spätestens wenn diese frühe Phase erfolgreich beendet und die Entscheidung für den künftigen SOA-Einsatz gefallen ist, sollte die systematische Fortentwicklung der SOA geplant werden, einschließlich umfassender SOA-Governance mit adäquaten Werkzeugen.

Einführung und Betrieb eines SOA-Registry und -Repository müssen in jedem Fall als eigenständiges Projekt angelegt sein: Kein Fachbereich möchte aus seinem eigenen Budget eine solch strategische Investition leisten. Deshalb sollten Unternehmen jedes Verwaltungssystem unter die organisatorische Kontrolle eines SOA-Governance Komitees stellen, das sich aus Vertretern unterschiedlicher Fachbereiche und der IT zusammensetzt.