Wie granular müssen SOA-Dienste sein?

20.11.2007
Von Johannes Helbig und Alexander Scherdin
Den passenden Zuschnitt von Services zu finden, ist erfolgsentscheidend für den Aufbau einer Service-orientierten Architektur.

Das Konzept der Service-Orientierung beinhaltet Aspekte, die immer wieder Anlass für kontroverse Diskussionen bieten. Dazu gehört die Frage nach der richtigen Granularität von Services ? und mit welchen Maßnahmen diese zu erreichen ist. Konkret geht es darum, wie viel oder wie wenig fachliche Funktionalität ein Service zur Verfügung stellen sollte. Von grober Granularität spricht man, wenn in einer SOA nur wenige Services vorhanden sind, die jedoch umfangreiche Funktionen in sich vereinen. Das Gegenteil, feine Granularität, liegt vor, wenn viele Services Funktionen sozusagen in atomarer Form verteilen.

Hier lesen Sie

  • wo die Probleme beim Zuschnitt von SOA-Services liegen;

  • wie die Deutsche Post das Thema angeht;

  • warum ein Service-Portfolio-Management wichtig ist.

Beide Szenarien sind in ihrer extremen Ausprägung alles andere als optimal. Wie zu groß geratene Legosteine können grobgranulare Services neue Bauvorhaben des Business ? respektive die damit verbundenen Anforderungen ? nicht ausreichend flexibel unterstützen. Aber auch eine überbordende Vielzahl feingranularer Services birgt Probleme. Im Sinne von Spezialbausteinen treiben diese sowohl die fachliche als auch die technische Komplexität in die Höhe ? und reduzieren zudem das Potenzial zur Wiederverwendung. Die Granularität hat somit entscheidenden Einfluss darauf, ob zentrale strategische Ziele einer SOA erreicht werden (siehe auch: Die zehn größten SOA-Hürden).

Wann jedoch ein Service ein ausgewogenes Maß an Funktionen bietet, ist schwer feststellbar. Einen absoluten Maßstab, an dem sich die richtige Granularität quasi rechnerisch exakt ermitteln lässt, gibt es nicht. Erst wenn man das Zusammenspiel der Services einer SOA betrachtet, können sinnvolle Aussagen zur relativen Granularität getroffen werden. Die richtige, oder besser angemessene Granularität ist somit Aufgabe eines gezielten Serviceportfolio-Managements (siehe auch: Wie die Post ihre SOA steuert). Welche Faktoren dabei eine Rolle spielen, wird im Folgenden erläutert.

Das Serviceportfolio

Schon bei der ersten Definition des Zielportfolios werden die Weichen für die Granularität der Services gestellt. Ausgangspunkt ist eine bereits in Grundzügen vorhandene Servicearchitektur. Diese gliedert die fachliche Architektur eines Unternehmens in so genannte Domänen und beschreibt Hauptleistungsbeziehungen zwischen diesen. Eine Domäne ist dabei nichts anderes als ein abstraktes Cluster für fachliche Objekte wie "Kunde", "Produkt" oder "Vertrag". Innerhalb von Domänen herrschen enge Interaktionsbeziehungen. Nach außen hin sind Domänen jedoch nur lose gekoppelt ? was gleichzeitig den Ansatzpunkt für Services darstellt.

Daraus resultiert das erste Kriterium für die Identifikation von Services ? und somit auch für eine angemessene Granularität: Als Services kommen nur wesentliche Leistungsbeziehungen zwischen Domänen in Betracht. Umgekehrt heißt das: Nicht jede beliebige Funktion im Unternehmen muss daraufhin überprüft werden, ob sie in Form eines Service abgebildet werden sollte. So gibt es zum Beispiel wenig Sinn, hochspezifische physikalische Algorithmen einer Crash-Simulation innerhalb der Domäne "Entwicklung" eines Automobilkonzerns als Services zu realisieren. Eine Konzentration aufs Wesentliche reduziert von vornherein die Anzahl der Servicekandidaten. So umfasst auch das Portfolio eines vergleichsweise großen Unternehmens wie der Deutschen Post nur etwas mehr als 100 Zielservices, beispielsweise "Kundeninformation".

