Best Practices, Tipps und Expertenempfehlungen zum Thema Service-orientierte Architekturen gibt es zuhauf. Die Erfahrungen der Deutschen Post zeigen unter anderem: Wer eine breit angelegte SOA-Strategie im Unternehmen realisieren will, kommt um ein professionelles Service-Management nicht herum. Damit verbunden sind eine Reihe von Unterstützungsfunktionen, die den Best Practices, Tipps und Expertenempfehlungen zum Thema Service-orientierte Architekturen gibt es zuhauf. Die Erfahrungen der Deutschen Post zeigen unter anderem: Wer eine breit angelegte SOA-Strategie im Unternehmen realisieren will, kommt um ein professionelles Service-Management nicht herum. Damit verbunden sind eine Reihe von Unterstützungsfunktionen, die den gesamten Lebenszyklus von Services abdecken: vom Identifizieren potenzieller Services über das Umsetzen bis hin zum Überwachen der neuen Landschaft. In der Ausgestaltung der SOA übernimmt der Service-Manager eine exponierte Position: Er ist Architekt und Bauleiter in einer Person.

Die Rolle des Service-Managements als einer Art SOA-Architekturbüro kann man durchaus wörtlich verstehen: Services sind in der SOA der Deutschen Post funktionale Bausteine, mit denen der strukturelle Bebauungsplan der Servicearchitektur Schritt für Schritt verwirklicht wird. Dies geschieht weder situativ noch isoliert, sondern immer im Hinblick auf den Beitrag der Services zur Gesamtarchitektur. Um SOA aus dem Business zu treiben, gilt es jedoch auch, den unmittelbaren Geschäftsnutzen im Auge zu behalten. Für ein Vorgehen, das beide Faktoren kombiniert, hat sich bei der Deutschen Post der Begriff Managed Evolution ausgeprägt.

Um seine Gestaltungsaufgaben zu erfüllen, ist das Service-Management auf effiziente Umsetzungsprozesse angewiesen. Das gilt besonders dann, wenn eine SOA-Strategie neu im Unternehmen eingeführt wird. Dabei muss das Team Service-Management-Prozesse in der Organisation etablieren und durch entsprechende Methoden, Rollen und Verantwortlichkeiten unterfüttern. Nur so kann das Service-Management auch seine operative Funktion als SOA-Bauleitung wahrnehmen.

Prozesse des Service-Managements

Services ähneln in gewisser Hinsicht Komponenten. Sie kapseln Funktionen und stellen diese lose gekoppelt und in verteilter Form zur Verfügung. Gleichzeitig gibt es Parallelen zwischen Services und Applikationen, beispielsweise hinsichtlich des Lebenszyklus oder dem Einrichten eines Portfolios. In Bezug auf Letzteres liegt es nahe, für das Service-Management ähnliche Prozesse aufzusetzen, wie sie aus dem Applikations-Management bereits bekannt sind.

Die operative Logik der Serviceerstellung lässt sich dabei prinzipiell in die Phasen Plan, Build, Run und Maintain einteilen. Jeder Service, der einmal als umsetzungsrelevant identifiziert ist, durchläuft insofern zunächst die Stationen der fachlichen und technischen Spezifikation. Im nächsten Schritt folgt das Programmieren und Testen. Das Service-Lifecycle-Management sorgt schließlich für die Versionskontrolle der Services und steuert den Betrieb und die Wartung.

Neben den operativen Aufgaben gibt es strategische und gestaltende Management-Prozesse: Das Service-Portfolio- und das Service-Standards- und Infrastruktur-Management. Sie sorgen dafür, dass sich Services sowohl auf der fachlichen als auch auf der technischen und organisatorischen Ebene in die Entwicklung einer SOA einfügen.

Service-Portfolio-Management

Die Entwicklung und das Management des Serviceportfolios sind eine Kernaufgabe des Service-Managements. Das Portfolio enthält sämtliche Services, die für eine SOA im jeweiligen Unternehmen relevant sind. Eine erste Version des Zielportfolios entsteht bereits aus der Entwicklung einer Service-Architektur. Im Sinne eines SOA-Generalbebauungsplans identifizieren die Verantwortlichen dabei die zentralen Geschäftsobjekte eines Unternehmens, führen sie in Domänen zusammen und beschreiben die verbleibenden Leistungs- oder Servicebeziehungen.

