Camunda 7 vs. 8 - Eine Betrachtung durch die Brille von Team Topologies

Viele Unternehmen nutzen seit Jahren Camunda 7 als Business-Process-Management-Lösung On-Premise. In der Regel wurde dabei die Camunda Engine in bestehende Java-Anwendung eingebunden und vom Entwicklungsteam eigenständig betrieben. Diese Teams waren im besten Fall stream-aligned organisiert: Sie kümmerten sich sowohl um die Entwicklung neuer Features als auch um den Betrieb ihrer Anwendungen, inklusive der eingebetteten Engine.

Ich kann mich noch an meine ersten Schritte mit Camunda vor 10 Jahren erinnern. Getting Started gelesen, Übungsaufgaben erledigt, Anwendung gestartet, läuft.

Mit Camunda 8 verändert sich die Architektur grundlegend. Die neue Engine basiert auf einer verteilten und hochskalierbaren Infrastruktur. Zwar ermöglicht Camunda 8 Run zukünftig einen vereinfachten Betrieb, der vor allem die lokale Entwicklung beschleunigt, jedoch ist diese Lösung für einen ausfallsicheren produktiven Einsatz nur eingeschränkt geeignet. Auch die einfache Einbettung in eine Java-Anwendung wie bei Camunda 7 entfällt. Stattdessen entstehen neue Anforderungen an das Wissen rund um verteilte Systeme, Messaging, skalierbare Infrastruktur, Kubernetes und andere Cloud-nahe Technologien. Dies stellt viele Organisationen vor die Herausforderung, dass ihre bisherigen Stream-Aligned Teams nicht mehr ohne Weiteres alle notwendigen Kompetenzen abdecken können – insbesondere dann, wenn Camunda 8 On-Premise (also in der eigenen Infrastruktur) betrieben werden soll.

Wie wirkt sich die Migration zu Camunda 8 auf die Organisationsstruktur aus und wie können Unternehmen den steigenden Bedarf an Spezialwissen effizient adressieren?

Nach eingehender Analyse verschiedener Migrationsszenarien zwischen den beiden Engines stellte ich mir die Frage: „Warum fühlt sich Camunda 8 für Teams, die bereits mit Camunda 7 vertraut sind, so grundlegend anders an?“ Eine Erklärung liefert Team Topologies.

Was ist Team Topologies?

Um die organisatorische Auswirkungen einer solchen technischen Veränderung zu verstehen, lohnt ein Blick auf Team Topologies von Matthew Skelton und Manuel Pais. Diese beschreiben sowohl vier grundlegende Teamtypen als auch die Interaktionsmuster zwischen diesen Teams.

Team Topologies ist ein Organisationsmodell, das beschreibt, wie Teams in einer Produktentwicklungsumgebung strukturiert werden können und miteinander interagieren sollten. Im Kern geht es darum, Teams so zu gestalten, dass sie möglichst autonom arbeiten. Dabei unterscheidet das Modell in vier grundlegende Teamtypen:

• Stream-Aligned Team
• Fokussiert auf die schnelle Lieferung von End-to-End-Features und den direkten Mehrwert für Kunden oder Fachabteilungen.
• Besitzt in der Regel die Autonomie, Entwicklung und Betrieb (DevOps) weitgehend selbst zu übernehmen.
• Platform Team
• Bietet zentrale Services, Dokumentationen und Plattform-Komponenten für andere Teams.
• Das Ziel besteht darin, wiederholende, komplexe Themen zu abstrahieren und als Self-Service zur Verfügung zu stellen um damit die kognitive Last des Stream-Aligend Teams zu verringern.
• Complicated-Subsystem Team
• Verantwortet einen besonders komplexen oder hochspezialisierten Teil des Systems, den ein normales Stream-Aligned Team nicht alleine betreuen kann.
• Typischerweise mit ausgeprägtem Fach- oder Technologiewissen in einem Bereich, z. B. KI, hochoptimierte Algorithmen oder eben auch BPM-Engines.
• Enabling Team
• Unterstützt andere Teams durch Coaching, Beratung und temporäres Enabling.
• Baut Brücken zwischen Innovation (neue Tools/Methoden) und deren produktivem Einsatz in den Stream-Aligned Teams.

