BPM

Open source workflow vs BPM Suites with API’s

You are developing a new software project, and you realize that for a part of it, you need a state machine. Or in other words, a workflow. You immediately think about looking for an open-source workflow engine that you can incorporate into your development. You search and find dozens. They all claim to be easy to use and integrate. None of them are.

open source code or API

This situation is very common. Open-source tools for managing workflows are usually very flexible and powerful, and equally complex to integrate, customize, operate, and above all maintain in the future.

Some open source workflow tool options are actually very powerful, robust, and flexible. For example Camunda, jBPM and Activiti, support the BPMN standard for graphical process notation. Other tools, such as Enhydra Shark, use other notations for graphical process modeling, and offer a specific execution engine for them.

At the other extreme, there are the BPM tools called low-code or no-code, such as Flokzu, which are based on not requiring programming or technical knowledge to be used. In these cases, the component that allows them to be integrated into other systems is their public interfaces, or simply API’s.

Benefits of Open Source Workflow

Open source BPM suites are especially advantageous in these scenarios:

  • When we require a high level of customization of the solution. That is, to adapt the solution, the form, the processes to a certain business need, or casuistry. In these scenarios, open source workflow suites give us total freedom to do so.
  • When the workflow and BPM component is a small part of large software development. In these cases, the whole product will require maintenance and evolution, so the differential of doing it also for the workflow component, is marginal.
  • When you need to guarantee performance levels. In these scenarios, having access to the process engine code can be very useful.
  • If you only require some process engine functionalities, and you want to remove (or hide) the others. In this case, being able to access the code allows you to do so and obtain a solution much more tailored to the needs of the application.

Restrictions when using an open source workflow

Along with flexibility come some relevant restrictions:

  • Need for a software development team. Integrating an open-source tool requires software developers. Considering the high (very high?) worldwide demand for these roles, this is a significant restriction.
  • Updating and installation of new versions. As new versions of the open source tool become available, you will want to incorporate them. This implies more tasks for the software development team. In some cases, when tightly coupled customizations or integrations have been introduced, this upgrade can be particularly complex.
  • Risk of obsolescence. It may happen, that the open-source branch you have chosen becomes obsolete (without evolution). In these cases, the replacement by another one that does have evolution and maintenance, can be very expensive (in time and risk).
  • Standards compliance. This may become a restriction, when new versions are released, in particular of the BPMN notation (OMG standard in version 2.0.2 at the time of this writing). It is important that open-source software incorporates these new versions. If they are not incorporated, it will be very difficult for software developers to incorporate these new versions, since it is a broad, complex, very powerful notation that includes a whole relevant graphic component. See the example below extracted from the documentation of version 2.0.2 of the BPMN standard.
BPMN 2.0.2 standard example: Shipment Process of a hardware retailer
BPMN 2.0.2 standard example: Shipment Process of a hardware retailer
  • Support for complex behaviors. Business processes and workflows can be very complex, involving hundreds of stages, and a large number of components in the flow with diverse behaviors. It can be very complex for the software developer to understand, and then limit or customize those behaviors in order to make them useful to their particular application. The following image presents an example of a collaborative process, also taken from the BPMN 2.0.2 standard documentation:
BPMN 2.0.2 standard collaboration example: Ordering and delivering pizza

Alternative: Workflow Suites with API’s

As an alternative to using an open source workflow, you can use a commercial product (a BPM Suite or Workflow Suite). It will provide all the process related capabilities and also an API’s to integrate with other systems or applications.

As an example, Flokzu provides a public API, which facilitates the execution of process actions from any other application.

Perhaps the most common use case is having a website for the onboarding of new clients, and in its end, starting a new workflow instance to enroll that client. This workflow is started through the New Process Instance method of the Flokuz API. The values of the new client (name, address, etc) are passed as parameters and stored in process variables.

But in addition, communication can be bi-directional. In a certain stage of the process, the workflow engine can invoke through an API a web service in another system, which performs another operation. Continuing with the example, the customer could be automatically registered in other systems. The process modeled in Flokzu would look like this:

Instead of using an open source workflow, this example integrates a commercial BPM Suite. New Client process example with API integration
Process integration through API – New client example

Advantages of the Product + API approach

The advantages of the approach of using a non-open source workflow product, and then integrating it into your development via API’s, are the exact opposite of the previous restrictions:

  • While there is still a need for a development team to integrate it through APIs, the work will be significantly less, and therefore the costs.
  • The software product will evolve, but the API interfaces will remain compatible. There is no need to worry about it. This decoupling is very important so that both the application and the workflow product can evolve independently.
  • In commercial products, the risk of obsolescence is much lower than in an open-source branch. Even more so if you use a world-leading product (such as Flokzu 😀). Software vendors will take care of updating the product, so that cost and complexity are on their side.
  • With regard to standards compliance, something similar happens. The provider of a workflow product, in order to stay in the market, must ensure compliance with process industry standards. In particular, it must resolve the compliance with the BPMN notation standard (OMG).
  • The complex behaviors that the BPMN standard supports will be resolved by the BPM product. The software project development will be isolated from this complexities.

Conclusions

Using an open source workflow as part of a larger development has some advantages and disadvantages.

The advantages include flexibility, customizability, and full control over what is running. Among the disadvantages, the main one is the high complexity that the workflow engines have. Their integration into another development will consume many resources (time and costs). And it will be very difficult to maintain afterward.

In this scenario, an alternative that deserves serious consideration is the use of a commercial, non-open-source workflow product. And integrate it with your software project through API’s.



Try Flokzu cloud BPM now.

Schedule here a 30 minutes session and see how you can easily integrate Flokzu with your custom software development.

Leave a Reply

Your email address will not be published. Required fields are marked *