Eigentlich bezeichnet der SOA-Begriff ein Phantom, denn eine verbindliche oder allgemein gültige Definition für eine Service-orientierte Architektur gibt es nicht. Gründe, warum man eine SOA implementieren sollte, werden dagegen zahlreich angeführt. Auch an Fürsprechern mangelt es der Idee nicht. Deshalb ist es kein Geheimnis, dass der Reiz einer SOA in der Möglichkeit liegt, Dienste flexibel zu koppeln. Das wiederum nährt die Hoffnung, die Kluft zwischen IT- und Fachabteilungen wirksam zu überbrücken. Denn immer wenn Fachabteilungen einen IT-basierenden Service zur Unterstützung des Tagesgeschäfts benötigen, ist das bislang mit umständlichen Tickets verbunden, die zumeist eine mühselige Abwicklungsprozedur bedeuten. Das eigentliche Ärgernis ist dabei nicht selten, dass sich beide Seiten einfach nicht richtig zu verstehen scheinen, so dass in langwierigen Sitzungen das tatsächliche Problem und die dazugehörige Lösung mühselig einzukreisen sind.

Und eben das scheint die SOA überflüssig zu machen. Denn man kann ja einfach bereits bestehende Dienste oder zumindest deren Komponenten heranziehen, um andere ähnliche Dienste bereitzustellen. So weit die Theorie, doch der Schein ist auch hier trügerisch. Zwar zeigen viele SOA-Modelle, wie man Komponenten flexibel koppeln oder austauschen kann, wie man jedoch Prozesse mit Geschäftslogiken und Regeln einbinden kann, bleibt ausgespart.

Wer darf wann welchen Dienst erstellen und zu welchem Zweck? Wer darf wann welchen Dienst mit welchem Ziel nutzen? Wie ist dabei vorzugehen? Wie erfolgt die Preisgestaltung der Dienste? Wie definiert und überwacht man Service-Levels? Hierzu bietet SOA keine Hilfe, kein Muster, keine Richtlinie. Zu allem Überfluss sind viele der vorgestellten Methoden auch nur bis zu einem gewissen Grad von den Fachabteilungen nutzbar, denn sie zwingen früher oder später zur Verwendung von Eclipse, Javascript oder sonstigen Software-Entwicklungssystemen zur Erzeugung von ausführbarem Code. Das aber verlangt Fachabteilungen schlicht zu viel ab.

SOA ist "nur" die Basis

Dennoch liefert die SOA eine wesentliche Basis, mit deren Hilfe sich das besagte Problem lösen lässt. Sie kann das Fundament bilden, auf dem man Stammdaten, Geschäftsregeln und Prozesse zu einem Framework zusammenfügen kann. Die Plattform also, mit deren Hilfe die Integration von Prozessen, Regeln und Services gelingen kann. Damit sich die angedeutete Grauzone jedoch beseitigen lässt, bedarf es eines weiteren Schritts: Voraussetzung dafür ist das zugrunde liegende Datenmodell. Dieses muss einheitlich und so beschaffen sein, dass die Datenelemente sehr eng an die Prozesse geknüpft sind.

Nimmt man beispielsweise einen typischen IT-Service wie den Betrieb einer Datenleitung von A nach B, heißt das zunächst, dass Daten zu verwalten sind. Etwa für die Leitung, für die benötigten Endkomponenten oder für die verantwortlichen Ansprechpartner. Jedes dieser Datenelemente "lebt" dabei über seinen Lifecycle-Prozess. Der beinhaltet einzelne Prozesse zum Beispiel zur Inbetriebnahme oder zum Change-Management. Entscheidend dabei ist die enge Verknüpfung von Datenelementen und Lifecycle-Prozessen, die dafür sorgt, dass Prozesse auf Dateninhalte zugreifen können.

