| Wie granular müssen SOA-Dienste sein? | |
| Servicezuschnitt in der Praxis testen |
1 Kommentar
wo die Probleme beim Zuschnitt von SOA-Services liegen;
wie die Deutsche Post das Thema angeht;
warum ein Service-Portfolio-Management wichtig ist.
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.
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.
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".
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").
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.
