BPM - A Guide for Skeptics
BPM - A Guide for Skeptics
Take a look at how Business Process Management, or BPM, is used, and the benefits you can get from its use of automation for versioning and more.
Join the DZone community and get the full member experience.Join For Free
The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.
In order to use technology to solve our problems, we need to know what a technology can do for us, and its core use cases. There is a lot of confusion about technologies in the Business Process Management (BPM) space and much of the literature is not clear about whether its audience is implementers, developers, architects, or executives. This tends to breed skepticism, especially among developers. This article is a clear starting point for developers and architects and aims to address the preconceptions that they might have.
What Is BPM?
BPM is a discipline centered on the modeling, management, improvement, and automation of business processes. One of its key tools is the BPMN notation. BPMN is a notation that can be used to express business logic. The best way to understand BPMN is to look at a simple example:
The order process begins at "start order review" with a start node. Then we have a user task (with a person symbol), meaning that the process will not move on until a person has provided input for "review order." The process then makes a decision on which path to go down in the "order approved?" gateway. How it makes that decision is not specified here (we will come back to that). Depending on the decision we go down one of two paths, each of which involves an automated task (or "service task") where an operation will be carried out without user input. Again we don’t know from the diagram what it will be. Afterwards, the process will end.
We don’t know how the decision is made at "order approved?" or what happens at "log order approval" or "log order rejection" because the diagram does not say. The diagram only captures the design of the process. The implementation is a separate question. The diagram is captured as XML by BPM design tools and in that XML there are defined ways to hook into code that implements the process. This might be as simple as embedding a script inside an XML element or putting a java class name on an attribute of an XML element. The BPMN standard defines a set of elements for designing processes but there is variation among vendors in the options they support for implementation.
This example is only simple as it is quite small and doesn’t involve many of the elements that BPMN supports. The total set of BPMN 2.0 elements is called the ‘palette’ and it is divided into levels. The full palette can be overwhelming to newcomers but it is much easier to get to grips with if starting just from the most commonly used elements in the level 1 palette.
Why Use BPM?
The BPMN diagram is a map of the business process that can be communicated to different kinds of stakeholders in a project, spanning a bridge from the business-focused roles to development-focused roles. The diagram is tied directly to the implementation of the project. It is not just a theoretical guide for the project like many diagrams that architects draw (only to find out later that developers are not following them). Implementation is hooked directly to the diagram. While different functions within the organization might have their own diagrams for a project, a BPM diagram is well-placed to cut across the silos.
The fact that BPM can hook directly to implementation can lead to complaints from developers that BPM is restrictive. This is more of a question of how BPM is used. As we saw in the previous section, BPM does not stipulate about how tasks are implemented - tasks such as "log order approval" from the previous diagram are a blank canvas.
BPM implementations being a blank canvas does cut both ways. Consider that "log order approval" does not show any small person in its box in the diagram that we looked at. The diagram does not treat it as a user task. But there is nothing to stop a developer from putting the implementation in there that does require user-input. There is a trade-off between visibility and flexibility. More visibility means a strong bridge between implementation and stakeholder understanding. But in a large project it might be that only some parts are good candidates for BPM, and in that case, one may need to put flexibility first. Trying to go for too much visibility can result in diagrams that are overly-complex and constraining.
Using BPM can reduce the time and effort involved in prototyping certain changes. If a change is a reorganization of a diagram that doesn’t involve adding new tasks with new implementations then using BPM can allow that to be delivered with minimal developer involvement.
BPM tools can also offer advantages with respect to versioning. Consider the scenario when a change to a diagram is made and the new version gets deployed. Typically the default behavior with BPM products is that running processes continue on the version of the process that was active when they were started unless a decision is made to migrate the already-running instances. Depending upon the tooling available, having these options can be valuable.
BPM is sometimes claimed to reduce the amount of code or effort needed to implement a project. This may or may not be the case in a given situation. Some of the time that would be spent coding on a non-BPM project might be spent creating a diagram on a BPM project. For some problems, there will be examples already available that one can follow. Many BPM tools offer a set of out-of-the-box solutions for common tasks and/or a library of connectors to perform operations on popular platforms. But these are not inherent features of BPM. BPM products and low-code platforms often overlap but BPM and low-code are different ideas.
When to Use BPM
If any of the "why" factors mentioned in the last section jump out when designing your solution then BPM might be a fit. If you start explaining your software problem and you naturally find yourself drawing a diagram that looks like a BPM diagram then you may have a good candidate for BPM use-case.
Common cases involve document-based or approval-based workflows like account opening processes or request-review processes. These kinds of use-cases come up a lot in government, large organizations and organizations that work a lot of with documents. Many good candidates tend to be processes that involve a mixture of automated steps and human or manual tasks.
One could choose BPM for organizational reasons. For example, you might think that part of your project requires close collaboration between a business function and a delivery function. Then perhaps focusing that collaboration on BPMN diagram could help.
On a big project, you may be concerned that your architecture could get away from you. Perhaps you have a large set of microservices and you want visibility of the flow between them. You might decide that they could be run from or as BPM service tasks, using BPM as an orchestration layer for the business flow.
Part of the decision about when to use BPM and for what parts of a project involve being aware of what BPM is unlikely to help with. Parts of a project that are highly specific to a particular organization or project tend to require bespoke development. For example, a heavily customized user interface or an integration with a bespoke-built in-house system.
Ultimately the decision will come down to experience and your judgment of what works best for your project and your team.
How to Use BPM
How to approach using BPM in a project depends upon the situation. Key choices will be about how to go about designing the processes, at which stages in the project, which tools to use, how to go about the implementation and testing and what parts of the project should use BPM. This short guide can only give some pointers to help avoid common pitfalls.
A key decision can be whether to buy into a BPM suite/platform or choose a lightweight embeddable BPM solution. A BPM suite provides a general-purpose user interface and out-of-the-box (OOTB) integrations and typically has an upfront monetary cost. The OOTB features can make it quick to get processes up and running. The suite should expose enough ways of interacting with it that it can work for situations requiring more bespoke development but flexibility for bespoke development is something to watch out for. Lightweight and embeddable solutions typically offer less out of the box but the most popular ones are highly flexible, free and open-source. With open source solutions, it is best to look for a solution with a good history, relevant examples, and a strong community. (For a better understanding of embeddable BPM and a range of implementation examples, see Activiti in Action by Tijs Rademakers.)
You need to be able to interact with your BPM tool in a flexible way. As was mentioned previously, service tasks are a blank canvas into which you can put whatever logic you need. But you might also want to interact with the process from other systems in your organization or your project. You should be clear about how you would go about interacting with the tool via REST or MQ or whichever medium seems most applicable to you.
It is important to be clear about how you see BPM working for you. Vendors tend to emphasize the benefits of BPM suites as low-code environments with all the integrations you could ever need. These benefits will work in certain cases and not others and there will be a spectrum in between.
Many of the complaints about BPM are about users finding it constraining. This can happen if the tool does not support enough integrations or does not support the right integrations for you. It can also happen when a BPM suite is chosen in order to reduce development effort without sufficient previous research on whether the fit is adequate. For example, an off-the-shelf general-purpose user interface might look great initially but can become more problematic as one finds more customizations that one wants to apply. Be clear about what support the product has for extending the user interface as well as business logic. And be careful to think about the whole development cycle. How, for example, will you test your BPM-enabled solutions before going live with them?
The way in which BPM is practiced within an organization is also very important. Beware of having BPM experts who jealously guard the diagrams. The diagram should be communicated across teams and organizational boundaries. If it gets too complex for that or there isn’t sufficient buy-in then be prepared to reconsider how much of the project needs to be covered by BPM. A popular complaint about BPMN is that users find it too complex. BPMN practitioners need to be sensitive to their audiences and teams using BPM also need to take time to get comfortable with BPMN by starting from simple examples. Many difficulties with the way BPM is practiced can be addressed by adopting a more pragmatic approach to the use of BPMN - the current bible on this from a process design perspective is Bruce Silver’s book BPMN Method and Style. The BPM implementation space is currently too varied for any text to achieve bible status.
Opinions expressed by DZone contributors are their own.