Camunda Platform Overview

Fokus part ini: membangun peta mental ekosistem Camunda agar Anda tidak mencampuradukkan Camunda 7, Camunda 8, Zeebe, embedded engine, remote orchestration engine, worker, Tasklist, Cockpit, Operate, Optimize, Identity, dan Connectors.

Camunda sering terlihat sederhana dari luar: ada BPMN diagram, lalu diagram itu “dijalankan”. Untuk senior backend engineer, itu terlalu dangkal.

Yang perlu dipahami adalah bahwa Camunda bukan hanya BPMN modeler. Camunda adalah ekosistem runtime, deployment, execution, task management, observability, identity, integration, dan operational tooling untuk process orchestration.

Dalam enterprise backend system, terutama Java/JAX-RS service yang berinteraksi dengan PostgreSQL, Kafka, RabbitMQ, Redis, Kubernetes, cloud, on-prem, dan sistem eksternal, kesalahan memahami komponen Camunda bisa menyebabkan desain yang salah sejak awal.

Contoh kesalahan umum:

• mengira Camunda 7 dan Camunda 8 hanya beda versi minor;
• mengira JavaDelegate di Camunda 7 sama dengan Zeebe job worker di Camunda 8;
• mengira Cockpit dan Operate adalah tool yang sama;
• mengira Tasklist adalah sumber kebenaran task business;
• mengira workflow engine boleh dipakai sebagai database bisnis;
• mengira BPMN deployment sama dengan application deployment;
• mengira retry engine cukup untuk menjamin correctness side effect;
• mengira semua failure workflow otomatis recoverable.

Part ini memberi peta besar sebelum masuk ke detail execution model.

1. Apa Itu Camunda?

Camunda adalah platform untuk process orchestration dan process automation.

Secara praktis, Camunda membantu sistem menjalankan proses bisnis yang:

• punya banyak langkah;
• berlangsung lama;
• melibatkan beberapa service;
• melibatkan manusia;
• membutuhkan approval;
• membutuhkan timeout dan SLA;
• membutuhkan retry dan incident visibility;
• membutuhkan audit trail;
• membutuhkan integrasi sistem eksternal;
• membutuhkan koordinasi state lintas entity dan service.

Dalam konteks CPQ dan order management, contoh proses yang cocok untuk workflow orchestration:

• quote approval;
• pricing exception approval;
• contract review;
• order validation;
• order decomposition;
• fulfillment orchestration;
• fallout handling;
• cancellation;
• amendment;
• renewal;
• manual intervention;
• customer-impacting reconciliation.

Camunda bukan sekadar library Java. Camunda juga bukan sekadar queue. Camunda adalah execution runtime untuk model proses.

2. Dua Dunia Besar: Camunda 7 dan Camunda 8

Camunda 7 dan Camunda 8 harus dipahami sebagai dua model arsitektur yang berbeda.

Camunda 7

Camunda 7 adalah Java-based BPMN process engine.

Ciri mental model utamanya:

• process engine berbasis Java;
• runtime state disimpan di relational database;
• bisa embedded di aplikasi Java;
• bisa berjalan sebagai shared engine di application server;
• automation bisa menggunakan JavaDelegate;
• automation bisa juga menggunakan external task worker;
• job executor mengambil dan menjalankan asynchronous jobs;
• Cockpit digunakan untuk monitoring dan operasi process instance;
• Tasklist digunakan untuk user task;
• History Service dan history tables penting untuk audit dan observability.

Camunda 7 terasa dekat dengan enterprise Java application karena engine-nya bisa berada di dalam runtime aplikasi yang sama.

Implikasinya:

• classpath aplikasi memengaruhi delegate;
• transaksi aplikasi dan engine bisa sangat dekat;
• database Camunda menjadi bagian kritikal runtime;
• deployment aplikasi bisa ikut memengaruhi process execution;
• job executor tuning menjadi penting;
• history cleanup dan database performance menjadi concern besar.

Camunda 8

Camunda 8 adalah distributed process orchestration platform yang menggunakan Zeebe sebagai workflow engine.

