Camunda vs Flowable: Ein Vergleich der BPM-Engines

Einleitung:
Business-Process-Management-(BPM)-Engines wie Camunda und Flowable sind Kernbausteine, um Geschäftsprozesse in Unternehmen zu automatisieren. Insbesondere Banken und Finanzunternehmen in der Schweiz stellen hohe Anforderungen an solche Plattformen – von verlässlichem On-Premise-Betrieb über Skalierbarkeit bis zur Compliance in regulierten Umgebungen. Seit dem ursprünglichen Vergleich von Camunda und Flowable hat sich viel getan: Camunda hat mit Camunda 8 eine völlig neue, cloud-native BPM-Plattform auf Basis der Zeebe-Engine eingeführt, während Camunda 7 (die klassische Java-basierte Engine) langsam auf das Abstellgleis rollt. Dieser aktualisierte Vergleich beleuchtet Camunda 7, Camunda 8 und Flowable unter den Gesichtspunkten CMMN-Unterstützung, Architektur, Skalierbarkeit/Performance, APIs & Integration, Lizenzierung/Enterprise-Funktionen sowie On-Premise-Tauglichkeit – mit besonderem Blick auf die Bedürfnisse von Banken und Versicherungen in der Schweiz.

CMMN-Unterstützung: Camunda vs. Flowable klarstellen

Ein wesentlicher Unterschied vorab: CMMN (Case Management Model and Notation) wird von Camunda kaum noch verfolgt. In Camunda 7 wurde die CMMN-Funktionalität zwar implementiert, befindet sich aber nur noch im Wartungsmodus – neue Features wird es nicht mehr geben camunda.com. In Camunda 8 wird CMMN gar nicht mehr unterstützt capitalone.com. Flowable dagegen bietet vollständige CMMN-Unterstützung und investiert weiter in dieses Standardverfahren forum.flowable.org

. Für use cases wie komplexe Fallbearbeitung (z.B. Kreditfälle, Compliance-Prüfungen), die von CMMN profitieren, ist Flowable somit von vornherein im Vorteil. Camunda selbst empfiehlt, solche Szenarien mit BPMN umzusetzen (teilweise mit Pattern-Workarounds), was jedoch je nach Anwendungsfall umständlich sein kann. Finanzunternehmen, die auf Case Management setzen, sollten diesen Unterschied besonders beachten.

Architektur: Camunda 7 (Java-Engine) vs. Camunda 8 (Cloud-native Zeebe)

Die Architekturen von Camunda 7 und Camunda 8 unterscheiden sich grundlegend. Camunda 7 ist eine monolithische Java-basierte Process Engine, ursprünglich ein Fork von Activiti. Sie läuft typischerweise innerhalb einer Java-Anwendung oder auf einem Application Server und nutzt eine relationale Datenbank zur Speicherung von Prozessinstanzen, Tasks und historischen Daten. Man konnte Camunda 7 je nach Bedarf eingebettet im eigenen Java-Code, als geteilte Engine auf einem Server oder als separaten Service mit REST-API betreiben blog.viadee.de. Diese Flexibilität erlaubte es z.B. Banken, die Engine direkt in bestehende Core-Banking-Anwendungen zu integrieren oder als eigenständigen BPM-Service in der eigenen Infrastruktur zu hosten.

Camunda 8 geht einen ganz anderen Weg: Es basiert auf der neu entwickelten Zeebe-Engine, die auf verteilte Microservice-Architektur setzt rst.software. Anstatt einer einzelnen Java-Engine mit gemeinsamer Datenbank besteht Camunda 8 aus mehreren komponenten (Zeebe Broker/Gateway, Operate, Tasklist, etc.), die typischerweise in einer Kubernetes-Umgebung orchestriert werden blog.viadee.de. Die Engine ist darauf ausgelegt, horizontal linear zu skalieren und kommt ohne relationale Datenbank aus – der klassische DB-Bottleneck von Camunda 7 entfällt blog.viadee.de. Dies bedeutet, dass Camunda 8 erheblich mehr Prozessinstanzen parallel verarbeiten kann, ohne an eine zentrale DB-Transaktion gebunden zu sein. Allerdings gibt es die Camunda-8-Engine nur noch als Remote-Service: Ein Einbetten in eigene Anwendungen wie bei Camunda 7 ist nicht vorgesehen forum.camunda.io. Die Prozessausführung läuft im Remote-Modus immer entkoppelt ab – Camunda 8 orchestriert nur die Reihenfolge der Tasks, die Ausführung der Aufgabenschritte erfolgt ausserhalb (ähnlich dem External Task Pattern von Camunda 7)blog.viadee.de.

