Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

19.12.2006

Wie sich SOA-Governance planen lässt

Stefan Tilkov 
Ein schrittweises Vorgehen führt zu einem umfassenden Überwachungs- und Steuerungssystem für Service-orientierte Architekturen.
SOA-Governance sollte den gesamten Lebenszyklus eines Softwareservice umfassen.
SOA-Governance sollte den gesamten Lebenszyklus eines Softwareservice umfassen.
Ein Informationsmodell, das der Servicearchitektur zugrunde liegt, gehört zu den Kernelementen eines Governance-Konzepts.
Ein Informationsmodell, das der Servicearchitektur zugrunde liegt, gehört zu den Kernelementen eines Governance-Konzepts.

Geht es um Service-orientierte Architekturen (SOA), dreht sich alles um den Service, den Dienst, als das zentrale Konzept. In der idealisierten SOA werden Services wiederverwendet, nicht Komponenten; Services sind die Einheit der Versionierung und des Deployments, nicht Systeme. Der Unternehmensarchitekt verwaltet keine Anwendungs-sondern eine Servicelandschaft. Dem Konzept zugrunde liegt ein Modell, das die Prinzipien der unternehmensübergreifenden, standardisierten Kommunikation - wie sie im Web gang und gäbe sind - und die Prinzipien guten Softwaredesigns auf die Unternehmens-IT überträgt.

Hier lesen Sie …

• was unter SOA-Governance zu verstehen ist;

• warum SOA-Governance wichtig ist;

• in welchen Schritten man vorgehen kann;

• welche Erfolgsfaktoren es gibt.

Schritte zur SOA-Governance

• Definieren des Informationsmodells,

• Festlegen von Prozess, Rollen, Verantwortlichkeiten,

• Definieren von Richtlinien,

• Werkzeugauswahl und -anpassung,

• Einführen und Initialisieren,

• Operationalisieren,

• Kontinuierliches Fortschreiben/Ändern.

Mehr zum Thema

www.computerwoche.de/

584585: Webmethods forciert SOA-Registry;

582989: Wie Repositories die SOA verwalten;

582230: IBMs SOA-Produktoffensive.

www.computerwoche.de/ soa-expertenrat/

Die Entwicklung von IT-Systemen erfolgt in der Regel in Form von Projekten, in denen ein Architekt die Einhaltung der Regeln und Richtlinien überwacht, die seiner Architektur zugrunde liegen. Dieselbe Aufgabe in einer unternehmensweiten Servicelandschaft, über einen Zeitraum von Jahren und projektübergreifend, lässt sich als SOA-Governance bezeichnen.

SOA-Governance definiert

Unter Governance versteht man ganz allgemein die Überwachung von geltenden Vorgaben - Richtlinien, Regeln oder Gesetzen - mit sinnvollen Mitteln. Dazu zählt das Definieren und Anwenden von Organisationsstrukturen, Rollen und Prozessen, die zur Überwachung der Umsetzung strategischer Unternehmensziele mit IT-Relevanz dienen - beispielsweise die globale Vereinheitlichung von Geschäftsprozessen. SOA-Governance muss daher sicherstellen, dass die dazu unternehmensweit definierten Richtlinien, Muster und Regeln über den gesamten Lebenszyklus von Diensten befolgt oder zumindest nur in begründeten Ausnahmefällen umgangen werden.

Zusätzlich zu den Regeln, die für einzelne Services gelten, soll auch das entstehende "Servicenetz" bestimmten Vorgaben genügen. So sollten zum Beispiel Services, die bereits existieren, wiederverwendet und nicht noch einmal neu entwickelt werden.

Warum SOA-Governance?

