Process Component Models: The Next Generation In Workflow ?

SOA Service Oriented Architecture Articles : Process Component Models: The Next Generation In Workflow ? by Tom Baeyens

Introduction

Tony Bear says

the BPM-folks are from Venus and the WS-folks from Mars
That exactly summarizes a big division in the BPM industry that might not be obvious. The term BPM-folks refers to the people that focus on process modelling. Their starting point is the analysis of procedures that describe how people and systems work together in an organisation. In the modeller's view, the initial focus is not on technology, but on non-technical business analysts that documents how people and systems work together. For many of BPM projects in that category, automation of the processes is not even considered. The final goal is actually to create more insight in how an organisation works by documenting the core business processes. The pure play BPM products that come from this background aim to ease the automation of software support for such business process descriptions. I'll refer to this camp as the BPM modellers.

The WS-folks refers to the people that focus on creating executable processes. Executable processes are software artifacts that serve as input for Business Process Management Systems (BPMS). Executable processes usually have graphical diagram representation. Currently, there is only one executable process language with adoption by big vendors and that is BPEL. BPEL is based on WS-* standards, that's why the people focussed on automation are termed WS-folks above. Service orchestration recently got a boost with the growing consensus around BPEL. I'll refer to this camp as the orchestration developers.

The thing that both movements have in common is the focus on a graphical diagram and inclusion of wait states. The diagram is an important instrument for both the BPM modellers and the orchestration developers. Diagrams have the ability to provide a very quick overview of a certain process. While this is a powerful instrument, be careful with that perceived simplicity. As diagrams that might look similar can have a very different meaning depending of the notation or of the underlying executable process language. Also the purpose of a diagram is a very important consideration. In case of the business analyst, the purpose of a process diagram is to help the explanation to another human. They help to bring the overview across and some level of vagueness is allowed. In case of the executable process languages, the diagrams are part of a process that specifies how a computer system must behave. So those types of processes are exact and have a very precise interpretation.

Inclusion of wait states is more technical in nature, but it is also found in both movements. If a business analyst draws a business process, different activities might relate to different resources. Some activities might translate into tasks for human people and other activities might translate into a piece of software that is executed on a computer system. When such a process is automated, the process engine drives the execution. This means that the engine internally might execute some of the activities automatically. Otherwise, in case the activity is performed outside the scope of the process engine, the process engine will need to keep track of the current state and wait until a signal is received from the external entity. For example, such an external trigger might be a user that clicks a button in a web application to indicate that a certain task is completed. Similarly, an ERP system might notify the process engine that the processing of a certain invoice is completed. The concept of wait states might seem a bit abstract and you might wonder why this is relevant in a discussion about workflow or process languages. It is an important aspect because traditional programming languages like Java don't have support for persistable wait states.

This article arguments that the gap between the analysis and the implementation of business processes is far bigger then the marketing of today's workflow tools might suggest. Also it will propose a much more realistic way of dealing with this situation. The current standards and initiatives will be explained with enough depth so that you can see how they relate to the movements and why. In the discussions, I'll identify the strengths and weaknesses of each discussed technology and describe the proper and improper ways of using them.

At the end, a new type of workflow technology is introduced called process component model. This type of framework can handle multiple process languages and it can support process languages that better support the transition from analysis process diagrams to executable processes.

Source: http://www.infoq.com/articles/process-component-models