Der auf diesem Weg erzeugte Zielsatz von Services wird nun im Rahmen des Portfolios weiterentwickelt und verfeinert. Dies geschieht primär unter fachlichen Gesichtspunkten; das heißt, die im Portfolio enthaltenen Services sind mit Business-Begriffen beschrieben, kapseln Geschäftslogik und spiegeln die wichtigsten Leistungsbeziehungen des Unternehmens wider.

Die Weiterentwicklung des Portfolios funktioniert ähnlich wie das Aufbauen einer Servicearchitektur. Zum Identifizieren von Zielservices kombiniert die Deutsche Post verschiedene Ansätze: Services werden einerseits top-down aus Geschäftsobjekten und deren Leistungsbeziehungen gewonnen. Andererseits wird dieses Vorgehen durch eine Bottom-up-Analyse auf Applikationsebene sowie eine Analyse der Geschäftsprozesse ergänzt.

Die Steuerung des Portfolios ist dabei zugleich Management- und Gestaltungsaufgabe; sie muss auf das spezifische Unternehmen zugeschnitten sein. Die anvisierte Richtung geben SOA-Konzepte vor: Im Portfolio ist einerseits eine lose Kopplung der über die Services inter-agierenden Domänen anzustreben – die Grundlage für die Modularität und Flexibilität einer SOA. Ebenso wichtig ist andererseits die semantische Integration des Portfolios. Dabei geht es darum, fachliche Kernfunktionen begrifflich zu vereinheitlichen und ohne Redundanzen in Services zu überführen.

Fachliche und technische Spezifikationen

Um das Serviceportfolio robuster zu gestalten und die Services auf die technische Ebene zu überführen, gilt es, deren Spezifikationen weiter auszudifferenzieren. Die Deutsche Post geht dabei nach einem einheitlichen Modell vor, dem so genannten Enterprise Business Object and Service Model (EBSM). Es ermöglicht eine durchgängige fachliche Beschreibung von Domänen, Geschäftsobjekten und Services.

Das EBSM nutzt die Unified Modeling Language (UML) als Beschreibungssprache und erfasst etwa 200 Kern- sowie einige hundert zusätzliche Geschäftsobjekte. Diese sind 13 verschiedenen Domänen zugeordnet, beispielsweise "Kunde", "Leistungserbringung" oder "Abrechnung". Das Portfolio umfasst dabei mehr als 100 Zielservices, die sich wiederum aus einzelnen Serviceoperationen zusammensetzen. Ein solches Modell bietet eine solide Basis, anhand dessen sich die Serviceeinführung nach Kriterien wie dem Geschäftsnutzen, der zu erwartenden Wiederverwendung sowie dem Potenzial zur Komplexitätsreduzierung priorisieren lässt.

Der eigentliche Spezifikationsprozess umfasst danach zwei Schritte. In der fachlichen Spezifikation legen die Verantwortlichen die Input- und Output-Parameter im Rahmen der Servicedefinition fest. Zusätzlich erarbeiten sie nicht funktionale Anforderungen wie zum Beispiel Quality of Service, also Antwortzeiten oder Verfügbarkeit sowie die erforderlichen Service Level Agreements (SLAs). Hinzu kommt das Beschreiben von Policies, Ownership- und Release-Informationen. Die fachliche Servicespezifikation bildet die Grundlage für alle am Prozess der Serviceerstellung Beteiligten. In der technischen Spezifikation werden anschließend plattformspezifische und andere technische Anforderungen festgehalten.

Service-Design-Toolchain

Als durchgängiges Modell erlaubt das EBSM nicht zuletzt eine bruchlose Transformation von den fachlichen Anforderungen an einen Service bis auf die Technikebene. Die Automatisierung der damit zusammenhängenden Arbeitsschritte ist daher ein nahe liegender Gedanke. Die Post nutzt dafür eine MDA-basierende (Model-Driven Architecture) Tool-Chain, die die gesamte Servicespezifikation bis hin zum Erzeugen von Codegerüsten abdeckt.

Die Transformation bis hin zum ausführbaren Code geschieht in drei Schritten: Ausgangspunkt der Service-Design-Toolchain ist erstens das Überführen des EBSM in ein PBSM (Project-specific Business Object and Service Model). Darin wird einerseits die Servicebeschreibung anhand der spezifischen Anforderungen des Projekts beziehungsweise des IT-Systems, das als Servicegeber fungiert, konkretisiert. Andererseits ist die Detailtiefe des PBSM gegenüber dem EBSM reduziert, da nur die für das Projekt relevanten Domänen, Geschäftsobjekte und Services enthalten sind.