Flowable orientiert sich architektonisch eher an Camunda 7. Die Flowable-Engine ist ein schlanker Java-Prozess-Engine-Kern, der ebenfalls in einer klassischen mehrschichtigen Architektur mit relationaler Datenbank läuft. Sie kann embedded in eine Java-Anwendung oder als separater Service im Server/Cluster betrieben werden und integriert sich hervorragend in Spring-basierte Umgebungen github.com. In Bezug auf die Architektur bedeutet das: Flowable lässt sich ähnlich flexibel deployen wie Camunda 7 (z.B. in einer On-Premise-Serverlandschaft der Bank), während Camunda 8 ein deutlich komplexeres Set-up mit verteilten Komponenten erfordert. Für konservative IT-Umgebungen in Banken, die oft noch auf bewährte Architekturprinzipien setzen, könnte die steilere Lernkurve von Camunda 8 eine Rolle spielen.

Skalierbarkeit und Performance

Durch die unterschiedlichen Architekturen ergeben sich grosse Unterschiede in der Skalierbarkeit. Camunda 7 skaliert traditionell vertikal und begrenzt horizontal – d.h. man kann die Engine auf stärkere Hardware setzen oder in einem Cluster mit gemeinsam genutzter DB betreiben. Letzteres stösst jedoch irgendwann an Grenzen, da die relationale Datenbank der limitierende Faktor für die Anzahl gleichzeitig laufender Prozesse ist blog.viadee.de. Für viele typische Anwendungen (inkl. der meisten bankinternen Prozesse) ist Camunda 7 performant genug, aber bei extrem hohen Lastspitzen oder Massendaten kann die Performance abfallen, wenn die DB zum Flaschenhals wird.

Camunda 8 wurde explizit für hohe Durchsatzraten und lineare Skalierung entworfen. Die Zeebe-Engine nutzt ein Event-Streaming- und Partitionierungsmodell, das es erlaubt, zusätzliche Broker-Knoten hinzuzufügen und so die Verarbeitung auf mehrere Instanzen zu verteilen – ohne zentrale Transaktionsdatenbank. In der Praxis kann Camunda 8 daher deutlich mehr Prozessinstanzen pro Sekunde verarbeiten als Camunda 7 blog.viadee.de. Für Finanzunternehmen mit Digitalisierungsprojekten, die sehr grosse Volumina (z.B. im Zahlungsverkehr oder Echtzeit-Processing) bewältigen müssen, kann diese Skalierbarkeit ein entscheidender Faktor sein. Allerdings sollte man beachten, dass Camunda 8 auf eventuelle Konsistenz setzt: Änderungen sind nicht sofort in allen Komponenten sichtbar, was bei stark verzahnten synchronen Prozessen zu berücksichtigen ist.

Flowable’s Performance ist mit Camunda 7 vergleichbar, da es ebenfalls auf dem etablierten transaktionsbasierten Modell mit relationaler DB beruht. Für die meisten geschäftlichen Workflows – etwa Kreditentscheidungsprozesse oder Kontoeröffnungen – ist Flowable ausreichend skalierbar. Bei Lasttests mit tausenden gleichzeitigen Instanzen hängt die Performance wie bei Camunda 7 vor allem von der Datenbank und dem Tuning der Umgebung ab. Einen speziellen, neu entwickelten „High-Throughput“-Modus wie Zeebe bietet Flowable nicht, dafür ist die Engine “leichtgewichtig” konzipiert und kann effizient auf moderner Hardware oder in Container-Orchestrierungen laufen. Kurz gesagt: Camunda 8 hat die Nase vorn, wenn es um massive Skalierung geht, während Camunda 7 und Flowable bei „normalen“ Prozesslasten performant und bewährt sind. In regulierten Branchen, wo Stabilität oft wichtiger ist als maximaler Durchsatz, relativiert sich der Vorteil von Camunda 8 – es sei denn, das Einsatzszenario erfordert wirklich das Handling von sehr grossen Ereignismengen in kurzer Zeit.