Ciri mental model utamanya:

• engine berjalan sebagai remote orchestration runtime;
• Zeebe broker menyimpan dan mengeksekusi workflow state;
• Zeebe gateway menjadi entry point client/worker;
• automation dijalankan oleh job worker eksternal;
• worker berkomunikasi dengan Zeebe melalui API;
• Operate digunakan untuk observability process instance dan incident;
• Tasklist digunakan untuk human task;
• Identity mengelola user, group, role, permissions;
• Connectors bisa dipakai untuk integrasi external systems;
• deployment bisa SaaS/cloud atau self-managed;
• self-managed deployment biasanya terkait Kubernetes, storage, search dependency, networking, dan observability stack.

Camunda 8 bukan embedded Java engine. Java/JAX-RS service tidak “menjalankan engine” secara langsung. Service lebih sering menjadi client atau worker yang berinteraksi dengan orchestration cluster.

Implikasinya:

• application deployment dan workflow engine deployment lebih terpisah;
• worker contract menjadi boundary utama;
• idempotency worker menjadi lebih penting;
• network failure antara worker dan engine harus dipikirkan;
• partitioning, backpressure, exporter, dan search dependency menjadi concern operasional;
• observability perlu mencakup broker, gateway, worker, Operate, Tasklist, Identity, dan dependency eksternal.

3. Mengapa Perbedaan Ini Penting untuk Senior Backend Engineer?

Karena desain yang benar di Camunda 7 bisa menjadi desain yang salah di Camunda 8.

Contoh:

Camunda 7 JavaDelegate mindset

public class ReserveInventoryDelegate implements JavaDelegate {
  @Override
  public void execute(DelegateExecution execution) {
    String orderId = (String) execution.getVariable("orderId");
    inventoryService.reserve(orderId);
  }
}

Mental model:

• delegate dipanggil oleh engine;
• code berada dekat dengan process engine;
• exception bisa menyebabkan job retry;
• transaction boundary bisa dekat dengan engine transaction;
• classpath dan dependency injection memengaruhi behavior.

Camunda 8 job worker mindset

@JobWorker(type = "reserve-inventory")
public void reserveInventory(final ActivatedJob job) {
  String orderId = (String) job.getVariablesAsMap().get("orderId");
  inventoryService.reserve(orderId);
}

Mental model:

• Zeebe membuat job;
• worker eksternal mengaktifkan job;
• worker melakukan side effect;
• worker complete/fail job;
• worker bisa crash setelah side effect tetapi sebelum complete;
• idempotency wajib dipikirkan;
• timeout, retry, duplicate execution, dan graceful shutdown adalah correctness concern.

Dari luar dua potongan code ini terlihat sama-sama “service task implementation”. Secara operational semantics, keduanya berbeda.

4. Camunda Modeler

Camunda Modeler adalah tool untuk membuat BPMN, DMN, dan form artifact.

Dalam engineering workflow, Modeler bukan hanya drawing tool. Modeler adalah authoring tool untuk artifact yang nanti dipakai runtime.

Artifact yang mungkin dibuat:

• BPMN process model;
• DMN decision table;
• forms untuk user task;
• connector template/configuration;
• deployment artifact.

Hal penting:

• BPMN harus diperlakukan sebagai source artifact;
• BPMN perlu code review;
• BPMN perlu versioning;
• BPMN perlu test;
• BPMN perlu deployment pipeline;
• BPMN perlu rollback strategy;
• BPMN perlu ownership.

Anti-pattern:

• BPMN hanya disimpan lokal oleh BA;
• BPMN diubah langsung di environment tanpa PR;
• BPMN tidak punya version tag;
• BPMN tidak dites;
• BPMN diagram berbeda dari behavior production;
• BPMN hanya “dokumentasi”, sementara logic real ada di service code.

5. Process Engine, Workflow Engine, dan Orchestration Engine

Istilah ini sering dipakai bergantian, tetapi sebaiknya dibedakan.

Process engine

Process engine menjalankan process definition.