Die zentralen Konzepte von SOA, wie zum Beispiel lose Kopplung, Wiederverwendung, Standardisierung und Interoperabilität, können nur umgesetzt und die damit verbundenen Vorteile nur dann erzielt werden, wenn geeignete Governance-Strukturen bestehen. Werden Services nicht nach einheitlichen Vorgaben erstellt, enthält die sprichwörtliche Lego-Kiste viele Bausteine, die ganz und gar nicht zueinander passen wollen. Das Erstellen der Architektur sowie das Ableiten der Vorgaben ist Aufgabe eines Architekten; die kontinuierliche Fortschreibung der Vorgaben sowie deren Durchsetzung Aufgabe der SOA-Governance. Für die strategische Planung des Themas SOA-Governance empfiehlt sich ein schrittweises Vorgehen (siehe Kasten "Schritte zur SOA-Governance").

Auch wenn es eine Reihe von Werkzeugen für SOA-Governance gibt, zeigt sich in der Praxis, dass eine Priorisierung entscheidend ist: Anstatt mit einer aufwändigen Werkzeugauswahl zu beginnen, sollte der Schwerpunkt zunächst auf dem Informationsmodell liegen, das der Servicearchitektur des Unternehmens zugrunde liegt. Konzepte wie Domänen, Services, Nutzungs- und Angebotsbeziehungen, Eigentümer, Schnittstellen etc. müssen in Beziehung zueinander gesetzt und (im Idealfall formal) beschrieben werden. Anbieter von Governance-Lösungen unterstützen in ihren Produkten oft nur einfache, sehr stark idealisierte Modelle, die zu einem erheblichen Anteil auf Annahmen beruhen und in der Praxis selten unverändert einsetzbar sind. Ein Grund dafür ist, dass eine SOA nicht im luftleeren Raum ("auf der grünen Wiese") entsteht, sondern existierende Gegebenheiten berücksichtigen muss - in der Praxis gibt es durchaus zu integrierende Dienste, die auf Cics-Transaktionen, Corba-Schnittstellen oder proprietären Konventionen beruhen.

Prozesse und Rollen

Auf Basis des Informationsmodells müssen Prozesse, Rollen und Verantwortlichkeiten festgelegt werden: Wer definiert Dienste? Wer genehmigt sie? Wann werden sie zu Informationszwecken veröffentlicht? Wie und von wem werden Entwicklung, Test, Inbetriebnahme, Betrieb und schließlich Außerbetriebnahme von Diensten vorgenommen? Auch hier zeigt sich in der Praxis, dass keine zwei Unternehmen identisch sind.

Obwohl es noch keine allgemein akzeptierten Rollenbeschreibungen für Service-orientierte Architekturen gibt, lässt sich die Rolle eines SOA-Gesamtarchitekten aus den Konzepten ableiten. Dieser ist verantwortlich für die Servicelandschaft als Ganzes und insofern vermutlich am besten mit einem Unternehmensarchitekten vergleichbar.

Der SOA-Gesamtarchitekt verantwortet die inhaltlichen Aspekte der SOA-Governance, um so eine seinen Vorgaben entsprechende Gesamtarchitektur sicherzustellen.

Die Definition einer unternehmensweiten Servicearchitektur ist nicht Teil von SOA-Governance, wohl aber die Ableitung durchsetzbarer Regeln und Richtlinien daraus. Um mit Hilfe der SOA-Governance zu einer hochwertigen Gesamtarchitektur zu gelangen, müssen die Dienste und die Beziehungen dazwischen Richtlinien entsprechen. Dies reicht von konzeptionellen Aspekten bis hin zu technischen Details. Konzeptionelle Aspekte ergeben sich unter anderem aus Architekturmustern, die in der Regel auch im Informationsmodell zu finden sind: So könnte zum Beispiel eine Regel definiert werden, die den Aufruf von Datendiensten aus Prozessdiensten heraus erlaubt, aber nicht andersherum. Beispiele für technische Aspekte sind die korrekte Verwendung von XML-Namespaces oder die Konformität zu Interoperabilitätsstandards wie dem WS-I Basic Profile. Es empfiehlt sich, mit einer überschaubaren und unstrittigen Menge von Regeln zu beginnen und diese sukzessive zu erweitern.

