Zum Inhalt springen
SOA-Serie Teil 6

Governance braucht ­Management

Governance braucht ­Management Wenn ein Unternehmen eine serviceorientierte Architektur einführen will, muss es auch geeignete Richtlinien in Kraft setzen. Dazu werden Verwaltungswerkzeuge gebraucht.

Autor:Redaktion connect-professional • 22.2.2007 • ca. 3:40 Min

Stetige Änderungsanforderungen an Unternehmen und immer komplexere Regulierungen erfordern vom Mana­gement, Richtlinien mit Kon­troll­instrumenten ein­zufüh­ren – eine so­genannte Unternehmens-Governance (Enterprise Governance). Norbert Schädler, IT Architect bei IBM, definiert Governance als angemessene Organisation zur Optimierung der Unternehmensführung. Ziel ist es, durch eine übergeordnete Struktur die Geschäftsziele auf strategischer, funktionaler und operativer Ebene zu unterstützen. Dazu bedarf es eines Governance-Modells, das beschreibt, was auf welche Weise getan werden soll und wer verantwortlich ist. Um eine Compliance – also die kontinuierliche Überprüfung der Einhaltung der Governance-Richtlinien – zu gewährleisten, muss ebenfalls in einem Governance-Modell definiert werden, wie gemessen werden soll. Es gilt, Regeln, Prozesse, Metriken und organisatorische Strukturen festzulegen, die für eine effektive Planung und Steuerung erforderlich sind, um die geschäftlichen Ziele zu erreichen.

Governance für Business, IT und SOA
Die IT implementiert Systeme zur Erreichung der vorgegebenen Geschäftsziele auf der Basis von Unternehmensgrundsätzen. Dadurch wird die IT-Governance – die Organisation zur Optimierung der Führung und Kontrolle der IT – zum wichtigen Teil einer Unternehmens-Governance. Durch Abstraktion von IT-Funktionalität auf der Basis geschäftsorientierter Dienste liefert eine serviceorientierte Architektur (SOA) einen Rahmen für eine Unternehmensarchitektur, die IT und Business umfasst. Die Nutzung einer SOA erleichtert die Realisierung einer IT-Governance mit dem Ziel geschäftlicher Agilität. In diesem Sinn erweitert service­orientertes Computing die IT-Governance im Kontext einer SOA. Traditionelle IT-Governance-Prozesse verteilen die Policies der verschiedenen Abteilungen innerhalb der IT auf Anwendungen, Netzwerke und Informationssysteme. Anders bei einer SOA-Governance: hier wird eine Domänenverantwortlichkeit eingeführt. Dabei definiert jede Domäne eine Menge von Services innerhalb eines Business-Kontexts: zum Beispiel eine Anzahl von Business Services wie Kundeninformationen oder Bestellprozesse. Jede Domäne ist für die Anwendungen verantwortlich, die die Services bereitstellen, und für die Wahrung der Service-Schnittstellen zu anderen Domänen. Jede Domäne muss Aufgaben wie Service-Management, Geschäftslogik, Kapselung, Service Level Agreements, Key Performance Indicators oder Datenformate und ihre Transformationen verwalten. SOA-Governance führt in der IT-Abteilung neue Rollen ein. Dies sind: Domänen-Manager, serviceorientierte Domänen-Businessanalysten, Fach­bereichsrepräsentanten, Domänen-Entwickler und Service-Tester. Der ­Domänen-Manager verwaltet Domänen und ist verantwortlich für die ­geschäftlichen Beziehungen zwischen seiner Domäne, den anderen Domänen und den Fachbereichen. Der Busi­ness-Analyst einer Domäne identifiziert, ­abstrahiert und normalisiert (in kanonischen Dokumenten) Business Ser­vices und übersetzt geschäftliche Anforderungen in Service-Definitionen. Der Fachbereichsrepräsentant kom­muniziert geschäftliche Anforderungen und identifiziert Business Services für jede Domäne. Der Domänen-Ent­wickler baut und assembliert die Services entsprechend des SOA Life Cycle. Der Service-Tester prüft die Services auf Konformität mit den vorgegebenen Business-Anforderungen. Personen innerhalb einer Service-Domäne sind für die Entwicklung und Verwaltung von Business Services, die in verschiedenen Anwendungen wiederverwendet werden, verantwortlich. Dies führt zu einer Änderung der Organisationsstruktur bei der Anwendungsentwicklung. Statt Funktionalität für eine Anwendung zu entwickeln, wird nun Funktionalität in einer Service-Domäne erstellt.

Komplexes Management
Voraussetzung einer SOA-Governance ist ein Service-Management. SOA verbindet nicht nur IT und Business, ­sondern erfordert das Zusammen­rücken der beiden Bereiche. Deshalb ­verlangt ein Service-Management eine Business- und eine IT-Sicht. SOA-­Anwendungen sind Composite Applications, die aus Service-Bausteinen ­zusammengesetzt werden. In der ­Business-Sicht wird der Geschäfts­prozess auf höchster Ebene mit seinen Aktivitäten definiert. Aktivitäten sind Services, die als Business Composites das Verhalten der Prozessaktivitäten fachlich beschreiben und vom Business-Prozess orchestriert werden. Die Business Composites werden mit Hilfe von Business Components assembliert und orchestrieren den Ablauf ihrer ­Business Components auf logischer oder fachlicher Ebene. Business Composites und Business Components ­haben Schnittstellen, die auf fachlicher Ebene durch die Definition der kanonischen Dokumenten-Schemas (siehe Teil 1 und 2 dieser Serie) spezifiziert sind und als Implementierungsvorgabe dienen. In der IT-Sicht werden die ­Business Components als IT Compo­sites implementiert und oft auf Basis von Standards – namentlich BPEL – orchestriert und zur Anwendung komponiert. IT Composites wiederum werden als IT Components assembliert und orchestrieren ihre Composites. IT Components können als verschiedene Typen implementiert werden oder ­definieren rekursiv wiederum ein IT Composite. Ein Service-Management über die verschiedenen Ebenen und Sichten ­hinweg ist äußerst kompliziert – man denke nur an die Versionierung und Wiederverwendung der Basiskomponenten bis hoch zu den Business Composites. Deshalb benötigt ein Service-Management komplexe Werkzeuge: etwa eine Registry zur Katalogisierung der geschäftlichen und technischen Services, ein zentrales Repository, das alle Governance-Richtlinien und Metadaten speichert, eine Rules Engine zur Automatisierung der Governance-Prozesse sowie ein Business Activity Monitoring zur Messung bei der Ausführung (siehe Teil 5 dieser Serie).

Offene Fragen
SOA-Governance und -Management sind schwierig und erfordern komplexe Technologien. Viele Fragen sind noch offen: Wie werden Composite Services über Business- und IT-Sicht hinweg verwaltet und wie wird die Versionierung durchgeführt? Wie findet man den gewünschten Business Service und die geeignete Implementierung mit den passenden KPIs? Das erfordert ein Management komplexer Ressourcen. Es ist zu hoffen, dass der Einsatz semantischer Technologien wie des Ressource Description Framework (RDF) zur Beschreibung von Ressour­cen und deren Beziehungen zu anderen Ressourcen sowie des RDF Schema (RDFS) für die Beschreibung von Domänen in absehbarer Zeit hier zum Einsatz kommen und Standards für SOA-Gover­nance setzen.

Dr. Peter Eichhorst ist Chef des IT-Dienstleisters Socon in Dresden und San Diego.