Redundanzen vermeiden

Jedoch bleibt auch bei einer Beschränkung auf die Hauptleistungsbeziehungen im Unternehmen die Aufgabe bestehen, im Portfolio für eine angemessene Granularität und Passgenauigkeit der Services untereinander zu sorgen. Um dafür einen Maßstab zu gewinnen, sollte schon bei der Entwicklung der Servicearchitektur eine erste, konzeptionelle Version eines Zielportfolios angefertigt werden. Der methodische Weg zur Identifikation der Zielservices führt dabei über eine Analyse der im Unternehmen vorhandenen Fachklassen oder auch Geschäftsobjekte.

Fachklassen beschreiben Objekte wie "Kunde", "Rechnung" oder "Adresse" ? und zwar ausschließlich unter fachlichen Gesichtspunkten. Jede Domäne einer Servicearchitektur enthält dabei einen Satz von Fachklassen, die miteinander in enger Beziehung stehen. In einer Domäne "Personal" wären dies zum Beispiel Fachklassen wie "Mitarbeiter", "Organisationseinheit" oder "Qualifikation". Aus dem Informationsbedarf der weiteren Domänen der Servicearchitektur lassen sich nun Zielservices ableiten. In Bezug auf das gewählte Personalbeispiel wären dies etwa "Personal-Management" oder "Organisations-Information".

Für die Granularität des so erzeugten Zielportfolios ist es von zentraler Bedeutung, die identifizierten Fachklassen eingehend semantisch zu analysieren. Die Meinungen dazu, was zum Beispiel unter einer Fachklasse namens "Kunden-Kontaktdaten" zu verstehen ist, können im Unternehmen leicht auseinander gehen. Im Briefgeschäft der Deutschen Post wird für die Zustellung zum Beispiel vor allem die Anschrift eines Sendungsempfängers im Vordergrund stehen. Der Vertrieb wird hingegen daran interessiert sein, wie man Entscheider innerhalb einer Kundenorganisation erreichen kann. Erst eine semantische Harmonisierung verhindert also, eine Vielzahl redundanter Services zu realisieren, die sich auf dieselbe Fachlichkeit beziehen, ohne jedoch unterschiedliche Sichten auf sie zu konsolidieren. Damit ist semantische Harmonisierung ein probates Mittel, um einem ausgefransten und zu feingranularen Serviceportfolio gegenzusteuern (siehe Grafik "Semantische Harmonisierung").

Konzentration auf relevante Services

Die mit der semantischen Harmonisierung verbundenen Aufgaben werden von vielen Unternehmen noch immer als die schwierigste Herausforderung in einer SOA empfunden. Die sich abzeichnende Herkulesaufgabe einer unternehmensweiten fachlichen Modellierung relativiert sich indes, wenn man versucht, schrittweise vorzugehen und sich ? durch einfache Priorisierung ? auf den Kern der Fachlichkeit des eigenen Unternehmens beschränkt. Dabei erweist sich die Einteilung von Fachklassen in Kategorien, also etwa A-, B- und C- oder sogar projektspezifische Fachklassen, als hilfreich (siehe Grafik "Fachklassen und Services").

A-Fachklassen besitzen dabei die größte Bedeutung. Beispiele sind etwa "Kunde" oder "Marktprodukt". Solche Klassen spielen in vielen Prozessen des Unternehmens eine zentrale Rolle. Mit ihnen verbundene Services wie "Kunden-Information" besitzen somit ein hohes Potenzial zur Wiederverwendung. Während bei der Deutschen Post Zielservices zu fast allen A-Fachklassen definiert sind, finden sich nur für einen Teil der B-Fachklassen zugeordnete Services. Die Priorisierung ist damit ein weiterer Hebel, um ein zu feingranulares Serviceportfolio zu vermeiden.

