In einer Service-orientierten Architektur repräsentieren Services klar definierte Funktionen, die unternehmensweit wiederverwendet werden können. Services leisten damit einen wichtigen Beitrag, um Schnittstellen-Wildwuchs und Komplexität zu reduzieren. Die Modularität von Services bietet zudem die Chance zu mehr Flexibilität, indem starre Verflechtungen zwischen Geschäftsprozessen und IT aufgehoben werden. Im Rahmen einer Service-Architektur stellen Services die spezifischen Leistungsangebote von Domänen nach außen hin in kohärenter Weise zur Verfügung. Die mit Planung, Realisierung und Betrieb von Services verbundenen Management-Aufgaben besitzen folglich eine exponierte Stellung. An der Schnittstelle zwischen Konzeption und Umsetzung, zwischen Fachlichkeit und Technik, ist das Service-Management ein zentraler SOA-Gestaltungsfaktor.
Gegenstand und Bezugspunkt des Service-Managements ist das Service-Portfolio. Durch dieses werden die Entwicklung und das Zusammenwirken der Services einer SOA maßgeblich gesteuert. Die damit verbundenen Aufgaben sind vielfältig. Sie reichen von der Identifikation potenzieller Service-Kandidaten über Planung und Realisierung von Services bis hin zum Management des Service-Lifecycles. All dies erfordert Prozesse und Verantwortlichkeiten, die entsprechend organisatorisch verankert werden müssen.
Integration auf semantischer Ebene
Das Service-Management hat im Kontext einer SOA-Strategie die Aufgabe, ein scharf umrissenes und somit handhabbares Portfolio fachlicher Services zu entwickeln und stabil zu halten. Die Überschaubarkeit eines Service-Portfolios reduziert den Aufwand für das Managen und die Weiterentwicklung individueller Schnittstellen erheblich. Voraussetzung dafür ist, Integrationen auf der semantischen Ebene voranzutreiben, also fachliche Kernfunktionalität redundanzfrei und einheitlich durch Services abzubilden.
Zusätzlich ist das Service-Management dafür verantwortlich, eine lose Kopplung von Services zu erzielen. Denn anders als in der viel zitierten Spaghetti-Architektur, in der alles mit allem verbunden ist, sollen Services modular und flexibel einsetzbar sein. Um dies zu erreichen, muss zweierlei beachtet werden: Einerseits ist Konzentration auf das Wesentliche gefordert - das heißt Services sollten primär Hauptleistungsbeziehungen im Unternehmen widerspiegeln. Andererseits ist der Blick fürs funktionale Ganze gefragt - also auf das Zusammenwirken von Services im Rahmen des Portfolios.
Nicht zuletzt hat das Service-Management eine wichtige strategische Funktion bei der Nutzbarmachung von SOA als Werkzeug zur schrittweisen Transformation von Prozess- und Anwendungslandschaften. Das bei der Deutschen Post dafür geprägte Stichwort heißt Managed Evolution – also die Balance zwischen architektonischen Integritätszielen und Geschäftsnutzen. Das Service-Portfolio fungiert dabei als Zielszenario, das nach Maßgabe des geschäftlichen Nutzens nach und nach von der konzeptionellen Ebene in die Realität überführt sowie immer weiter verfeinert wird.
Ein Blueprint reicht für den Anfang
Grundsätzlich entsteht die erste Iteration eines Service-Portfolios aus der Entwicklung einer Service-Architektur. Die damit zusammenhängenden Aktivitäten wurden bereits im letzten Teil der CIO-Serie zu SOA beschrieben. Die Verfeinerung des Portfolios durch die Identifikation zusätzlicher Ziel-Services bedient sich einer ähnlichen Methodik. Bei der initialen Erzeugung des Portfolios muss nicht unbedingt die sofortige Realisierung von Services im Vordergrund stehen. Ziel ist vielmehr - im Sinne eines Blueprints -, einen möglichst umfassenden Überblick über die zentralen Leistungsbeziehungen im Unternehmen zu gewinnen.
Als Methoden des Target Service Discovery eignen sich dabei sowohl Top-down- als auch Bottom-up-Ansätze. Bei Ersterem erfolgt die Identifikation von Services primär auf der Basis von Geschäftsobjekten und Prozessen. So ist es nahe liegend, dass ein Geschäftsobjekt "Kunde“ über einen Service "Kundeninformation“ verfügen wird, der sich aus verschiedenen Service-Operationen wie zum Beispiel "Suche Kunde über Name und Adresse“ zusammensetzt. Durch das Nachvollziehen der entsprechenden Prozesse rund um das Geschäftsobjekt können weitere Service-Kandidaten identifiziert werden, zum Beispiel ein Qualitäts-Check für Kundenadressen.
Reality-Check fürs Portfolio
Die Autoren unterscheiden zwischen Service-Objekten und Service-Prozessen.Die Kombination aus der Analyse statischer Geschäftsobjekte und deren dynamischen Beziehungen sorgt dabei für Vollständigkeit. Im Sinne eines ergänzenden Bottom-up-Ansatzes können zusätzlich gegenwärtig genutzte Applikationen und deren Funktionalität auf weitere Zielservices überprüft werden. Dies kann zugleich als Reality-Check für das im Vorfeld top-down erzeugte Portfolio dienen. Eine alleinige Nutzung von Bottom-up-Ansätzen verbietet sich, da damit weder eine Vollständigkeit des Portfolios noch die erforderliche Integration auf semantischer Ebene zu garantieren ist.
Die Service-Architektur und das durch Target Service Discovery erzeugte Service-Portfolio stellen gemeinsam einen umfassenden SOA-Bauplan für das Unternehmen dar. Der Weg zur Umsetzung dieses Bauplans führt nun über die Realisierung von Services. Auch dies kann prinzipiell top-down, bottom-up oder in einer Kombination der beiden Ansätze erfolgen. Unabhängig vom gewählten Vorgehen sollte indes die Umsetzungspriorität der im Portfolio enthaltenen Services bekannt sein. Dies kann anhand von Kriterien wie dem Geschäftsnutzen, der zu erwartenden Wiederverwendung und dem Potenzial zur Komplexitätsreduzierung der jeweiligen Services festgestellt werden.
Managed Evolution als Kompromiss
Ein Top-down-Ansatz würde auf dieser Basis mit einer Reihe von Schlüsselprojekten starten, in denen Kern-Services der künftigen SOA gezielt realisiert werden. Im Gegensatz dazu würden bei einem Bottom-up-Ansatz Services eher aus den unmittelbaren Anforderungen von Projekten realisiert. Beide Ansätze haben Vor- und Nachteile, wie zum Beispiel hohe Initialkosten auf der einen oder die Gefahr einer unvollständig ausgebildeten SOA auf der anderen Seite. Die Deutsche Post verbindet daher beide Ansätze und treibt SOA im Rahmen der bereits erwähnten Strategie der Managed Evolution voran.
Services werden dabei nicht durch dezidierte SOA-Projekte realisiert, sondern sehr stark aus Einzelprojekten heraus, die mit oder ohne SOA ohnehin gestartet worden wären. Jedes dieser Projekte wird aus dem Business getrieben und erzeugt unmittelbaren Geschäftsnutzen. Das Service-Management übernimmt dabei eine koordinierende Funktion. Es sorgt dafür, dass in jedem Projekt nach Möglichkeit Services implementiert oder vorhandene Services wiederverwendet werden. Das Zielportfolio gewinnt dabei immer weiter an Substanz, strategische SOA-Integrationsziele werden auf evolutionärem Weg erreicht.
Services unterliegen einem Lifecycle
Dies macht ein Lifecycle-Management erforderlich, das die Entwicklung von Services über die Zeit hinweg verfolgt. Handwerkliche Basis des Lifecycle-Managements sind fachliche und technische Repositories, die eine Versionskontrolle möglich machen. Auf der strategischen Ebene fungiert das Zielportfolio als Maßstab, an dem die Weiterentwicklung von Services ausgerichtet werden kann. Eine isolierte Betrachtung einzelner Services, ohne den Kontext des Portfolios, kann hingegen leicht zu Fehlentwicklungen führen.
Hierbei explizit angesprochen sind auch Fragen nach der richtigen Service-Granularität. Diese zu erzielen erfordert im Kern ein effektives Service-Portfoliound Lifecycle-Management, das auf SOA-Prinzipien fußt. Das Bestreben nach semantischer Integration des Portfolios sorgt dabei dafür, dass fachliche Funktionalität vereinheitlicht und somit einer potenziellen Überlappung von Services entgegengewirkt wird. Im Umkehrschluss wird durch die Umsetzung von loser Kopplung vermieden, dass eine überbordende Anzahl von Services entsteht.
Neben den auf das Service-Portfolio bezogenen Aktivitäten besitzt das Service-Management eine stark ausgeprägte fachliche Dimension. In enger Zusammenarbeit mit dem Business umfasst dies zum Beispiel die Definition von Service-Ownership oder die Entwicklung geeigneter Budgetierungsmodelle für die Realisierung von Services. Auch die Umsetzung von Services beginnt mit der fachlichen Spezifikation und mündet - bei der Deutschen Post im Rahmen einer definierten Service-Design-Toolchain - später in der technischen Spezifikation und Realisierung.
In Bezug auf die operativen Tätigkeiten hat das Service-Management dabei durchaus Ähnlichkeiten mit dem Management von Applikationen. Zum Beispiel müssen effiziente Entwicklungs- und Wartungsprozesse etabliert und nachgehalten werden. Nicht funktionale Anforderungen an Services - zum Beispiel Antwortzeiten oder Verfügbarkeit - müssen definiert und überwacht werden. Und nicht zuletzt gilt es, Infrastrukturen zur Dokumentation und zum Test von Services aufzubauen.
Die erforderlichen Skills für das Service-Management sind in vielen Unternehmen vorhanden, müssen jedoch noch weiterentwickelt und neu ausgerichtet werden. Insbesondere, wenn die Rolle des Service-Managements neu etabliert wird, haben der Aufbau eines stabilen Handlungsrahmens aus Prozessen und Methoden sowie die Definition klarer Verantwortlichkeiten hohe Priorität. Erst wenn diese Voraussetzungen geschaffen sind, kann das Service-Management seine eigentliche Funktion als strategisches Werkzeug zur Transformation von Prozess- und Anwendungslandschaften erfüllen.