API- und Integrationsmöglichkeiten

Für Entwickler und Architekten ist entscheidend, wie sich die BPM-Engine in die bestehende Systemlandschaft integrieren lässt. Camunda 7 punktet hier traditionell mit direkten Java-APIs und einer REST-API. In einer eingebetteten Nutzung können Java-Delegates direkt im selben JVM-Prozess ausgeführt werden, was eine enge Kopplung und sogar gemeinsame Transaktionen mit der Anwendung erlaubt. Alternativ bietet Camunda 7 eine vollständige REST-API, über die externe Anwendungen Prozesse starten, Tasks abfragen oder abschliessen können. Diese Flexibilität machte Camunda 7 für viele Banken attraktiv, da man z.B. im Core-Banking-System Java-Module mit Camunda integrieren konnte und zugleich in anderen Bereichen (etwa einer Online-Banking-Plattform) über REST auf die Engine zugreifen konnte.

Camunda 8 setzt in Sachen Integration auf ein dezidiertes Gateway mit gRPC-API. Statt direkt mit der Engine zu sprechen (was aufgrund der Entkopplung nicht möglich ist), läuft alle Kommunikation über das Zeebe-Gateway und dessen gRPC-Schnittstelle blog.viadee.de. Über diesen Kanal können Prozesse gestartet, Aufgaben abgeholt und abgeschlossen werden. Da gRPC im Java-Ökosystem weniger verbreitet ist, stellt Camunda offizielle Client Libraries für Java, JavaScript, etc. bereit, die die Kommunikation erleichtern blog.viadee.de. Zusätzlich verteilen sich die Schnittstellen bei Camunda 8 auf mehrere Services – z.B. gibt es eine GraphQL-API für die Tasklist und eine REST-API für das Operate-Tool (Prozessmonitoring) blog.viadee.de. Für Integrationen bedeutet das etwas mehr Aufwand und neue Technologien (z.B. gRPC, GraphQL) im Vergleich zur gewohnten REST/Java-Welt. In einer modernen Microservice-Architektur sind diese Patterns jedoch gut anschlussfähig. Ein Nebeneffekt: Da Camunda 8 immer remote arbeitet, gibt es keine Java-Delegates oder direkten Execution Listener mehr im Engine-Prozess – solche Logik muss in externe Worker ausgelagert werden forum.camunda.io.

Flowable bietet hinsichtlich Integration ein sehr entwicklerfreundliches Modell. Wie Camunda 7 stellt Flowable Java-APIs bereit und kann nahtlos in Spring-Anwendungen integriert werden github.com. Gleichzeitig gibt es auch hier eine umfassende REST-API, sodass man Flowable entweder via HTTP ansprechen oder als eingebettete Library nutzen kann – je nach Bedarf. Diese Dualität ist für viele Banken ideal: z.B. kann ein Core-Banking-System Flowable als integrierten Workflow-Orchestrator verwenden, während andere Satellitensysteme über REST mit dem Workflow-Service kommunizieren. Auch Message-Queue- oder Event-Integrationen lassen sich realisieren, vergleichbar zu Camunda 7 (z.B. External Task Pattern analog in Flowable umsetzbar). Insgesamt erfordert Flowable keine neuen Protokolle oder Frameworks in der Integration; Entwickler können auf vertraute Technologien setzen. Für bestehende Java-Stacks in Finanzunternehmen ist das ein Pluspunkt, da die Lernkurve geringer ist. Camunda 8 hingegen bringt modernere Schnittstellentechnologien mit, was in zukunftsorientierten Architekturen (Stichwort Cloud-native Banking) vorteilhaft sein kann – sofern das Know-how für gRPC & Co. vorhanden ist.

