Wie sich SOA-Governance planen lässt

10.01.2007
Autor(en): Stefan Tilkov, Geschäftsführer und Principal Consultant bei der innoQ Deutschland GmbH.

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.

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

CW TV: SOA ist keine Architektur, sondern ein Vorgehen

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

SOA-Governance sollte den gesamten Lebenszyklus eines Softwareservice umfassen.

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

SOA-Governance umfasst sowohl Entwicklung und Betrieb von Services als auch klassische IT-Management-Aufgaben.

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.