Di Camunda 7, istilah process engine sangat literal: Java process engine menjalankan BPMN, mengelola runtime tables, jobs, tasks, variables, incidents, dan history.

Workflow engine

Workflow engine adalah runtime yang mengeksekusi alur kerja.

Workflow engine tidak hanya “memanggil step”. Ia menjaga:

• posisi eksekusi;
• variable;
• wait state;
• timers;
• messages;
• retries;
• incidents;
• task lifecycle;
• process completion.

Orchestration engine

Orchestration engine menekankan koordinasi lintas sistem.

Di Camunda 8, istilah orchestration lebih cocok karena Zeebe mengorkestrasi:

• workers;
• external services;
• human tasks;
• timers;
• messages;
• connectors;
• long-running processes.

Orchestration engine bukan service bus. Ia tidak seharusnya menjadi tempat semua data, semua business rules, atau semua domain state disimpan.

6. Camunda 7 Component Mental Model

Camunda 7 biasanya terdiri dari beberapa area besar.

6.1 Process Engine

Core runtime yang menjalankan BPMN.

Tanggung jawab:

• deploy process definition;
• start process instance;
• move execution token;
• evaluate gateway;
• create user task;
• create jobs;
• execute jobs;
• manage variables;
• manage incidents;
• write history.

6.2 Repository Service

Mengelola deployment dan process definition.

Pertanyaan review:

• process definition version berapa yang aktif?
• deployment artifact berasal dari pipeline mana?
• apakah BPMN deployed manual atau otomatis?
• apakah version tag digunakan?

6.3 Runtime Service

Mengelola process instance yang sedang berjalan.

Dipakai untuk:

• start process;
• correlate message;
• query instance;
• update variable;
• signal execution jika applicable.

6.4 Task Service

Mengelola user task.

Dipakai untuk:

• query task;
• claim task;
• assign task;
• complete task;
• update task variable;
• manage candidate user/group.

6.5 History Service

Menyediakan data historis.

Concern:

• audit requirement;
• retention;
• history level;
• query performance;
• data privacy;
• cleanup.

6.6 Management Service

Mengelola jobs, incidents, dan operational command tertentu.

Concern:

• failed job;
• retry;
• incident resolution;
• job definition;
• job executor behavior.

6.7 Job Executor

Komponen yang mengambil dan menjalankan asynchronous jobs.

Job executor sangat penting untuk:

• async service task;
• timer;
• retry;
• failed job;
• incident;
• throughput;
• transaction boundary.

Jika job executor bermasalah, process bisa terlihat “stuck” walaupun BPMN benar.

6.8 Cockpit

Tool operasional untuk melihat process definitions, process instances, incidents, jobs, variables, dan runtime state.

Cockpit cocok untuk operator dan engineer.

6.9 Tasklist

Tool untuk user task.

Tasklist cocok untuk manusia yang perlu claim, inspect, dan complete task.

Namun dalam enterprise product, sering ada custom task UI. Jika demikian, Tasklist mungkin hanya tool internal/debugging atau bahkan tidak digunakan.

6.10 Optimize

Tool analytics/process intelligence jika digunakan.

Concern:

• process KPIs;
• bottleneck;
• SLA;
• throughput;
• aging;
• business monitoring.

Internal verification diperlukan karena tidak semua instalasi Camunda 7 memakai Optimize.

7. Camunda 8 Component Mental Model

Camunda 8 memiliki mental model berbeda.

7.1 Orchestration Cluster / Zeebe Runtime

Pada Camunda 8, core orchestration runtime berpusat pada Zeebe. Pada versi tertentu, komponen inti seperti Zeebe, Operate, Tasklist, dan Identity dapat dikemas atau dioperasikan dengan model deployment yang berubah mengikuti versi platform.

Karena itu, jangan menghafal topology secara statis. Selalu verifikasi versi Camunda 8 yang dipakai.

Yang perlu dipahami:

• Zeebe broker menjalankan process orchestration;
• gateway menjadi entry point client dan worker;
• partition membagi workload;
• log stream menyimpan record eksekusi;
• exporter mengirim data untuk observability/search;
• Operate membaca data operasional;
• Tasklist membaca dan mengelola user task;
• Identity mengelola access;
• Connectors menjalankan integrasi tertentu.

