Having a myriad of options can be a wonderful thing, but it can also be overwhelming... Such is the case in the workflow market today. If you're a company looking for a workflow or BPM (Business Process Management) platform here in 2019, should you choose:
A BPM suite, such as IBM BPM, Pegasystems or Appian,
An open-source workflow platform such as Camunda BPM, Flowable or Activiti or
A lightweight workflow or service orchestration platform such as Camunda Zeebe or Netflix Conductor?
Let's look at this at a high-level and talk about some of the characteristics of each that should be considered when making a decision. At the end, we'll provide two questions that - when answered - will get you started off on the right foot in your own evaluation process.
BPM suites were built to provide complete toolkits for the build-out of complex business process applications. This means that they often augment their process modeling and execution capabilities with very useful tools such as drag-and-drop interface designers, low- or no-code data integration capabilities, application dashboard builders and/or process reporting tools. They are also often available with pre-built solution templates that are ready for customization. Here's an example of a drag-and-drop user interface creation tool - appropriately called the Interface Designer - within Appian that is designed to allow users to build user interfaces easily and rapidly (image available here and used under US fair use doctrine):
Figure 1: Appian's Interface Designer
In Appian's case, their low-code capabilities are so good that they've pivoted and are now characterizing themselves as a "low-code" company instead of as a BPM/workflow company. (We believe this was a smart pivot for them, as per the discussion in our blog entry here).
Unfortunately, due to the need for the vendors to provide such wide feature sets, they aren't able to really focus on their process/workflow/orchestration engines; as a result, those engines may not compare well to competitive engines offered by open-source platforms or lightweight workflow systems. This can manifest itself, for example, in engines that either don't perform well under load or that don't have the capability to orchestrate fully-automated workflows. Additionally, their platforms tend to be inflexible by comparison; they give you low- or no-code capabilities to do great things, but you can only do those things in the ways in which they've prescribed. This can hamstring developers and can lead them to develop rogue, one-off solutions outside of the BPM suites. Moreover, they generally aren't well-suited for working with today's container and container-management solutions, such as Docker and Kubernetes.
The takeaway? These platforms should be used in situations where traditionally-deployed, large-scale and feature-rich software applications are required, perhaps where you don't have another tool for building user interfaces or where you don't have another tool to use for reporting on the data that is collected by running your workflow applications. They can help you deploy simple or very specific workflow applications quickly; just understand that this power comes at the cost of flexibility and throughput performance.
Open-source BPM platforms differ from BPM suites in two substantive ways: (1) that they focus much more on the capabilities of their core engines and (2) that they are purpose-built to be flexible and developer-friendly. Let's dig into those items a bit.
First, they focus on ensuring that their core engines are extremely performance-oriented. Let's take Camunda BPM as an example. When I was at Camunda as the Director of their consulting and technical sales team in North America, we had their biggest-volume customer (globally) right in our backyard. The company was processing ~100 million workflow node instances daily on inexpensive, commodity hardware. That volume simply would not be achievable with any of the BPM suites.
Second, they focus on being developer-friendly. Again taking Camunda BPM as an example, you can run it (1) within an existing Java application (on an application server or not), (2) on a Tomcat or Java Enterprise Edition application server with a shared engine - or multiple shared engines - across applications, (3) via Spring Boot or (4) in a container, e.g. Docker. Moreover, you can use Java, JavaScript or any application that can call a REST API to build code for use with the process applications hosted on the platform. That degree of flexibility isn't afforded by the BPM suites.
Importantly, they offer the same general workflow capabilities as the BPM suites. They offer virtually the full slate of BPMN 2.0 features, i.e. all of the capabilities that you would expect from a full-featured workflow or business process management product.
These tools also allow you to synchronously execute fully-automated processes, similar to what you would do with an ESB/EAI tool like webMethods or with a "lightweight" workflow tool like Netflix Conductor. Consider the following two process models:
Figure 2: A traditional human workflow (built for Camunda BPM)
Figure 3: A microservices orchestration (built for Camunda BPM)
(Though the workflows above were built for Camunda BPM, they would work perfectly - and virtually identically - within Activiti and Flowable as well.)
In Figure 2, you see a couple of traditional User Tasks along with lanes, a common BPMN 2.0 construct that denotes user/group responsibilities for tasks. This is a relatively standard human-centric workflow, which can be handled easily by these systems. Figure 3 shows a fully-automated workflow process, which doesn't have any User Tasks and could be handled in a "straight-through" or synchronous manner if desired.
On the other hand, none of these tools have robust, capable user interface designers, and they generally offer rudimentary reporting capabilities as compared to the BPM suites. It will simply take longer in some cases to build your BPM applications. If you need or want those features, you should likely start your search with the BPM suites described above.
Due to their flexibility and full-featured BPMN 2.0 support, our defaullt recommendation is to start here when considering a workflow solution for your enterprise. While they don't have some of the supporting, ancillary features that the BPM suites have, the chances are that you have other tools that you can use to build advanced UI's, report on the data generated from your BPM applications, etc. These open-source platforms won't limit what you can do within your workflow applications, and they will allow you to build microservices orchestrations as well.
"Lightweight" workflow platforms, often somewhat misleadingly called "microservices orchestration platforms", are laser-focused on streamlined, high-performance workflow orchestrations. They also differ from other workflow/BPM solutions in that they significantly limit the capability set for building workflows. For example, neither Camunda Zeebe nor Netflix Conductor offer anything similar to a User Task from BPMN 2.0; you're left to handle/manage any user interactions entirely outside of the platform.
We say that they're somewhat misleadingly called "microservices orchestration platforms", because that implies that other workflow platforms can't orchestrate microservices endpoints. That's not the case; you could orchestrate sets of microservices endpoints using any of the BPM suites or using any of the open source platforms.
Let's dig into the limited feature sets of these platforms in more detail. Consider Figure 2 and Figure 3 above... Given that Zeebe uses a stripped-down version of BPMN 2.0 to model its orchestrations, you could model the workflow captured in Figure 3. However, you wouldn't be able to model the workflow captured in Figure 2, as some of the features referenced therein just aren't available in Zeebe. That limits the use cases where you can apply Zeebe. The same is true for Netflix Conductor; though it's more mature as a platform and does offer more features than does its competitor Zeebe, you still wouldn't be able to model the workflow captured in Figure 2. As with Zeebe, you could model the workflow captured in Figure 3 in Conductor, albeit in a different - but fundamentally similar - form:
Figure 4: The "statistical-arbitrage" microservices orchestration in Netflix Conductor
On the other hand, these platforms are designed to enable their users to handle massive throughput volumes. We have precious little real-world information on these platforms' volume-handling capabilities, as they are all new and thus have significantly smaller install bases. We do have the following Kibana screen capture from Netflix regarding their usage of Conductor (available here and used under US fair use doctrine):
Figure 5: Usage of Netflix Conductor within Netflix (over a 7-day period)
The problem with the above - if you've been paying close attention - is that the volumes shown don't compare favorably with the reported volumes on Camunda BPM by the high-volume North American customer mentioned above. However, with that stated, the theoretical volume-handling capabilities of Netflix Conductor and Zeebe - given that they don't leverage relational databases for data storage - are much higher than those of their open-source competitors or of the BPM suites.
It's difficult to recommend the use of these so-called "lightweight" workflow solutions over either the BPM suites or their open-source competitors. If you are going to be handling truly massive volumes, you should consider them and do your own testing. However, if that isn't the case, you'll likely be better off with either an open-source platform or a BPM suite.
Summary
We've talked at a high-level about the relative capabilities of BPM suites, open-source BPM platforms and lightweight workflow platforms, and we've compared the strengths and weaknesses of each. And we've given you a lot of information! Thus, to simplify the above and to give you a jumping-off point for your own decision-making process, here is an admittedly oversimplified set of two questions that should get you started:
Do you need either user interface generation capabilities or advanced reporting capabilities within your BPM/workflow platform? If yes, start your assessment with the BPM suites.
Do you need to handle theoretically massive daily volumes, e.g. in the range of billions of workflow instances per day or more? If yes, start your assessment with the lightweight workflow solutions.
If the answers to both questions are no, then start your evaluation with the open source BPM platforms; they collectively offer the best combination of workflow capabilities, high-performance capabilities and flexibility for more enterprises embarking on workflow initiatives today.
If you have additional questions or need customized guidance on making your own product selection, please contact us at info@summit58.co. We'd be happy to help!