Warum man eine Workflow-Engine braucht

Systeme zur Prozessausführung, meist als Workflow- oder Business-Process-Management-Systeme (BPMS) bezeichnet, können eine zentrale Rolle für die digitale Transformation von Unternehmen spielen. Dennoch gibt es Vorbehalte gegen den Einsatz derartiger Systeme. So gab es in der Vergangenheit oftmals schlechte Erfahrungen mit schwergewichtigen, zentralen Plattformen. Und im Zusammenhang mit modernen Microservice-Architekturen befürchten viele Entwickler, dass ein BPMS die möglichst unabhängigen Microservices zu eng aneinander koppelt.

Bernd Rücker gelingt es in seinem englischsprachigen Buch diese Vorbehalte zu entkräften. Dabei setzt er auf den Einsatz leichtgewichtiger, „Entwickler-freundlicher“ BPMS. Als Mitgründer der Firma camunda verfügt Rücker über jahrelange Erfahrung aus zahlreichen Kundenprojekten. Die Ausführungen in dem Buch sind aber unabhängig von einem bestimmten Produkt für jede Prozessautomatisierungsinitiative relevant.

Meist werden innerhalb eines Prozesses mehrere Systeme und externe Services aufgerufen. Hier bietet ein Workflow-System entscheidende Vorteile gegenüber selbst entwickelten Punkt-zu-Punkt-Verbindungen. Beispielsweise erleichtert es die Behandlung von Fehlern oder Verfügbarkeitsproblemen in lange laufenden Prozessen. Dies wird dadurch möglich, dass das System den Bearbeitungszustand jeder Prozessausführung verwaltet. Damit wird anderem auch das Monitoring der Prozessausführung und die spätere Nachvollziehbarkeit aller durchgeführten Schritte erreicht. Ein wesentlicher Pluspunkt für Workflow-Engines ist zudem die verbesserte Zusammenarbeit zwischen Fachabteilungen und Software-Entwicklern auf Grundlage eines gemeinsamen grafischen Prozessmodells.

Auch die Nachteile des Workflow-Engine-Einsatzes werden nicht verschwiegen. So stellt ein Workflow-System eine weitere Komponente in einer Systemarchitektur dar und erhöht damit die Komplexität. Zudem darf der Einarbeitungsaufwand nicht unterschätzt werden.

Auch in einer lose gekoppelten Microservice-Landschaft können Workflow-Engines sinnvoll sein. Um die Services möglichst unabhängig zu halten wird in einer solchen Architektur häufig eine Ereignis-basierte Kommunikation genutzt. Der Service, der ein Ereignis meldet (z. B. „Zahlung eingegangen“), muss sich nicht darum kümmern, was daraufhin passiert. Ein anderer Service (z. B. zur Versandabwicklung) kann den betreffenden Ereignis-Typ abonnieren und auf jedes Eintreffen reagieren (z. B. einen Warenversand veranlassen).

Mit Hilfe eines solchen Zusammenspiels können komplette Geschäftsprozesse abgewickelt werden. Leider hat dies den Nachteil, dass der Gesamtablauf nicht mehr sichtbar ist. Dadurch werden Änderungen extrem schwierig. Auch ein Fehler oder der kurzzeitige Ausfall eines Service kann zu schwer lösbaren Problemen führen. Die Services sind also gar nicht so unabhängig. Vielmehr sind sie dadurch gekoppelt, dass sie eine bestimmte zeitliche Reihenfolge einhalten müssen. Der Einsatz einer Workflow-Engine erhöht die Kopplung daher nicht. Dafür kann man den Prozess besser managen.

Dabei muss keine Abhängigkeit zu einer zentralen Workflow-Plattform entstehen. Vielmehr kann eine leichtgewichtige Workflow-Engine auch als Komponente innerhalb eines Microservice genutzt werden.

Aber nicht nur das Zusammenspiel von Microservices lässt sich mit einem Workflow-System koordinieren. Auch Abläufe innerhalb eines monolithischen Systems können gesteuert werden. Ebenso lassen sich Benutzer-Tasks, Entscheidungsregeln, Software-Bots und physische Geräte im Internet der Dinge orchestrieren.

Ein weiterer wichtiger Aspekt in dem Buch ist das Zusammenspiel von Softwareentwicklung und Prozessautomatisierung. Ein „Entwickler-freundliches“ Workflow-System kann nahtlos in existierende Werkzeugketten und Continuous-Integration-Abläufe eingebunden werden. Unter anderem lassen sich Prozessmodelle versionieren, und die gewohnten Testwerkzeuge können auch für die Prozesse genutzt werden.

Das zugrunde liegende Entwicklungsmodell sieht dabei so aus, dass der Ablauf grafisch in BPMN modelliert und von der Workflow-Engine ausgeführt wird. Alles andere – wie z. B. Benutzerdialoge, Datenhaltung oder auch der „Glue-Code“ zur Anbindung externer Systeme – wird herkömmlich programmiert. Dies hat den Vorteil, dass man die Programmiersprache und die Programm-Bibliotheken seiner Wahl nutzen kann. Im Gegensatz zu Workflow-Systemen, die dem Low-Code-Ansatz folgen, sind andererseits keine Datenmodellierungstools oder grafische GUI-Builder integriert, die eine durchgängigere Unterstützung bei der Entwicklung einer Prozessanwendung bieten würden.

Zu den weiteren im Buch behandelten Themen zählen unter anderem:

• BPMN als empfohlene graphische Prozessmodellierungsnotation
• Verschiedene Architekturvarianten
• Auswahl und Evaluierung von Workflow-Engines
• Der geeigneter Zuschnitt von Prozessen
• Kommunikation und Transaktionen
• Monitoring, Analysen und Visualisierung
• Mythen im Zusammenhang mit der Prozessautomatisierung
• Zusammenarbeit von Business und IT
• Vorgehen zur Einführung von Prozessautomatisierung

Sehr wertvoll ist es, dass die zahlreichen Empfehlungen ausführlich begründet und anhand von Beispielen gut nachvollziehbar illustriert werden. Da der Schwerpunkt des Buchs auf architektonischen und technischen Aspekten liegt, richtet es sich in erster Linie an Software-Architekten und Entwickler. Andererseits dürfte das meiste auch für Nicht-IT-Experten gut verständlich sein. Daher profitieren auch Business-Analysten und fachlich orientierte Prozessexperten von dem Buch. Auch sie sollten verstehen, welche Auswirkungen bestimmte architektonische Entscheidungen haben. Die Voraussetzung für eine erfolgreiche Zusammenarbeit von Business und IT ist ein gegenseitiges Verständnis der jeweils anderen Seite. Das Buch ist somit jedem zu empfehlen, der in irgendeiner Weise mit Prozessen und ihrer Automatisierung zu tun hat.

---

Bernd Ruecker:
Practical Process Automation.
Orchestration and Integration in Microservices and Cloud Native Architectures.
O’Reilly, 2021
Das Buch bei amazon (Anzeige)