Für die Deutsche Post hat sich die Unterscheidung von Services und Serviceoperationen bewährt. Serviceoperationen wie "SucheLieferantÜberName" oder "prüfeKundenBonität" beschreiben elementare Informationsbedarfe, die sich auf Daten oder auf Funktionen beziehen können. Services wie zum Beispiel "Lieferanten-Information" oder "Kunden-Information" bündeln Serviceoperationen und helfen, die Übersicht zu behalten, auch wenn die Anzahl der Serviceoperationen im Lauf der Zeit deutlich wächst.

Gerade durch die vielfachen Verwendungsmöglichkeiten werden die auf A-Fachklassen aufbauenden Services im Lauf der Zeit tendenziell immer mächtiger. Um hierbei die Entstehung grobgranularer Services mit einer überbordenden Anzahl von Serviceoperationen zu vermeiden, müssen die Verantwortlichen gegensteuern.

Die auf diese Weise erreichte allmähliche Verfeinerung des Portfolios nutzt letztlich dasselbe methodische Gerüst, das auch beim Identifizieren von Services zum Einsatz kommt. Dennoch hat ein rein architekturgetriebener Ansatz des Portfolio-Managements seine Grenzen. Denn in einem Serviceportfolio müssen sich insbesondere die realen Geschäftsanforderungen eines Unternehmens widerspiegeln. Das Wissen um eine theoretisch hohe Bedeutung von Fachklassen und der daraus abgeleiteten Services muss insofern um Praxiswissen ergänzt werden.

Servicezuschnitt in der Praxis testen

Eine weitere Überprüfung und Konkretisierung des Portfolios sollte daher auf Basis einer Analyse vorhandener Geschäftsprozesse erfolgen. Bei diesem Praxis-Check können zum Beispiel zusätzliche relevante Fachklassen und Servicekandidaten identifiziert werden. Vor allem aber kann die Passgenauigkeit des Portfolios anhand des konkreten geschäftlichen Hintergrunds überprüft werden. Die bereits geleistete statische, architekturgetriebene Analyse wird somit durch eine dynamische Sicht auf Fachklassen und Services ergänzt. Informationsbedarfe aus verschiedenen Geschäftsprozessen können konsolidiert und auf potenzielle Services und Serviceoperationen abgebildet werden. Hiermit ergibt sich auch ein Korrektiv für grobgranulare Services: Nur Serviceoperationen, die ein Unternehmen in mehreren relevanten Geschäftsprozessen benötigt, werden weiterverfolgt. Die übrigen potenziellen Serviceoperationen mögen zwar theoretisch interessant sein, werden aber mangels Praxisbezug und Wiederverwendbarkeit aus dem Portfolio gestrichen.

Prinzipiell lässt sich auch dieser prozessorientierte Ansatz auf konzeptioneller Ebene und unabhängig vom Tagesgeschäft betreiben; er bleibt dann aber zwangsläufig abstrakt. Die Deutsche Post verfolgt daher im Kontext ihrer Strategie der Managed Evolution einen stärker geschäftsnutzengetriebenen Ansatz. Dabei werden fachseitig motivierte Projekte dazu genutzt, vorhandene Services wiederzuverwenden, zu erweitern oder auch neue Services zu realisieren. Die konkreten Projektanforderungen liefern dabei gleichzeitig eine Basis, um das vorhandene Portfolio an der Praxis auszurichten.

Die Auseinandersetzung mit einem spezifischen fachlichen Prozessgebäude im Rahmen eines Business-Projekts führt dabei gleich zu mehreren positiven Effekten: Erstens ist davon auszugehen, dass ein fachseitig gestartetes Projekt hohe Business-Relevanz besitzt, wodurch die entsprechende Ausdifferenzierung des Portfolios auf eine solide, Business-getriebene Grundlage gestellt wird. Zweitens ermöglicht die enge Zusammenarbeit zwischen Projekten und Service-Management eine kontrollierte Entwicklung des Portfolios. Dabei wird sowohl die Integrität des Portfolios als auch dessen Praxisnutzen gefördert.