7.2 Zeebe Broker

Broker adalah inti execution runtime.

Tanggung jawab konseptual:

• menyimpan workflow state;
• memproses commands;
• membuat jobs;
• menangani timers;
• menangani message correlation;
• membuat incidents;
• menulis records;
• menjaga partition state.

Broker bukan application service. Jangan menaruh business logic Java di broker.

7.3 Zeebe Gateway

Gateway adalah entry point untuk client dan worker.

Dipakai untuk:

• deploy process;
• start process instance;
• activate job;
• complete job;
• fail job;
• throw BPMN error;
• publish message;
• query/operate melalui API sesuai kapabilitas versi.

Gateway memisahkan worker/client dari broker topology internal.

7.4 Partition

Partition adalah pembagian state/workload Zeebe.

Implikasi:

• throughput dipengaruhi partitioning;
• process instance diarahkan ke partition tertentu;
• broker health dan partition leadership penting;
• backpressure bisa muncul;
• scaling tidak sama dengan menambah pod worker saja.

7.5 Job Worker

Worker adalah aplikasi eksternal yang mengambil job dari Zeebe.

Dalam konteks Java/JAX-RS system, worker bisa berada:

• di service yang sama dengan REST API;
• di dedicated worker service;
• di batch/consumer service;
• di Kubernetes deployment terpisah;
• di on-prem service yang connect ke cloud orchestration;
• di cloud service yang connect ke on-prem dependency.

Worker harus menangani:

• idempotency;
• timeout;
• retry;
• concurrency;
• backpressure;
• safe shutdown;
• external API failure;
• DB transaction failure;
• duplicate job execution;
• partial side effect.

7.6 Operate

Operate adalah tool untuk melihat dan mengoperasikan process instance di Camunda 8.

Dipakai untuk:

• process instance inspection;
• incident inspection;
• variable inspection;
• process path inspection;
• retry/resolution action tertentu;
• production triage.

Operate bukan replacement untuk domain dashboard. Operate menjawab pertanyaan runtime workflow, bukan seluruh business KPI.

7.7 Tasklist

Tasklist adalah UI untuk human tasks.

Concern:

• assignment;
• completion;
• form;
• due date;
• user identity;
• authorization;
• task aging;
• task search;
• stale task handling.

Jika product memiliki custom UI, Tasklist tetap perlu dipahami sebagai reference semantics.

7.8 Optimize

Optimize digunakan untuk process analytics jika tersedia dan digunakan.

Cocok untuk:

• bottleneck analysis;
• throughput analysis;
• SLA analysis;
• task aging;
• business process improvement;
• executive/process dashboard.

Namun operational alerting sering tetap membutuhkan metrics/logs/traces terpisah.

7.9 Identity

Identity mengelola access untuk komponen platform.

Concern:

• user;
• group;
• role;
• permission;
• tenant;
• service account;
• application access;
• worker credential;
• admin access.

Security review harus memastikan process/task/variable access tidak terlalu lebar.

7.10 Connectors

Connectors adalah integration mechanism untuk menghubungkan process dengan external systems.

Contoh connector:

• HTTP connector;
• inbound webhook connector;
• messaging connector jika tersedia/digunakan;
• custom connector.

Connector cocok untuk integrasi yang cukup generik. Untuk logic kompleks, idempotency berat, transaction dengan database bisnis, atau domain-specific retry, custom worker sering lebih aman.

8. Embedded Engine vs Remote Orchestration Engine

Ini salah satu perbedaan paling penting.

Embedded engine

Engine berada di dalam aplikasi.

Biasanya relevan untuk Camunda 7.

Kelebihan:

• integrasi Java mudah;
• delegate bisa langsung memakai service bean;
• deployment sederhana untuk aplikasi monolith/modular monolith;
• local debugging relatif mudah.

Risiko:

