Eine serviceorientierte Architektur setzt sich aus den verschiedensten Komponenten zusammen, wie zum Beispiel Prozessdefinitionen oder Policies. Bereits bei Konzeption, Implementierung und Inbetriebnahme entsteht eine Fülle von SOA-Artefakten: Aus der Analyse stammen Geschäftsprozesse sowie die begleitende Dokumentation; anschliessend kommen Architekturentwürfe, Implementierungsbeschreibungen sowie die Betriebsdokumentation hinzu. Da diese Artefakte einen langfristigen Wert für Nutzer und Anbieter von Services besitzen, müssen sie für alle SOA-Teilnehmer abrufbar sein.
Ein übergreifender SOA-Governance-Ansatz ist für den Projekterfolg entscheidend. Daher ist es nötig, im ersten Schritt wesentliche organisatorische Aspekte zu klären. Unternehmen müssen Rollen definieren für Fach- und Service-Architekten, für Service-Entwickler und für Organisationseinheiten wie ein SOA-Governance-Team, das Anlaufpunkt und Kontrollinstanz für SOA-Fragen ist. Diese Rollen sowie das SOA-Governance-Team wachsen schrittweise – jedoch sind sie frühzeitig zu definieren und zu besetzen, damit SOA zum wirtschaftlichen Erfolg beiträgt.
Auf der organisatorischen Seite sollte ein SOA-Bibliothekar das Projekt unterstützen. Dieser Mitarbeiter kennt, verwaltet und kommuniziert alle Details zu den vorhandenen Systemen und Services. Gleichzeitig erhöht er durch sein Engagement die Sichtbarkeit der SOA-Projekte im eigenen Haus.
Des weiteren hilft er bei der Definition eines Regelwerks: Die Regeln beschreiben beispielsweise, wie das Projektteam neue Services entwickelt. Ähnlich wie in einem Content-Management-System wird festgehalten, wer welche Aufgaben hat, wer Dienste testet und freigibt und wer Systembetreiber über Neuigkeiten und Änderungen an genutzten Diensten informiert.
Services und zugehörige Artefakte folgen einem spezifischen SOA-Service-Lebenszyklus. Zu Beginn stehen die Analyse und Optimierung von Geschäftsprozessen. Anschliessend erfolgt das Service-Design, bei dem die Definition und die Implementierung der Schnittstelle stattfindet. Am Design einer Service-Schnittstelle beteiligen sich typischerweise folgende Mitarbeiter: Ein Verantwortlicher aus der Fachabteilung, dem der Service fachlich zugeordnet ist. Ausserdem ein Software-Architekt, der das fachliche Design verantwortet und damit die Integrierbarkeit in die Service-Landschaft sicherstellt. Weiterhin sind die technisch orientierten Rollen Service-Designer und Service-Entwickler zu besetzen, die den Entwurf und die Implementierung der Dienste übernehmen. Abläufe wie der hier beschriebene Design-Prozess stellen die kontinuierliche Evolution der gesamten SOA sicher.
In der Praxis stellen Facharchitekten, Service-Designer und Entwickler immer wieder während der Entwurfs- und Implementierungsphase dieselben Fragen, wie etwa die nach existierenden Diensten und deren Schnittstellen, zugehörigen Geschäftsprozessen oder verantwortlichen Organisationseinheiten. Besonders wichtig für diese Rollen sind die Beziehungen zwischen Services und beteiligten Artefakten wie Service-Schnittstellen, Anforderungs-, Architektur- und Testdokumentation sowie den Service-Policies und SLAs.
Um alle Details einer SOA an zentraler Stelle abzubilden, stellen SOA Registries und Repositories die benötigten Management-Werkzeuge bereit. Deren Funktionsumfang geht über ein klassisches UDDI-Verzeichnis weit hinaus: Während einfache Service Registries nicht viel mehr als Schnittstellenbeschreibungen von Diensten speichern, erlauben Repositories die Verwaltung einer Vielzahl weiterer Service-Informationen. Ein Repository erfasst sämtliche SOA-Komponenten, speichert Prozesse, Regeln, Service-Level-Agreements, Verfügbarkeiten, Zugriffsrechte und weitere Details der Infrastruktur.
Entwurf und Implementierung stellen jedoch nur einen Teil einer SOA dar. Ist ein Service in den produktiven Betrieb übergegangen, benötigen Betreiber, Facharchitekten und Manager Informationen zur effektiven Nutzung einzelner Services. Voraussetzung hierfür ist, dass ein Monitoring von Service-Aufrufen zur Laufzeit erfolgt. Dann lassen sich auch Nutzungs- und Zugriffsmuster auf Dienste sowie die Einhaltung von SLAs feststellen. Ein Gradmesser für die erreichte Wiederverwendung eines Services ist die Häufigkeit der Nutzung. Damit verbunden ist eine mögliche Verrechnung (Provisioning) von Services. Nicht oder nur wenig genutzte Dienste sind damit ebenfalls rasch identifizierbar und können von den Verantwortlichen aus dem Produktivbetrieb entfernt werden. Die meistgenutzten Dienste lassen sich dann als Best-Practice-Lösung unternehmensweit einsetzen.
Zudem erlauben SOA Registries und Repositories die effiziente Integration bestehender Metadaten, Policies und Dokumente aus heterogenen IT-Landschaften in eine SOA. Sie unterstützen also insbesondere die SOA-typische Kombination der «Top-Down»-Neuentwicklung von Services mit dem «Bottom-up-Harvesting» bestehender, produktiver IT-Anwendungen als Services im Rahmen einer Gesamtverwaltung von SOA-Artefakten.
Ist erst einmal eine gut gepflegte SOA-Governance-Lösung im Einsatz, so bietet dies dem Unternehmen auf Ebene der Geschäftsabläufe eine Reihe von Vorteilen. So ist beispielsweise Business-Service-Monitoring möglich, und der IT-Verantwortliche erhält den Überblick über Status und Nutzung von Diensten. Dies ist notwendig für eine ROI-Analyse und eine Prozess-Evolution. Konventionellen Registries fehlen hierfür wesentliche Referenzinformationen, wie etwa eine Korrelation zu Geschäftsprozessen. Weiterhin erhöht sich die Sichtbarkeit von Daten, Prozessen und Compliance Level: Ähnlich wie konventionelles Application-Monitoring liefert ein Service-Repository 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 im Sinne von Business Agility. Schliesslich gewinnt IT-Governance an Leistungsfähigkeit: SOA-Assets werden durch SOA-Governance zu Wirtschaftsgütern, erst eine SOA-Governance-Lösung macht diese Assets jedoch greifbar. Damit wird ihr Einfluss auf die wertschöpfenden Unternehmensprozesse transparent und regelbar.
Unter diesen Voraussetzungen hilft Governance, den zentralen Auftrag von IT und SOA zu erfüllen: nämlich Informationstechnologie und Services optimal im Sinne der Unternehmensziele einzusetzen. Bei der praktischen Umsetzung sollten IT-Verantwortliche auf Lösungen setzen, die offene und herstellerneutrale Standards unterstützen. In der Praxis wird die Frage nach dem Management von SOA-Infrastrukturen gerne verdrängt: Wer sich erst damit beschäftigt, wenn die Komplexität nicht mehr zu beherrschen ist, wird mit Folgekosten bestraft.
Beispiel für eine Registry/Repository-Architektur
Eine Registry stellt – vergleichbar einem Branchen-Telefonbuch – ein Verzeichnis der verfügbaren Dienste bereit, aus dem neben der Adresse nur wenige zusätzliche Informationen (Metadaten) über einen Dienst hervorgehen. Ein Repository hingegen speichert und kategorisiert Dienste zusammen mit ihren Eigenschaften sowie zusätzlichen Artefakten. Doch der Einsatz zweier getrennter Technologien für Registry und Repository erfordert eine aufwendige Synchronisation und birgt das Risiko inkonsistenter Darstellungen – ganz abgesehen vom erhöhten Betriebsaufwand. Für SOA-Governance ist das reibungslose Zusammenspiel zwischen Registry und Repository unerlässlich. Denn nur so ist es möglich, Governance-Prozesse effektiv zu beschreiben, auszuführen und zu kontrollieren.
Die Anbieter von SOA-Governance-Lösungen kooperieren in verschiedenen Gremien, um die Interoperabilität im SOA-Bereich weiterzuentwickeln. Unternehmen wie Sun und Infravio favorisieren hierfür beispielsweise den Standard ebXML (Electronic Business XML). Das stärker SOA-orientierte UDDI (Universal Description, Discovery and Integration) nutzen unter anderem Software AG, Fujitsu und HP. Initiativen wie die Centrasite Community, ins Leben gerufen von Fujitsu und Software AG, entwickeln derzeit neue auf UDDI basierende Standards. An dieser Kooperation sind unter anderem Firmen wie Ambersoft, IDS Scheer, Ilog, Mindreef und Vordel beteiligt.