Was auf den ersten Blick den Beigeschmack von übergroßer Reglementierung haben mag, schafft in Wahrheit große Freiräume, weil sich Prozesse so sinnvoll konsolidieren lassen. Vor allen Dingen aber führt es dazu, dass Services und Prozesse auch für nicht technisches Personal erschließbar werden. Damit wird nicht nur die Kluft zwischen IT und Fachabteilungen wirksam geschlossen, sondern man schafft ein Framework, das gleichzeitig Produktiv- und Entwicklungsumgebung ist und die Möglichkeit bietet, Applikationen flexibel und bedarfsgerecht zu erstellen.

Diese enge Koppelung von Daten und Prozessen bringt aber noch einen weiteren Pluspunkt, der im Zusammenhang mit dem Thema Revisionssicherheit zum Tragen kommt: Wenn ein eindeutiger Rückbezug der Daten auf die Geschäftslogik über die zugehörigen Prozesse besteht, lässt sich ohne großen Aufwand nachvollziehen, wer wann in welchem Zusammenhang Stammdaten angelegt, verändert oder gelöscht hat.

Vier Säulen eines Soba-Frameworks

Maßgeblich sind für ein Soba-Framework (Gartner-Bezeichnung für Service Oriented Business Applications) vier paritätische Säulen: Prozesse, Daten, Regeln und handelnde Parteien. Diese sind in einem Benutzerportal zu integrieren.

Die Prozessebene dient dazu, Geschäftsprozesse als kollaborativ übergreifende Prozesse und die darin verwendeten Lifecycle-Prozesse der zugehörigen Daten zu verwalten. Hier sind Aktivitäten mit den Anweisungen für die handelnden Personen, Entscheidungsregeln und Transitionen in den gegebenenfalls aggregierten Prozessen definiert und werden vom Prozess-Manager ausgewertet. Der Inhalt der Daten bildet gleichzeitig die Basis für die Entscheidungsregeln, mit deren Hilfe sich die Prozesse steuern lassen. Ist beispielsweise bei der Kenngröße "Auslastung" einer Datenleitung der Wert 80 Prozent als Schwelle bestimmt, tritt mit dem Erreichen dieser Grenze eine automatisierte Entscheidungsregel in Kraft. Zum Beispiel: "Mit dem Bereitstellen einer weiteren Leitung fortfahren".

Hinter der Regelebene versteckt sich ein Repository, in dem die Vorgaben als ablauffähiger Code hinterlegt sind, wobei sich neue Regeln mit einfachen Mitteln aus den bereits bestehenden bilden lassen müssen. Das heißt auch, dass das Repository sich jederzeit ergänzen und verändern lassen muss, um ständig die aktuelle Geschäftslogik verfügbar zu haben, ohne dass Release-Wechsel des Frameworks selbst notwendig sind. Bleibt man im Beispiel der Datenleitung, bedeutet das etwa, dass sich die Abrechnung des Betriebs über die Regeln der verschiedenen Faktoren ableiten lässt. Von Rabatten über technische Kenngrößen wie "genutzte Bandbreite" bis hin zu kaufmännischen Kenngrößen wie "Status der Geschäftsbeziehung". Ändert sich eine Regel, so wird nur der Algorithmus im Repository ausgetauscht, das restliche Framework der Applikation ist davon jedoch nicht betroffen.

In der Datenebene ist das Modell abgebildet, auf dessen Basis sich Daten integrieren und aggregieren lassen, um so das Geschäftsvokabular für alle funktions-, abteilungs- und unternehmensübergreifenden Prozesse in einem Repository zusammenzuführen. In den Metadaten werden die Datentypen und ihre semantischen Beziehungen beschrieben. Über Bildung von Templates aus den Metadaten ist eine weitere Spezialisierung und Individualisierung des Datenmodells möglich, insbesondere auch bezüglich der prozeduralen Beziehungen zwischen Datenelementen und den sie steuernden Prozessen. Beim Betrieb der Datenleitung lässt sich beispielsweise festlegen, welches Configuration Item (CI) "Leitung" mit welchen CIs "Komponenten" von "welchen Personen" in "Betrieb zu nehmen" und "im Betrieb zu betreuen" ist. Diese Beziehungen müssen für den Benutzer möglichst einfach und übersichtlich dargestellt werden.