Eine ähnliche Transformation folgt im zweiten Schritt. Aus dem PBSM wird dabei das so genannte PSM (Platform-specific Service Model) erzeugt. Auch hier ergänzt das Team die für diese Modellebene erforderlichen Informationen, irrelevante Informationen blendet es aus. Im dritten und letzen Schritt wird das PSM in Codegerüste umgewandelt. Sie bilden die Basis für die Entwicklung von ausführbarem Servicecode. Unterm Strich liefert jede Transformation von einer Modellebene zur anderen eine Grundlage für die weitere Ausarbeitung der Servicespezifikation. Dieses Vorgehen erspart manuelle Eingriffe, steigert die Qualität und beschleunigt den Prozess der Servicespezifikation und -Realisierung.

Implementierung und Lifecycle-Management

Grundsätzlich unterscheidet sich die Implementierung von Services nur wenig von herkömmlicher Softwareentwicklung. Zwei Unterschiede sind trotzdem erwähnenswert: Zum einen lässt sich der Servicecode wie schon beschrieben komplett oder teilweise automatisiert erzeugen - ein Muss besteht hierbei indes nicht. Unabdingbar sind andererseits Testverfahren für Services, die auf ein verteiltes und lose gekoppeltes Umfeld abgestimmt sind. Während Modultests auf einer entsprechend ausgestatteten Entwicklungsplattform laufen können, erfordern Integrationstests eine vollständige SOA-Testumgebung.

Einmal implementiert, bilden Service-Interfaces stabile Elemente einer SOA. Mit der Zeit aber können sich Implementierungsdetails von Services verändern – etwa weil sie durch weitere Funktionen ergänzt oder weil Service-Provider erneuert oder ausgetauscht werden. Damit diese Änderungen auf kontrollierte Weise in eine SOA einfließen, ist ein entsprechendes Lifecycle-Management erforderlich. Operative Hilfsmittel dafür sind fachliche und technische Repositories, die eine Versionskontrolle ermöglichen.

Zusätzlich steuert das Service-Management die Weiterentwicklung von Services. Hierbei gilt es, Services einerseits nicht mit Funktionen zu überfrachten und anderseits funktionale Redundanzen zu vermeiden, sprich: eine angemessene Granularität zu erreichen. Auf welche Weise dies erfolgen kann, stellt die COMPUTERWOCHE in einem weiteren Beitrag der Deutschen Post vor.

Schwerpunkte des Service-Managements

Vergleicht man wie eingangs erwähnt die Rolle des Service-Managers mit der eines Architekten und Bauleiters, fällt eines auf: Die Aufgaben des Service-Managements besitzen klar abgrenzbare strategische und operative Schwerpunkte. In strategischer Hinsicht ist das Portfolio das wichtigste Instrument des Service-Managements. Dessen Entwicklung und Steuerung entscheidet grundlegend über die Ausgestaltung einer SOA.

Die operativen Gesichtspunkte des Service-Managements verhalten sich hierzu nicht wie die Kür zur Pflicht. Im Gegenteil bilden effiziente Prozesse erst die Voraussetzung für weitergehende strategische Gestaltungsaufgaben. Ein solider Handlungsrahmen ist notwendig, um eine effektive Zusammenarbeit der zahlreichen am Prozess Beteiligten zu gewährleisten. Dabei leistet ein gut aufgesetztes Service-Management nicht zuletzt einen Beitrag zur Akzeptanz von SOA im Unternehmen.

Beim Identifizieren und Zuschneiden von Services liegen die Aufgaben des Architekten und Bauleiters am dichtesten beisammen: Die aus der Geschäftslogik heraus betriebene Entwicklung von Services ist und bleibt eine anspruchsvolle Gestaltungsaufgabe. Methoden können dabei unterstützen, sie ersetzen indes nicht Erfahrung und Kreativität des Gestalters. Was also die viel zitierte Mischung aus Kunst und Methode betrifft – zumindest auf diesen Aspekt des Service-Managements trifft die Beschreibung zu.

Mehr zum Thema Service-orientierte Architekturen finden Sie im SOA-Expertenrat der COMPUTERWOCHE. (wh)