Back in 2016, I wrote an article comparing and contrasting some of the most popular open source Business Process Management (BPM) products. I recently did some research on this topic and quickly realized that so much has changed. In true open source fashion, I recently presented on this topic at the Open Source Summit and I wanted to share my findings in this article as well. 

Open source overall continues to accelerate in its adoption across the world. As of June 2022, public Github has 200 million repositories with 83 million developers,  more than 400% increase from 2016. For open source BPM projects, there’s been a continued trend of projects growing with Flowable forking off of Activiti in 2017. Change continues to be consistent in this space.

This article will provide an overview of workflow, BPM, and some of the industry standard notations that BPM products support. Next, the article will cover BPM alternatives and when to use one or the other along with scalability considerations. Finally, there’s a deep dive on four open source BPM projects: jBPM, Camunda, Activiti and Flowable. This piece will compare each of the four against these three dimensions:

• Open source model (i.e. community vs. enterprise)
• Capability set
• Community activity

What is a workflow?

Workflow is often an overloaded term. It can have at least three different meanings based on the context. At the basic level, a workflow is the structured flow of discrete steps of a business process. One form of workflow is human workflow. An example is a person investigating a case or routing an application to another group for review. A second form of workflow is system orchestration. There may be a set of APIs that need to be called in a particular order to complete a business process that only involves system steps. A third type of workflow involves a hybrid of both human and system orchestration. Often system orchestration may encounter an error scenario or may need something to be reviewed for further research.  

From these three examples you can see how it’s important to understand the context of a workflow, as it can have different meanings. The characteristics of a workflow can also range in different levels of complexity. There are two categories of workflows: simple and complex. Here are some of the characteristics for each:

Simple workflow

• Task management — think of a users to-do list
• Notifications — alerts the user via email or texts
• State management — the status of an item e.g. not started, in-progress or complete
• Low number of users in a single group — no cross team or department coordination

Complex workflow

(includes all of the simple characteristics plus the below)

• Many groups / users — spans many departments or divisions
• Multiple levels of workflow — various branches and paths
• Exception paths, call backs — error handling and route backs to earlier steps based on conditions
• Case management — ad-hoc investigative type activities that are not predicable; May use one or more workflows depending on conditions
• Integration with rules — if/then type logic for business or policy decisions
• Integration with system orchestration — combination of a human workflow and system workflow

It’s important to understand the workflow characteristics of a use case since that will direct you to the proper solution. So what are some of the possible workflow solutions? What is a BPM product and what problems does it solve? Let’s dive into that.

What is a BPM product?

At their core, BPM products provide visual modeling and execution of models that manage business processes. They often provide additional integration capabilities with various adapters. Similar names are Business Process Management System (BPMS) or Intelligent Business Process Management System (iBPMS ). Other categories of products may just provide modeling, but a BPM/BPMS/iBPMS product provides both modeling and execution. The open source landscape can be confusing as there are 20+ products out there that provide different levels of capability.

Industry standard notations

One common theme that open source BPM products support are some of the industry standard notations implemented by the Object Modeling Group. There are three industry standard notations: BPMN, CMMN, and DMN. Let’s walk through each of these in more detail.

BPMN — Business Process Modeling Notation

BPMN was first published in 2004 and provides an industry standard for modeling business processes. It is significant as it makes BPMN visual models portable, meaning a BPMN diagram built in one application can be used in another (as long as the tooling did not overlay any proprietary items on top of it). It also encourages business and tech collaboration. Often you can have a business analyst familiar with BPMN create a business process, then hand it over to their tech partners to implement in a BPM product. Below is a high-level view of some of the key icons in the detailed specification:

DMN — Decision Modeling Notation

Often in a business process you need if/then logic to make business decisions. This is where DMN comes in handy. It was first published in 2015 and provides an industry standard notation for business rules and decisions that is compatible with BPMN.

CMMN — Case Management Modeling Notation

A third type of industry standard modeling notation is CMMN, which was first published in 2014. Case management is typically different from a standard workflow since it is ad-hoc and investigative in nature along with being unpredictable.

Below is a view that summarizes the three different industry standard notations. Typically open source BPM products will support some combination of these — either all three or BPMN and DMN. Later in this article we will talk more about CMMN and some of the findings Camunda found with it.

Now that we have a good handle on the different types of industry standard notations BPM products provide, let’s talk about alternatives.

When to use a BPM product?

While BPM products are great at solving multiple workflow problems in a visual way, you may not always need that a capability that rich. In some scenarios, a lighter weight solution based on configuration may be a better fit. Below are a few examples of state machines:

• AWS Step Functions (Workflow Studio): Provides a way to orchestrate lambda functions in AWS; Also provides a visual modeler (does not support BPMN)
• XState: A JSON-based state machine that can be used to implement workflows
• Conductor (Netflix): Can be used for system orchestration geared towards microservices

