I happen to like elephants

Well, I like baby elephants. I think they're sweet. See:



Anyway, Phil Gilbert (discovered via Tom Baeyens at JBoss) makes a ferocious attack on BPEL. It's a well-written article that makes some good points.

His argument is clever so it's easy to miss the gaping hole in the floor (perhaps the elephant crashed through the floorboards under the weight of its own metaphor). However, there is a hole in his argument and it's important to discuss it.

Firstly, few could argue that he is making some good points: the "version 1" versus "version n" problem is a real one, for example. I also like his implied analogy between Java bytecode for a JVM and BPEL for a BPM-execution-engine.

However, "Business Process Management" does not equal "Modeling for Execution" and it is very important to separate these two concepts.

When you develop UML diagrams in the fashion Phil describes, you are explicitly modeling a future computer program. By contrast, the outcome of a business process modeling exercise does not have to be a running, automated, version of the process. A good Business Process Modeling tool provides value independently of other components in your stack. A classic example is the kind of project that models an existing process, performs analyses and simulations, recommends improvements to the process, analyses the proposals and which leads to a successful change in the way the organisation operates. There is no need for a runtime to be involved at all. There is no parallel I can think of between this kind of BPM project and a project in the application development space that UML dominates so successfully.

Of course, at the other end of the spectrum, a BPM solution could be implemented entirely inside a single runtime environment (an example would perhaps be a bank loan application process). In such a case, a 1-1 correspondence between the model and the runtime is, of course, highly desirable. Indeed, there is a case to be made that a suitably augmented BPEL development tool would be the right place to perform the work.

In the middle lies the most common case: a "to-be" model includes portions that will live inside a BPM execution engine, parts that are purely manual, parts that are performed by third-parties and parts that are implemented in other systems.

It goes without saying that this case is the hard one. Some parts of the model need to be made executable. Some parts need to be turned into staff manuals. Some parts need to be used as input to an application development exercise. And the whole thing needs to stay in sync. Nobody said this would be easy.

Given this bigger picture, I think he may be clouding the landscape somewhat by focussing his fire on BPEL.