I had the opportunity to spend a week in sunny Brisbane, Australia, to attend the 5th International Conference on Business Process Management, the largest academic conference in the BPM space. Hajo A. Reijers and I presented a paper on the use of biological mechanisms for task allocation, which are particularly useful in the emergency response domain (you can download the paper in the publications section here).Today I gave a two hour tutorial on the state of BPM standards, which was very well attended. The emerging landscape of integration, choreography, notation, and interchange standards in the BPM field are both confusing for practitioners and a fertile research field for researchers. Thankfully there are some efforts from standards groups to clarify the scope of their efforts and the impact of their specifications. I had a chance to talk to Karsten Ploesser of SAP, one of the co-authors of the BPEL4People draft specification, which is emerging as a very focused document, which will probably make it easier to understand and implement in practice - one key aspect that affects the adoption and diffusion of standards.Since I received a large number of requests for the presentation slides I made them available on slideshare. You can download the PDF of the presentation here and an audio recording is available here. 

| View | Upload your own

Update: All slides from the BPM 2007 conference are available for download here: http://bpm07.fit.qut.edu.au/program/index.jsp 

I came across a call for papers for a special issue of the Cutter IT Journal on BPM - broken promises or building blocks of modern EA, edited by Bartek Kiepuszewski, which I re-posted here. What piqued my interest was how the call was phrased. There are two items that I don’t particularly agree with:

• The WfMC never attempted to standardize the architecture of a BPMS or workflow management system. The purpose of the group was to work on standards that allow for the interoperability of these systems. To make systems interoperable you need interface specifications, but you do not need to know about the internal architecture of the other system (rule #1 of loose coupling, or as Maier and Rechtin put it: The greatest leverage in systems architecting is at the interfaces). The WfMC reference model was never meant as an architecture model, it is simply a collection of those interfaces that the WfMC thinks should be standardized.
• While there are overlapping standards in the BPM area, we are far from a standards war. Compared to battles such as Blue-Ray vs. HD DVD the BPM community gets along pretty well. Most importantly, the shakeout of standards affects end users to a very limited extent, since the most visible component of the standards stack - BPMN - is universally agreed upon. Everything underneath is in flux, but that is something that vendors have to decide on, not users. The tug-of-war between BPDM, XPDL and BPEL is a bit like deciding on a file format for word processing documents. I don’t need to be able to read a .docx file in its native format, nor should it be of concern to me. It should be of concern to me whether people I collaborate with can read and write documents in a format we can all process. In 95% of the cases we either agree on a platform, or we use converters that work just fine. Caveat: If you have ever worked with people who love LaTeX, that’s a whole different issue…

John Evdemon said at the last BPM Think Tank that a lot of BPM standardization is Management by Magazine. Come to think of it, it’s a bit absurd, since the very group that makes the standards is the same group that has to implement them. In absence of any opposing views, much of what is written in magazines is being perceived as the ultimate truth, which is a bit sad. Academia has a system of peer reviews to make sure that there are checks and balances in place. But who in industry reads academic journals?

I am attending the BPM Think Tank in Burlingame this week, and there are many insightful presentations around emerging standards in the BPM space, such as BPDM, BPMM, BMM, BPMN 2.0 and OSRM. But one thing makes me wonder - with every revision, every iteration, the standard specifications grow in size. The new BPMM specification has a whopping 505 pages in draft version. A participant asked what the effect would be if the BPMN 2.0 specification, which combines BPMN and BPDM, would be a 1,000 page document. Nobody knows… I had a look at some older and newer specifications, and this is what I came up with:

There are some interesting observations to make:

• Standard specifications seem to double between versions. The only exception is UML, which actually shrank 300 pages between versions 1.3 and 2.0
• Some organizations produce shorter specifications than others. For example, IETF specifications seem to be rather concise, compared to OMG or OASIS specifications.

Now, counting pages is not a very exact metric to gauge the complexity of a specification, but it is safe to assume that a 300 page specification is significantly more complex than a 60 page specification. I brought this up at the Think Tank, and it was suggested that specs grow because the working groups add clarifications and explanations. But it is also possible that as the standard specs grow, the effort to implement them and to prove conformance with all aspects of a specification increases significantly. If that is the case, do bigger standards keep the industry from advancing?

Web Services in their simplest incarnation support only stateless communication between a requester and a provider. Many services are potentially long running, and contingencies for alternative service invocation or service failure have to be provided. For this reason, a number of Web Services Choreography standards are currently being developed, for instance BPEL or WS-C. We take a look at the current state of the standards field, and compare the history and outcome of the different standardization efforts. This is an exploratory case study, motivated by two observations. First, that the current interest in web services is directing attention to issues that have a longer history in the workflow community. Second, that the debate over web services choreography standards appears to be deeply influenced by architectural style, understood by relatively few. We started with one question - whether the technical debate has merit and should be better understood by a wider community. We also ask whether the battle is only about the technology. We found answers to both questions…

• zur Muehlen, Michael; Nickerson, Jeffrey V.; Swenson, Keith D.: Developing Web Services Choreography Standards - The Case of REST vs. SOAP. Decision Support Systems 40 (2005) 1, pp. 9-29.