Als Schnittstelle zum Benutzer fungieren dabei Portale, die die Interaktion mit den Prozessen und Diensten ermöglichen. Hier lassen sich Applikationen und Dienste als Summe von Prozessen orchestrieren, wobei natürlich die Rolle und Verantwortlichkeit der jeweiligen Benutzer in einem Rechtekonzept abgebildet sein muss.

In drei Schritten zum Soba-Framework

Damit stellt sich letztlich die alles entscheidende Frage, wie man zum Aufbau eines Soba-Frameworks vorgehen muss. Im Wesentlichen sind es drei Schritte, die die maßgeblichen Etappen markieren:

• die Definition des Datenmodells,

• die Bestimmung der Prozesse zur Verwaltung der Daten,

• das Festlegen der übergreifenden Prozesse zum Betrieb der Applikationen, die die einzelnen Prozesse aggregieren.

Um das Datenmodell zu definieren, muss man Antworten geben auf Fragen wie:

• Welche Daten sind für den Geschäftsbetrieb notwendig?

• Welche Parameter sind dafür erforderlich?

• Welche strukturellen Beziehungen bestehen zwischen den Datenobjekten?

Daneben gilt es festzulegen, welche Gültigkeitsbereiche die Objekte haben, welche Regeln anzuwenden sind und wie die Daten abgelegt werden müssen.

Beim Dienst "Betrieb einer Leitung" sind Datenelemente für die CIs Leitung mit Kenngrößen wie Bandbreite, Carrier oder Mietkosten zu belegen. Daneben sind für die CIs der Endkomponenten Kenngrößen wie Komponentenklasse oder IP-Adresse zu bestimmen. Damit der Service jedoch reibungslos funktionieren kann, muss man mit umgangssprachlichen Mitteln Beziehungen zwischen diesen beiden Gruppen herstellen. Also etwa nach dem Muster "Zugang über" oder "Steht am Standort". Umgangssprachlich heißt dabei mit den Begriffen aus dem Geschäftsbetrieb. Das ist deshalb wichtig, damit auch Fachabteilungen Dienste konfigurieren können.

Eng damit einher gehen die Prozesse zur Verwaltung der Daten. Dabei ist zum Beispiel zu bestimmen, wie man Datenobjekte erzeugt, wie man sie verändert oder natürlich auch wie man sie löscht. Darüber hinaus ist jeweils zu klären, in welchen Schritten man das tut und wer zuständig ist. Und natürlich muss bestimmt sein, welche Regeln dabei zugrunde liegen.

Um die Prozesse als Teil der Applikationen zu regeln, muss man zunächst bestimmen, welche Datenobjekte benötigt werden. Ferner muss festgelegt sein, welche Aggregationen notwendig sind, in welcher Form der Lifecycle betroffen ist und in welchen Schritten vorgegangen wird. Zudem muss man den Gesamtvorgang dokumentieren, definieren, wer zuständig ist und welche Regeln zur Anwendung kommen. Wesentlich ist natürlich auch, Service-Levels zu fixieren und Eskalationsszenarien zu formulieren.

Der gesamte Vorgang "Betrieb einer Datenleitung" gliedert sich in viele Einzelprozesse. Die fassen einerseits alle Tätigkeiten für diesen Geschäftsvorgang zusammen, also etwa die Bestellung einer Leitung beim Carrier oder die Installation von Endkomponenten. Andererseits enthalten sie auch die Bearbeitung der CI-Stammdaten über ihren ganzen Lifecycle inklusive Beschaffung, Inbetriebnahme oder Change-Management.

Technisch muss die Plattform dazu in der Lage sein, die Datenelemente, Regeln und Prozesse basierend auf dem einheitlichen Datenmodell als Services zu interpretieren, um damit als ein Service-Delivery-Framework zu fungieren. Es bietet eine logische, einheitliche Sicht auf Design, Entwicklung, Komposition oder Bereitstellung von Diensten. Die so definierten Services sind dabei abstrakt in strukturierten Metadaten zu beschreiben, die das Framework interpretiert. Aus den fachlichen Anforderungen entsteht also kein Programmcode, sondern ausschließlich strukturierte Metainformation. (ue)