Lizenzierung und Enterprise-Funktionen

Bei der Wahl der BPM-Engine spielen auch Lizenzmodelle und verfügbare Enterprise-Features eine grosse Rolle – gerade in grossen Finanzinstituten, die Support und langfristige Planungssicherheit brauchen. Hier unterscheiden sich Camunda 7, 8 und Flowable teils erheblich.

Camunda 7 wurde in zwei Editionen angeboten: die Community Edition (CE) ist Open Source (Apache-Lizenz) und kostenlos nutzbar, während die Enterprise Edition eine kostenpflichtige Subskription mit Support und zusätzlichen Features (z.B. erweiterte Cockpit-Funktionen, LDAP-Integration, Camunda Optimize für Reporting etc.) umfasst. Viele Unternehmen – auch Banken – haben Camunda 7 zunächst in der freien Version evaluiert und bei produktivem Einsatz dann auf die Enterprise-Version upgegradet. Wichtig zu wissen: Camunda hat angekündigt, Camunda 7 nur noch bis etwa 2027 aktiv zu supporten (Community-Updates sogar nur bis Oktober 2025) pretius.com. Danach endet der volle Support (Extended Support mit reinen Bugfixes bis 2027). Neukunden werden klar in Richtung Camunda 8 gelenkt, da Camunda 7 zwar noch gewartet wird, aber keine Weiterentwicklung mehr erfährt.

Camunda 8 bricht auch beim Lizenzmodell mit der Tradition des Open Source. Die neue Plattform hat keine freie Community-Edition mehr, sondern erfordert für den produktiven Betrieb immer eine kommerzielle Lizenz pretius.com. Zwar ist der Quellcode der Kern-Engine Zeebe öffentlich einsehbar, aber die Nutzung der Gesamtplattform (inkl. Operate, Tasklist, etc.) ist in Produktion nur mit gültigem Vertrag erlaubt. Camunda 8 wird sowohl als SaaS (Camunda Cloud) angeboten als auch als Self-Managed Variante für eigene Rechenzentren, jeweils in gestaffelten Enterprise-Paketen. Kostenfreie Nutzung ist nur für Entwicklung/Testing in begrenztem Rahmen möglich pretius.com. Für Banken bedeutet dies: Wenn man auf Camunda 8 setzen will, muss man ein Budget für Lizenz & Support einplanen. Dafür erhält man aber auch Zugriff auf alle neuen Komponenten, Sicherheitsupdates und den Camunda-Support. Die Enterprise-Funktionen in Camunda 8 umfassen u.a. Operate (Prozessmonitoring ähnlich Cockpit), Tasklist (Aufgaben-UI), Optimize (BI/Reporting) und Identity (Rechtemanagement) – viele davon waren in Camunda 7 nur als Zusatzprodukt oder in der Enterprise-Version erhältlich. In Camunda 8 sind sie integraler Bestandteil des Angebots (jedoch nicht modular frei wählbar in der Community, da es diese nicht gibt).

Flowable verfolgt ein duales Modell, das dem von Camunda 7 ähnelt: Es gibt eine Open-Source-Engine (Flowable Community) unter Apache-2.0-Lizenz github.com, die kostenlos genutzt und auch angepasst werden kann. Darüber hinaus bietet die Firma Flowable Enterprise-Produkte (z.B. Flowable Work für Case-Management mit UI, Flowable Engage für Chatbot-Integration usw.), die kommerziell lizenziert werden forum.flowable.org. Diese Enterprise-Tools setzen auf den Open-Source-Kern auf, bieten aber komfortable Web-Oberflächen, Integrationen (z.B. Elasticsearch-basierte Suche) und zusätzlichen Support für den Betrieb. Ein Finanzunternehmen kann also prinzipiell mit der kostenlosen Flowable-Engine starten und selbst Lösungen darum bauen – oder das Enterprise-Paket erwerben, um schneller einsatzfähige Lösungen (inkl. Modellierungs-UI, Admin-UI etc.) zu bekommen. Die Kosten für Flowable-Enterprise sind individuell verhandelbar; tendenziell gelten sie als flexibler und oft günstiger im Vergleich zu grossen BPM-Suiten. Dennoch sollte man bedenken: Die Open-Source-Version von Flowable hat keine eingeschränkten Engine-Funktionen (alles, inkl. CMMN, ist enthalten), aber für professionellen Einsatz in einer Bank sind oft die Enterprise-Erweiterungen für Monitoring, Skalierung (z.B. Multi-Node-Tools) und Support sehr wertvoll. Hier kommt es auf die Anforderungen und Ressourcen der Bank an: Verfügt man über ein starkes Inhouse-Entwicklungsteam, kann die Open-Source-Variante ausreichend sein; benötigt man schnelle Ergebnisse und Hersteller-SLA, ist die Enterprise-Version sinnvoll.

