ADR-013: BPM Engine Strategy — Camunda 7 Fork Evaluation & Replacement

Status

Proposed — Pending engineering team review

Context

The platform runs two active BPM workflows on Camunda 7.17.0 Community Edition (Gen 1 stack: Java 11 / Spring Boot 2.6.8):

1. Purchase Request (~10 states): payment → entitlements → wallet debit/credit → notifications → refunds
2. Shoutout Video (~12 states): offer → purchase → celebrity recording → FFmpeg/Mux → admin review → delivery

Additionally, 9 legacy BPM repos exist (broadcast variants, meet-and-greet, livestream, keepsake videos) — most are inactive or superseded.

Camunda 7 CE went End of Life in October 2025. No further security patches, bug fixes, or releases will be made. The repositories have been archived and marked deprecated.

Since EOL, four community forks have emerged. The target architecture (Session 11) initially proposed replacing BPM with Spring State Machine. This ADR revisits that assumption based on two key inputs:

1. Meet & Greet (the only Spring SM implementation) is completely retired — no Spring State Machine is running in production, and no team has active SM operational experience
2. Strategic intent to expand process-based capabilities — BPM is seen as a platform investment for future workflows, not just a legacy dependency to replace

Current BPM Footprint

Prior Spring State Machine Implementation (Retired)

The platform previously ran Spring State Machine for the Meet & Greet workflow, which has since been completely retired:

• Enum-based states (CelebState, FanState, ModerState — 8-12 states each)
• Redis persistence with PostgreSQL fallback
• Timer events for reminder notifications
• GraphQL mutations for manual state alignment

This implementation is no longer running in production. It cannot be cited as proven infrastructure. No team members are actively maintaining or operating Spring State Machine code.

Strategic Direction: BPM as Platform Capability

The platform roadmap anticipates expanding process-based capabilities significantly beyond the current 2 workflows. Potential future BPM use cases include:

• Expert onboarding workflows — multi-step verification, background checks, profile completion with SLAs
• Content approval pipelines — editorial review, compliance checks, publish/reject flows
• Event lifecycle management — proposal → approval → scheduling → promotion → execution → follow-up
• Subscription lifecycle — trial → conversion → renewal → cancellation → win-back campaigns
• Dispute resolution — fan complaint → expert response → admin mediation → resolution
• Custom expert workflows — experts defining their own fulfillment flows for new product types

This strategic intent means the BPM engine is an investment in platform capability, not overhead to minimize. The “overkill” argument that applied when evaluating for 2 simple workflows does not apply when evaluating for a platform-wide process orchestration strategy.

Decision

Adopt Operaton as the Camunda 7 replacement. Migrate existing BPMN workflows with minimal changes. Invest in BPM as a strategic platform capability for current and future process-based features.

Why Operaton Over Other Options

Alternatives Evaluated

Option 1: Operaton (Recommended)

Community-owned fork. v1.0 feature-complete, compatible with Camunda 7.24. Apache 2.0. Forming a German eingetragener Verein (registered association) for ownership. Spring Boot 4 support in Operaton 2.0 (April 2026).

Why chosen: Best combination of zero-effort migration, community governance (no vendor lock-in), and strategic extensibility. The platform already runs this engine — Operaton IS Camunda 7 with a different namespace. Choosing Operaton preserves all existing operational knowledge and BPMN assets while providing a foundation for future process-based capabilities.

Option 2: Fluxnova (FINOS / Linux Foundation)

Fork of Camunda 7 governed by FINOS under the Linux Foundation. Backed by Fidelity, NatWest, Deutsche Bank, Capital One. First release November 2025. Focused on audit-ready workflows for regulated financial services.

Why not chosen: Fluxnova’s focus on regulated financial services (audit compliance, consortium governance for banking) is more specialized than our needs. Operaton is more general-purpose. However, Fluxnova has the strongest governance model — if regulatory compliance requirements emerge, Fluxnova should be reconsidered.

Option 3: CIB Seven

Fork by CIB (German company). v2.1 released, Apache 2.0. Commercial support available. Roadmap includes Spring Boot 4 (May 2026), AI agent integration (Oct 2026).

Why not chosen: Reintroduces single-vendor dependency — the same risk pattern that led to Camunda 7 EOL. CIB Seven’s value proposition (commercial support, marketplace, AI agents) is compelling but the governance model is a concern.

Option 4: EximeeBPMS

Fork by Consdata (Polish company). Apache 2.0. First release Q2 2025. Focused on stability for existing Camunda 7 users.

Why not chosen: Smallest ecosystem of the four forks. No differentiated value for our use case.

Option 5: Spring State Machine

