Business Process Modelling is a collection of tools for declarative process management. Often a drag-and-drop interface allows business people to design a process in the form of a diagram. Each instance of the process travels through this diagram, executing certain code on each step. Sounds abstract?

Well, not every application is simply loading JSON from MongoDB and returning it via RESTful API. Some systems manage processes that have many steps that span over time. For example, imagine you are filling an insurance claim. It sounds simple, but the lifecycle of such a claim is actually quite complex. First of all the insurer needs to reply within 48 hours. Within that time frame someone needs to contact you. If an accident was small, you are reimbursed immediately. Otherwise an expert needs to visit your house or see your car. If a claim is accepted, you have a choice of paying yourself and get back the money later on. Or insurer covers everything on your behalf. Depending on your choice, you either need to submit plenty of invoices or the insurer must schedule repairs. These are wildly different processes. Moreover, if your claim is rejected, there is a separate appeal sub-process. Each step can fork into multiple parallel sub-processes that merge later on. For example one department collects invoices whereas the other verifies documentation. Each step has certain timeouts. Each step can have an error condition.

OK, what’s the point of this example? Well, how would you implement such a system? Do you immediately think about claims database table with a status column? Depending on your claim’s status, different actions are taken. Moreover, you have a bunch of periodic schedulers. They query the database from time to time to find timed-out statuses. But what about history and auditing? Oh, so you also have claim_history table that gathers historical data.

But what about different versions of the process? What? Well, new law, new regulations or business plan becomes effective next week. But simply changing the code won’t make it. Old processes need to run old logic, whereas new ones should apply different rules…

All of this complexity is somewhat hidden with BPM framework. First of all the process is first drawn. Using a special notation known as BPMN. This is actually quite natural. You use arrows to show how insurance claim changes state over time - and why. Then the diagram is translated into fairly standard XML. Now those pesky developers need to fill in the gaps. I mean, writing code that does some logic. For example sending an SMS when a claim enters a certain state. Or transferring money when a transition happens from one state to another. This is considered an implementation detail.

BPM framework also has a lot of features like versioning. You can have thousands of processes running, for example one for each insurance claim. But depending on when it was started or what kind of contract we have, each process runs a slightly different version of the code. Deploying new code won’t change the behavior of old processes. We also get a ton of auditing for free. Like: how many processes we have in each state, which states are taking the longest, etc. Declarative forks and joins where process splits to perform different actions in parallel are great as well. BPM engines are often used in microservice environments. There, they orchestrate processes distributed over many applications. Last but not least, many frameworks have beautiful UIs.

So, why aren’t you using BPMs in each and every project, yet? Well, these frameworks are actually quite heavyweight. They require a database with a few dozens of tables. This may limit scalability. Also, sometimes all you need is a straightforward if statement. Burying business logic behind complex XML that’s executed by some engine is often too much. So, the choice is yours. As always you must choose wisely.

That’s it, thanks for listening, bye!

More materials

• Business process modeling
• Camunda
• Activiti