SOA muß auch verwaltet werden

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 Anforderungsdokumente; 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.

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 Repository" bezeichnet wird.

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.

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. 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-"Repository" sowohl mit dem Enterprise Service Bus (ESB) als auch mit den SOA-Management- und Monitoring-Werkzeugen verzahnt sein.

Die 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 Rol-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-Levels: Ä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.

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

www.softwareag.com/at/