SOA-Forschung für die Geschäftspraxis

Service-orientierte Architekturen (SOA) sind extrem anspruchsvoll, weil die Business-seitig analysierten und definierten Geschäftsprozesse von der IT in sogenannt orchestrierte oder choreografierte Services umgegossen werden müssen.
Jana Koehler, Manager Business Integration Technologies am IBM-Forschungslabor in Rüschlikon, untersucht mit ihrem Team genau die Probleme, die sich beim Herausarbeiten einer Service-Choreografie auf der Basis von Business-Prozess-Modellen
ergeben.

In ihrem Paper «The Role of Visual Modeling and Model Transformations in Business-driven Development» schicken Koehler und ihre Mitautoren voraus, dass eine einfache und direkte Umsetzung höchstens in isolierten «Spielzeug-Beispielen» funktioniert. Für realistische SOA-Applikationen, die diese Bezeichnung auch verdienen, sind zahlreiche Hürden methodologischer und technischer Art zu überwinden.
Die Forscher in Rüschlikon arbeiten seit 2001 an entsprechenden Lösungen, die selbstredend auch in die Tools und in die Middleware von IBM einfliessen. Grundsätzlich beruft sich Koehler auf Business-driven Development (BDD), eine agile Software-Entwicklungsmethode für IT-Lösungen, die direkt den Geschäftsanforderungen entsprechen.

Business-driven Development

BDD setzt sich aus den fünf Phasen Modellierung, Entwicklung, Einsatz, Überwachung sowie Analyse & Adaption zusammen. Während des BDD-Prozesses fliessen permanent Geschäftsanforderungen hinunter auf die IT-Ebene und IT-Anforderungen hinauf auf den Business-Level. In der Theorie klingt das einfach und unkompliziert, in der Praxis jedoch entpuppt sich diese Top-Down/Bottom-Up-Synchronität als höchst herausforderungsreich.

Wie Koehler hervorhebt, verträgt sich nämlich ein Business-Prozess-Modell, das aufgrund von Geschäftsanforderungen und -zielen erstellt wurde, nicht unbedingt mit einer skalierbaren, zuverlässigen und leistungsfähigen Choreografie wiederverwendbarer IT-Services. Das rührt daher, dass zwischen dem Blickwinkel eines Business-Analysten und der Wirklichkeit heutiger Programmier-Modelle und Software-Engineering-Ansätze eine riesige Lücke klafft. Ausserdem lässt sich eine Service-Choreo­grafie, die in einem Top-Down-Ansatz aus einem Business-Prozess-Modell abgeleitet wird, möglicherweise nur schwer oder gar nicht mit einer bestehenden IT-Infrastruktur integrieren. Dies wiederum liegt daran, dass zwischen einer zwar «ideal», aber abstrakt gestalteten neuen Lösung und der realen IT-Infrastruktur mit ihrer Software, Hardware und Netzwerk-Topologie ebenfalls Welten liegen können.

DAS Modell gibt es nicht

Die Crux liegt dabei laut Koehler in der weit verbreiteten Überzeugung, dass es so etwas wie DAS Modell eines Geschäftsprozesses gibt. Mit anderen Worten: Dass ein einziges Modell den Prozess beschreibt und dass dieses Modell sowohl dem Business-Experten als auch dem IT-Spezialisten gerecht wird, der den Geschäftsprozess implementieren soll. In ihrer Forschungsarbeit kamen die Rüschlikoner aber zu dem eindeutigen Schluss, dass diese Annahme höchst unrealistisch ist.
Sie betonen deshalb die Notwendigkeit, das Analyse-Modell und das Design-Modell eines Geschäftsprozesses klar voneinander zu trennen. In der Objekt-orientierten Programmierung ist ein analoges Vorgehen heute gang und gäbe. Sodann muss eine Schritt-für-Schritt-Methode entwickelt werden, die einen möglichst bruchlosen Übergang vom Analyse zum Design-Modell eines Geschäftsprozesses ermöglicht.

Vom Analyse- zum Design-Modell

Anhand eines Zahlungsanspruchs an eine Versicherung erläutert Koehler das Problem der beiden Modelltypen. Bei der Versicherung besteht dabei der sehr vereinfachte Geschäftsprozess aus Business-Sicht aus den drei Unterprozessen Informationsbeschaffung, Fallaufzeichnung und Fallerledigung. Daraus ergibt sich ein klassisches Analyse-Modell des Prozesses, dass komplett von IT-Aspekten absieht, für Simulationen und Diskussionen mit Business-Analysten aber durchaus verwendet werden kann.
Damit der Prozess für die IT relevant wird und implementiert werden kann, muss ein erstes Design-Modell erstellt werden, in dem der Datenfluss sowie Entscheidungs- und Zusammenführungspunkte explizit gemacht werden. Dies geschieht teilweise automatisch mit Tools wie beispielsweise dem WebSphere Business Modeler von IBM. In einem manuellen Top-Down-Schritt wird der Fluss von Geschäftsinformationen sichtbar gemacht –und in einem ebenfalls manuellen Bottom-Up-Schritt werden bereits in der IT-Infrastruktur vorhandene Datenstrukturen durchgesehen. Dadurch können wiederverwendbare Datentypen zum Vorschein kommen, welche die benötigten Geschäftsinformationen beinhalten und den Prozess weitertreiben.

