Migration von Appway zu Camunda (mit CIB seven): Einführung und Motivation

1. Einleitung
   Willkommen zur dreiteiligen ONLU-Blogserie „Migration von Appway zu Camunda (mit CIB seven)“. Wir liefern wir Ihnen fundiertes Expertenwissen – von den Beweggründen über die technische Umsetzung bis hin zu praxiserprobten Best Practices.

Inhaltsverzeichnis

1. 1. Teil 1: Einführung & Motivation

1. 1. Teil 2: Architektur & Integration

1. 1. Teil 3: Best Practices & Migrationsstrategien

Hintergrund: Warum von Appway auf Camunda wechseln?

Appway gilt seit Jahren als einer der führende BPM-Plattform, vor allem im Finanzsektor – insbesondere für digitale Onboarding-Prozesse in Banken. Allerdings handelt es sich um eine proprietäre Lösung, deren Anpassung und Weiterentwicklung stark vom Hersteller abhängig ist. Solche monolithischen Automatisierungs-Plattformen erfordern oft umfangreiche kundenspezifische Anpassungen, was Vendor Lock-in und technischen Schulden Vorschub leistet. Mit anderen Worten: Je mehr Speziallogik in Appway implementiert wurde, desto stärker steigt die Abhängigkeit vom Hersteller und desto schwieriger wird eine spätere Ablösung. Zudem können umfangreiche Customization-Projekte die Auslieferung neuer Funktionen verlangsamen und die Flexibilität einschränken.

Camunda bietet hier einen modernen Gegenentwurf. Als offene BPM-Plattform auf Basis des ISO-Standards BPMN 2.0 ermöglicht Camunda eine transparente, standardisierte Abbildung von Prozessen – ohne proprietäre Modellierung. BPMN-Modelle liegen als XML vor, was einen herstellerunabhängigen Austausch erlaubt. So lassen sich Modelle prinzipiell von einem Tool ins andere übertragen, ohne neu modellieren zu müssencamunda.com. Dadurch wird Vendor Lock-in auf Prozess-Ebene vermiedencamunda.com. Ausserdem ist Camunda quelloffen (Community Edition) und kann on-premise betrieben werden. Insbesondere mit dem Fork CIB seven steht eine langfristig unterstützte Open-Source-Variante der Camunda 7 Engine zur Verfügung, ohne Lizenzkosten und mit voller digitaler Souveränität für den Betreiberonlu.ch. Diese Offenheit und Standard-Konformität erhöhen die Zukunftssicherheit: Prozesse können bei Bedarf auch in anderen BPMN-Systemen weitergenutzt oder ausgetauscht werden.

Ein weiterer Aspekt ist die moderne Architektur: Camunda lässt sich leicht in Microservice-Landschaften integrieren (z.B. als eingebettete Engine in Spring-Boot-Services) und skaliert flexibel. Im Gegensatz dazu stehen ältere BPM-Suiten wie Appway, die oft als umfassende Suite mit eigenem UI-Framework, Workflow-Engine und Datenhaltung daherkommen – was Änderungen an einzelnen Komponenten erschwert. Zusammengefasst motivieren also Vendor-Lock-in, Flexibilitätsanforderungen und der Wunsch nach einer modernen, cloud-fähigen Architektur viele Unternehmen dazu, von Appway auf Camunda umzusteigen.

Camunda als BPMN-Engine und CIB seven als ergänzende Komponente

Camunda zeichnet sich als schlanke BPMN-Workflow-Engine aus, die sowohl automatisierte Abläufe orchestrieren als auch menschliche Aufgaben (User Tasks) steuern kann. Wichtige Features wie BPMN 2.0-Unterstützung, eine DMN-Entscheidungsengine für Geschäftsregeln und offene REST/Java-APIs für Integrationen sind out-of-the-box vorhanden. Damit fokussiert sich Camunda auf die Rolle des Orchestrators im Backend – die Prozesslogik wird zentral ausführbar gemacht, während Fachlogik in Form von Services angebunden wird. Im Vergleich dazu beinhaltete Appway neben dem reinen Workflow-Management auch Funktionen wie integrierte Case Management-Flows und ein Dokumentenmanagement. Diese Zusatzfunktionen müssen bei einer Ablösung ggf. durch andere Systeme oder Komponenten ersetzt werden.

