In February and March 2006, I posted to my ebizQ blog "IT Directions," a five-part series of articles describing the likely future of Business Process Management (BPM). You can find the first of these entries at http://www.ebizq.net/blogs/it_directions/archives/2006/02/bpmn_will_kill.php

Since the ideas go somewhat against the grain of current analyst (and vendor) predictions, I was not expecting the articles to be received with much enthusiasm by the industry in general. So it was a pleasant surprise to find the articles not only the subject of widespread attention - apparently garnering an unprecedented number of page hits - but also being taken very seriously. For example, bpmg.org asked if they could republish them, analyst warnings were issued based on the content, and some of the largest companies in the world contacted me subsequently to request private strategic briefings.

In this brief summary, I will outline the predictions made in the original series. However, the reader interested in these ideas is advised to turn to the original blog entries, which contain not only more detailed explanation of the predictions, but also consequent strategy guidance and recommendations, for which there is not enough space here.

The starting point is to recognize that the graphical notation for process modelling known as BPMN is on the way to universal adoption. BPMN is generic enough to cater not only to BPM techniques for business automation, but also to more longstanding workflow techniques for the support of processes in which human input is required at key data entry and decision points. BPMN is not suitable, and cannot realistically be extended, to cover the more dynamic, interactive forms of human collaborative work - which require the techniques of Human Interaction Management (aka HIM) along with a simplified, enhanced form of the notation known as Role Activity Diagrams (RADs). However, for almost all other forms of business process, BPMN is a good fit, and suits the business user better than competing notations such as UML Activity Diagrams.

Further, the OMG are currently extending BPMN with the provision of a "metamodel" known as BPDM. One immediate business impact of this is that BPMN will then automatically acquire a corresponding XML dialect, on which basis I predict that the XML process execution language BPEL will effectively become obsolete. BPMN is rich enough to express enough fine-grained detail of a business process to support execution - so why translate one XML dialect (BPDM) into another (BPEL) for this purpose. The current investment into BPEL by tool vendors will not be enough to save it, since the emergence of BPDM means that BPEL will become a redundant language - one that actually offers negative ROI to the user, due to unavoidable round-tripping problems. And since BPEL is already plagued by feature weakness and resulting compatibility issues, few users are likely to shed tears for its passing.