You valid to support that fully. You valid BPMN process if you need to build a software system that allows its users to model and execute their own business processes, and you are on the build vs. buy stage of your analysis. You’re most likely considering a host of different BPMN-based solutions. However, unless your domain is finance, banking, or insurance, you are likely to conclude that ready enterprise-grade engines, such as Camunda or jBPM, are too heavy for your use case.
Let’s dive into what ‘too heavy’ means here, why you may want to consider a lightweight alternative, and which areas of a BPMN engine actually lend themselves to some trimming and simplification.
Camunda dominates the market for a reason. But is it right for your use case?
Here are the benefits of using Camunda or similar established solutions that we believe are key to their success:
- A mature and robust Java-based solution. There are countless Camunda implementations, which means that the solution is battle-tested and ready to handle business-critical processes.
- Open-source. You can analyze the code yourself and understand it thoroughly. You can also affect the development pipeline.
- Flexible and standard-based. With the full expressive power of BPMN at your disposal, you can be safe in the knowledge that, should you need to design an unusually complex and unique executable business process, you will be able to do so.
And here are some of the most important factors that make us recommend a lighter approach whenever that seems to be a better fit for the use case:
- A Java-based solution. If your main stack doesn’t involve Java, you should think twice before adding a heavy dependency to your project. Also, be warned that hosting a large Java-based application in a way that ensures scalability is not trivial.
- Considerable implementation costs. Open source is not the same as plug-and-play. Implementing Camunda takes a hefty amount of time and effort. Especially if Java is not your forte, you should take into account that getting the exact behavior you want out of Camunda may require an intimate knowledge of not only Java but also all the idiosyncrasies and quirks every large open-source solution is bound to have.
- Flexibility breeds complexity. We will look at complexity in a little more detail. Looking at the high-level picture, though, we believe there are two main sources of complexity you should be aware of:
- Camunda needs to be complex enough to support absolutely any process that is valid BPMN, and BPMN is a powerful standard used across many industries and business domains.
- Camunda is developed to serve countless different use cases, and it shows. That’s both the beauty and the curse of every multipurpose tool. It does everything you need it to do, and much more.
This complexity may be justified in some places and seemingly unnecessary in other places, but that doesn’t really change the fact that you will now have to invest in generating Camunda-specific expertise within your organization. While having an active open source community is always useful, getting good at a complex solution is a task in and of itself, and you will be well advised to take it into account in your considerations.
- Performance and memory requirements. Last but not least, Camunda tends to be a memory hog. You may find that your list of ongoing maintenance tasks may have to be extended to include keeping Camunda performant while also avoiding overprovisioning.
A bird’s eye view at a BPMN engine architecture
Let's review the high-level components of a workflow management system so that we can pinpoint the sources of complexity and address them.
First, we’re going to need a way to describe the different processes we want to be able to run. Business Process Model and Notation is a well-established and internationally recognized standard that allows you to do just that - describe any business process you can imagine and do so in a way that will be understandable by both business analysts and developers. Usually, a business analyst modeled a process using a modeler, which outputs a BPMN file with an XML-based syntax parseable by a BPMN engine.
Your BPMN file defined the process as a series of activities triggered by events and orchestrated via connections and gateways, which may form subprocesses. With a BPMN definition in place, you can start writing the actual implementation logic where applicable (mainly user and service tasks, which are types of activities).
Finally, you’re going to need a way to create process instances and keep track of their internal state. This means keeping tabs on the data flowing within the process as well as keeping track of where you are in the process (or where multiple agents are in the process, as dictated by branching logic). All that is covered by a BPMN engine.
What can be simplified?
Here are the most common sources of complexity that you may want to consider when evaluating your options.
Area of complexity: Getting to grips with Java
If you have a team of Java pros at your disposal, that doesn’t apply. But If you’re not that familiar with Java, you may have to spend quite a lot of time trying to wrap your head around all the complexities of adding a Java-based solution to your project - from hosting to optimization, etc.
What can you do?
Area of complexity: The extent of expressiveness of the process description syntax
Precisely because BPMN is a well-established and all-encompassing standard, it needs to be very expressive. It allows for describing processes, sub-processes, and logical and temporal dependencies between subprocesses and process nodes. All that makes for an awful lot of Java code that you’re only going to tap into if your use case is very complex.
Simplifications to consider:
Even if your domain requires a subset of the more complex features, adopting a selective approach to BPMN by removing some of its expressiveness may be beneficial to adopt. More specifically:
- When it comes to activities, user tasks (most often forms) and service tasks (custom pieces of code) are all you need to simulate most, if not all, the behaviors that can be achieved with the remaining activity types.
- Start and end events are indispensable, but you may find that a host of intermediate events can be simulated or disposed of entirely.
- You’re going to need to split and join gateways. Still, you may find that other gateway types offered by BPMN may not be necessary, e.g., an exclusive gateway can be achieved with a combination of join gateway and an end event.
Area of complexity: Form-heavy use-cases require workarounds
Support for forms in Camunda is rather basic, i.e., the form definitions are not very expressive and constitute a part of the user task definition. The available validation and control rules are rudimentary. If you need more complex validation and flow control rules (e.g., co-dependent checkboxes, conditional validation based on evaluating values in other fields), you have to put in the work to build around Camunda. There are ways to achieve that, but none of them is simple.
Simplifications to consider:
If you know your use case is going to require sophisticated validation logic, or your solution is going to be in general form-heavy, you may want to consider going for a tailor-made engine design to support that fully.
Area of complexity: Camunda-specific history tracking implementation
Different History tracking implementations boil down to who and when has access to the historical values of the variables passed around in the process. Let's consider a simple example of when that can come in handy.
Take a simple software license purchase process, with a single requester and a single approver:
If the request is rejected time and time again, the requester may want to review past versions of how they motivated their need for a license. The reviewer, at this point no doubt irritated, would gladly review the past rejection reasons as well.
The way history tracking is implemented, this simple scenario is complex. It is achievable but doing so is rather challenging and time-consuming.
Simplifications to consider:
If you plan on implementing long-running processes, especially ones with loops, and the access to the historical states of your variables is important for business reasons, you may want to go with a tailored approach to persistence that is more suitable for this purpose both in terms of performance and technical simplicity.
Conclusion
While there are many more areas of complexity, the ones listed above are the ones we know may give you some grief if left unattended. BPMN-based solutions are powerful but complex. Fortunately, there is a way to reduce that complexity while also making the solution more powerful in handling your particular domain.
If you are at the stage of exploring your options, take your time. Consider a pre-mortem analysis on top of your regular SWOT. Investigate all the pros and cons carefully. Consider the needs of your use case first and foremost. The rest of the decisions will follow.
Last but not least, choose your weapons carefully. If the goal is to build something lightweight and tailored to your needs, our experience shows that a combination of Node (speed) with TypeScript (enterprise-level type safety) works great. However, make sure you take into account your existing team's skills and preferences.
We hope some of the above tips will help you in that process. If so, we would be happy to help you identify just the right approach to building your business process management solution, so don’t hesitate to get in touch.
PS. If your use case is going to form heavy, you may want to check out our open-source react forms library, uniforms. We have used it successfully in BPMN-related form scenarios, and it works like a charm. Give it a try!
category