Eine wichtige Rolle bei der Migration spielt CIB seven, ein von der Firma CIB entwickelter Fork von Camunda 7. CIB seven ist eine zu Camunda 7 voll kompatible Weiterentwicklung der Engine und wird ab Ende 2024 als Open-Source-Projekt betreut onlu.ch. Für Anwender bedeutet das: Bestehende Camunda 7 Prozesse, APIs und Modelle laufen unverändert weiter onlu.ch. CIB seven adressiert insbesondere die langfristige Unterstützung der Camunda-Engine (Stichwort Camunda 7 EoL) und bietet bereits zusätzliche Funktionen und eine moderne Oberfläche in Aussicht onlu.ch. Als Ergänzung dazu gibt es CIB flow, eine Low-Code-BPM-Plattform von CIB, die auf CIB seven aufbaut onlu.ch. CIB flow stellt eine webbasierte Oberfläche für Modellierung und Ausführung bereit, inklusive Formular-Designer, vordefinierten Konnektoren zu Drittsystemen und UI-Modulen (Tasklist, Admin, Monitoring) onlu.ch. Damit entsteht in Kombination eine benutzerfreundliche Komplettlösung, welche die Camunda-Engine im Hintergrund nutzt, aber ähnlich wie Appway eine integrierte Modellierungs- und Präsentationsschicht bietet.

In der Praxis kann ein migriertes System also folgendermassen aussehen: Camunda/CIB seven übernimmt unsichtbar die Ausführung der BPMN-Prozesse, während CIB flow oder ein individuelles Frontend die Benutzerschnittstelle und Formularlogik darstellt. Unternehmen haben hier die Wahl, entweder auf eine Low-Code-Plattform (wie CIB flow) zu setzen, um schneller voranzukommen, oder ein eigenes Frontend (z.B. in Angular) zu entwickeln, das über Camundas REST-APIs mit der Engine kommuniziert. Beide Ansätze lösen den bisherigen Appway „All-in-One“-Stack in eine flexiblere Schichtenarchitektur auf: einerseits der Prozess-Orchestrator Camunda, andererseits frei wählbare UI- und Service-Komponenten.

Herausforderungen bei der Migration von Appway zu Camunda

Die Ablösung eines gewachsenen Appway-Systems bringt verschiedene technische und organisatorische Herausforderungen mit sich. Im Folgenden die wichtigsten Punkte und wie man ihnen begegnen kann:

• • Legacy-Schnittstellen (SOAP-Webservices): Viele Appway-Installationen integrieren externe Systeme über SOAP-APIs. Camunda setzt zwar primär auf REST, kann aber ebenfalls SOAP-Endpunkte ansprechen – etwa mittels Connector oder Service Task. So existiert ein vorgefertigter SOAP HTTP Connector in Camunda, mit dem sich SOAP-Requests (URL, Payload, Headers etc.) direkt aus einem Prozess heraus ausführen lassen docs.camunda.org. In der Migrationspraxis sollte man prüfen, welche Schnittstellen modernisiert werden können (z.B. Umstellung auf REST oder Messaging) und welche vorerst via Camunda angebunden werden müssen. Die Erfahrung zeigt, dass es sinnvoll ist, bei der Migration zunächst Kompatibilität zu bestehenden Schnittstellen herzustellen – also Camunda so zu erweitern, dass es die alten SOAP-Services nutzt – um dann in einem zweiten Schritt die Schnittstellen selbst zu modernisieren (z.B. durch neue Microservices).

• • Ausgelagerte Geschäftslogik: In Appway können Geschäftsregeln und Logik teils in Prozessen (z.B. als Skripte) stecken, teils in externen Java-Komponenten oder Datenbank-Prozeduren „ausgelagert“ sein. Eine Herausforderung ist, diese verteilte Logik beim Umstieg vollständig zu erfassen und neu zu implementieren. Best Practice ist, dabei so viel wie möglich von der Logik aus dem Workflow selbst ins Backend zu verlagern. Konkret bedeutet dies, dass der Camunda-Prozess idealerweise nur den Ablauf steuert (Sequenz, Zuweisung von Tasks, Aufruf von Services), während die fachliche Berechnung in externen Services oder DMN-Entscheidungstabellen erfolgt. Dadurch bleibt der Prozess schlank und änderbar, ohne bei jeder Logikanpassung neu deployt werden zu müssen. In Appway eingebettete Skripte müssen in Java-Services oder Regeln übertragen werden. Diese Entkopplung erfordert anfangs etwas Architekturarbeit, zahlt sich aber langfristig in besserer Wartbarkeit aus.