• coupling tinggi antara process engine dan aplikasi;
• classpath/dependency conflict;
• rolling deployment bisa memengaruhi job execution;
• job executor bisa berjalan di banyak node tanpa desain yang matang;
• database Camunda menjadi bottleneck;
• upgrade engine terkait aplikasi.

Remote orchestration engine

Engine berjalan terpisah dari aplikasi.

Biasanya relevan untuk Camunda 8/Zeebe.

Kelebihan:

• engine lifecycle terpisah;
• worker bisa diskalakan independen;
• orchestration cluster dapat menjadi platform shared;
• lebih natural untuk microservices;
• lebih jelas boundary antara process orchestration dan service logic.

Risiko:

• network dependency;
• worker timeout dan duplicate execution;
• operational complexity lebih tinggi;
• observability harus lintas komponen;
• schema/contract antar process-worker harus disiplin;
• local development bisa lebih kompleks.

9. Camunda dalam Java/JAX-RS Backend System

Dalam Java/JAX-RS system, Camunda biasanya muncul dalam beberapa pola.

Pattern A: REST API starts a process

Client
  -> JAX-RS API
    -> validate request
    -> create business record
    -> start process instance
    -> return 202 Accepted + tracking id

Cocok untuk long-running workflow.

Concern:

• idempotency key;
• business key;
• correlation ID;
• process version;
• DB transaction boundary;
• what happens if DB commit succeeds but process start fails;
• what happens if process starts but API response fails.

Pattern B: Worker calls domain service

Camunda job
  -> Java worker
    -> domain service
      -> PostgreSQL/MyBatis
      -> Kafka/RabbitMQ publish
    -> complete/fail job

Concern:

• side effect idempotency;
• retry safety;
• worker transaction;
• outbox pattern;
• duplicate job execution;
• worker crash after DB commit;
• complete job failure after side effect.

Pattern C: External event correlates to process

Kafka/RabbitMQ/API callback
  -> consumer/API
    -> validate event
    -> correlate message to process instance

Concern:

• correlation key;
• duplicate event;
• late event;
• missing process instance;
• event replay;
• message expiration;
• ordering assumption.

Pattern D: User completes task through custom UI

User UI
  -> JAX-RS Task API
    -> authorize user
    -> validate form
    -> complete user task
    -> update business state if needed

Concern:

• task visibility;
• stale task;
• concurrent completion;
• claim/unclaim;
• audit;
• form validation;
• domain invariant.

10. Camunda and PostgreSQL/MyBatis/JDBC

PostgreSQL can appear in two different roles.

10.1 Camunda runtime database

Relevant mostly for Camunda 7.

The database stores engine runtime and history state.

Concern:

• runtime tables;
• history tables;
• variable serialization;
• job tables;
• incident tables;
• indexes;
• cleanup;
• transaction isolation;
• connection pool;
• backup/restore.

10.2 Business application database

Relevant for both Camunda 7 and Camunda 8.

The business database stores quote/order/customer/product/agreement state.

Concern:

• workflow variable vs database state;
• outbox table;
• inbox table;
• idempotency table;
• optimistic locking;
• state transition table;
• audit table;
• process instance mapping;
• migration impact.

Critical rule:

Do not use process variables as your primary business database.

Process variables are orchestration context. Business state belongs in the domain database unless there is a very explicit reason otherwise.

11. Camunda and Kafka/RabbitMQ/Redis

Kafka

Kafka is usually event stream infrastructure.

Common workflow roles:

• event starts process;
• event correlates message;
• worker publishes event;
• outbox publishes event after DB commit;
• workflow reacts to external state change;
• process drives downstream integration.

Failure modes:

• duplicate event;
• out-of-order event;
• replay starts duplicate process;
• schema evolution breaks worker;
• correlation key mismatch;
• event published before DB commit;
• process completed before late event arrives.

RabbitMQ

RabbitMQ is usually command/task messaging infrastructure.

Common workflow roles:

• command starts process;
• worker receives command;
• reply message correlates to process;
• DLQ captures failed command;
• retry queue interacts with workflow retry.

Failure modes:

• retry storm from both RabbitMQ and Camunda;
• dead-lettered reply never correlated;
• duplicate command;
• routing key mismatch;
• message TTL expires before process wait state exists.