Zusammengefasst: Camunda 8 setzt voll auf ein kommerzielles Abo-Modell, während Flowable den Open-Source-Weg beibehält und optional Enterprise-Angebote hat. Für eine Bank mit strikten Compliance-Vorgaben kann Open Source attraktiv sein (Stichwort: Unabhängigkeit, kein Vendor-Lock-in), aber gleichzeitig muss man abwägen, ob man den fehlenden offiziellen Support intern auffangen kann. Camunda ist als kommerzieller Anbieter in der BPM-Welt sehr etabliert, was auch bedeutet, dass Expertise am Markt leichter zu finden sein könnte. Flowable ist etwas weniger bekannt, hat aber ebenfalls eine aktive Community und wird von ehemaligen Activiti-Entwicklern getragen – die Codebasis ist erprobt.

On-Premise-Betrieb und Relevanz für regulierte Branchen

Für Schweizer Banken und Versicherungen als stark regulierte Branche sind Aspekte wie Datenhoheit, Security und Compliance entscheidend. Viele Institute bevorzugen (oder verlangen) einen On-Premise-Betrieb ihrer Kernsysteme, um volle Kontrolle über Daten und Prozesse zu haben – Cloud-Lösungen werden oft nur zögerlich oder in isolierten Bereichen zugelassen, insbesondere wenn Kundendaten oder transaktionsrelevante Daten im Spiel sind. Vor diesem Hintergrund ist die Betriebsart der BPM-Engine ein kritischer Faktor.

Camunda 7 ist von Grund auf für On-Premise prädestiniert. Man kann die Engine in der eigenen Infrastruktur betreiben – sei es auf dedizierten Servern, in virtuellen Maschinen oder containerisiert im eigenen Rechenzentrum. Alle Komponenten (Datenbank, Webapps wie Cockpit/Tasklist etc.) laufen unter voller Kontrolle der Bank. Dies passt gut zu den üblichen IT-Vorgaben in Banken, wo Software idealerweise innerhalb der eigenen Sicherheitszonen betrieben wird. Camunda 7 lässt sich in hochsicheren Umgebungen (mit Netzwerksegmentierung, ohne Internetzugriff) problemlos einsetzen und erfüllt die Anforderungen an Auditierbarkeit und Nachvollziehbarkeit, die etwa die FINMA stellt.

Camunda 8 wurde primär mit einer Cloud-Strategie im Blick entwickelt. Das Standardangebot ist ein SaaS-Service, gehostet in der Cloud des Anbieters (Camunda Cloud). Für Banken ist dieses Modell oft problematisch, da dabei Prozessdaten ausserhalb der eigenen Infrastruktur gespeichert und verarbeitet würden. Zwar garantiert Camunda Cloud den Betrieb in europäischen Rechenzentren und bietet Verschlüsselung und ISO-Zertifizierungen – dennoch haben viele Finanzfirmen Policies, die eine Auslagerung solcher Workflows in eine öffentliche Cloud untersagen. Die gute Nachricht: Camunda 8 gibt es auch als Self-Managed Variante, die auf eigenen Servern (bzw. in einer privaten Cloud) betrieben werden kann blog.viadee.de. 

