Durch SOA sind viele Unternehmen in die Lage versetzt worden, Systeme, Funktionalitäten und Daten in verschiedene logische Schichten zu trennen und Services zu erstellen, die reine Geschäftsfunktionalitäten ohne technischen Ballast bieten. Also Services, die von Fachanwendern verstanden und genutzt werden können. Gleichzeitig gibt es eine Fülle von Services externer Unternehmen, die die Möglichkeit bieten, eigene Applikationen anzureichern. Also wäre es doch nun ein Leichtes, den Fachanwendern all diese Services zur Verfügung zu stellen, damit diese sich mit geringem Aufwand maßgeschneiderte Anwendungen selbst „zusammenklicken“ können.

Ist das eine gute Idee? Ohne eine Governance-Lösung lautet die Antwort mit Sicherheit „Nein“. So gibt es zum Beispiel in der Regel externe Services, die laut Unternehmensrichtlinien nicht genutzt werden dürfen. Oder es gibt Services, für die das Unternehmen Lizenzgebühren bezahlen muss. In beiden Fällen wäre es fatal, wenn Fachanwender unkontrolliert auf solche Services zugreifen und sie sich für eigene Anwendungen zu Nutze machen würden. Die Implikationen solcher Fälle reichen von Sicherheitsrisiken bis hin zu lizenzrechtlichen Fragen. Um ein Unternehmen vor den Gefahren eines solchen „Anwendungs-Wildwuchses“ zu schützen, muss es also Kontrollmechanismen geben, die für die Einhaltung von gewissen Rahmenbedingungen sorgen. Solch ein Kontrollmechanismus schützt Anwender sowohl während der Entwicklungsphase als auch während der Laufzeit einer Applikation vor unautorisierten Zugriffen auf Services jeder Art. Eine Governance-Lösung sollte dem Anwender einerseits aufzeigen, welche Services überhaupt genutzt werden dürfen, und andererseits muss sie dafür sorgen, dass eventuelle Service Level Agreements (SLAs) mit externen Serviceanbietern eingehalten werden.

1. • Beschreibungssicht (Description Focus)
   • Nutzungssicht (Consumption Focus)
   • Implementationssicht (Implementation Focus)
   • Kontrollsicht (Control Focus)

In diesem Zusammenhang haben viele Unternehmen den verständlichen Wunsch, die Geschäftsprozessdienste mit Hilfe eines möglichst zentralen Repositories zu administrieren. Allerdings ist hierbei die dafür benötigte Integration der Service-Metadaten eine nicht nicht zu unterschätzende Herausforderung.

Grund: da in der Regel die Service-Metadaten in recht unterschiedlichen Tool-Umgebungen existieren (z.B. Anwendungsentwicklung, Middleware, Service-Management-Tools, etc.), muss zunächst eine semantische Harmonisierung vorgenommen werden. Ähnlich wie bei der Datenintegration (etwa im Zusammenhang mit Master-Data-Management-Ansätzen) müssen mögliche Inkonsistenzen dieser Service-Basisinformationen erst aufgelöst werden, bevor eine Übertragung in ein zentrales Repository erfolgen kann.

In der Praxis sind unterschiedliche Lösungsmuster für die Metadaten-Integration zu beobachten, die auch kombiniert zum Einsatz kommen können:

1. • Bridging/Federation – das kontrollierte Verteilen von BSR-Metadaten auf der Basis einer standardisierten Beschreibung (führender Standard: XML Metadata Interchange (XMI))
   • Physical Integration – die vollständige (meist tool-gestützte) Integration von BSR-Metadaten in einem zentralen Repository
   • Extraction – der Aufbau eines (meist eigenentwickelten) BSR-Metadaten-„Warehouse“ zu Adminstrationszwecken und für das Berichtswesen
   • View Integration – die virtuelle Integration von BSR-Metadaten auf der Basis eines Portal-Ansatzes

Keines dieser Lösungsmuster bietet eine vollständig optimale Balance zwischen Nutzen und Aufwand. Vor allem die Ausbildung eines zentralen Repositories ist mit erheblichen Investitionen verbunden: neben den vergleichsweise hohen Anschaffungskosten für das zentrale BSR-Software-Tool müssen nicht zu unterschätzende Initialaufwendungen für die semantische Harmonisierung der vorhandenen Service-Metadaten berücksichtigt werden; aus einer reinen ROI-Betrachtung heraus ein häufig schwer zu rechtfertigender Business Case.

Gartner geht davon aus, dass aus rein pragmatischen Erwägungen sich in der Praxis zunächst das Lösungsmuster „Bridging/Federation“ etablieren und mittelfristig gesehen in den meisten Unternehmen in Kombination mit einem der anderen Lösungsmuster auftreten wird.

Fazit: ein „Königsweg“ ist noch nicht in Sicht!

