Interesting article over on InfoQ: "
The Seven Fallacies of Business Process Execution" which makes the argument that combining BPMN and BPEL is a waste of time. I have to strongly agree here. I have many objections to suggesting that your analysts write a Business Process in BPMN and then generate BPEL for execution. Firstly, is that you expect analysts to write correct BPMN processes. Secondly, only a subset of BPMN is actually compilable to BPEL. Thirdly, round-tripping isn't possible. However, mainly this whole approach is doomed for simple fact that BPMN is complicated and BPEL is complicated. So even if you could do it, debugging, problem-resolution and maintainance would render such solutions unsupportable in practice.
However, it makes the contention that everything you need to solve BPM already exists. The magical solution consists of:
- BPEL
- SCA - Service Component Archtiecture (composite application framework).
- Human Task 1.0 - Web service for defining and scheduling tasks to be completed by humans (e.g. soliciting input / approval).
- Web Services (that do other stuff in the business process).
So the solution seems to be BPEL to model the business process, Web Services to implement specific functionality (e.g. createCustomer), Human Task to represent tasks that humans are required in the loop for (e.g. approve this loan decision ? ) and SCA as a means to deploy all these various bits together a composite application. While I agree with the sentiment here, I would caution that Human Task is unproven and ditto for SCA. But we can boil this down to the basic message of BPEL orchestrating Web Services (where some of those Web Services are concerned with interacting with Humans).
This is the approach Cape Clear advocates and the message is fine as far as it goes - but here's the problem. Where do you start to design your process? It is BPEL outwards? Do I describe things in WSDL and then define them in BPEL and invoke on Web Services. What about interface design? Sure even Human Task can be coupled with some rendering technology to allow simple forms to be generated, but that is for back-office work. What about front-office / customer-facing web site, where does this fit in. So this isn't a development framework, but a collection of things that you could cobble together to form a solution. How are such solutions extended and maintained (new tasks, modified task descriptions, etc, etc). For me, quite apart from the unproven status of Human Task and SCA, it seems very early days for this approach - but in theory it has merit.
Powered by ScribeFire.