So now you may be wondering, when should I use a BPM product? A general rule of thumb, is that when the workflow is easier to build visually in a model than in code or configuration, use a BPM product. A use case typically falls somewhere along two dimensions: degree of integration and complexity of the business process. A business process that needs high integration and/or high complexity are typically the sweet spots for a BPM product. Below is a matrix that uses the simple and complex workflow characteristics and aligns them against integration and business process complexity dimensions.

It's important to make sure you are using the right solution for your use case. BPM products can be overkill if the integration and/or business process complexity is low.

Monolith, microservices, and scalability considerations

One area of caution when using BPM products is to make sure you aren’t building a monolith application inside it. It is easy to do this as the products often provide a lot of the tooling that you need to make an application. Additionally, some of the BPM products themselves are monolithic deployments. We will touch on this later as a number of open source BPM products are moving to a more cloud native microservice-based deployment model. A key consideration is to be intentional about what things you build inside the BPM product and what things you keep outside of it. I typically recommend that you only use the BPM product for what it's good at — workflow. Keep everything else external to the product and use the various adapters to build integration with the workflow.

A key goal to strive for is to build microservices when using BPM products. One way to do this is to break up a process into sub-processes and deploy each as their own microservice to make it more scalable.

Another scalability consideration is to assess the deployment approach of the BPM engine. There are generally two approaches: in-process/embedded mode, or standalone mode. Each of these approaches have their pros and cons.

In-process/embedded mode

With the in-process/embedded mode, the BPM engine runs as part of your application, under the same JVM. This approach provides high performance as there are not any network calls between the application and your BPM engine. However, it creates tight coupling between the two. It also can make scaling harder since to scale the BPM engine, you also need to scale the application.

Standalone mode

With the standalone mode, the BPM engine is deployed as its own standalone service and the application integrates with it via API calls. This decouples the BPM engine from the application and also allows each to be scaled independently. One drawback is that it can provide lower performance due to the network API calls between the application and the BPM engine.

Open source BPM comparison

Now that we’ve covered a lot of the background and context, let’s start to take a closer look at some of the open source BPM products. First, let's look at some of the historic milestones of open source BPM, specifically focusing in on the ones that were based on re-writes of jBPM (i.e. Activiti) or forks of jBPM (i.e. Camunda, Flowable)

Launching in 2003, jBPM was the first open source BPM product to market. It was the sole open source BPM product for about seven years until Activiti was launched in 2010. Three years later in 2013, Camunda forked off of Activiti. Then in 2017, Flowable was born by forking off of Activiti. When each of these products forked, some parts of the architecture were reused while other parts were completely re-written.

From an industry standard notation perspective, the first version of BPMN was published in 2004, followed by version 2.0 published seven years later in 2011. CMMN was published in 2014, followed by DMN a year later in 2015.

For the next several years after DMN was published, we saw a number of the open source products build support for DMN along with CMMN. Interestingly, after five years of community feedback, Camunda decided to remove support for CMMN based on community feedback that it was too complex. Users found it easier to build case flows in BPMN than CMMN.

In 2020, jBPM started a new project known as Kogito, a refactor of the architecture of Drools and jBPM to be cloud native and microservice-based. In 2022, Camunda released v8 of their product which is highly scalable and focused on process orchestration.

Overall open source BPM interest

Which of these four BPM products are the most popular? I generated a Google trends graph to get a read on which ones were used in Google searches the most. Note that this is not a mapping to actual user installations. Also, there were a number of search terms I had to filter out for Activiti and Flowable to make sure terms like yogurt and concrete weren’t getting mixed in.

The results are interesting. jBPM was one of the top search queries from 2004 until around 2010 and then interest in Activiti spiked and overtook jBPM through 2016. Later in 2016, Camunda became the top search query and has had the most interest since then while Activiti and Flowable were about even while jBPM had the lowest search queries.

Now let’s get into the detail of each of these products, taking a close look at the three dimensions we mentioned earlier:

• Open Source model (i.e. community vs. enterprise)
• Capability set
• Community activity

Open source model (i.e. community vs. enterprise)

This is one of the most important aspects to understand as each open source BPM product has a different open source model. It is often confusing, but you need to be clear on what is available in the community vs. enterprise so you can ensure the solution solves the problem.

jBPM has the simplest and most open model. Everything in the community version is in the enterprise version. The enterprise version is based on several branches back from the latest community version to ensure its a stable version (vs. experimental features). The delta you get with the enterprise version is support from Red Hat.

Camunda has a slightly different model where their engine (i.e. Zeebe) is source-available and their modeler is open source while their other modules that provide operational capabilities are not open source, but are available to use for free in QA. The nuance with source-available is very close to open source, the difference is you can’t use it to host a commercial solution that is offered to others (e.g. think SaaS provider).