Um die Vorteile einer SOA zu nutzen, ist es zunächst einmal sehr wichtig, einen Governance-Prozess im Unternehmen zu etablieren. Dieser steuert den gesamten Lebenszyklus service-basierter Anwendungen. Er beginnt mit der Analyse der entsprechenden Geschäftsanforderungen, erstreckt sich über die Modellierung, das Design und die Implementierung von Services in dem Enterprise Services Repository, und endet mit der Einführung und der Optimierung der neuen, service-basierten Anwendungen (den sogenannten “Composite Applications”).
In diesem Umfeld kristallisieren sich bei SAP drei neue Rollen besonders heraus: die Rolle eines Business Process Experts (BPX), die eines Enterprise-Architekts sowie die eines Service-Entwicklers. Ein BPX besitzt tief greifendes Verständnis für Geschäftsprozesse und versteht es, die Anforderungen an neue Prozesse, in einer Definition von existierenden und fehlenden Funktionalitäten auszudrücken. Dabei muss ein BPX weit mehr Kenntnisse über den gesamten End-to-End-Prozess besitzen als ein klassischer Prozessberater. Er ist daran interessiert, Prozess-Innovation durch die Möglichkeiten von SOA-Architekturen voll auszuschöpfen.
Ein Enterprise-Architekt hat, neben der Entwicklung der Gesamtarchitektur, einen Fokus auf die logische Sicht der einzelnen Domänen bzw. Prozess-Komponenten. Die Anforderungen wandeln sich von einer klassischen IT-Infrastruktur und Architektur-Konzeption zu einem funktionalen Domänen bzw. Prozesskomponenten-Management. Weiterhin spielt das Service-Portfolio-Management eine zentrale Rolle. Welcher Semantik sollen die Services folgen, damit eine globale Architektur effizient und effektiv realisiert werden kann? Deshalb sind technische Kenntnisse nur die Grundlage, um die Architektur zu verstehen. Erfolgreiche SOA-Plattformen setzen eines voraus: Semantische Standards müssen aus dem Eff-Eff beherrscht und beachtet werden.
Der Service-Entwickler implementiert im Anschluss den sogenannten “Glue Code”. Mit anderen Worten: Er implementiert den Zugriff auf bestehende Funktionalität im Backend-System. Stehen nun alle benötigten Enterprise Services zur Verfügung, kann der Business Process Expert den fertigen Prozess modellieren, ausführen und dem Geschäftsbereich die neue Lösung zur Verfügung stellen.
Die Erstellung service-basierter Applikationen erfordert Kenntnisse und Fertigkeiten im Umgang mit neuen Methoden und modellbasierten Tools. Es hat sich gezeigt, dass der Umfang von Schulungsmaßnahmen in Unternehmen häufig in direktem Verhältnis zu dem Ausmaß die jeweiligen SOA-Initiative steht. Unabhängig davon, wie schließlich ein Entwicklungsplan für eine Organisation aussehen mag, ist es wichtig, dass Mitarbeiter in einem SOA-Projekt sowohl die technischen Standards verstehen und anwenden als auch eine einheitliche betriebswirtschaftliche Semantik zur Beschreibung der Enterprise Services nutzen.
SOA-Plattformen werden nur dann erfolgreich sein, wenn das Bewusstsein der oben genannten Voraussetzungen in den Köpfen der Mitarbeiter etabliert ist und die Verantwortlichen über die notwendigen Fähigkeiten verfügen.

Rolf Schumann, CTO SAP EMEA

1. „Wild West SOA“: Wahllose Verbreitung von Services ohne formelle Rahmenbedingungen
2. „Duplicated SOA“: Wildwuchs durch Duplizierung von Services (statt: „Re-Use“)
3. „Shelfware SOA“: Keine durchgängige Nutzung von Services

Gartner geht davon aus, dass nur auf der Basis eines kontrollierten Governance, die SOA-Ziele – nämlich u.a. konsequente Wiederverwendung und Vermeidung unnötiger Duplizierung – auch erreicht werden können. Zu den wichtigsten Koordinationsaufgaben der SOA-Governance zählen:

• Definition und Anpassung von Geschäftsprozessen, die durch SOA-Technologien unterstützt werden sollen
• Definition, Entwicklung, Zugriff, Ausführung, Betrieb und Wartung von wiederverwendbaren Services
• Identifikation der benötigten Service-Level und entsprechender Zugriffsrechte
• Festlegung der Service-Ownership und einer angemessenen Kostenverteilung
• Bestimmung von Richtlinien und Verantwortlichkeiten für alle SOA-relevanten Tätigkeiten (siehe obige Punkte)
• Messung des Grades der Wiederverwendung und Compliance sowie die Spezifizierung von Anreizen zur permanenten Verbesserung des Richtlinieneinhaltung.

Diese Aufgaben der SOA-Governance werden in vielen Unternehmen in einem sogenannten SOA Center of Excellence (SOA CoE) zusammengefasst. Vor allem für unternehmensübergreifende und grosse Projekte empfiehlt sich ferner eine Erweiterung des Aufgabenspektrums um die Rollen und Verantwortlichkeiten, welche sowohl zentral als auch dezentral innerhalb eines übergreifenden Integration Competence Centers (ICC) wahrgenommen werden:

Abbildung 1: Rollen und Verantwortlichkeiten eines Integration Competence Centers (ICC)

Eine Zusammenarbeit zwischen Fachabteilungen und IT findet in diesem Zusammenhang vor allem innerhalb der Aktivitätenblöcke „Enterprise Architecture“ und „Business Analysts“ statt. Hier werden koordiniert durch das SOA CoE die Rahmenbedingungen für die zu implementierenden Geschäftsprozesskonzepte gemeinsam festgelegt.