Praktisch bedeutet das jedoch einen erhöhten Aufwand: Eine Bank müsste eine Kubernetes-Clusterumgebung bereitstellen, die verschiedenen Camunda-8-Komponenten installieren, konfigurieren und betreiben. Nicht jeder IT-Betrieb ist bereits so aufgestellt, um eine verteilte Microservice-Plattform intern zu managen. Zudem gelten für Camunda 8 Self-Managed aktuell noch ein paar Einschränkungen (Stand heute sind einige SaaS-Features nur eingeschränkt on-prem verfügbar). Für regulierte Branchen ist der Self-Managed-Weg aber meist der einzig gangbare, wenn man Camunda 8 nutzen will – und er ist grundsätzlich machbar (einige grosse Banken und Versicherer evaluieren oder nutzen Camunda 8 bereits on-premises, oft in Container-Plattformen wie OpenShift). Wichtig: Die Bank bleibt dennoch auf den Hersteller angewiesen, gerade was Updates und Support angeht, da ohne Lizenz die Plattform nicht betrieben werden darf.

Flowable ist von seinem Ursprung her eine On-Premise- / Eigenhostungs-Lösung. Als Open-Source-Engine konzipiert, läuft Flowable in jedem beliebigen Umfeld – ob klassisch auf einem Applikationsserver, integriert in eine bestehende Anwendung oder in Docker/Kubernetes innerhalb der Bank. Es gibt keine Verpflichtung, irgendeinen Cloud-Service zu nutzen. Das gibt Finanzunternehmen maximale Souveränität: Sämtliche Prozessdaten verbleiben inhouse, und Anpassungen können bei Bedarf am Code vorgenommen werden. Flowable, Inc. selbst bietet (soweit bekannt) kein eigenes Public-Cloud-BPM SaaS an – das Geschäftsmodell ist eher, Lizenzen für die Enterprise-Tools zu verkaufen oder Projekte zu unterstützen. Somit fügt sich Flowable sehr gut in streng regulierte IT-Umfelder ein. Beispielsweise hat die Zürcher Kantonalbank (ZKB), die grösste Kantonalbank der Schweiz, Flowable als Lösung für die Prozessautomatisierung gewählt, um interne Abläufe signifikant zu beschleunigen flowable.com. In diesem Fall konnte Flowable on-premise implementiert werden, was den hohen Datenschutz-Anforderungen gerecht wird. Gerade wenn eine Bank CMMN-Case-Management nutzen möchte (z.B. in der Kreditsachbearbeitung oder im Compliance-Umfeld), ist Flowable aufgrund seiner vollständigen Unterstützung und On-Premise-Fähigkeit eine sehr attraktive Option.

Zusammengefasst müssen Banken und Versicherer für sich bewerten: Camunda 7 lässt sich problemlos on-prem betreiben, wird aber perspektivisch abgelöst. Camunda 8 bietet moderne Cloud-Technologie und enorme Skalierung, erfordert on-prem jedoch einen modernen Containerized-Betrieb und kommt nicht ohne kommerzielle Verträge. Flowable ist vollständig on-premises einsetzbar (Open Source), was maximale Kontrolle erlaubt – aber auch hier sollte man für Produktiveinsatz die enterprise-level Tools in Betracht ziehen. In der Schweiz, wo regulatorische Anforderungen streng sind, könnte Flowable daher in manchen Fällen der pragmatischere Weg sein, sofern die Funktionen ausreichen und man mit dem kleineren Hersteller kein Problem hat. Camunda 8 wiederum kann für Institute interessant sein, die bewusst eine Cloud-native Ausrichtung verfolgen (etwa neue Digitalplattformen losgelöst vom Kernbankensystem), oder die extrem hohe Lasten abbilden müssen, wo der Architekturvorteil zum Tragen kommt.

Vergleichstabelle: Camunda 7 vs. Camunda 8 vs. Flowable

Zur besseren Übersicht fasst die folgende Tabelle die wichtigsten Kriterien und Unterschiede zwischen Camunda 7, Camunda 8 und Flowable zusammen:

(Legende: BPMN = Business Process Model and Notation, CMMN = Case Management Model and Notation, DMN = Decision Model and Notation)

Fazit: Entscheidungskriterien für Finanzunternehmen

Die Wahl zwischen Camunda 7, Camunda 8 und Flowable hängt stark von den individuellen Anforderungen und Strategien eines Unternehmens ab. In der Finanzbranche – wo Zuverlässigkeit, Compliance und Datenkontrolle Priorität haben – sollten folgende Überlegungen in die Entscheidung einfliessen:

• Modernisierung vs. Bewährtes: Camunda 8 repräsentiert einen modernen, cloud-nativen Ansatz mit hoher Skalierbarkeit und zukunftsweisender Architektur. Unternehmen, die langfristig auf Microservices und Cloud-Technologien setzen (vielleicht als Teil einer Digitalisierungsstrategie oder um sehr volatile Lasten abzudecken), finden in Camunda 8 eine leistungsfähige Plattform. Allerdings ist der Reifegrad einer neuen Engine zu bedenken – Zeebe ist noch relativ jung (entwickelt seit ca. 2017) blog.viadee.de, während Camunda 7 und Flowable auf jahrelang erprobten Engines basieren. Für konservative Use Cases könnte „bewährte Stabilität“ wichtiger sein als cutting-edge Technologie.

• Funktionaler Bedarf (BPMN/DMN/CMMN): Wenn Case Management (CMMN) ein wesentlicher Teil der Anforderungen ist (etwa in komplexen Fallbearbeitungen, die Flexibilität erfordern), ist Flowable aufgrund seiner vollständigen Unterstützung klar im Vorteil. Camunda 8 würde in diesem Punkt komplett ausscheiden, Camunda 7 nur mit Workarounds in BPMN capitalone.com. Für reine BPMN-Workflow-Orchestrierung mit Decision Tables (DMN) bieten alle drei Lösungen solide Funktionen. Camunda 8 integriert DMN direkt in Prozessabläufe etwas eleganter als Camunda 7 (automatisches Triggern von Decisions)

  pretius.com

  – doch für die meisten Finanz-Prozesse ist das kein Game-Changer, da DMN auch in Camunda 7/Flowable problemlos nutzbar ist.

• Integrationsaufwand und Technologie-Stack: Banken mit grossen Java-basierten Anwendungslandschaften und vielen Legacy-Systemen könnten den nahtlosen Java/REST-Ansatz von Camunda 7 oder Flowable bevorzugen. Hier ist der Einstieg schnell: Entwickler kennen die APIs, es gibt keine überraschenden neuen Technologien. Camunda 8 erfordert dagegen u.U. neue Skills (gRPC, Kubernetes) – was mittelfristig zwar ein Invest in moderne Fähigkeiten sein kann, kurzfristig aber die Hürde erhöht. Wenn eine Bank bereits stark in Richtung Cloud Native unterwegs ist (Container-Plattform vorhanden, Event-Driven Architecture etabliert), lässt sich Camunda 8 natürlich leichter integrieren. Falls nicht, könnten Camunda 7 oder Flowable im aktuellen Zustand schneller zum Ziel führen.

• Betriebs- und Lizenzkosten: Für viele Finanzentscheider sind TCO und Compliance-Kosten entscheidend. Camunda 7 Community war attraktiv, weil keine Lizenzkosten anfielen – diese Option fällt mit Camunda 8 weg. Camunda 8 bedeutet also Lizenzkosten (und nicht zu knapp, je nach Instanz-Anzahl/Clustergrösse). Dafür bekommt man aber Support und Weiterentwicklung vom Marktführer. Flowable bietet prinzipiell die Möglichkeit, Lizenzkosten zu sparen (Open Source nutzen), was jedoch durch höheren Eigenaufwand relativiert werden kann. Eine Bank, die unabhängiger von Vendors sein möchte und ggf. eigene Entwickler-Teams hat, kann mit Flowable Community einen kostengünstigen Weg beschreiten. Wenn allerdings dedizierter Support und Garantien gefordert sind – was in kritischen Bank-Prozessen oft der Fall ist – sollte man auch bei Flowable die Enterprise-Version einkalkulieren. Insgesamt sind die kommerziellen Camunda-8-Pakete vermutlich teurer als eine Flowable-Enterprise-Lizenz, da Camunda als Marktführer seine Preise entsprechend positioniert hat. Hier lohnt es sich, Angebote einzuholen und auch zu schauen, welche Features im Preis enthalten sind.

