Geschäftsprozesse sind ein zentrales Element betrieblicher (und auch vieler anderer) Anwendungen. Camunda bietet die Möglichkeit, Geschäftsprozesse explizit zu modellieren sowie auszuführen und ist damit zu einem beliebten Werkzeug bei der Digitalisierung von Geschäftsprozessen geworden. Wir haben in den letzten Jahren mehrere Projekte mit Camunda umgesetzt, von denen wir hier vier vorstellen möchten (natürlich anonymisiert). Die Projekte unterscheiden sich stark in ihren Anforderungen und auch in der Art der Verwendung von Camunda und zeigen so die vielseitigen Einsatzmöglichkeiten von Camunda auf.

Im folgenden gehen wir kurz auf die Anwendungsfälle ein und diskutieren die Unterschiede sowie Vor- und Nachteile der unterschiedlichen Einsatzszenarien. In weiteren Beiträgen werden wir dann einzelne Szenarien genauer beleuchten.

Szenario I: Vom SAP-Altsystem zur modernen Webanwendung

In diesem Szenario starteten wir mit einem bestehendem SAP-System, das bereits die Abläufe des Prozesses in Teilen abgebildet hat. Der Prozess war aber bei weitem nicht vollständig digitalisiert. Es gab weiterhin Laufzettel und Checklisten, die von Mitarbeitern abgearbeitet wurden. Wie man sich vorstellen kann, war der Prozess fehleranfällig und es kam immer wieder zu Verzögerungen und steckengebliebenen Prozessen. Kunden beschwerten sich regelmäßig und es war nicht möglich, das Angebot zu skalieren und das volle Geschäftspotenzial auszunutzen.

Damit war die Entscheidung klar: Es sollte eine moderne Webanwendung entwickelt werden, die das bestehende System Schritt für Schritt abgelöst und den Prozess komplett abbildet und steuert. Während der Übergangsphase sollte es möglich sein, mit beiden Systemen parallel zu arbeiten und bei Bedarf zwischen den Systemen zu wechseln. Die Entwicklung folgte einem klassischen Scrum-Prozess mit zweiwöchentlichen Releasezyklen. Das bedeutete für uns jede zweite Woche eine neue Prozessversion im Produktivbetrieb unterstützen zu müssen. Zugehörige Prozesse, wie Warenbeschaffung oder Rechnungsstellung, sollten weiter über das Bestandssystem erfolgen.

Aus diesem Szenario ergaben sich mehrere Herausforderungen, die einen starken Einfluss auf die Architektur und unsere Designentscheidungen hatten:

  • Wir mussten den reibungslosen Parallelbetrieb von Alt- und Neusystem sicherstellen, ohne dass es beim Wechsel zwischen den Systemen zu Abweichungen oder Fehlern kam. Das Altsystem hatte allerdings weder klare Prozesszustände noch definierte Übergänge zwischen einzelnen Prozessschritten.
  • Durch die kontinuierlichen Prozessanpassungen musste eine möglichst reibungsfreie Migrationsstrategie erarbeitet werden.
  • Unterschiedliche Typen und Konfigurationen von Geschäftsobjekten benötigten spezielle Prozessabläufe. Daher musste die Applikation mehrere Prozessvarianten unterstützen.

Um die Komplexität des Setups gering zu halten, haben wir Camunda als Dependency in die Anwendung eingebunden. Das System kann als Microservice oder besser Self Contained System in einer größeren Systemlandschaft gesehen werden. Um die Fehlersuche einfach zu halten und sicherzustellen, dass es keine Abweichungen zwischen verschiedenen Prozessinstanzen gibt, haben wir uns entschieden, keinen Parallelbetrieb von mehreren Prozessversionen zu unterstützen. Darum war es in diesem Projekt sehr wichtig, die Migration von Prozessen einfach und robust zu gestalten. Unsere erste Entscheidung war daher, möglichst wenig Informationen in den Prozessvariablen zu speichern und uns nach Möglichkeit auf die ID des Geschäftsobjekts zu beschränken.

Um nicht für jede neue Prozessversion ein eigenes Migrationsskript schreiben zu müssen, haben wir den Prozess in Phasen geteilt und einen ‘Event Sourcing’-Mechanismus für fachliche Events konzipiert. Statt einer komplexen Abbildung des Zustands von einer älteren Prozessversion auf die aktuelle Version, haben wir einen effizienten ‘Replay’-Mechanismus für Prozesse entwickelt. Beim Update der Prozessversion wurden alle alten Prozessversionen gelöscht. Für jedes Geschäftsobjekt wurde ein neuer Prozess angelegt. Dieser wurde direkt mittels der fachlichen Ereignisse in den richtigen Zustand geschoben. Durch diesen Ansatz konnten wir Prozesse flexibel anpassen sowie schnell und effektiv neue Anforderungen umsetzen.