Redis

Redis is usually supporting infrastructure.

Common roles:

• idempotency cache;
• distributed lock;
• rate limiter;
• worker coordination;
• process status cache;
• feature flag;
• kill switch;
• temporary lookup cache.

Failure modes:

• lock expires while worker still running;
• cache lies about process status;
• Redis outage disables worker coordination;
• idempotency key evicted too early;
• Redis becomes hidden source of truth.

12. Camunda in Kubernetes, Cloud, On-Prem, and Hybrid Environments

Camunda in production is infrastructure-sensitive.

Kubernetes concerns

• StatefulSet vs Deployment;
• resource request/limit;
• liveness/readiness probe;
• PodDisruptionBudget;
• anti-affinity;
• persistent volume;
• secret management;
• ingress/network policy;
• horizontal scaling;
• rolling upgrade;
• worker safe shutdown;
• GitOps drift.

AWS concerns

• EKS;
• RDS/PostgreSQL if Camunda 7 database is used;
• OpenSearch/Elasticsearch if Camunda 8 search dependency is used;
• S3 backup;
• IAM/service account;
• Secrets Manager;
• CloudWatch;
• VPC/private endpoint/security group.

Azure concerns

• AKS;
• Azure Database for PostgreSQL;
• managed search dependency if used;
• Blob backup;
• Key Vault;
• Azure Monitor;
• managed identity;
• VNet/private endpoint/NSG.

On-prem/hybrid concerns

• firewall;
• TLS/internal CA;
• air-gapped deployment;
• patch management;
• backup ownership;
• monitoring ownership;
• cloud-to-on-prem connectivity;
• worker connectivity across network boundary;
• customer-managed infrastructure.

For CSG context, do not assume which topology is used. Verify actual deployment.

13. Platform Capability Map

14. What You Must Not Assume in CSG

Do not assume:

• CSG uses Camunda;
• CSG uses Camunda 7;
• CSG uses Camunda 8;
• CSG uses both;
• CSG uses BPMN for quote/order workflow;
• CSG uses DMN;
• CSG uses Tasklist;
• CSG uses Cockpit or Operate;
• CSG uses Optimize;
• CSG uses Connectors;
• CSG stores process state in PostgreSQL;
• CSG runs Camunda in Kubernetes;
• CSG uses AWS or Azure for Camunda runtime;
• CSG deploys BPMN through GitOps;
• CSG has standard retry policy;
• CSG has standard incident ownership.

You can use this series as a mental model, but actual system understanding must come from codebase, diagrams, manifests, dashboards, runbooks, and team discussions.

15. Internal Verification Checklist

Use this checklist when entering a new codebase or architecture discussion.

Platform/version

• Is Camunda used at all?
• Is it Camunda 7, Camunda 8, both, or migration in progress?
• What exact version is deployed?
• Is Camunda 7 Enterprise support/EOL relevant?
• Is Camunda 8 deployment using older separate components or newer orchestration cluster packaging?

Runtime topology

• Is the engine embedded, shared, or remote?
• Where does the engine run?
• Where do workers run?
• Are workers part of existing Java/JAX-RS services or separate services?
• Are workers deployed in Kubernetes?
• Are any workers on-prem while engine is cloud-based, or vice versa?

Artifact ownership

• Where are BPMN files stored?
• Where are DMN files stored?
• Are forms stored as code?
• Who reviews BPMN changes?
• Is there a process model approval workflow?
• Are BA/product involved in process modelling?

Deployment

• How are BPMN/DMN artifacts deployed?
• Is deployment manual or pipeline-driven?
• Is version tag used?
• Are process definitions promoted across environments?
• Is rollback defined?
• Is process migration supported or avoided?

Tooling

• Is Camunda Modeler used?
• Is Cockpit used?
• Is Operate used?
• Is Tasklist used?
• Is Optimize used?
• Are internal dashboards used instead?

Integration