• Strategische Roadmap und Herstellerabhängigkeit: Camunda 7 befindet sich auf dem Weg zum Ende des Lebenszyklus (End-of-Life). Wer heute noch auf Camunda 7 setzt (etwa weil es akut den Bedarf erfüllt), braucht eine Migrationsstrategie für die Zukunft – entweder späterer Umstieg auf Camunda 8 oder Wechsel zu einer Alternative. Camunda 8 wird von Camunda intensiv vorangetrieben und dürfte für die nächsten Jahre das Flaggschiff bleiben. Flowable entwickelt seine Engine ebenfalls kontinuierlich weiter und hat sich klar zu CMMN und klassischen BPM-Technologien bekannt

  forum.flowable.org

  . Hier spielt auch Herstellerabhängigkeit eine Rolle: Camunda als Unternehmen hat eine starke Präsenz und Community (viele Erweiterungen, Forenbeiträge, Konferenzen etc.), Flowable ist etwas kleiner aufgestellt, aber spezialisiert. Manche Banken tendieren dazu, auf den „Marktstandard“ zu setzen (das wäre aktuell Camunda), andere suchen gezielt Nischenlösungen, die genau ihren Zweck erfüllen.

Fazit in Kürze:

• Camunda 7 ist eine robuste Wahl für heutige On-Premise-Anforderungen, insbesondere wenn man schnell eine bewährte BPM-Lösung braucht und CMMN keine Rolle spielt. Allerdings ist es technologisch am Ende seines Innovationszyklus – für langfristige Projekte sollte man die absehbare Ablösung berücksichtigen.
• Camunda 8 ist ideal, wenn sehr hohe Skalierbarkeit oder eine Cloud-native Ausrichtung verlangt wird. Für neue Digitalinitiativen (z.B. API-orchestrierte Prozesse, hohe Volumina in Echtzeit) kann Camunda 8 die Weichen richtig stellen. In streng regulierten Umfeldern muss man jedoch den Mehraufwand für Self-Managed-Betrieb und die Lizenzabhängigkeit einplanen.
• Flowable eignet sich hervorragend für flexible On-Premise-Lösungen mit vollem BPMN/DMN/CMMN-Funktionsumfang. Es ist eine kosteneffiziente Alternative, die bereits von Banken erfolgreich eingesetzt wird (z.B. ZKB in Zürich)flowable.com. Unternehmen, die maximale Kontrolle und CMMN-Funktionalität wünschen, finden in Flowable einen passenden Kandidaten. Man sollte aber realistisch einschätzen, dass eventuell zusätzliche Entwicklungsarbeit nötig ist, um den Komfort einer Camunda-Enterprise-Lösung nachzubilden.

Letztlich gibt es kein pauschales «One size fits all». Jedes Institut sollte die Optionen anhand der eigenen Kriterien bewerten. Oft hilft eine Proof-of-Concept-Phase mit den favorisierten Engines, um zu sehen, welche am besten in die bestehende Landschaft passt. Auch ein Blick auf aktuelle Analysen und Community-Vergleiche lohnt sich – z.B. hat 2022 ein Tech-Blog von Capital One verschiedene Open-Source-BPM-Systeme (Camunda, Flowable, etc.) detailliert verglichen capitalone.com. Wichtig ist, die langfristigen Folgen der Entscheidung im Blick zu haben: Technologie-Stack, Wartbarkeit, Kosten und regulatorische Compliance. Mit den hier dargestellten Informationen und Kriterien sind Banken und Finanzunternehmen in der Schweiz nun besser gerüstet, um eine informierte Entscheidung zwischen Camunda 7, Camunda 8 und Flowable zu treffe