Process Modelling And Process Execution

Jim Sinur talks about a lesser known aspect in BPM and workflow: the interaction of process modeling with process execution. He walks through 5 use cases of BPM and explains which tools that apply best: modelling tools or a Business Process Management System (BPMS, aka runtime process engine).

The part of it that I think is not enough known is the differentiation between the modelling tools and the process engines. The aim of modelling tools is to let the analyst create a diagram to help with documenting business processes. On the other hand, the aim of the BPMS is to track the progress of process executions and to execute the automated parts of it on a computer system.

BPMSs offer modelling capabilities, but since those models need to be executed later on, there is more to it then just the diagram. The diagram of an executable process will be more restricted then a diagram of an analysis model. Also the diagram of the executable process will be tied to software execution so changes to the diagram lead to changes to software execution.

There are some good tools for process analysis and there are some good BPMSs that support a graphical diagram view onto their executable processes. But making the link between those two worlds is not handled by today's technologies.

BPEL is known as a BPM language. It's an executable process language. And because of its focus on WSDL and executability, it is not suitable to let a non technical business analyst model a business process.

BPMN is mostly known as a graphical notation for business process diagrams. It's a good language for the business analysts, but creating easy and maintainable bindings to executable process languages is not yet demonstrated. Especially the gap between BPMN and BPEL is too big to keep in sync with round tripping.

So this leads to a software development cycle for processes that is completely similar to any other software automation project. Non tech business analysts can create analysis models. From analysis models, implementation models can be distilled. After that translation, the business analyst will only be able to see the implementation models in read only mode. The analyst will still recognise the diagrams, which results in a common language between the business analysts and the development team. That is a big added value that BPMSs can bring.

XPDL and jPDL have already today are most suited for aligning the executable process model with the analysis model. While BPEL is very complementary technology on an ESB, it is still very problematic in making the link between analysis models and executable models.

With jPDL 4 that we are currently conceiving, it will be possible to just add technical details to the analysis model and keep the original diagram as-is for the executable process. That is quite an achievement as the analysis model will not have taken into account persistence, transaction demarcation and concurrency details. Making all of those technical details fit into any Java application architecture is something that we can be proud of. But let's not make this into a jPDL blog.

The main message of this blog was that the link between modelling tools and process execution engines is still not as good as most people assume. Especially not with the two technologies that are mostly known: BPMN and BPEL. While the link between BPMN and BPEL is broken, both technologies can still be very usefull on their own.