Keep informed?
Subscribe for our newsletter now!

Workflow-Engine? Die bauen wir selbst…

Feuer ist ein RisikoEigene Workflow-Engines zu bauen scheint nach wie vor ein angesagtes Thema zu sein. Auch wir sind mit der Fragestellung gerade bei verschiedenen Kunden konfrontiert. Warum man im Jahr 2009 immer noch eigene Engines baut ist mir ein Rätsel, ich will auch kurz sagen warum.

Denn als ich neulich im Zuge der Wochenendplanung die Zitty durchblätterte viel mir der kleine Cartoon zu unserer Linken in die Hände. Und mir drängte sich sofort der Vergleich zu Workflow-Engines auf, auch wenn dies aus sozial-psychologischer Sicht vielleicht bedenklich ist 😉

Fragt man Projekte warum sie Workflow- bzw. Process-Engines selbst bauen möchten hört man häufig:

  • “Wir haben nur ganz einfache Anforderungen, einen ganz simplem Zustandsautomat. Da ist eine Workflow-Engine Overkill.”
  • “Wir müssen die Engine in die eigene Anwendung einbauen.”
  • “Wir haben Produkt x evaluiert und es passt einfach nicht”

Klingt ja soweit auch ganz plausibel, oder? Ich möchte den Argumente jedoch ganz kurz ein paar Gedanken widmen:

Wir haben nur ganz einfache Anforderungen

Mit jedem eingesetzten Produkt oder Framework steigt natürlich die Komplexität. Auch ist die Lernkurve mancher Workflow-Engines nicht gerade flach, gar keine Frage. Ich habe es jedoch schon so oft gesehen, dass mit einem einfachen Zustandsautomaten gestartet wird, meist dann so irgendwie eine Entät/Tabelle pro “Prozessinstanz” mit einer Spalte, die den Zustand angibt. Denn Persistenz und eine Datenbank braucht man ja sowieso.

Aber Moment, wenn ich Wartezustände habe, brauche ich dann nicht auch Timeouts oder Eskalationen?

Oder möchte ich nicht vielleicht von einem Zustand in einen Folgezustand “gehen”, wobei ich eine Entscheidung treffen muss (also ein datenbasiertes exklusives Gateway in BPMN)?

Naja, ok, das bauen wir schon auch irgendwie in den eigenen Zustandsautomat ein. Die Softwareentwicklung hat ja auch vor der Existenz von Workflow-Engines funktioniert. Werkelt man also weiter vor sich hin, möchte man häufig die Prozesse flexibler haben. Also fix ein XML-Format definiert. Eventuell sogar dem Standard XPDL oder bald BPMN 2.0 bedient, aber eher nicht. Ist ja auch wieder zu komplex. Es soll nur bitte der (Produkt-) Manager nicht mit dem Wunsch nach grafischer Darstellung der Porzesse kommen! Wozu auch, XML ist doch eh prima lesbar.

Okay, geschafft. War doch ganz einfach. Und wir haben keine unnötigen Features in unserer Maschine 🙂

Aber wir haben eben leider auch manch anderes nicht unbedingt in unserer Maschine: Skalierbarkeit? Concurrency bedacht? Versionierung von Prozessen? …?

Brauchen wir doch auch nicht, wir haben ja auch nur einfache Anforderungen. Und das Produkt entwickelt sich ja auch nich weiter, wenn man erstmal Begehrlichkeiten nach Workflows geweckt hat? Oder vielleicht benutzt es mal der Kollege an einer anderen Stelle (Hurra, Wiederverwendung)? In meiner Projekterfahrung habe ich auf jeden Fall schon so viele Engines gesehen, die dann doch nach und nach aufgebohrt wurden/werden mussten und am Schluß auch ganz schön leistungsfähig waren. Und dabei ist es dann nicht nur um die Personentage der Entwicklung schade, sondern vor allem um die Wartung. Und im gegensatz zur Neuentwicklung macht die noch nicht mal Spaß.

Wir müssen die Engine in die eigene Anwendung integrieren

Soll die Engine in das eigene Produkt eingebaut werden gelten in der Tat andere Regeln. Viele BPM Produkte und Workflow-Engines sind hier wirklich ungeeignet, wenn auch nicht generell. Das man Integration mit der eigenen Anwendung nicht mit Webservices realisieren möchte, nun das verstehe ich gut. Auch kommen manche Engines als dicke Server daher, mit entsprechenden Installtions- und Hardware-Anforderungen. Und günstig sind die Produkte auch nicht, schon dreimal nicht wenn man sie ins eigene Produkt integriert und weiterverkaufen möchte.

