Da ist diese Abfolge. Eine Abfolge von Webseiten.  Diese immer wiederkehrende Abfolge von Webseiten. Immer wiederkehrende Abfolgen von Dingen nennt man doch Prozess. Und Prozesse kann man mit Hilfe einer Process Engine ausführen.

HEUREKA! Ich steuere meinen Pageflow mit einer Process Engine! Verdammt, bin ich genial! Oder?

Keine Gratwanderung

Wer auf solche Ideen kommt, der ist bei seiner Wanderung auf dem schmalen Grat zwischen Genie und Wahnsinn abgerutscht. Ich verrate aber nicht in welche Richtung ;-)

Natürlich lassen sich mit einer Business Process Engine Abfolgen von Seiten steuern. Aber das ist so, als würde man statische Webseiten als JSPs bereitstellen oder als würde man eine ganze Datenbank zum Speichern von nur einem Boolean nehmen oder als würde man mit seinem SUV zum Brötchenholen fahren.

Eine Process Engine (und ich verwende diesen Begriff ab jetzt bewusst ohne seinen Vornamen Business) ist eben für die Ausführung von Geschäftsprozessen da. Ein Geschäftsprozess besteht aus einzelnen Schritten, die alle zusammen zur Wertschöpfung beitragen. Jeder Schritt stellt dabei eine in sich geschlossene Geschäftsfunktion dar.

Sicherlich kann das Ausfüllen eines mehrseitigen Formulars zur Wertschöpfung beitragen – aber höchstwahrscheinlich nur als einzelner Schritt: „Formular ausfüllen“.

Viele Schritte machen noch keinen Geschäftsprozess

Entscheiden, ob eine Abfolge einen (Teil-)Prozess oder nur eine einzelne Aktivität darstellt, kann man anhand dieser Kriterien:

1. Gibt es mehrere Beteiligte?

• Für jeden Beteiligten muss es mindestens einen eigenen Schritt geben.
• Beispiel: Brief schreiben (Absender) und Brief ausliefern (Postbote)

2. Sind die Arbeitsschritte fachlich abgeschlossen?

• Wenn ein Schritt stets nur mit seinem Nachbarschritt zusammen gemacht werden kann, dann gehören die beiden zusammen.
• Beispiel: Püreepulver in Topf schütten und Püree umrühren

3. Gibt es eine Unterbrechungen zwischen den Schritten?

• Wenn ein Vorgang zwischen zwei Schritten niedergelegt werden kann oder muss, dann sind das auch zwei verschiedene Dinge.
• Beispiel: Pizza in vorgeheizten Ofen legen, (nach 12 Minuten) Pizza aus Ofen nehmen

Diese Kriterien, angewandt auf das Steuern einer Abfolge von Formularseiten, um bei diesem fiktivem Beispiel zu bleiben, ergeben folgendes Bild:

• Es gibt nur einen Beteiligten.
• Das Ausfüllen einer Formularseite ist sinnlos ohne das Ausfüllen der anderen.
• Der Benutzer muss alle Formularseiten am Stück ausfüllen.

Die modellierte Geschäftsfunktion

Sehr gerne wird auch mal eine ganze Funktion in ein Prozessmodell gegossen. Erstens, weil’s geht und zweitens, weil man den Fokus verloren hat ;)

Auch hier kann man die drei Kriterien anwenden und feststellen, dass…

• … es nur einen Beteiligten gibt, nämlich die ausführende Maschine.
• … die Funktion nur als Ganzes einen Mehrwert liefert, während gleichzeitig der Mehrwert ihrer einzelnen Schritte auf die Funktion beschränkt ist.
• … es keinen ersichtlichen Grund gibt, zwischen zwei Schritten eine Pause einzulegen und erst am nächsten Tag fortzufahren.

Always have an Engine?

Das alles zielt aber nur auf die Frage ab: Habe ich einen Geschäftsprozess? Die andere Frage bleibt aber noch unbeantwortet: Brauche ich eine Process Engine?

Das ist eine spannende Frage, aber zum Glück stellt sie sich nur, wenn man überhaupt einen Geschäftsprozess hat. Hat man keinen, braucht man nämlich auch keine Process Engine!

Aber wann ist so eine Engine überhaupt von Vorteil?

Wenn die Beteiligten an dem Prozess Systeme und Benutzer sind, hat man schon mal eine gute Grundlage für den Einsatz einer Process Engine. Anders, als wenn all Beteiligten ihre Aufgaben manuell durchführen, wie beim obigen Beispiel mit dem Pizzabacken. Hier muss man genau hinsehen: Für einen Pizza-Lieferdienst, der Überblick über all seine Bestellungen braucht, mag es Sinn ergeben. Für den ambitionierten Hobby-Pizza-Bäcker nicht. (Ok, ja, es wäre irgendwie cool, aber …)

Das allein ist aber noch kein ausreichendes Entscheidungsmerkmal pro oder contra Process Engine. Bis hierhin hat man gerade mal ein Indiz, ob sich IT-Unterstützung lohnen kann oder nicht. Umsetzen könnte man das trotzdem noch ohne Engine – Ein IF hier, ein ELSE dort, da noch ein GOTO ;), und fertig ist die Prozessimplementierung.

Weitere Vorteile einer Engine liegen außerhalb des eigentlichen Prozessablaufs. Dinge wie Protokollierung der ausgeführten Schritte, Auswertungen, Persistierung von Prozessinstanzen und Zentralisierung fallen hier hinein.

Back button considered evil

Jetzt schließt sich auch langsam wieder der Kreis: Wenn man seinen Pageflow von einer Engine steuern lässt, dann muss man sich den damit verbundenen Problemen stellen.

Das kleinere Übel ist, dass jeder Seitenwechsel von der Engine protokolliert wird. Oder gar nichts. Das ist irgendwie doof und überhaupt gibt es bessere Wege, das Verhalten seiner User mitzuschneiden. Wir stehen da gerne beratend zur Seite :)

Viel schlimmer, ja richtig böse, ist der Back-Button!

Man kann ja nicht einfach von Seite 2 zurück auf Seite 1 gehen, ohne dies der Engine mitzuteilen und deren Urteil abzuwarten! Aber genau das machen Browser! Eigentlich sind Browser böse. Überhaupt, dieses Internet …

Aber mal im Ernst: Das Navigieren in Webseiten hat seine eigene Funktionsweise und ist mehr auf Freiheit ausgelegt und weniger auf Beschränkung. Möchte man das anders haben, sind andere Ansätze besser geeignet. Eine native Anwendung bietet einem alle Möglichkeiten, das Benutzererlebnis durch einen Prozess zu kontrollieren.

Die Single Page Applications im Webbereich sind leider nicht so gut geeignet, denn auch sie laufen im Browser, dem bösen. Dennoch gibt es auch hier Möglichkeiten, eine Verbindung mit einer Process Engine einzugehen, solange man darauf achtet, dass man durch den Prozess nicht die Anwendung selbst steuert, sondern die sie als Sichtfenster auf Prozesse und als Hilfsmittel für die Bearbeitung von Tasks verwendet.

So wie man ja auch mit dem Gaspedal den Motor steuert und nicht andersrum ;-)