• • Neubau des Frontends: Appway bringt einen eigenen UI-Layer mit (z.B. sogenannte Screen Tasks, Formulare und Kollaborations-Features innerhalb der Plattform). Bei einem Wechsel auf Camunda steht man vor der Aufgabe, die Benutzeroberfläche komplett neu aufzubauen. Camunda liefert keine fertigen Endanwender-Oberflächen für Prozesse mit – abgesehen von technischen Admin-Tools (Cockpit) und einer einfachen Tasklist für Human Tasks. In der Regel entscheiden sich Unternehmen hier für moderne Web-Frameworks wie Angular oder React, um die User Experience nach ihren Wünschen zu gestalten. Das bedeutet einen erheblichen Aufwand: alle Appway-Dialoge, Formulare und Benutzerinteraktionen müssen neu entwickelt werden. Alternativ kann – wie oben erwähnt – ein Low-Code-Ansatz mit CIB flow gewählt werden, wo ein Formular-Designer bereits existiert onlu.ch. Beide Wege erfordern jedoch, dass man die bisher in Appway definierten UI-Flows rekonstruiert. Praktisch sollte früh ein UX-Konzept erstellt werden, das die bestehenden Appway-Oberflächen analysiert und als Vorlage für das neue Frontend dient. Oft bietet es sich an, die Gelegenheit zu nutzen, um das Frontend zu modernisieren oder zu vereinheitlichen, anstatt es 1:1 nachzubauen.

• • Datenübernahme und laufende Prozesse: Nicht zu vergessen ist die Frage, was mit bereits laufenden Workflows und bestehenden Daten passiert. Appway-Prozesse, die zum Zeitpunkt der Umstellung noch nicht abgeschlossen sind, können meist nicht ohne Weiteres in Camunda weitergeführt werden, da die Modelle und internen IDs anders sind. Hier gibt es zwei Strategien: Entweder lässt man alte Fälle im Appway-System auslaufen (Parallelbetrieb, siehe Best Practices unten), oder man versucht eine transparente Migration laufender Instanzen durchzuführen. Letzteres ist komplex – man müsste den Zustand jedes Appway-Prozesses extrahieren und in einem äquivalenten Camunda-Prozess wiederherstellen. Aufgrund dieser Komplexität wird in der Praxis häufig auf einen Big-Bang mit Instanz-Migration verzichtet und stattdessen mit Parallelbetrieb gearbeitet (siehe unten „selektive Migration“). Zusätzlich müssen Stammdaten oder Dokumente aus Appway (etwa im internen DMS von Appway gespeicherte Dateien) in neue Systeme migriert oder angebunden werden. Eine gründliche Datenanalyse vorab ist daher essentiell, um nichts zu übersehen. Variante 3 ist ein Big-Bang-Ansatz mit dem Abschluss aller Prozessinstanzen zum Stichtag. Ab dem Go-Live-Termin werden sämtliche Prozesse ausschliesslich über die neue Plattform abgewickelt – das Altsystem ist damit vollständig abgeschaltet

Im nächsten Beitrag steigen wir tiefer in die Architektur ein und zeigen, wie Camunda und CIB seven konkret in moderne Microservice-Landschaften integriert werden können – inklusive Best Practices für den sanften Umstieg.

1. Teil 1: Einführung & Motivation Teil 2: Architektur & Integration Teil 3: Best Practices & Migrationsstrategien

• • • • Appway Hintergrund und Übernahme durch FNZ fnz.com

• • • • Herausforderungen monolithischer BPM-Plattformen (Vendor Lock-in) camunda.com

• • • • BPMN-Standard verhindert Vendor Lock-in camunda.com

• • • • Camunda vs. Appway – Funktionen im Vergleich softwaresuggest.com

• • • • CIB seven und CIB flow – Beschreibung der Komponenten onlu.ch

• • • • CIB seven Vorteile (Open Source, Kompatibilität) onlu.ch

• • • • Camunda SOAP-Integration (Connector) docs.camunda.org

• • • • Camunda & Kafka Zusammenspiel camunda.com

• • • • Event-getriebene Orchestrierung mit Camunda (Beispiel) medium.com

• • • • Migrationsstrategien Parallel vs. Big Bang camunda.com