Embed lightweight state machine directly in the consolidated service. No external engine.

Why not chosen: Two critical factors changed from the initial Session 11 proposal:

1. Meet & Greet retirement eliminates the “proven pattern” argument. There is zero Spring SM production experience on this platform. The migration would be a greenfield rewrite with no operational precedent, versus a near-zero-effort fork migration that preserves existing BPMN files and operational knowledge.

2. Strategic intent to expand BPM usage. Spring SM is a reasonable choice if BPM is a legacy dependency to minimize. It is a poor choice if BPM is a platform capability to invest in. Each new workflow built on Spring SM requires custom state machine code, custom persistence, custom monitoring, and custom debugging. A proper BPM engine provides all of these out of the box and adds visual modeling, human task support, process versioning, and audit trails as the platform grows.

Decision Matrix

Weight rationale: “Strategic extensibility” is now the highest-weighted criterion (25%) because BPM is being evaluated as a platform investment, not just a migration decision. “Migration effort” remains high (20%) because we want to move off EOL Camunda 7 quickly. “Governance risk” is weighted equally (20%) because the Camunda 7 EOL was itself a governance failure — avoiding that pattern is a priority.

Operaton vs Fluxnova: Scores are nearly identical (9.1 vs 9.0). The tiebreaker is strategic fit: Operaton is general-purpose BPM while Fluxnova is focused on regulated financial services. For a fan-to-athlete engagement platform, Operaton is the better default. If compliance/audit requirements emerge, Fluxnova would become the better choice.

Migration Approach

1. Update Maven dependencies — replace org.camunda.bpm with Operaton equivalents. Operaton provides a migration utility for namespace changes.
2. Validate BPMN files — existing process definitions should work without modification (same BPMN 2.0 standard)
3. Test database compatibility — Operaton uses the same DB schema as Camunda 7.24. Verify against our 7.17.0 schema (may need schema migration scripts from 7.17 → 7.24 level)
4. Upgrade to Gen 2 stack — move BPM services from Java 11 / Spring Boot 2.6.8 to Java 21 / Spring Boot 3.x as part of migration (aligns with ADR-003)
5. Write BDD test scenarios for every state transition path (TDD — tests before implementation)
6. Run in parallel with Camunda 7 during validation (dual-write, compare outcomes)
7. Drain Camunda 7 instances — stop creating new process instances, wait for in-flight to complete
8. Switch traffic to Operaton
9. Remove Camunda 7 dependencies — update BPM repos, remove old engine from deployment

Schema Migration Consideration

Our Camunda engine is on 7.17.0 while Operaton targets 7.24 compatibility. There may be schema migrations needed between these versions. This is a known gap that needs validation:

• Camunda 7.17 → 7.24 schema changes should be documented in Camunda’s migration guides
• Operaton may provide migration tooling for this path
• If schema migration is complex, this becomes the highest-risk step — validate early

Future BPM Architecture Vision

With Operaton as the BPM foundation, future process-based capabilities can be built using standard BPMN:

┌─────────────────────────────────────────────────────┐
│                    Operaton BPM Engine                │
│  ┌──────────────┐  ┌──────────────┐  ┌────────────┐ │
│  │  Purchase     │  │  Shoutout    │  │  Expert    │ │
│  │  Workflow     │  │  Workflow    │  │  Onboarding│ │
│  └──────────────┘  └──────────────┘  └────────────┘ │
│  ┌──────────────┐  ┌──────────────┐  ┌────────────┐ │
│  │  Content     │  │  Event       │  │  Dispute   │ │
│  │  Approval    │  │  Lifecycle   │  │  Resolution│ │
│  └──────────────┘  └──────────────┘  └────────────┘ │
│                                                       │
│  ┌─────────────────────────────────────────────────┐ │
│  │  Shared: Cockpit │ Tasklist │ History │ Metrics  │ │
│  └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
         │              │              │
    ┌────┴────┐   ┌────┴────┐   ┌────┴────┐
    │RabbitMQ │   │Postgres │   │  Redis  │
    └─────────┘   └─────────┘   └─────────┘

Each new workflow is a BPMN file + service task implementations — not a custom state machine framework. Visual modeling, process versioning, instance monitoring, and audit trails come for free.

Hypothesis Background

Primary: Operaton (community-owned Camunda 7 fork) is the right BPM engine for the platform’s current workflows and strategic expansion into process-based capabilities.

