Modelling a business process in the right way will be key challenge

By now you've probably heard all the latest buzzwords floating around: SOA, BPM, etc. Groups such as Gartner use them to fill their weekly reports. These next-generation solutions all promise more flexibility, maintainability and more business process alignment. Most of these promises are true if we speak about an ideal situation. But in practice it can be whole different. One of the important points is the way the processes are modelled. That can be done in different ways and not every approach will lead to the desired solution. In general: modelling a business process instead of using a programming language to create an IT solution that is easier to understand. But the problems we are solving are the same, so also of the same complexity. The only difference is the level of abstractness we use in defining a solution. So the WAY you define a solution stays important in all methods!

In this article I will explain two different methods used for modelling a business process (in a BPM studio by example). I will also point at some important constructions that make a processe more robust.

When we look at orchestration of (web)services there are at least two fundamental different ways of modelling:

model a process as workflow and event-driven modelling.

Workflow modelling

In this approach we model a process as a sequence of activities. We can graphically model this by a flow chart (or Petri-nets, or whatever technique you prefer). Choices can be modelled based on the business rules of a company.

Example business process modelled as a workflow:

This approach has the advantage that you immediately see the structure of the business process. When using a model-driven BPM studio it is easy to build or change this kind of processes. However, you need all the knowledge about a process before you can model it. This means a thorough understanding of the workflows within a company. When you have experience with determining a companies internal workflows you know that’s a difficult process.

Event-driven modelling

Another approach is the event-driven modelling of a business process. In this approach you model a business process like a Finite State Machine (FSM, more information). Each transition in this FSM has a condition which corresponds with a certain business rule.

Example event-driven model of a business process:

Each arrow, by example from state1 to state2, has a condition (some event), by example event A. When event A is fired the process will go from state1 tot state2. In this way you can model a process by just defining the business rules. The advantage of this is that you only have to determine a business rule and two states for defining a part of the business process. You don’t have to know the structure of the whole process. Of course the disadvantage of this is that you either don’t have a full overview of the process. Mostly this way of modelling isn’t done graphically but by adding rules to a rules engine.

Some patterns

Workflow modelling is most used in model-driven BPM studio’s. But as already mentioned the way you do this will give different solutions. By example the way you model asynchronous communication between services. The most simple approach is seen in the next figure.

We do an invoke to some webservice, execute some other actions and wait with receive on the call-back of the invoked webservice. This is a very straight forward approach and it can be a good solution. But if the invoked webservice is very fast in giving a call-back it can happen that we are not already in the receive activity. Of course an ESB can queue a message for a while, but timeouts can happen. A better approach is seen in the next picture.

In this picture you see a flow construction. The meaning of a flow is that all activities in it will be executed in parallel. A flow has a join condition which determines how this activity can be completed. The most simple options are: 'wait for all parallel activities to be completed' and 'just wait for one activity to complete'.

So in this situation it can’t happen that the invoked webservice gives a call-back before we are ready for receiving this message. So this is a better approach, but still not the best. Consider the situation in which the webservice has something to do with human interaction. This could be very time consuming. In the worst case the person who has to react is away (vacation or something). For these kind of situations we have to add some timeout function. We can do this in the following way.

We have to embed another flow. The join condition for this flow is 'wait for one activity to complete'. So either the receive or the wait will be completed. Here we have our timeout function!

As you see, modelling a business process for technical implementations isn’t always as straightforward as it looks like. I will come back to this topic later including some other patterns. If you have some nice, useful patterns yourself please contact me!