« BPMN will kill BPEL. Will it kill BPM too? | Main | Orchestration and choreography »

The previous blog entry showed how, despite the investment into the BPEL standard by OASIS and into supporting technology by tool vendors, BPEL in fact incurs cost without providing benefit. Hence, it will probably be phased out over the next few years. In this entry, I will look at some of the implications of this - and how, although there are short-term implications for the BPM dream, all is not lost.

The original “third wave” vision for BPM was as a layer above middleware and component technologies, a layer that was fundamentally different because it was based on mathematical principles. A true BPM tool was supposed to be based on an underpinning “process formalism”, such as Petri nets or the pi-calculus. Why? So you could assert things about business processes, and then prove them – for instance, that given a certain input X, you would get a certain output Y. The idea was that businesses would thus gain true control over their IT, by incorporating the specification for each process right into the executable implementation of that process. The requirements would effectively generate the code.

BPEL was supposedly constructed with this aim in mind, although its formal underpinning has been much debated (since it attempts to mix and match various formalisms, an approach giving rise to various problems). BPMN, however, is a different animal altogether. Some aspects of BPMN (e.g. the fundamental Pool and Lane constructs) have no semantics whatsoever. Quoting the BPMN specification (v1.0 of 3 May 2004):

“A Pool represents a Participant in the Process. A Participant can be a specific business entity (e.g, a company) or can be a more general business role (e.g., a buyer, seller, or manufacturer). Graphically, a Pool is a container for partitioning a Process from other Pools, when modeling business-to-business situations, although a Pool need not have any internal details (i.e., it can be a “black box”).” (P.103)

“Lanes are used to organize and categorize activities within a Pool. The meaning of the Lanes is up to the modeler. BPMN does not specify the usage of Lanes. Lanes are often used for such things as internal roles (e.g., Manager, Associate), systems (e.g., an enterprise application), an internal department (e.g., shipping, finance), etc.” (p.106)

In other words, the fundamental BPMN construct, a swimlane, is at most a suggestion that certain activities should be carried out by the same agent. This is at most. In practice, it is "up to the modeler" what a swimlane means. Hardly the formal underpinning that a BPMS was supposed to possess …

In general, BPMN does not possess a mathematical or logical basis. This is intentional - nowhere in the BPMN specification does it claim to have such an underpinning. But if BPEL vanishes from the picture, as BPML has already done, where does the informal nature of BPMN leave BPM?

BPM as implemented via BPMN will be simply a graphical interface to component tooling – a higher-level, more business-focused way to build J2EE and .NET artifacts. This is very useful, of course. However, one must recognize that without a formal basis that permits business needs to be directly embedded in business processes, the original third wave dream cannot come true. For the moment, BPM is about expressing business processes in BPMN, and this is not going to fundamentally change enterprise IT.

Fortunately, there is still hope for the third wave - from two sources.

The first hope for the third wave lies with a major type of enterprise business processes that BPMN does not even attempt to address. Hence, these processes are still open to the kind of transformation originally envisaged for BPM in general. As analyst firm ZapThink pointed out recently:

"… speaking of business processes, when humans are involved, it makes very little sense to have a centralized, computer-based system coordinating business processes on behalf of humans."

A lengthy public discussion recently concluded that current BPM techniques and tools do not cater for collaborative human work processes. Not only do collaborative human work processes require peer-to-peer techniques for computerized support, but there are fundamental technical reasons why notations such as BPMN and BPEL are unsuited to describing, implementing and managing them. Hence, tools are emerging that provide the necessary support for collaborative work, and that have the formally sound underpinning originally intended for BPM as a whole.

Lightweight, client-side tools for process-based collaboration between humans offer a route forward for third wave BPM that is independent of current BPM standards. In future blog entries I will look in more detail at how the enterprise IT landscape will soon be changed forever by low-cost, peer-to-peer technologies for process support. It may be goodbye BPEL, but it's hello people.

The second hope for the third wave comes from an emerging standard for business process description. Unlike BPMN or even BPEL, this new standard has a genuinely sound formal underpinning - in fact, it is based on the pi-calculus, generally acknowledged as a leading mathematical technique for business process analysis. In the next blog entry, I will look again at business processes suited to heavyweight server-side enterprise technology, and discuss how these processes can - and inevitably will - be brought under the control of true third wave techniques.

TAKE AWAY

In the meantime, the reader is advised to consider carefully the direction of their strategic, long-term investment in process support tools. In particular ...

Should you be considering client-based as well as server-based solutions? For certain processes, server-based technology may be the only choice available – for other processes, though, there may be better options.

And should you be thinking twice about the techniques you adopt for process description? In the next blog entry, I will continue this look at the impact of new process standards, and show what the future holds for BPMN. Having made BPEL redundant, are there technologies on the way that will render BPMN itself obsolete?

Posted by keithhb in Business Process Management |Digg This|Add to del.icio.us