Wozu braucht man eine Workflow Engine

Heute lassen sich robuste und skalierbare Geschäftsanwendungen in immer kürzerer Zeit erstellen. Möglich ist dies nicht zuletzt seitdem die Java Enterprise Technologie (Java EE) eine neue Stufe als Applikationsplattform erreicht hat. Mit der Version 6 von Java EE hat sich die Softweareentwicklung deutlich vereinfacht. Bei der Entwicklung einer neue Anwendungen kann man sich meist voll und ganz auf die Geschäftslogik selbst konzentrieren. Dinge wie das Datenbankmanagement, der Zugriffschutz oder Schnittstellen wie WebServices treten mehr und mehr in den Hintergrund. Diese Basisfunktionen einer modernen Geschäftsanwendung werden durch Frameworks wie JPA, JAAS oder CDI optimal abgedeckt. Die Folge ist, dass die Entwicklung einer Geschäftsanwendung heute weit weniger Zeit in Anspruch nimmt, als dies noch vor Jahren der Fall war. Vor allem mit Hilfe der Java Persistence API (JPA) ist es heute sehr einfach geworden Geschäftsobjekte aus der realen Welt in einer Geschäftsanwendung abzubilden. Warum sollte man sich also große Gedanken darüber machen, wie der zu implementierende Geschäftsprozess am Ende genau aussieht? Es ist relativ einfach sämtliche Informationen die innerhalb einer Anwendung verwaltet werden müssen auf Attribute der einzelnen Geschäftsobjekte zu ‚mappen‘. Der Zugriff darauf ist aus allen Schichten einer Enterprise Anwendung möglich. Eine auf Basis der Java EE Technologie entwickelte Anwendungen ist darüber hinaus sehr robust und sicher und kann auch auf großen Servern problemlos betrieben werden. Im Grunde kann man also bei der Entwicklung einer neuen Geschäftsanwendung damit beginnen, die einzelnen Informationen die innerhalb der Anwendung verwaltet werden sollen auf entsprechende Geschäftsobjekte abzubilden. Die Geschäftsobjekte können dann mit der entsprechenden Geschäftslogik auf ein Web-Frontend übertragen werden. Technologien und Frameworks gibt es für jeden Geschmack.

Im Grunde also alles klar und einfach? Ja und nein – denn die Mächtigkeit der Java Enterprise Technologie verleitet aus meiner Sicht auch viele Entwckler dazu, die Dinge stark aus einer objekt-relationalen Sicht zu betrachten. Das eigentliche Problem bei der Entwicklung einer Geschäfsanwneudng beginnt aber meist dann, wenn mehr und mehr Informationen über den Geschäftspozess selbst ins Spiel kommen, der bei dieser Herangehensweise kaum Beachtung findet.

Hierzu möchte ich ein typisches Szenario aus der Softwareentwicklung beschreiben:

Es soll eine neue Geschäftsanwendung entwickelt werden, die einen Verkaufsprozess innerhalb einer Vertriebsabteilung unterstützt. Die Anwendung soll Kundendaten (z.b. Name, Email, Addresse) und die Produkte die verkauft werden sollen (Produktbezeichnung, Preis, Menge) verwalten. Der Geschäftsablauf selbst erscheint relativ trivial: Ein Vertriebsmitarbeiter selektiert einen Kunden oder legt diesen neu an, sofern dieser noch nicht in der Datenbank gespeichrt ist. Als nächstes wählt der Anwender ein oder mehrere Podukte aus und fügt diese einem virtuellen Wartnkorb hinzu.

Die einzelnen Funktionen können mit den oben geannten Technologieen relativ schnell implementiert werden.
Aber was passiert nun, wenn neue Anforderungen aus dem Management eintreffen. Zum Beispiel folgende Fragestellungen:

• Welchen Status haben einzelne Verkaufsvorgänge?
• Wann wurde ein Vorgang von einem  Vertriebsmitarbeiter zuletzt bearbeitet?
• Welche Vertriebsmitarbeiter arbeiten an einem Vorgang?
• Wie hoch war der Verkaufspreis für einen Vorgang bevor dieser zuletzt geändert wurde?

Das Problem mit dieser Art von Fragestellungen ist, dass die Informationen dahinter nicht typischer Weise objektorientiert abgebildet werden können. Auf den ersten Blick erscheint es noch relativ einfach: Man fügt ein neues Attribut mit dem Namen ‚Status‘ ein, in dem man den aktuellen Stand des Verkaufsprozesses verwaltet. Auch ein Attribut für den aktuellen Verkäufer ist rasch eingefügt. Aber die Dinge werden schnell komplexer je häufiger Informationen verwaltet werden müssen, die den Verlauf des Verkaufsprozesses dokumentieren, sich also mit dem Lebenszyklus eines Geschäftsobjekts beschäftigen.
Man kann sich hier eventuell noch gut vorstellen eine Liste mit allen Vertriebsmitarbeitern zu speichern, die an einem Verkauf beteiligt waren. Aber was passiert nun, wenn dann auch noch der Status gespeichert werden soll der von einem bestimmten Vertriebsmitarbeiter zuletzt angelegt wurde? Und irgendwann wird es dann richtig anspruchsvoll – meist dann, wenn die Anforderungen scheinbar kaum mehr etwas mit dem ursprünglichen Datenmodell zu tun haben. Auch dazu ein Beispiel:

Es soll sichergestellt werden, dass nur die Vertriebsmitarbeiter aus der Gruppe-A Verkaufsprozesse im Status ‚Bestellt‘ ändern dürfen, mit Ausnahme von Vertriebsmitarbeitern aus Gruppe-B, sofern diese den jeweiligen Verkaufsprozess selbst erstellt haben.

Das sind keinesfalls theoretische Szenarien, sondern Anforderungen an Geschäftsanwendungen wie ich sie selbst erlebt habe.
Es kommt nun die Frage auf: wie soll man diese Art von Komplexität eigentlich abbilden? Und vor allem: was könnte in Zukunft noch an Anforderungen dieser Art auf uns zukommen? Wie soll man sich also darauf vorbereiten?
Genau hier ist der Punkt erreicht, in dem der Sinn einer Workflow Engine deutlich wird.
Eine Workflow Engine oder BPM System liefert eine vollständig andere Sichtweise auf eine Geschäftsanwedung als dies mit Hilfe des reinen Datenmanagements möglich ist. Und dadurch gelingt es, mit Hilfe einer Workflow Engine auch ganz andere Fragestellungen zu beantworten. Für eine Workflow Engine sind nicht die Geschäftsobjekte (Kunde, Produkt, Preis) interessant, sondern die Art und Weise, wie diese Daten entstehen – also der Geschäftsprozess selbst. Man kann sagen, eine Workflow Engine beantworte weniger die Frage welche Daten verarbeitet wurden, sondern vielmehr warum diese Daten verarbeitet wurden.

WIE FUNKTIONIERT EINE WORKFLOW ENGINE:

Zunächst einmal kennt eine Workflow Engine lediglich das Geschäftsprozess Modell und nicht deren Geschäftsobjekte. Es geht also darum, den Prozess formal oder mit Hilfe eines graphischen Tools zu beschreiben. Ein typischer Ansatz ist hier die Erstellung eines BPMN Modells. Das Modell beschreibt wie der Geschäftsprozess aussieht, welche Personen daran mitwirken, und welche Zustände und Aktivitäten in unterschiedlichen Szenarien möglich sind.
Sobald eine Workflow Modell erstellt wurde, kann mit Hilfe einer Workflow Engine ein neue Instanz dieses Geschäftsprozesses gestartet werden. Die Prozessinstanz verknüpft die Geschäftsdaten (Kunde, Produkt, Preis) mit dem Geschäftsprozess (Verkaufsprozess).
Der eigentlich interessante Aspekt darin ist aber die Tatsache, dass die Verwaltung der Geschäftsobjekte und die Verwaltung der Prozessinstanzen durch den Einsatz einer Workflow Engine vollständig getrennt von einander erfolgen kann. Die entscheidende Information welche in einem entsprechenden Geschäftsobjekt gespeichert werden muss, ist der Verweis auf die Prozessinstanz, welche durch die Workflow Engine bereitgestellt wird. Somit speichert die Geschäftsanwendung weiterhin die Daten, der Zustand und die Logik des Geschäftsprozesses wird aber durch die Workflow Engine verwaltet.

In Folge dieser Architektur können jetzt zu einem Geschäftsobjekt zusätzliche Informationen über den Verlauf des Geschäftsprozesses verwaltet werden. Zum Beispiel könnten nun folgende Fragen beantwortet werden:

• Wie ist er aktuelle Status eines bestimmten Verkaufsprozesses?
• Wer ist aktuell für einen Verkaufsprozess verantwortlich?
• Wer hat zuletzt an einem Verkaufsprozess gearbeitet?
• Welche Aktivitäten folgen auf den aktuellen Status?
• Welche Anwender haben aktuell zugriff auf einen Prozess?

Das sind nur einige Beispiele für typische Fragestellungen welche durch den Einsatz einer Workflow Engine beantwortet werden können. Viel wichtiger ist aber die Tatsache, dass durch die Verwendung einer Workflow Engine das Verhalten der Geschäftsanwendung durch Änderungen am Workflow Modell beinflusst werdne kann – Stichwort: Model Driven Development.
Das bedeutet, das in vielen Fällen die eigentliche Anwendung gar nicht mehr von Änderungen der Geschäftslogik betroffen ist und dadurch die Anwendung wesentlich flexibler gemanagt und weiterentwickelt werden kann.

Ich denke das eben beschriebene Szenario zeigt deutlich dass die Notwendigkeit einer Workflow Engine nicht immer zu Beginn einer Softwareentwicklung sichtbar ist. Aber je komplexer eine Geschäftsanwendung wird, desto wichtiger ist aus meiner Sicht der Einsatz einer Workflow Engine um wirklich leistungsfähige Enterprise Anwendungen entwickeln zu können. Und dabei ist es vor allem  wichtig zu verstehen, daas eine Workflow Engine die eigentliche Softwareentwicklung nicht ersetzt, sondern diese auf einer ganz neuen Ebene unterstütz und die Möglichkeiten vielfach erweitert.

Daher meine Empfehlung: Das nächste mal wenn Sie das Attribut ‚Status‘ in eines ihrer Geschäftsobjekte einfügen, halten Sie für einen Moment inne und stellten Sie sich die Frage:
Ist es nicht einfacher eine Workflow Engine einzusetzen?