Aber spätestens seit die Open Source Gemeine Process Engines entdeckt hat, gilt dieses Argument nicht mehr. Mit den verschiedenen Vertretern dieser Zunft (Beispielsweise JBoss jBPM, Nova Bonita oder Enhydra Shark) kann eine meist leichtgewichtige Java Engine in die eigene Anwendung problemlos integriert werden. Oft bieten die Engines entsprechend vielseitige Konfigurationsmöglichkeiten, so dass sie entsprechend dem eigenen Bedarf angepasst werden können. Teilweise kann auch die Workflow-Sprache noch angepasst oder erweitert werden.  Konsequent zu Ende gedacht ist dies aktuell auch in der JBoss Process Virtual Machine (PVM), die nur den grundlegenden Zustandsautomat definiert, und keine Sprache. Möchte man also tatsächlich eine eigene Engine bauen, könnte man dies zumindest als Grundlage nehmen um nicht das ganze Rad neu zu erfinden.

Wir haben x evaluiert, es passt nicht

Den Punkt habe ich reserviert, um mir ein bisschen Frust von der Seele zu schreiben 🙂 Evaluieren heißt halt leider mehr, als einen Studi nen Tag ranzusetzen, der das dann auf Anhieb erst mal nicht zum Laufen bekommt. Ich entschuldige mich bei allen, die sich auf den Schlips getreten fühlen (aber wer trägt denn in der IT heute noch Schlips ;-))! Ja, es ist leider wahr, dass gerade die Open Source Engines eine gewisse Einstiegshürde legen. Also mal eben nebenbei aufsetzen ist daher recht schwierig. Man muss sich also ein bisschen Zeit nehmen. Um einmal jBPM als Beispiel zu nehmen: Bisher hatte ich bei keinem Kunden in einem Workshop etwas gefunden, was mit jBPM nicht relativ einfach umgesetzt werden kann. Immerhin sind in die aktuelle Version einige Jahre an Reifeprozess und Erfahrung eingeflossen. Meist erlebt man schon nach einigen Minuten bei der ersten Frage ein “Ah ha”-Erlebnis beim Kunden: “So geht das also. Cool. Ist ja ganz einfach. Zum Glück haben wir das nicht selbst gebaut.”

Natürlich darf man den zweiten Teil des Satzes nicht vergessen: “Das muss man aber wissen”. Ja, stimmt. Da erfordern die Produkte eben leider doch ein bisschen Einarbeitung. Aber aus meiner Sicht ist die Zeit hier deutlich besser investiert als in der eigenen Engine. Denn

  • Die Wartung erfolgt extern,
  • Das Produkt wird weiter entwickelt,
  • Man profitiert von der Erfahrung, die im Produkt steck,
  • Man kann Support kaufen bzw. sich Internet-Foren bedienen und
  • Man bekommt viele Features, die man zu Anfang vielleicht nicht braucht, später aber wichtig werden können.

Zu guter Letzt

Ich kann also nur immer sagen: Bitte, nicht selbst entwickeln! Die Engines bringen einiges mit, was man nicht mal so eben selbst entwickelt. Es ist die Lernkurve fast immer wert! Und diese Engine ist dann eben kein unkalkulierbares Risiko. Um in der Analogie des Comics vom Anfang zu bleiben: ich glaube sogar, dass es zukünftig für viele Anwendungen wichtiger wird, Prozessorientierung besser zu verinnerlichen. Dies würde vielen Anwendungen auch gut tun. Es ist also ein wichtiger Fortschritt, bei dem ich lieber dabei bin als zuzuschauen. Aber klar, muss ich ja sagen, ist ja mein Job 😉

Kurz gesagt: In einer perfekten Welt wird die Engine also vielleicht sogar eine Art Selbstverständlichkeit. So wie OR-Mapper heute. Und es will doch auch keiner mehr ein zweites Hibernate entwicklen, oder?

P.S.

Sollte jemand anderer Meinung sein oder doch einen guten Grund parat haben, warum die Eigenetwicklug sein musste bzw. Sinn macht, lasst es mich wissen!

Already read?

Scientific performance benchmark of open source BPMN engines

Why BPMN is not enough

Decision Model and Notation (DMN) – the new Business Rules Standard. An introduction by example.

New Whitepaper: The Zero-Code BPM Myth

14 Responses

Leave a reply