Business processes - to code, or not to code, that is the question

Code & Tech

Business processes are all around us. Pizza delivery, orders shipment and invoice acceptance are just a few examples. We need to implement these processes in software delivered to our customers. Processes have their participants, who complete process tasks. Process steps result in actions like data row updates in databases, parcels being moved around warehouses, documents delivered, and so on. On top of that we have some non functional requirements like good performance, security, scalability, maintainability and testability. And we can't forget that the customer needs to understand and approve our implementation of the process. After all, it is their work we are trying to automate.

We can use a wide range of tools to implement business processes. They start from plain old object oriented Java code, and end up with specialised workflow engines often offered as part of commercial Enterprise Business Process Management Suites. Let's have a closer glance at each of the possibilities.

To code

First comes the custom object oriented implementation like we were taught at school. We write down user stories, take the nouns, turn them into domain objects. Next we take the verbs and they become methods on our objects. We create a 3-tier J2EE architecture, where our domain objects are mapped to the database. The logic of the process goes to stateless session beans. On top of that we add some UI, which triggers modifications of the model and observes its state. That is all - we are done. As simple as that ;)
The process is coded as chains of method invocations. Is it efficient? Probably it is. Actually this could be the method giving the best performance. We can also write unit tests, so we are covered for the testability requirement.

Limitations of coding approach

Problems start, when we want to show the process to the customer. We have no visual representation of the process flow. Extra diagrams need to be drawn, so that the client can see and approve the process. In 99% cases we will use UML for that. However we are responsible for keeping the diagram in sync with the implementation. Anyone who ever has documented software architectures in UML, knows that it is a Sisyphean task.

Descriptive tests

There is actually a second alternative to maintaining the UML diagrams. A good way to demonstrate how the system works, are well described tests. They will probably not cover the whole process, but only its parts. However they can tell the customer and anyone, who wants to inspect the application, how it behaves and what use cases it fulfils.
There is a very good tool for that named Cucumber. Using Cucumber we can define tests in the Behaviour Driven (BDD) way. For example we can define a feature using the special Gherkin language

Feature: Process invoice

Scenario: Process invoice with high value
Given Invoice value over 1000 dollars
When Accountant gets such invoice
Then Accountant’s boss should approve

We write the Java bindings for each step, for example to specify what it means that “Accountant’s boss should approve”

[code lang="java"]
@Given("^Invoice value over (\\d+) dollars$")
public void Invoice_value_over(int dollars) throws Throwable {
Invoice invoice = new Invoice(dollars);
processInvoice(“Accountant”, invoice);

<code>@Then("^Accountant’s boss should approve")
public void Accountants_boss_should_approve() {
assertEquals(process.state, States.APPROVE_INVOICE);

Using this approach we can illustrate and specify what happens with the process on every transition. However it is hard to get the whole picture from such granular bits.

Problems with adaptability to change

We also encounter a problem, when the need arises to modify the process and enrich it with new features. As system designers and maintainers, we need to take care of proper migration to the new process. We face the challenge of managing existing process instances running in the old process flow, which have not finished before the deployment of the new process version. They will have to coexist with new instances, started after the new version has been deployed. This is certainly not a trivial task.

Or not to code

Let’s take a look at the second alternative, where we use a special business process notation and a workflow engine capable of understanding this notation and running processes defined this way.

BPMN diagram for invoice business processes

The image above depicts a business process defined using the BPMN 2.0 notation. This example is taken from the examples delivered by the Camunda company. Camunda is one of the vendors who ship BPMN compatible workflow engines.

BPMN rocks!

Looking at the diagram we can draw one apparent conclusion. We see the whole process at a glance. The notation of boxes (tasks) and arrows (process flow) is pretty straightforward. Only perhaps gateways (decision points) need some more explanation, but together with the “yes” and “no” outgoing arrows, they aren’t so hard to grasp either.

BPMN notation is quite similar to UML, but it has one tremendous advantage. Starting from the BPMN 2.0 version (released in 2011, so it is widely available now), these diagrams are directly executable by workflow engines. We do not need to write a single line of code, to execute the process. We also benefit from readily available features such as user task assignment and users’ task lists. Most workflow engines also support process versioning and mapping between process versions. And the icing on the cake is the ability to monitor the process and provide performance and optimisation reports. Oh, and they provide unit testing capability too. It is very easy to instantiate a process instance in tests, run transitions between tasks and make assertions on the process state.

Second thoughts about business processes

For us these are enough arguments to choose a workflow engine over a custom process implementation in a programming language. Often, when we start designing a simple system, we are tempted to implement a “simple” workflow in our custom code. At first it seems really simple, just a few state transitions and we are done. But as the project proceeds, we keep adding features and we end up with yet another custom workflow engine that we have to maintain. And this workflow engine will surely not be as well tested, as mature solutions which are already available on the market.

We could also argue, that perhaps a ready workflow engine is too heavy (in terms of megabytes of jar files) and we don’t want to be dependent on it. It is a good point. We have to be careful, because most workflow engines are offered in suites with extra tools. These tools can include sophisticated ontologies for domain modelling, Business Rules Engines, Enterprise Service Bus Integration, Content Management Systems and many more. We can use all of them, if we have the need, but a well designed system will always allow us to choose just the workflow engine library and build our solution just upon this one brick. In a well designed workflow product, the workflow engine should be quite simple and serve one specific purpose - executing the business processes.
Features like data and domain models, organisational structures, business rules and integration with external systems should be covered outside the workflow engine.


We hope that this article has convinced you to choose a workflow engine, when you have to implement business processes in your application. There is a wide variety of solutions for Java starting from free open source software such as Red Hat's jBPM, Alfresco Activity and Camunda. They are all open source and available for free, but each is also backed by a company, which is responsible for its development and provides consulting for business processes implementation.