Um überhaupt qualifizierte Aussagen über die im Unternehmen verfügbaren Dienste treffen zu können, muss deren Existenz zunächst einmal dokumentiert sein. In der Regel kommt dafür eine zentrale Informationsablage zum Einsatz, in der Informationen über die Dienste sowie die damit verbundenen Informationen gespeichert werden.

Verzeichnisdienste

Mit dem mittlerweile in der Version 3 verfügbaren Oasis-Standard UDDI (Universal Description, Discovery and Integration) wird ein Verzeichnisdienst standardisiert, nicht jedoch die Informationsablage selbst: ein Verzeichnis beinhaltet nur Verweise, die Ablage von Artefakten wie zum Beispiel Service-Beschreibungen erfolgt extern. Aus diesem Grund, aber auch wegen der eher geringen Akzeptanz von UDDI in der Praxis, existieren mittlerweile eine Reihe von Produkten, die Verzeichnis- und Repository-Funktionen miteinander kombinieren. UDDI spielt hier noch die Rolle des kleinsten gemeinsamen Nenners und wird zum Beispiel für die Integration von Governance-, Management-, Entwicklungs- und Testwerkzeugen verwendet.

Eine Werkzeugauswahl sollte erst auf Basis der sich aus Informations- und Prozessmodell sowie den Richtlinien ergebenden Anforderungen erfolgen. In größeren Unternehmen empfiehlt sich der Einsatz eines integrierten Registry/Repository-Konzepts; in überschaubaren Umgebungen ist es durchaus möglich, auch langfristig ganz ohne eine häufig sehr teure kommerzielle Lösung auszukommen. Zur Verwaltung einer Handvoll Dienste reicht auch die Dateiablage, verbunden mit einigen Arbeitsanweisungen; für etwas größere Anforderungen können Open-Source-Werkzeuge eingesetzt werden. Fällt die Wahl auf eine kommerzielle Registry/Repository-Lösung, sollte immer berücksichtigt werden, wie gut das dem Werkzeug zugrunde liegende Informations- und Prozessmodell den unternehmensspezifischen Bedürfnissen angepasst werden kann.

Einführung und Initialisierung

Ein halbvermietetes Einkaufszentrum regt nicht zum Shopping an, ein beitragsleeres Diskussionsforum nicht zum Debattieren. Ähnlich verhält es sich auch mit einem leeren SOA-Repository: Infrastruktur allein ist nur ein Mittel, kein Selbstzweck; ein initiales Befüllen mit Informationen ist daher ausgesprochen sinnvoll. Es gilt allerdings, die richtige Balance zu finden: Stehen nur Informationen zur Verfügung, die erkennbar ausschließlich Beispiel- oder Lückenfüllercharakter haben, ist dies ebenfalls kontraproduktiv.

Die Einführung der zentralen Informationsablage erfolgt daher im Idealfall koordiniert mit einem ersten Projekt, das Dienste anbietet (und gegebenenfalls externe Dienste konsumiert). Die Dienste sollten, am besten im Konsens mit dem Projektteam, den geltenden Richtlinien entsprechend gestaltet und unmittelbar zentral erfasst werden. Auf diese Weise wird ein erster Grundstock für einen sauber katalogisierten Service-Pool geschaffen.

Erfolgreiche SOA-Governance ist umso leichter, je weniger sie als Ballast, als Zusatzaufwand oder als notwendiges Übel empfunden wird. Neben dem unternehmensweiten Qualitätsziel erhöht sich die Erfolgswahrscheinlichkeit ungemein, wenn die für die Governance Verantwortlichen - in der Regel ein oder mehrere (Unternehmens-)Architekten - sich als Dienstleister für Projekte empfinden. Gerade zum Zeitpunkt der Einführung von SOA-Governance gehört es daher zu ihren Aufgaben, den Nutzen durch aktives Werben sowohl für die Wiederverwendung bestehender Dienste als auch für das Einhalten der Regeln und Richtlinien bei neuen Diensten zu vermitteln.

Operationalisierung

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.

Kontinuierliches Fortschreiben

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.

Unklare Definitionen

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.

Technische Herausforderungen

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.

Weiche Erfolgsfaktoren

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