Denn mittlerweile ist zwar die Einsicht eingekehrt, dass ein Architekturkonzept alleine keine flexibel koppelbaren Dienste schafft. Aber andererseits zeichnet sich auch eine Lösung für viele ins Stocken geratene Projekte ab: SOA braucht Governance. Einen wesentlichen Schritt dazu bildet die methodische Definition von Geschäftsmodellen in Enterprise-Ontologien.
Unzureichende Planung, falsche Erwartungen und ungenügendes Wissen. Das sind wohl die Hauptursachen für die meisten gescheiterten SOA-Projekte. Dabei begann das Missverständnis in den meisten Unternehmen wahrscheinlich damit, dass man SOA für eine Technologie hielt, die einem helfen könne, Dienste zu koppeln oder wiederzuverwenden. Und genau das ist zu kurz gesprungen: SOA sind ein Architekturkonzept – keine Technologie und auch kein Baukasten. Viele Softwareanbieter sind jedoch genau damit durch die Lande getingelt. Das Dumme dabei war nur, dass viele dieser Baukästen entnervte Fachabteilungen zurückgelassen haben, die mit integrierten Entwicklungsumgebungen (IDE), nicht durchgängigen UML-Tools (Unified Modelling Language), ausführbarem Code oder ähnlichen Dingen hantieren sollten, die sie schlicht und einfach überforderten.
Trotzdem müssen die Fachabteilungen natürlich dazu in der Lage sein, ihre Anforderung von Anfang bis Ende möglichst selbst umzusetzen. Genau das macht den SOA-Gedanken ja so attraktiv. Insbesondere auch deshalb, weil die permanent variierenden Anforderungen bislang eines der Haupthindernisse für die informationstechnologische Unabhängigkeit der Fachabteilungen im Geschäftsbetrieb waren.
Im Kern ist SOA letztlich nur eine Blaupause, die es ermöglicht, Geschäftsregeln, Rollen- und Rechtekonzepte so bereitzustellen, dass auch Fachabteilungen diese verbinden und als Dienste anbieten können. Aber SOA liefern eben keine Komponenten, die man irgendwie koppeln oder wiederverwenden könnte.
Methodologie und Execution Engine als Voraussetzung
Damit sich dies in die Tat umsetzen lässt, müssen zwei Voraussetzungen erfüllt sein: Man benötigt eine geeignete Methodologie und eine dazu passende Softwareplattform. Die Methodologie kommt dem vielfach herbeigewünschten Baukasten sehr nahe, denn sie soll Modelle, Verfahren und Werkzeuge vorgeben, um Produkte systematisch zu entwickeln und zu gestalten. Die Softwareplattform ist die entscheidende Komponente für die Anwender in den Fachabteilungen: Damit greifen sie auf die verfügbaren Bausteine zu und erzeugen die gewünschten Dienste. Die Plattform ist also eine ausführende Instanz, die die von der Methodologie bereitgestellten Elemente interpretiert, ohne bei jeder Veränderung Programmcodes zu generieren. Sie kontrolliert somit nicht nur die ablaufenden Prozesse, sondern auch das Zusammenstellen der jeweiligen Modellkomponenten.
Letztere sind sozusagen die Einzelbestandteile der Geschäftsprozesse – also Abläufe, Daten, Regeln, Services und Interaktionen, die man über die Softwareplattform als Gesamtkomposition orchestriert. Damit ein etwaiger Informationsverlust zwischen den Modellen ausgeschlossen bleibt, sollten alle Modelle nach demselben Typ implementierbar sein.
In ihrer Gesamtheit bilden sie ein Unternehmen mit all seinen Entitäten vollständig ab und können als Enterprise-Ontologien bezeichnet werden. Man kann sie als formale und eindeutige Definitionen eines gemeinsamen Konzepts in einem Unternehmen oder eines Teils davon begreifen, die von der eingesetzten Software und mehreren Personen in gleicher Weise verstanden werden. Auf den Punkt gebracht ist eine Ontologie eine formale von Menschen und Maschinen interpretierbare Beschreibung.
Damit sich Enterprise-Ontologien umsetzen lassen, ist eine Methodik für ein passendes maschineninterpretierbares Systemmodell erforderlich. Jedes Enterprise-Modell muss zudem vollständig beschreibbar und durch eine Execution Engine direkt ausführbar sein.
OPM liefert Systemmethodik zur Beschreibung
Eine holistische Systemmodelliermethodik für die Modelle ist beispielsweise die Object Process Methodology (OPM) des Massachusetts Institute of Technology. Um die formale und eindeutige Spezifikation eines in einer Entreprise-Ontologie beschriebenen Geschäftsmodells in einem Systemmodell zu implementieren, genügen die Elemente „Objekte“, „Prozesse“, „Zustände“, „prozedurale und strukturelle Links“ sowie „Relationen zur Spezialisierung und Aggregation“. Die OPM ist so als Methodik reflexiv, das heißt, mit ihren eigenen Mitteln erweiterbar, und damit als Modellsprache vollständig.
Das unterscheidet sie zum Beispiel vom MDE/SCA-Ansatz (Model Driven Engineering/
Service Component Architecture) mit vielen unterschiedlichen Modelltypen, unter anderem der UML, die für verschiedene Aspekte Erweiterungen durch aufgesetzte Methodiken benötigt (zum Beispiel Use-Case-, Klassen- und Aktivitätendiagramm).
Durch ihre wenigen, einfachen Grundmodelle und die Vereinheitlichung von Metadaten und Modelldaten ist ein in OPM definiertes Enterprise-Modell leicht durch eine Execution Engine zu interpretieren. Die zentrale Eigenschaft der Methodik ist die feste Koppelung von Objekten mit den Prozessen, die sie in ihrem Verhalten steuern.
So entsteht ein vollständiges System, in dem Objekte nicht ohne Prozesse transformiert werden und Prozesse ohne Objekte, auf die sie wirken, keine Bedeutung haben. Dabei ist immer verbindlich geregelt, wer gemäß seiner Rolle wann welche Eingriffe vornehmen darf. Im Sinne einer so durch das Aspektemodell erzeugten Governance bilden die Prozesse für die verschiedenen Vorgänge des Geschäftsmodells den Kern der so gebildeten Applikationen.
Fachabteilungen können diese Applikationen nach ihren geschäftlichen Maßgaben modellieren. Dabei müssen sie sich aber eben nicht mit Bits und Bytes auseinandersetzen - denn die bleiben in der IT, die interne beziehungsweise externe Services als Business-Intelligence oder Business-Rules bereitstellt. Die Fachabteilungen können sich so allein auf ihre Zuständigkeit beschränken.
Fazit
Auch wenn ihr Ruf schwer gelitten hat, so hat die SOA-Idee weder etwas von ihrer Berechtigung noch von ihrer Umsetzbarkeit verloren. Eine angemessene Erwartungshaltung kann dabei Wunder wirken. Jedoch nur, wenn man sich bei der Umsetzung nicht auf gefährliches Halbwissen verlässt und eine alte IT-Regel beherzigt: Think big, start small.