• Evidence: Camunda 7 CE is EOL since October 2025 — replacement is mandatory (L2)
• Evidence: Both BPMN files show sequential state flows with conditional routing — existing processes are BPMN-native and would require rewriting for Spring SM (L1)
• Evidence: No human tasks in current workflows, but strategic roadmap anticipates human-in-the-loop processes (L0 — product intent, not verified requirements)
• Evidence: Platform already operates a Camunda 7 engine — Operaton preserves all operational knowledge (L2)
• Evidence: Meet & Greet Spring SM is completely retired — no alternative in-house BPM experience exists (L2)
• Evidence: Operaton v1.0 is compatible with Camunda 7.24, community-owned with no commercial capture risk (L1)

Alternative 1: Adopt Fluxnova (FINOS/Linux Foundation). - Not rejected — strongest governance model. Nearly tied with Operaton on scoring (9.0 vs 9.1). Preferred over Operaton if regulated-industry compliance requirements emerge.

Alternative 2: Spring State Machine. - Rejected for strategic reasons: does not scale to platform-wide process orchestration. Also rejected on practical grounds: no in-house production experience (Meet & Greet retired), requires full rewrite of both workflows, and each future workflow would require custom implementation rather than BPMN modeling.

Alternative 3: Stay on Camunda 7.17.0 CE (do nothing). - Rejected: EOL since October 2025. No security patches. Archived repositories. Running on deprecated Java 11 / Spring Boot 2.6.8. Unacceptable risk.

Falsifiability Criteria

• If Operaton schema migration from 7.17 → 7.24 level is prohibitively complex → evaluate Fluxnova (which may have different migration tooling) or CIB Seven
• If Operaton’s eingetragener Verein fails to materialize and the community fragments → migrate to Fluxnova (strongest institutional backing)
• If no new BPM-based workflows are created within 12 months → the strategic extensibility argument was premature; re-evaluate whether the engine overhead is justified
• If Operaton lags on Spring Boot 3.x/4.x support → evaluate Fluxnova or CIB Seven which have announced Spring Boot 4 timelines
• If regulatory audit requires specific certifications that Operaton lacks → evaluate Fluxnova (FINOS/banking consortium focus)

Evidence Quality

Overall: L0 (WLNK capped by schema migration path L0 and governance sustainability L0 — both need validation before committing)

Actions to Improve Assurance

Bounded Validity

• Scope: Purchase-request-bpm and shoutout-bpm workflows initially. Extends to all future process-based workflows as platform capability.
• Expiry: Re-evaluate Operaton vs Fluxnova if governance concerns materialize, or if regulated-industry requirements emerge.
• Review trigger: If schema migration from 7.17 proves prohibitively complex. If no new BPM workflows are created within 12 months (strategic argument invalidated). If Operaton releases stall or community fragments.
• Monitoring: Track Operaton release cadence, contributor activity, and eingetragener Verein legal status. Track schema migration success during implementation. Track number of new BPM workflows created to validate strategic investment thesis.

Consequences

Positive: - Eliminates EOL BPM engine dependency (Camunda 7.17.0 CE) - Near-zero migration effort — same engine, different namespace - Preserves existing BPMN files, database schema, and operational knowledge - Retains Cockpit for runtime process inspection - Retains BPMN visual process modeling for future workflows - Provides human task support, audit trails, process versioning for future capabilities - Community-owned governance — no single-vendor EOL risk - Each new workflow is a BPMN file, not a custom state machine framework - Aligns with strategic intent to expand process-based capabilities

Negative: - Continues to require BPM engine deployment (operational overhead vs embedded Spring SM) - Operaton governance is still maturing (eingetragener Verein not yet established) - Schema migration from 7.17 to 7.24 level may require careful planning - BPM services still on Gen 1 stack (Java 11 / Spring Boot 2.6.8) — must upgrade as part of migration - Keycloak identity sync plugin (cibseven-keycloak) must be replaced or ported to Operaton equivalents

Mitigated by: Schema migration validated early in implementation. Fallback to Fluxnova or CIB Seven if Operaton governance fails (all forks share the same codebase origin). Gen 2 stack upgrade done as part of migration, not as a separate effort.

Decision History

This ADR supersedes the Session 11 target architecture recommendation to use Spring State Machine. That recommendation was based on two assumptions that have since been invalidated:

1. Assumption: Meet & Greet Spring SM validates the pattern in production → Invalidated: Meet & Greet is completely retired
2. Assumption: BPM is a legacy dependency to minimize → Invalidated: Strategic intent is to expand BPM as a platform capability

The original analysis correctly identified that Spring SM is a good fit for 2 simple workflows with no human tasks. But “good fit for today’s 2 workflows” is a different question from “right strategic foundation for the platform’s process orchestration needs.”

Camunda 7 Fork Landscape Reference (as of February 2026)

Decision date: 2026-02-01 Review by: 2026-08-01