thanks for your response, please see my response at:

http://www.ebpml.org/blog/208.htm

thanks for your response, please see my response at:

http://www.ebpml.org/blog/208.htm

There is a critical point in your article (http://www.infoq.com/articles/seven-fallacies-of-bpm) where you make the point that Bruce is wrong, because he thinks you keep layering implementation on your process until you’re done, and you argue that that is clearly wrong because these state-changes must be modeled separate from BPMN (the BEL if you will)… But I think you misunderstand where the “BPMN Camp” would draw the line around the process – indeed, those state changes would not be part of the “process” per se – triggering the state changes, but the actual management of the state changes will be via webservices, or other means. Those webservices are outside the BPMS for obvious encapsulation reasons.

It just seems to me to be that there’s a massive failure of communication. Which is easy to have happen when you have so many vague buzzwords floating around that can be interpreted so many different ways. And so many abstractions, also easily interpreted differently. I read a few of your articles and they seem to have a running theme of being brutally negative about everyone you’re quoting – they’re all “missing the boat”. I have to admit that on specific points I often agree with you :) But I also have perspective on the roles of these folks in the BPM ecosystem. My role is to make processes real for customers. For some, their role is “analyst” for some, “trainer”, for some, “CTO of software vendor” , etc. Each has their own lens through which they see BPM, BPMN, and BPEL. As a BPM practitioner, BPMN has been far more useful to me than BPEL. Just because I don’t find BPEL useful as an implementation of BPMN, doesn’t mean that I think BPEL should be resigned to the 7th circle of Hell – it just means that it should be used for what it is good at – orchestrating webservice calls. The fact that people mistook BPEL for process implementation explains a lot about why stack vendors thought that BPM was a “feature” on their EAI/SOA stack… and I think that’s where much of the confusion has come from…

I am, right now, using Lombardi to implement a process that interacts with webservices that manage the lifecycle of business data. Its a fantastic process, if I say so myself (and truly, I’m paying compliment to the customer for arriving at it, I am merely realizing that process in Lombardi). There’s no removing developers from BPM so long as software is involved in BPM. It would be like trying to remove statistics from Six Sigma (good luck!). But that doesn’t mean that the development can’t be done in the context of a model that everyone can grok (understand).

I choose not to be sad, but rather to move forward creating value with BPM. Sometimes the small actions of water molecules add up to a wave. Not all waves will build at the same speed. Not all markets will develop equally quickly. BPM is complex, its taking longer to come to fruition. But rather than be discouraged by this, I think it has given some of the software vendors time to mature (e.g. Lombardi) and some bigger vendors time to invest in the space (e.g. IBM, Oracle). Its even provided some space for people to develop the skills to roll out these BPM initiatives – the human capital component that takes the longest to develop!

There is a critical point in your article (http://www.infoq.com/articles/seven-fallacies-of-bpm) where you make the point that Bruce is wrong, because he thinks you keep layering implementation on your process until you’re done, and you argue that that is clearly wrong because these state-changes must be modeled separate from BPMN (the BEL if you will)… But I think you misunderstand where the “BPMN Camp” would draw the line around the process – indeed, those state changes would not be part of the “process” per se – triggering the state changes, but the actual management of the state changes will be via webservices, or other means. Those webservices are outside the BPMS for obvious encapsulation reasons.

It just seems to me to be that there’s a massive failure of communication. Which is easy to have happen when you have so many vague buzzwords floating around that can be interpreted so many different ways. And so many abstractions, also easily interpreted differently. I read a few of your articles and they seem to have a running theme of being brutally negative about everyone you’re quoting – they’re all “missing the boat”. I have to admit that on specific points I often agree with you :) But I also have perspective on the roles of these folks in the BPM ecosystem. My role is to make processes real for customers. For some, their role is “analyst” for some, “trainer”, for some, “CTO of software vendor” , etc. Each has their own lens through which they see BPM, BPMN, and BPEL. As a BPM practitioner, BPMN has been far more useful to me than BPEL. Just because I don’t find BPEL useful as an implementation of BPMN, doesn’t mean that I think BPEL should be resigned to the 7th circle of Hell – it just means that it should be used for what it is good at – orchestrating webservice calls. The fact that people mistook BPEL for process implementation explains a lot about why stack vendors thought that BPM was a “feature” on their EAI/SOA stack… and I think that’s where much of the confusion has come from…

I am, right now, using Lombardi to implement a process that interacts with webservices that manage the lifecycle of business data. Its a fantastic process, if I say so myself (and truly, I’m paying compliment to the customer for arriving at it, I am merely realizing that process in Lombardi). There’s no removing developers from BPM so long as software is involved in BPM. It would be like trying to remove statistics from Six Sigma (good luck!). But that doesn’t mean that the development can’t be done in the context of a model that everyone can grok (understand).

I choose not to be sad, but rather to move forward creating value with BPM. Sometimes the small actions of water molecules add up to a wave. Not all waves will build at the same speed. Not all markets will develop equally quickly. BPM is complex, its taking longer to come to fruition. But rather than be discouraged by this, I think it has given some of the software vendors time to mature (e.g. Lombardi) and some bigger vendors time to invest in the space (e.g. IBM, Oracle). Its even provided some space for people to develop the skills to roll out these BPM initiatives – the human capital component that takes the longest to develop!

it is sad that neither the BPMN nor the BPEL camp understand how these two standard relate to each other and each camp is trying to annihilate each other. Until both understand how they relate (I don’t mean “map”) then we will stand where we are, i.e. no where.

There is nothing to cheer about this situation, only sorrows on so many opportunities wasted across IT departments to make BPM successful.

JJ-

it is sad that neither the BPMN nor the BPEL camp understand how these two standard relate to each other and each camp is trying to annihilate each other. Until both understand how they relate (I don’t mean “map”) then we will stand where we are, i.e. no where.

There is nothing to cheer about this situation, only sorrows on so many opportunities wasted across IT departments to make BPM successful.

JJ-