Methodik durch Erfahrung ergänzen

Ein strukturiertes Vorgehen in der beschriebenen Weise hilft, die Forderung nach angemessener Granularität innerhalb des Portfolios umzusetzen. Auch im Portfolio-Management ist jedoch nicht zuletzt Erfahrungswissen nötig, um einen optimalen Zuschnitt der Services zu erzielen. Dass es zum Beispiel sinnvoll ist, Vertriebskanäle und Kundeninformationen voneinander abzukoppeln, um funktionale Silos zu vermeiden, legt eher die Erfahrung nahe, als die bloße Methodenkenntnis.

Dies gilt auch für zukünftige Anforderungen an eine SOA: Fusionen, neue Marktstrategien oder Outsourcing können bei der Gestaltung des Portfolios ? soweit bekannt ? zwar mitbedacht werden. Der Blick in die Zukunft bleibt IT-Managern indes auch mit SOA verwehrt. Andererseits erlauben die Nutzung einer SOA und der richtige Zuschnitt des Portfolios im Zweifelsfall eine deutlich schnellere Reaktion auf strategische Veränderungen, als dies mit herkömmlichen Methoden möglich wäre.

Nicht vergessen werden sollte bei allen erforderlichen Methoden und Prozessen des Portfolio-Managements, dass SOA einen evolutionären Ansatz darstellt. So startete auch die Deutsche Post ihre SOA auf Basis von wenigen Services. Mit der weiteren Nutzung von SOA im Unternehmen kann die Ausdifferenzierung und Verfeinerung des Portfolios dann Schritt für Schritt erfolgen. Voraussetzung dafür ist, dass parallel funktionierende Prozesse des Portfolio-Managements aufgebaut werden. Mit der zunehmenden Wiederverwendung und Erweiterung von Services wird außerdem ein Lifecycle-Management erforderlich, mit dem die Weiterentwicklung von Services gesteuert wird.

Faustformel gibt Anhaltspunkte

Zu Beginn des Beitrags wurde darauf hingewiesen, dass man Granularität nicht isoliert, sondern im Kontext des unternehmensindividuellen Portfolios betrachten muss. Neben diesem relativen Maßstab gibt es jedoch auch eine empirische Daumenregel, die insbesondere Unternehmen, die mit SOA erst beginnen, Anhaltspunkte geben kann: die so genannte Heuristik der Zehnerpotenzen.

Ausgangspunkt sind die fachlichen Domänen einer Servicearchitektur (siehe Grafik "Faustformel Servicegranularität"): Ihre Anzahl liegt in der Praxis meist in einem Bereich von sechs bis 16. Grob gemittelt können Unternehmen damit von etwa zehn Domänen als Ausgangspunkt für die Entwicklung einer eigenen Servicearchitektur ausgehen. Auch wenn die Zahl der Zielservices pro Domäne variiert, sind zehn Services ein guter Anhaltspunkt. Das Portfolio einer Enterprise-Architektur wird also durch etwa 100 Zielservices beschrieben. Zwar schwankt die Anzahl der Serviceoperationen pro Service im Einzelnen noch stärker. Dennoch sind zehn Serviceoperationen wieder ein guter Mittelwert: Die Anzahl von elementaren, häufig benötigten Informationsbedarfen, die in einem Unternehmen die Basis einer SOA darstellen, liegt also bei etwa 1000.

Das aus dieser groben Faustformel abgeleitete Mengengerüst mit Leben zu füllen bleibt indes eine unternehmensindividuelle Aufgabe. Insofern liegen die entscheidenden Faktoren für eine angemessene Granularität im Service-Management und in der Anwendung der Prinzipien loser Kopplung und semantischer Harmonisierung auf das Portfolio. Der Ansatz der Managed Evolution hilft dabei, Zielservices mit hohem Geschäftsnutzen zu realisieren und gleichzeitig die Integrität des Portfolios voranzutreiben.

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