Activiti und Imixs Workflow sind zwei Open Source BPM Frameworks auf Basis von Java. Geht es um das Thema Geschäftsprozessmanagement, werden diese beiden Systeme häufig miteinander verglichen. Dabei scheinen die Frameworks auf den ersten Blick dasselbe Ziel zu verfolgen. Dennoch ergeben sich bei genauerer Betrachtung einige Unterschiede, die zeigen, dass die Einsatzgebiete dieser beiden Frameworks sehr unterschiedlich sein können. Bei Activiti handelt es sich – ähnlich wie JBoss BPM – um eine sogenannte Process Engine. Imixs Workflow stellt dagegen – wie der Name schon sagt – eine Workflow Engine bereit. Auch wenn die Begriffe BPM und Workflow oft synonym verwendet werden, unterscheiden sich die Konzepte und Zielsetzungen dahinter doch in einigen Details. Im folgenden sollen die Unterschiede zwischen Activiti und Imixs Workflow aufgezeigt werden.
ACTIVITI – DIE PROCESS ENGINE
Bei einer Process Engine wie Acitiviti oder auch JBPM von JBoss handelt es sich um Systeme zur Ausführung und Überwachung von Geschäftsprozessen anhand eines Prozessmodells. D.h. es wird zunächst in einem technischen Modell (meist in Form eines BPMN Modells) ein bestimmter Prozessablauf möglichst detailliert beschrieben. Die Process Engine kann anhand dieses Modells dann eine einzelne Prozessinstanz durch das Prozessmodell leiten, ohne dass hierfür zwingend ein Eingreifen von außen nötig wird. Dabei bilden die einzelnen Knoten und Verzweigungen des Prozessmodells den Fahrplan für die Prozessinstanz ab. Jeder Knoten und jede Verzweigung enthält Informationen darüber, wie die Prozessinstanz weitergeleitet werden muss. Dies kann anhand eines Beispiels verdeutlicht werden. Nehmen wir einen Prozess zur Bonitätsprüfung von Kunden. Ziel dieses Prozesses soll es sein, vor dem Versand einer Warensendung an den Kunden dessen Bonität zu prüfen. Ein Prozessmodell einer Process Engine könnte dabei wie folgt aussehen:
Der Prozess durchläuft für jede Kundenbestellung zunächst drei Prüfschritte und entscheidet dann ob es zur Warenlieferung kommt, oder ob der Auftrag storniert werden muss. Die Process Engine kann dabei eine neue Prozessinstanz vollautomatisch durch den Prozess leiten. Daten wie Kundennummer oder der Warenwert werden dabei genutzt, um die einzelnen Prozessschritte auszuführen. Jeder Prozessschritt ist dazu mit einem Programmblock des Softwaresystems verknüpft, welcher durch die Process Engine automatisch aufgerufen wird. Dabei durchläuft also der Prozess die einzelnen Teilschritte bis der Endpunkt erreicht wird – also die Warenlieferung freigegeben oder abgelehnt wird. An dieser Stelle wird der Prozess dann angehalten und persistiert (z.b. in einer Datenbank). Da es nicht immer möglich ist, eine Prozessinstanz vollständig automatisiert durch den Prozess zu routen, kennen Process Engines das Konzept der Events. Dabei handelt es sich um bestimmte Ereignisse, welche eintreten müssen bevor eine Prozessinstanz an einer bestimmten Stelle weiter geroutet werden kann. Beispielsweise könnte der Teilschritt ‚Kreditlimit prüfen‘ solange angehalten werden bis durch ein ERP System die notwendigen Daten bereitgestellt wurden. Erst dann wird die Process Engine den Vorgang an dieser Stelle fortsetzen. Weitere Beispiele für Ereignisse sind das Eintreffen einer Email oder das Warten auf eine Benutzereingabe durch den Anwender.
In jedem Fall ist jedoch die Process Engine für die Ausführung des Prozesses verantwortlich. Erst wenn sämtliche Stufen des Prozesses technisch korrekt durchlaufen wurden und sämtliche dafür notwendigen Bedingungen erfüllt wurden, kann der Prozess abgeschlossen werden.
Da eine Process Engine also einen genau beschriebenen technischen Ablauf durchführen und überwachen kann, werden solche Systeme sehr häufig in Softwaresystemen mit komplexen Ablaufsteuerungen eingesetzt. Welche konkreten Funktionen und Programmaufrufe mit den einzelnen Prozessschritten verknüpft sind, entscheidet hier der Softwareentwickler, der das Prozessmodell in ein entsprechendes Softwaresystem integriert.
IMIXS – DIE WORKFLOW ENGINE
Anders verhält es sich nun bei einer Workflow Engine. Eine Workflow Engine verwaltet die Geschäftsprozesse weniger als einen technischen Ablauf innerhalb eines Softwaresystems, sondern vielmehr als Arbeitsabläufe (sogenannte Workflows) innerhalb eines Unternehmens. Im Gegensatz zu einer Process Engine werden bei einer Workflow Engine dazu die einzelnen Arbeitsschritte aus betriebswirtschaftlicher Sicht beschrieben, die bei der Durchführung des Geschäftsprozesses im Vordergrund stehen. Die Workflow Engine wird dazu meist in ein System eingebettet, das die einzelnen Arbeitsschritte verwaltet – das Workflow Management System.
Auch beim Einsatz einer Workflow Engine wird zunächst ein bestimmter Geschäftsprozess anhand eines Prozessmodells – dem Workflowmodell – beschrieben. Es wird aber dabei nicht beschrieben, wie eine einzelne Prozessinstanz durch den Geschäftsprozess geroutet werden muss, sondern welche Arbeitsschritte zur Durchführung des Geschäftsprozesses ausgeführt werden müssen. Es geht bei Workflow Management also weniger um den technischen Ablauf eines Prozesses, sondern vielmehr um den Arbeitsablauf aus betriebswirtschaftlicher Sicht. Ein Workflow Modell beschriebt dazu sämtliche Arbeitsschritte, welche notwendig sind, um ein zuvor definiertes betriebswirtschaftliches Ergebnis zu erzielen. Nehmen wir auch hier wieder den Prozess der Bonitätsprüfung. Im Gegensatz zur rein technischen Beschreibung des Prozesses in einem BPM System wird in einem Workflow Management Systemen beschrieben, welche Personen wann welche Arbeitsschritte durchführen müssen, damit der Prozess das gewünschte betriebswirtschaftliche Ergebnis herbeiführt. Ein Prozessmodell einer Workflow Engine könnte dabei wie folgt aussehen:
Die Aufgabe des Workflow Management Systems ist es hier ein bestimmtes Maß an Kundenzufriedenheit sicherzustellen und zu vermeiden, dass ein Kunde bei Überschreiten des Kreditlimits aus dem Verkaufsprozess „herausfällt“.
Dazu stellt ein Workflow Management System bereits eine Vielzahl typischer Funktionen zur Bearbeitung von Arbeitsabläufen bereit. Zum Beispiel:
- Welche Aufgaben werden derzeit von einem Mitarbeiter bearbeitet
- Was ist aus fachlicher Sicht bisher in einem bestimmten Geschäftsprozess getan worden
- Wer wird als nächster informiert (z.b. per Email)
- Welche Personen im Unternehmen haben Zugriff auf eine Vorgang
- Von wem wurden welche Geschäftsprozesse gestartet und wer kann einen bestimmten Vorgang bearbeiten
Das Workflow System unterstützt also Anwender und Unternehmen bei der Durchführung von Geschäftsprozessen. Die Ziele solcher Systeme sind unter anderem:
- Bereitstellung von Aufgabenlisten für Mitarbeiter
- Lückenlose Dokumentation des Geschäftsprozesses
- Sicherstellung eines zuvor definierten Bearbeitungsweges
- Einleiten von neuen Arbeitsschritten bei abweichendem Geschäftsprozess
Das Workflow System sammelt also zum einen Informationen über den Verlauf der Prozesse und stellt zum anderen diese Informationen rechtzeitig den jeweils verantwortlichen Mitarbeitern im Unternehmen zur Verfügung. Dadurch steuert und überwacht das Workflow Management System die einzelnen Vorgänge im Unternehmen und hilft das eigentliche betriebswirtschaftliche Ziel – hier der Verkauf des Produktes – zu optimieren.
BPM ODER WORKFLOW?
Anhand dieser beiden Beispiele wird deutlich, dass es nicht darum geht, ob ein Geschäftsprozess mit Hilfe einer Process Engine wie Activiti oder mit Hilfe eines Workflow Systems wie Imixs Workflow implementiert wird, sondern vielmehr um die Frage, wie die technischen, als auch die betriebswirtschaftlichen Aspekte eines Geschäftsprozesses optimal erfüllt werden können.
Dabei kann der oben beschriebene Geschäftsprozess durchaus problemlos mit beiden Technologien abgebildet werden. Welchen Schwerpunkt man bei der Umsetzung setzt, bleibt letztendlich dem Anwender überlassen.
Wenn dazu beide System zum Einsatz kommen, handelt es sich aber keineswegs um einen Architekturfehler, sondern vielmehr um das Zusammenwirken zweier unterschiedlicher Technologien. Und dies ist in der modernen IT ein durchaus typischer Geschäftsprozess.