Activiti has a different open source model than jBPM and Camunda. They provide the bare bone pieces of all of their capabilities, but to get the more advanced capabilities you have to purchase the enterprise version. Flowable also follows a similar open source model as Activiti.

Capability set

Now let’s take a look at the high-level capability set of each of the four products, focusing in on these areas:

• Rules Engine
• Modeling & Execution Environment
• Deployment modes
• Dashboards
• Case Management
• Cloud Native / Serverless / Containers
• Cloud Managed Service Offering

1. Rules engine

jBPM is the only open source BPM product that provides a built-in Business Rules Management System, known as Drools. Camunda, Flowable and Activiti all support DMN notation which leverages decision tables, however Drools comes with many more capabilities including a forward and backward chaining inference engine that uses an enhanced version of the Rete algorithm. This enables Drools to automatically figure out which rules to execute and in what order.

2. Modeling & execution environment

jBPM provides a web-based modeler that is part of the overall UI known as Business Central. Within Business Central you can deploy, manage and track the workflow processes

Camunda provides a Desktop modeler along with a web modeler (which is only available via the SaaS offering) The operational modules known as Tasklist, Operate, and Optimize are only available in the enterprise (but can be used in a QA environment for free)

Activiti provides a web based modeler along with an eclipse plug-in as part of the community version, while the enterprise version adds on Process Analytics, Customized Business Applications, Nobile, DMN Designer, Process Apps Designer, Administration, Analytics, and Integration. 

Flowable provides a web based modeler along with an eclipse plug-in and provides the various core capabilities of various operational modules including Task, Admin, and Identity Management in the community version.

3. Deployment modes

jBPM, Activti, and Flowable all support both an in-process/embedded mode along with a standalone mode. Camunda only supports a standalone mode. This was an intentional decision as they found the in-process/embedded mode created scalability challenges for their community, thus went with a standalone only mode starting in v8 of Camunda.

4. Dashboards

jBPM is the only product that provides dashboard capabilities in their community version. The other three provide dashboards in their enterprise editions, specifically Camunda Optimize, Flowable Work, and Activiti Process Analytics.

5. Case management

jBPM and Flowable provide support for CMMN, while Camunda and Activiti do not. Earlier we discussed Camunda’s intentional decision to remove support for CMMN based on community feedback.

6. Cloud native / serverless / containers

As mentioned earlier, jBPM is heavily investing in the Kogito project which is the next generation of the jBPM and Drools projects that moves to a cloud native microservices deployment. It also includes support for reactive messaging (Kafka) and serverless workflow leveraging (knative). The plan is to continue to offer the traditional jBPM and Drools projects along with the next generation (Kogito) projects to allow users to choose between the projects.

Camunda 8 is touted as a process orchestrator and highly scalable. They provide support for Kubernetes and Helm charts. Activiti is known for its easy integration with Spring Boot and also has support for Kubernetes. Flowable has recently done several examples of how their engine can run in a serverless approach, such as running the engine in an AWS Lambda.

7. Cloud managed service offering

One of the biggest changes since 2016 is that we are now seeing open source BPM products provided as managed service offerings in the cloud. Camunda provides a SaaS offering while Alfresco Activiti provides a PaaS offering known as Alfresco Cloud. Both of these are enterprise options that remove the need to manage any infrastructure.

Community activity

If you are going to use an open source product, you want to use one with an active community. This enables you to rely on the community for support and enhancements instead of doing it all on your own. Below are commit graphs for the four open source BPM products. The scale of each of these is a bit different so you have to pay attention to that detail when interpreting the graphs. What I found is Camunda and Flowable appear to be the most active projects, followed by jBPM (which has had a consistent level of activity for the last three years), and then Activiti being relatively quiet over the past two years with sudden spikes of commits. The quietness of Activiti commits may be a result of the Flowable fork (where previous Activiti contributors are now focused on committing to Flowable).

Comparison summary

Below is a side-by-side chart that summarizes the comparison of the three different dimensions against each of the four products that were discussed above. My recommendation is to focus on the things that are different for the open source BPM products and determine which of those matter for your company and use cases that you are trying to solve for. Also, stay closely connected with the community to understand the roadmap and what things are changing as the landscape is constantly changing.

Conclusion

We’ve touched on several key open source BPM topics in this article along with providing a comparison of four of the common projects. Ultimately it’s up to you to decide which one best fits your needs and use cases. It’s an exciting time in open source BPM and the only thing that stays the same is things are constantly changing. Stay tuned as Capital One continues to create, share and contribute to the world’s open source solutions!

To learn more about this topic, check out author Andrew Bonham's speaker session about Open Source BPM Comparison from the 2022 Open Source Summit.

The analysis in this article was performed on jBPM 7.7, Camunda 7.17.0, Flowable 6.7.2, and Activiti 7.3.10