• Which Java services start process instances?
• Which services act as workers?
• Which process steps call PostgreSQL/MyBatis/JDBC?
• Which steps publish Kafka events?
• Which steps use RabbitMQ?
• Is Redis used for idempotency, lock, cache, or coordination?

Operations

• Where are incidents viewed?
• Who owns incident resolution?
• How are retries triggered?
• How are stuck process instances repaired?
• Are worker metrics available?
• Are process SLA metrics available?
• Are task aging metrics available?

Security

• Who can view process variables?
• Who can complete user tasks?
• Are sensitive variables redacted?
• Are connector secrets protected?
• Are worker credentials rotated?
• Is tenant isolation required?

16. Senior Engineer Heuristics

Heuristic 1: Diagram is not the system

The BPMN diagram is only one part of the system.

The real system includes:

• BPMN;
• worker code;
• business database;
• API contract;
• message broker;
• retry policy;
• incident handling;
• dashboards;
• runbooks;
• deployment pipeline;
• people operating manual tasks.

Heuristic 2: Runtime semantics matter more than visual shape

Two diagrams can look similar but behave differently because of:

• async boundary;
• timer configuration;
• message correlation;
• variable mapping;
• worker retry;
• gateway condition;
• transaction boundary;
• incident behavior.

Heuristic 3: Every service task is a failure boundary

For every service task ask:

• What external system is touched?
• Is the operation idempotent?
• What happens if the worker crashes after side effect?
• What happens if completion fails?
• What is retried?
• What is not retried?
• Who owns the incident?

Heuristic 4: Human task is operational debt unless designed carefully

For every user task ask:

• Who sees it?
• Who owns it?
• What is the SLA?
• What happens if nobody acts?
• Can two users complete it concurrently?
• Is there audit?
• Is there escalation?

Heuristic 5: Versioning is not optional

A process definition will change while old process instances still run.

Therefore ask:

• What happens to running instances?
• Are variables backward compatible?
• Are workers backward compatible?
• Are message names stable?
• Is migration needed?
• Can old version be drained?

17. Production Failure Modes at Platform Level

18. Minimal Vocabulary You Must Own

Before continuing deeper, make sure these terms are clear.

• process definition;
• process instance;
• BPMN model;
• token;
• activity;
• gateway;
• event;
• service task;
• user task;
• business rule task;
• variable;
• scope;
• job;
• worker;
• incident;
• retry;
• message correlation;
• timer;
• compensation;
• process version;
• business key;
• correlation key;
• deployment;
• migration;
• Tasklist;
• Cockpit;
• Operate;
• Optimize;
• Identity;
• Connector.

If these terms are fuzzy, production debugging becomes guesswork.

19. Reference Anchors

Use official documentation as the source of truth for version-specific details:

• Camunda 8 Self-Managed components: https://docs.camunda.io/docs/self-managed/about-self-managed/
• Camunda 8 8.8 release notes and Orchestration Cluster architecture change: https://docs.camunda.io/docs/reference/announcements-release-notes/880/880-release-notes/
• Camunda 8 reference architecture: https://docs.camunda.io/docs/self-managed/reference-architecture/
• Camunda 7 documentation: https://docs.camunda.org/
• Camunda 7 Enterprise support and release policy: https://docs.camunda.org/enterprise/release-policy/
• Camunda Modeler: https://camunda.com/download/modeler/

20. Part Summary

Camunda must be understood as a platform, not just a BPMN renderer.

Key takeaways:

• Camunda 7 and Camunda 8 are architecturally different.
• Camunda 7 is closer to Java process engine thinking.
• Camunda 8 is closer to distributed orchestration and worker thinking.
• Modeler creates executable artifacts, not just diagrams.
• Cockpit and Operate serve similar operational goals but belong to different worlds.
• Tasklist is human task tooling, not necessarily your product UI.
• Optimize is process analytics, not a replacement for operational monitoring.
• Identity and authorization must be designed, not assumed.
• Connectors are useful but not always safer than custom workers.
• In enterprise systems, actual topology must always be verified internally.

The next part builds the decision framework: when Camunda 7 fits, when Camunda 8 fits, when neither fits, and how to reason about migration risk.