Team Topologies definiert zudem klare Interaktionsmuster, um einen reibungslosen Ablauf zu ermöglichen. Ziel ist es, durch diese klaren Strukturen, die kognitive Last der Stream-aligned Teams zu verringern und dadurch die Produktentwicklung zu beschleunigen.

💡Das Buch zu Team Topologies bietet eine ausführliche Einführung in das Thema. Dort erwarten Dich viele weitere spannende Themen wie Conway’s Law, Interaction Modes und Fracture Planes!

Unterschiede in der Architektur von Camunda 7 und Camunda 8

Damit wir verstehen, woher der zusätzliche organisatorische Aufwand bei einer Camunda-8-Migration kommt, ist es wichtig, die wesentlichen technischen Differenzen zwischen Camunda 7 und Camunda 8 zu beleuchten. Diese Unterschiede helfen dabei aufzuzeigen, warum sich der Betrieb nicht mehr „nebenbei“ in einem einzigen Team abbilden lässt und warum sich daraus ein größerer Bedarf an spezialisiertem Wissen ergibt.

• Camunda 7
• Monolithische Engine, die meist direkt in Java-Anwendungen eingebettet wurde oder als Remote Engine pro Projekt verwendet wurde.
• Häufiger Ansatz: Das Stream-Aligned Team betreut sowohl die fachlichen Prozesse als auch die Technik der Engine.
• Einfache Nachvollziehbarkeit der Prozessdaten.
• Betrieb On-Premise ohne große Komplexität möglich.
• Camunda 8
• Verteilte Architektur: Eine hochskalierbare, dezentrale Prozess-Engine mit eigenen Komponenten wie Broker, Gateway und Elasticsearch.
• Benötigt tiefe Kenntnisse in Cloud-nativen Technologien (Kubernetes, verteilte Systeme, Monitoring).
• Höhere Komplexität beim Nachvollziehen der Prozessdaten, da keine relationale Speichertechnologie in der Engine verwendet wird.
• Deutlich komplexerer Betrieb, wenn On-Premise (und nicht in Camunda Cloud) genutzt wird.

Der grundlegende Unterschied ist also, dass Camunda 7 eher monolithisch, vergleichsweise leicht zu betreiben war und bekannte Speichertechnologien verwendet, während Camunda 8 auf eine verteilte Architektur setzt und somit einen deutlich höheren Aufwand bei Installation, Betrieb und Wartung mit sich bringt, speziell wenn es On Premise genutzt wird.

Auswirkungen auf die Nutzung und die Teamstruktur

Mit Camunda 7 konnte ein Stream-Aligned Team noch „nebenbei“ den Betrieb sicherstellen: Die Engine war vergleichsweise unkompliziert. Bei Camunda 8 hingegen stößt ein klassisches Stream-Aligned Team schnell an Grenzen:

• Technologische Tiefe: Die neue Architektur erfordert spezielles Wissen (Kubernetes, Messaging, Skalierbarkeit).
• Monitoring & Observability: Das Monitoring eines verteilten Systems ist komplexer als in einer integrierten Architektur.
• Wartung & Updates: Das Update- und Patch-Management der Camunda 8 Infrastruktur ist aufwendiger. Auch Themen wie Backups oder Disaster Recovery erfordern weiterreichende Kenntnisse in Operations.

Ein Stream-Aligned Team kann diese Expertise oft nicht vollumfänglich aufbauen und gleichzeitig die eigentliche Fachentwicklung stemmen. Es besteht daher die Gefahr von Engpässen und einer Überlastung einzelner Experten.

Plattform- oder Complicated-Subsystem-Team als Lösung

Um Camunda 8 On-Premise professionell zu betreiben, empfiehlt sich die Einführung eines speziellen Teams – je nach Kontext als Platform Team oder Complicated-Subsystem Team:

• Platform Team
• Stellt die Camunda-8-Infrastruktur als einen klar definierten Service für die Stream-Aligned Teams bereit. Das gilt sowohl für zentrale Cluster, als auch die Bereitstellungen von eigenen Instanzen.
• Ähnlich wie bei Datenbanken oder Kubernetes-Clustern entfällt für das Stream-Aligned Team der Betrieb, sodass sie sich auf die fachliche Umsetzung von Prozessen konzentrieren können. Complicated-Subsystem Team
• Hat tiefgehende Spezialkenntnisse in Kubernetes und ist verantwortlich für die Weiterentwicklung und Betreuung der BPM-Infrastruktur des Teams rund um Camunda 8.
• Arbeitet in enger Zusammenarbeit mit den Stream-Aligned Teams, um die Anforderungen umzusetzen

Welche Variante ist besser?

Ich würde empfehlen zunächst mit einem Complicated-Subsystem Team zu starten, um die Komplexität besser immer Griff zu haben. So können erste Erfahrungen gesammelt und durch eine enge Collaboration mit dem Stream-Aligned Team schnell Änderungen vorgenommen und Probleme beseitigt werden. Die Änderungs- und Innovationszyklen bleiben so zu Beginn kurz.

Sobald das Unternehmen eine gewisse Reife in der Nutzung von Camunda 8 erreicht und sich abzeichnet, dass der Bedarf an Prozessautomatisierung skaliert, kann das Complicated-Subsystem Team in ein Platform Team überführt werden. Damit wird die Lösung so bereitgestellt, dass die Stream-Aligned Teams die BPM-Plattform als Service nutzen können – ähnlich wie bei anderen zentralen Infrastrukturangeboten. Diese Transformation erfolgt in der Regel schrittweise und ermöglicht eine kontrollierte Skalierung über mehrere Projekte und Teams hinweg.

Wie Camunda SaaS die Komplexität reduziert

Alternativ zum On-Premise-Betrieb kann Camunda SaaS vieles vereinfachen. Dabei übernimmt der Hersteller die Bereitstellung und Wartung der verteilten Infrastruktur. Die Vorteile:

• Outsourcing des Betriebs: Das komplizierte Cluster-Management liegt bei Camunda.
• Skalierung on demand: Teams müssen sich nicht um die Skalierung der Engine kümmern.
• Schneller Einstieg: Weniger Initialaufwand in Wissen, Infrastruktur und Monitoring.

Dadurch entfällt die Notwendigkeit eines Plattform Teams und das Unternehmen kann wichtige Ressourcen anderweitig verwenden.

Zusammenfassung

Während Camunda 7 On-Premise problemlos von einem Stream-Aligned Team genutzt und betrieben werden konnte, ist das bei einem Camunda-8-Einsatz On-Premise deutlich aufwändiger. Die neue Architektur verlangt spezialisiertes Wissen rund um Cloud-native Technologien und verteilte Systeme. Ein Betrieb durch ein einzelnes Stream-Aligned Team übersteigt oft die vorhandene Expertise und Kapazität. Stattdessen sind dedizierte Experten-Teams gefragt, etwa als Platform Team oder Complicated-Subsystem Team.

Eine sinnvolle Herangehensweise ist es, zunächst mit einem Complicated-Subsystem Team zu starten und dieses Team im weiteren Verlauf zu einem Platform Team auszubauen, sobald das Unternehmen Camunda 8 stärker skaliert. Unternehmen, die diese Komplexität umgehen wollen, können auf Camunda SaaS zurückgreifen, wo Betrieb und Skalierung bereits vom Hersteller übernommen werden.

Dadurch bleibt mehr Freiraum in den Stream-Aligned Teams, um sich auf das fachliche Prozessdesign und die eigentliche Wertschöpfung zu konzentrieren. Ein punktuelles Enabling Team kann zusätzlich den Know-how-Aufbau beschleunigen und so eine reibungslose Migration zu Camunda 8 unterstützen.