Just got back from the WfMC Standards Tutorial in Mainz, Germany. What a collection of Business Process Management (BPM) expertise ! It has been a long time since someone mentioned BPM to me without it being immediatly followed by BPEL. It turned out that the whole day gave a very clear picture that i've been preaching for a while as well: BPEL is good for service orchestration but is has got nothing to do with BPM.
I didn't go there for the tutorial, but more for meeting the people behind the WfMC and get a good feeling about the direction they are heading. Where before I was in doubt wether the organisation was pining away, I now saw that they are more alive then ever.
Updating XPDL 2.0 to make sure that you could get a lossless roundtrip from BPMN is a very clever move. Now THAT is a combination for BPM. For analysing and automating business processes, the featureset of BPEL doesn't even come close to the featureset of XPDL or BPMN. And that is an understatement: It's a different planet in another solar system is probably more appropriate.
This, of course, brings up a more nasty issue, in which WfMC might have done a better job in the past: PUBLIC RELATIONS. The WfMC has been overclassed and bypassed by the marketing around BPEL. With or without WfMC becoming better at markting, I am very confident that public perception of BPM will change quite soon. More and more people are realizing that BPEL is for service orchestration, not BPM. Too bad this often requires a desillusion and a lesson learned the hard way.
This BPEL-BPM link that was at the basis of the hype is now causing quite some controversy. Infoq gives a good summary of recent discussions. Most of this controversy boiles down to the discrepancy of what BPEL actually is (service orchestration) and what has been marketed for (BPM).
So you might got the impression that I don't really like BPEL. And yet... I LOVE BPEL ! There, I said it. I think that BPEL is well conceived, complete and does one thing well: SERVICE ORCHESTRATION. How many specifcations get that kind of credit ? For publishing new services as a function of other services, BPEL is the best technology out there. I even consider it very complete. That is why I'm NOT one of those who claim that BPEL is lacking task management and needs BPEL4People. Forget about BPEL being a solution for BPM. Basically, the lack of task management and perceived need for BPEL4People is only an illusion created by their own marketing efforts of promoting BPEL for BPM.
So if you ever see me bashing BPEL again, remember, it's not BPEL itself that I'm bashing, it's the BPEL-BPM marketing link that I'm trying to get rid of. Real BPM folks get really frustrated with that link. I actually have no idea how it came about that this link turned out more stubborn than a whole bunch of greenpeace activists in a rubber boat. Hopefully, we can drop the 'Real' soon as every business and IT person will start to see the difference.
There is one thing however that I think currently is missing and could be the next step for the WfMC: a conceptual execution model. A very complex term for something that would be same as the relational model for databases. Standardizing process languages presents a unified picture to the business analyst. But as the developer needs to add technical details to that process, a unified view upon the execution model is needed. On the process modelling side, there are indeed a number of metamodels (most notable efforts are the XPDL metamodel and BPDM) that describe the process definition terminology. But there is currently a complete lack of mindshare for the executional metamodel. That is all the data that represents the current state of a process execution and how this data is updated when a process executes. All the engines that I have seen so far just is one of a very few execution models.
There is another area where we (the whole BPM industry) needs to improve. Typically, the initiative to go for BPM technology comes from business management. The approach is that processes are developed with a BPM System (BPMS) and that a link can be made to other software components wherever necessary. I think this approach only works well in a limited number of situations. I am much more in favour of considering processes as a part of your overall software development effort. Process languages are just Domain Specific Languages (DSL) and should be integrated in your plain software development environment.
OK, but where is JBoss jBPM positioned in all of this ? First of all, JBoss jBPM is a platform for process languages. At the base there is a java library to define and execute graphs. The actual process constructs like e.g. send email, user task and update database are defined on top of this. Every process language is made up of a set of such process constructs. And that is what is pluggable in this base library. On top of the JBoss jBPM base library, we have implemented several process languages as a set of process constructs: jPDL, BPEL and SEAM pageflow:
- jPDL is a process language with a clean interface to Java and very sophisticated task management capabilities. There is no standard for Java process languages, so it is proprietary.
- BPEL is a service orchestration language. As said before, in BPEL, you can write new services as a function of other services. This is typically a component of an Enterprise Service Bus (ESB).
- SEAM pageflow is a language that allows for the graphically define the navigation between pages in a SEAM web application.
After the kind words for XPDL, Why is there no support in jBPM ? Good question. The answer is that we want XPDL support in the JBoss jBPM platform. It is be relatively easy to implement XPDL on top of our base library. But it didn't yet get any priority yet because of the extra indirection to Java, lack of adoption and its XML schema that is a little to verbose.
Lack of adoption could definitely change after people realize that XPDL is the standard for BPM and BPEL is the standard for service orchestration. Also, I still think a clean compact XML schema is important, but I don't consider this a showstopper any more. That only leaves XPDL language neutrality which, if you're working only on the Java platform, introduces an unecessary indirection. That could in fact also be considered as XML verbosity. So the conclusion is that there is not much left except for market adoption. You can help resolve that part by bugging our sales people and ask them about our XPDL support :-)
Overall, the visit to the WfMC Standards Tutorial was time well spend and I can recommend it to everyone that is involved with BPM in one way or another.