SOA meets BPM

Die Wiederverwendbarkeit von Services ist einer der zentralen Vorteile, die serviceorientierte Architekturen (SOA) versprechen. Nicht nur sollen dadurch bereits getätigte Investitionen in anderen Projekten genutzt werden. Es geht auch darum, Doppelentwicklungen zu vermeiden – all dies mit dem Ziel, die IT Kosten für Unternehmen deutlich zu senken.

Von einem rein technologischen Standpunkt aus betrachtet, birgt die Webservice-Technologie sicherlich die Möglichkeit, Services in unterschiedlichen Szenarien wiederzuverwenden. Wie jedoch stellt sich das in einem betriebswirtschaftlichen oder semantischen Zusammenhang dar?

Da Services betriebswirtschaftliche Prozesse abbilden, sind sie aus Unternehmenssicht dann wieder verwendbar, wenn sie häufig und an mehreren Stellen innerhalb des Unternehmens gebraucht werden. Die Granularität der Services ist somit ein entscheidender Faktor. Insofern gilt die Faustregel: Je feiner die Granularität und je weniger umfassend und spezifisch damit die Funktionalitäten, die der Service zur Verfügung stellt, umso höher ist die Wahrscheinlichkeit, dass er in verschiedenen Zusammenhängen verwendet werden kann. Was heißt dies nun für die Serviceentwicklung?

Bei vielen Projekten lässt sich derzeit beobachten, dass Services eher für spezifische Anwendungsfälle entwickelt werden.Wenn ein Service beispielsweise den kompletten Suchvorgang nach allen Informationen, die innerhalb eines Systems für die Ausführung eines Prozesses nötig sind, zusammenfasst, wird er sich in aller Regel nicht für andere Prozesse einsetzen lassen. Theoretisch wären somit rein technische Services wie z.B. „Lösche Datenbankeintrag“ der richtige Weg, um eine hohe Wiederverwendbarkeit zu gewährleisten. Das aber ist gleich in mehrfacher Hinsicht problematisch: Zunächst wäre bei der Komposition von neuen Applikationen eine Fülle an Services nötig. Der Aufwand, der hierbei entsteht, macht ein solches Vorgehen unwirtschaftlich und widerspricht einer der Grundideen, die hinter dem SOA Konzept stehen - der einfachen und flexiblen Erstellung und Änderung von Prozessapplikationen. Auch aus Kommunikationsgründen macht eine derartige Granularität wenig Sinn. Sind nämlich die Services quasi losgelöst vom betriebswirtschaftlichen Kontext, besteht für die Verantwortlichen auf Geschäfts- und auf IT-Seite keine gemeinsame Diskussionsgrundlage. Eine am Prozess orientierte Top-Down Entwicklung wird so erschwert.

Daher sollten die Services einer SOA betriebswirtschaftliche Funktionalitäten im Idealfall in einer Granularität bieten, die geschäftsobjektgetrieben ist. Diese Vorgehensweise hat folgenden Vorteil: Es wird eine Granularitätsebene für die Services geschaffen, die einerseits prozessunabhängig ist, sich gleichzeitig jedoch an betriebswirtschaftlichen Zusammenhängen orientiert. Dadurch fällt die Verständigung zwischen der Geschäfts- und der IT-Seite leichter und die unterschiedlichen Anforderungen können zu einem besseren Ausgleich gebracht werden. Derart gestaltete Services haben ein hohes Wiederverwendungspotenzial , weil die in einem abgeschlossenen Geschäftsobjekt gebündelten Funktionalitäten mit großer Wahrscheinlichkeit in verschiedenen Prozessen wieder auftreten. Gleichzeitig bleibt der Aufwand bei der Komposition von Applikationen überschaubar, da die Granularität eben nicht so fein ist, dass dafür unzählige Services gebraucht würden. Ein Beispiel für eine solche Serviceoperation wäre das Anlegen einer Bestellung. Die Bestellung ist als Geschäftsobjekt sowohl aus einer betriebswirtschaftlich-fachlichen als auch aus IT-Perspektive ein logischer, in sich geschlossener Vorgang. Auch wenn hinter so einem Objekt aus IT-Sicht eine Vielzahl von funktionalen Operationen steht, können die Mitarbeiter den Service der bekannten Struktur einer Bestellung nach anlegen. Dieser lässt sich in der Folge in verschiedenen Prozessen wiederverwenden.

Doch nicht nur der Serviceschnitt hat in der Praxis einen Einfluss auf die Wiederverwendung. Die Services müssen auch sinnvoll verwaltet werden. Dafür ist es neben einer betriebswirtschaftlich logischen Klassifizierung notwendig, dass die Services betriebswirtschaftlich und technisch schlüssig benannt, durch einheitliche Dokumentationsvorschriften in ihrem Verhalten beschrieben und diese Informationen zentral zur Verfügung gestellt werden. All dies ermöglicht die Suche nach benötigten Services und erleichtert einen Anforderungsabgleich. Das wiederum hilft, Doppelentwicklungen zu vermeiden und stellt letztlich die Wiederverwendung von vorhandenen Services sicher.

Ein weiterer wichtiger Aspekt, der in diesem Zusammenhang ebenfalls beachtet werden muss, ist das Datentypenmodell, auf dem die Services basieren. Im Idealfall sollten die innerhalb eines Unternehmens vorhandenen Services für die gleichen betriebswirtschaftlichen Zusammenhänge auch die gleichen Datentypen und Datenstrukturen (und Namen) verwenden. Auf diese Weise kann ein Mehraufwand durch Mappings und Konvertierungen bei der Komposition der Services verhindert und so die Wiederverwendung von vorhandenen Services attraktiver gemacht werden.

Zusammenfassend lässt sich also Folgendes sagen: Um im Rahmen einer erfolgreichen SOA Strategie Services mehrfach verwenden zu können, ist ein klar regulierter, zentral gesteuerter Governanceprozess nötig, der ein einheitliches Modell für die Serviceentwicklung, deren Verwaltung und die zu verwendenden Datentypen vorgibt.