Camunda hat uns in diesem Projekt nicht nur geholfen, die Prozesse umzusetzen, sondern war auch ein wichtiges Mittel zur Kommunikation mit dem Fachbereich. Das iterative Vorgehen war zum Einen eine Herausforderung, gab uns aber zum Anderen die Möglichkeit, schnell auf Probleme und Wünsche aus dem Betrieb zu reagieren und so das System schnell für den Einsatz zu optimieren.

Szenario II: Big Bang!

Hier waren wir an der Entwicklung eines neuen Software-Systems beteiligt, das im Kern ebenfalls auf der Camunda-Engine aufsetzte. Sowohl die Anforderungen als auch die Umsetzung und die Ausgestaltung der Prozesse unterscheidet sich jedoch stark vom ersten Szenario. Das System war eine vollständige Neuentwicklung (Stichwort ‘grüne Wiese’) und diente zum unternehmensweiten Lieferantenmanagement. Die Prozesse zum Anlegen neuer Lieferanten sowie die Änderung von Daten bestehender Lieferanten sollten dabei über Camunda abgedeckt werden.

Eine der größten Herausforderungen bei der Entwicklung des Systems war dessen Auditfähigkeit und damit die genaue Nachvollziehbarkeit des Prozessablaufs. Wenn der Prozess einmal in einer Version gestartet wurde, durfte diese Prozessinstanz nicht mehr geändert werden. Alle Ereignisse und Entscheidungen mussten weiterhin nachvollziehbar sein. Es musste nachträglich möglich sein auszuwerten, wie der Prozess durchlaufen worden war und warum ein bestimmter Pfad gewählt wurde. Genau wie im ersten Szenario gab es darüber hinaus die Anforderung, mehrere Prozessvarianten zu unterstützen. Die Komplexität hier war aber höher, da es unterschiedlichen Faktoren gab, die den Prozessablauf beeinflussten. Zu guter Letzt sollte das System in einem großen Schritt in Betrieb genommen werden (Big Bang) und das Altsystem ablösen.

Aus diesen Anforderungen ergab sich eine völlig andere Herangehensweise an die Umsetzung des Geschäftsprozesses. Im Gegensatz zum ersten Szenario entschieden wir uns für eine relativ schwergewichtige Prozessimplementierung. Alle prozessrelevanten Daten wurden explizit in den Prozessvariablen abgelegt. Erst nach Abschluss eines Prozesses wurden die Daten in andere Datenbanktabellen übertragen. Dadurch kam der Camunda-Datenbank sowie den zugehörigen History-Tabellen eine gesonderte Bedeutung zu. Zusammen mit den schwergewichtigen Prozessvariablen konnten wir so die Nachvollziehbarkeit der Prozessinstanzen und die Auditfähigkeit des Systems sicherstellen.

Um das Altsystem in einem Schritt ablösen zu können, wurden die Prozessdaten alter Systeme durch einen Initialimport in das neue System überführt. Dies geschah nach einer Pilotphase in einem großen Livegang (Big Bang). In der Anfangsphase, in der wir das Projekt begleitet haben, waren Migrationen von Prozessinstanzen daher gar nicht notwendig.

Da je nach Geschäftsbereich und Land der Prozess unterschiedlich funktionieren und unterschiedliche Daten erfasst werden mussten, wurden der Prozessablauf über eine Konfiguration gesteuert. Diese wurde für die betroffene Kombination beim Prozessstart geladen und am Prozess hinterlegt. Während der Prozessausführung war sie verantwortlich für Pfade in der Ablaufsteuerung und Konfiguration der UI-Masken. Für die Auditfähigkeit des Systems musste auch diese Konfiguration historisiert werden und durfte nicht mehr verändert werden.

Szenario III: Shadow Mode

Ähnlich wie im ersten Szenario ging es in diesem Projekt um die Ablösung eines über viele Jahre gewachsenen Bestandsystems. Das System war über die Jahre immer komplexer gewordenes Batch-System, das speziell auf einen Großkunden zugeschnitten war. Der gesamte Prozess war in einer 50-seitigen Prozessdokumentation beschrieben, welche die aktuelle Implementierung natürlich nicht mehr widerspiegelte. Durch viele Sonderlocken und den an sich schon komplexen Prozess war das bestehende System nicht mehr flexibel genug um neue Anforderungen effizient umzusetzen.

Es sollte ein neues System auf Basis von Camunda entwickelt werden, um den Prozess wieder flexibel an neue Anforderungen und neue Szenarien anpassen zu können. Dazu sollte im ersten Schritt der Prozess eines Pilotkunden in Camunda nachgebaut werden. Das gab uns die Möglichkeit, ihn zunächst parallel zum bestehenden System zu betreiben und dort auf Abweichungen im Ablauf zu überprüfen (Shadow Mode). Hier ging es im Wesentlichen darum, die Prozessabläufe zu vergleichen, Fehler auszuschließen und Abweichungen zum dokumentierten bzw. angenommenen Ablauf des Prozesses zu finden. Danach sollte das neue System den Prozess komplett übernehmen, um diesen dann sukzessive verbessern zu können.