Falls ein solches erstes Design-Modell einen zyklischen Prozess darstellt oder beinhaltet, ist es allerdings für die Programmierung mit BPEL (Business Process Execution Language) nicht geeignet. Denn BPEL unterstützt keine unstrukturierten Zyklen, sondern offeriert klar strukturierte Loops in Gestalt von «while»-Aktivitäten. Mit anderen Worten: Das erste Design-Modell muss so umgestaltet werden, dass alle Prozess-Aktivitäten, die von einem Zyklus tangiert werden, in einen Loop eingekapselt sind.
Daraus resultiert im Versicherungs-Fallbeispiel jetzt ein Design-Modell, aus dem mit BPEL und WSDL (Web Service Description Language) automatisch Runtime-Code generiert werden kann. Dieses Design-Modell eignet sich aber kaum mehr als Anschauungsmaterial für Business-Verantwortliche. Allerdings sind die schrittweisen Transformationen des Modells von der Business-Sicht über eine erste Design-View bis hin zum kompletten Design-Modell absolut notwendig für die Wiederverwendung von existierenden Services und Datenstrukturen.

Business-driven Development im Zentrum

Investitionen schützen

Die grosse Herausforderung auf dem Weg zu einer modernen SOA besteht eben gerade darin, gleichzeitig möglichst viele der von den Anwenderunternehmen bereits getätigten Investitionen zu schützen. Koehler und ihre Kollegen haben deshalb in ihrer BDD-Forschung von Beginn an grossen Wert auf konkrete Anwender-Szenarien gelegt. Einen wesentlichen Teil ihrer Arbeit widmen sie dem Einsatz von Prozess-Modellen in der Praxis.
Im Zentrum ihrer BDD-Methodologien steht die Unterscheidung zwischen vier Prozess-Modelltypen. Neben den bereits erwähnten Analyse- und Design-Modellen untersuchen sie auch die Erstellung und den Gebrauch von Referenzmodellen und sogenannten Legacy Process Models. Erstere beschreiben Best Practices für eine bestimmte Branche. Letztere sind Prozessmodelle, die eine Anwenderfirma bereits erstellt hat, die aber nur indirekt und als Input für einen Software-Entwicklungsprozess gebraucht wurden. Die Investitionen in diese alten Modelle sollen erhalten werden.

Allerdings müssen die Modelle verbessert werden, damit sie als Ausgangspunkt für künftigen Qualitäts-Code und entsprechende Architekturen dienen können. Zu diesem Zweck importieren die Forscher die Legacy-Modelle in ihre eigenen Tools und strukturieren sie um. Dabei werden oft semantische Fehler zutage gefördert, die dann korrigiert werden.
Die Referenzschemen wiederum können dabei helfen, bessere Modelle zur ­«ToBe»-Analyse zu erstellen. Zudem dienen sie quasi als Wegbereiter bei der Verfeinerung der Analyse-Modelle bis hin zu den Design-Modellen. Dies ist vor allem dann der Fall, wenn das Referenzmodell nicht nur Prozesse, sondern auch gebrauchsfertige Service-Komponenten und Datenmodelle enthält. Ein anschauliches Beispiel dafür ist etwa die IBM Insurance Application Architecture, ein Referenzmodell-Repository für die Versicherungsbranche. Die systematische Verwendung von Referenzmodellen für die Verbesserung existierender Geschäftsprozesse ist aber eine anspruchsvolle Sache, wenn sie über simple Sandkastenspiele hinausgeht.

Bestimmte Transformationen von Prozess-Modellen können vollständig automatisiert werden. So etwa die Kontrollfluss-Extraktion, die ein Datenfluss-Modell in ein Kontrollfluss-Modell umwandelt, oder umgekehrt das Data Container Assignment, das ein Kontrollfluss-Modell in ein Datenfluss-Modell verwandelt. Auch das oben erwähnte Entfernen von Zyklen läuft automatisch ab. Andere Transformationen, die häufig Verfeinerungsschritte am vorliegenden Modell erfordern, muss der Anwender selber durchführen.
In ihrer methodologischen Arbeit entwickeln Koehler und ihr Team detaillierte Richtlinien, die vorzeichnen, wie manuelle und automatische Schritte ineinander übergehen, wann sie ausgeführt werden und warum.

Bottom-Up und Top-Down

Spezielles Augenmerk richten die Forscher dabei auf das Ineinandergreifen von Bottom-Up- und Top-Down-Entwicklungsschritten, also die Problemstellungen, die entstehen, wenn Business-Ansprüche nach unten fliessen und IT-Ansprüche nach oben. Zentral sind in diesem Zusammenhang die Service- und die Prozess-Identifikation. Dabei geht es darum, die richtige Granularität von Services festzulegen und sich über deren Wiederverwendung möglichst früh im Software-Entwicklungsprozess Gedanken zu machen. Gemäss Koehler ist die Service- und Prozess-Identifikation beim heutigen Stand der Dinge noch zu wenig durchdacht und weit davon entfernt, eine gut strukturierte und vermittelbare Materie zu sein.
Einen methodologischen Schwerpunkt der Rüschlikoner Forschung bilden auch die Fragestellungen, die sich aus der Verwendung verschiedener Formen von Modellen ergeben. Traditionellerweise wurden Geschäftsprozesse meistens in Flussdiagrammen dargestellt. Heute liegt es im Trend, diese mit Business-Objekten und Business-Status-Maschinen zu verknüpfen. Deshalb eröffnen die semantischen Beziehungen zwischen den diversen Formen von Modellen und ihre Rolle in Geschäfts- und Programmier-Modellen Koehler ein hochinteressantes und breites Forschungsfeld.

Analyse-Modell fürs Business, Design-Modell für die IT