Die Herausforderungen in diesem Projekt ergaben sich im Wesentlichen durch die Komplexität des Prozesses, die geforderte Flexibilität sowie durch die vom Kunden gesetzten Rahmenbedingungen:

  • Als Projektziel sollte die Anpassbarkeit und Erweiterbarkeit des Prozesses für einzelne Kunden deutlich vereinfacht werden. Damit war diese Anforderung ein wesentlicher Faktor aller Entwurfs- und Architekturentscheidungen.
  • Die Umstellung von einem zeitgesteuerten Batch-System auf ein neues Echtzeit-System brachte ganz eigene Herausforderungen mit sich. So lieferte das Altsystem nur einmal pro Tag einen mehrere GB großen Datenbank-Dump welcher innerhalb kürzester Zeit verarbeitet werden musste.
  • Im ersten Schritt sollte das Verhalten des Altsystems exakt abgebildet werden, unabhängig davon ob es im Nachhinein als richtig oder falsch betrachtet wurde. Beim Abgleich der Prozesse kam es jedoch aufgrund der Komplexität und einiger Bugs im Altsystem immer wieder zu Abweichungen.

Gemeinsam mit unserem Kunden haben wir uns in diesem Projekt für eine Microservice-Architektur entschieden in der jeder Service Task von einem eigenen Microservice verarbeitet wird. Das lieferte die notwendige Flexibilität um die Prozesse leicht anpassen und erweitern zu können. Camunda spielte dabei im Wesentlichen die Rolle des Orchestrators. Wie im zweiten Szenario wurden auch in diesem Projekt die wesentlichen Daten in eigenen Datenstrukturen innerhalb der Prozessvariablen verwaltet. Ob dies der richtige Weg ist, wurde heiß diskutiert und wird sich erst in Zukunft zeigen.

Szenario IV: Manchmal ist Camunda auch nicht das Richtige

Zum Abschluss wollen wir noch auf ein Szenario eingehen, welches zeigt, wie man Camunda nicht einsetzen sollte. In diesem Fall haben wir bei unserem Kunden ein neues Software-System mit einer Microservice-Architektur auf Basis von Domain-driven Design (DDD) vorgefunden. Es gab dort einen Orchestrierungsdienst, der sich um den Transfer der Daten von einem Microservice in einen anderen gekümmert hat. Einer der Schritte bei der Orchestrierung ist dabei als fachlicher Prozess in Camunda in einem eigenen Microservice abgebildet worden.

Allerdings brachte der Einsatz von Camunda in diesem Fall mehr Nachteile als Vorteile: Es ist ein technischer Microservice in das System eingezogen worden, obwohl eine Microservice-Architektur nach DDD fachlich geschnitten sein sollte. Der Camunda-Microservice ist ausschließlich vom Orchestrierungs-Microservice aufgerufen worden und hat umgekehrt wieder den Orchestrierungs-Microservice aufgerufen. Dies hatte zyklische Abhängigkeiten auf verschiedenen Ebenen zur Folge, wodurch ein sauberes Schneiden von fachlicher Logik nicht mehr möglich war. Des Weiteren ist der Prozess, der mit Camunda abgebildet wurde, viel zu einfach gewesen, als dass er den Einsatz eines solchen Setups erfordert hätte: Er beinhaltete keinerlei manuelle User Tasks und ist, je nach Antwortzeit der involvierten Microservice-Aufrufe, in wenigen Sekunden abgearbeitet worden. Komplexe Aktionen, wie ein Persistieren von Prozessdaten oder ein Wiederanfahren von Prozessen im Fehlerfall, war fachlich nicht nötig.

Unser Ansatz war in diesem Fall tatsächlich, den gesamten Camunda-Prozess inkl. Microservice aus der Anwendung auszubauen und durch wenige fachliche Operationen im Orchestrierungs-Microservice zu ersetzen. Die gesamte Anwendungslogik wurde an dieser Stelle dadurch einfacher, kompakter und konnte direkt durch Unit-Tests getestet werden.

Ende.

In diesem Artikel haben wir vier Szenarien beschrieben in denen wir mit Camuda gearbeitet haben. Beim Einsatz von Camunda sind viele Entwurfsentscheidungen an den verschiedensten Punkten zu treffen. Abhängig von den ganz speziellen Anforderungen und Rahmenbedingungen können diese dabei sehr unterschiedlich ausfallen. In zukünftigen Artikeln werden wir auf ausgewählte Szenarien detaillierter eingehen. Bei Interesse kannst du dich hier registrieren:

Live Webinar: Softwareentwicklung skalieren, ohne sich im Wachstumsprozess aufzureiben

„Im Webinar wurden genau die Pain Points angesprochen, die in unserem Wachstum gerade auftreten. Bei stetig steigender Zahl an Mitarbeitern im Dev & Product Team mussten wir selbst feststellen, wie schwierig es ist, eine sinnvolle Struktur aufzubauen, die bei jedem das Maximum an Effizienz und Leistung hervorbringt und gleichzeitig zu einer gesunden Arbeitsatmosphäre führt.”
Pascal von Briel, Co-Founder & CPO @ exporto GmbH