Comments on: Nine Outrageous Things I Learned At Think Tank http://www.brsilver.com/wordpress/2006/05/24/nine-outrageous-things-i-learned-at-think-tank/ Bruce Silver's blog on business process management Fri, 21 Nov 2008 23:23:36 +0000 http://wordpress.org/?v=2.5.1 By: BPMS Watch » BPEL Bashing Redux: Seeking a Middle Ground http://www.brsilver.com/wordpress/2006/05/24/nine-outrageous-things-i-learned-at-think-tank/#comment-227 BPMS Watch » BPEL Bashing Redux: Seeking a Middle Ground Tue, 26 Sep 2006 18:09:29 +0000 http://www.brsilver.com/wordpress/2006/05/24/nine-outrageous-things-i-learned-at-think-tank/#comment-227 [...] I, too, was shocked when John Evdemon announced at Think Tank that portability was never a goal of BPEL, and I agree with Dave that hyping process portability was a big factor in getting BPEL’s “coalition of the willing” on board in the early days.  So his dismay on this point is justified. [...] [...] I, too, was shocked when John Evdemon announced at Think Tank that portability was never a goal of BPEL, and I agree with Dave that hyping process portability was a big factor in getting BPEL’s “coalition of the willing” on board in the early days.  So his dismay on this point is justified. [...]

]]> By: bruce http://www.brsilver.com/wordpress/2006/05/24/nine-outrageous-things-i-learned-at-think-tank/#comment-90 bruce Tue, 30 May 2006 23:32:50 +0000 http://www.brsilver.com/wordpress/2006/05/24/nine-outrageous-things-i-learned-at-think-tank/#comment-90 David, I haven't dug into the XPDL spec enough to know if it's the answer to portabiliity today. I'm relying on statements made by Keith Swenson at the Think Tank that 1) XPDL 2.0 was designed to contain everything in BPMN, and XPDL would continue to track further enhancements of BPMN; 2) several BPMS offerings already use BPMN as an executable design front end, indicating there is room in the notation for all necessary executable detail (possibly in vendor-specific annotations); and 3) several BPMS offerings use XPDL as a container for the complete executable design. So while not all XPDL is BPMN, all BPMN is serializable as XPDL.  Or to put a slightly finer point on it... XPDL won't make a proprietary implementation portable, but it might make an implementation which is fully described in BPMN portable to other platforms that incorporate the full BPMN semantics. I agree it may be a leap of faith to say that these three statements in combination imply XPDL = portability. Maybe not today. But I think WfMC has the chance to make it so and will do it. The writing is on the wall for BPEL and other low-level execution languages: in the future, executable design will be at a higher level, and the BPEL or whatever will be generated under the covers. For that reason, as you say and I have come around to, BPEL doesn't matter... as long as portability comes from somewhere. As I've posted elsewhere, OMG has given Keith and his XPDL co-conspirators (Mike Marin, Robert Shapiro) an opening to become the de facto BPMN serialization while BPDM makes the world safe for choreography. Seizing that opportunity will put more focus on the metamodel piece of XPDL. More precision in the semantics will lead to portability, I think. On the business side, this is the non-BPEL vendors' chance to finally realize their dream -- to make BPEL actually not matter! Portability of XPDL is the key, so I think it will happen, if it is not actually there today. David,
I haven’t dug into the XPDL spec enough to know if it’s the answer to portabiliity today. I’m relying on statements made by Keith Swenson at the Think Tank that 1) XPDL 2.0 was designed to contain everything in BPMN, and XPDL would continue to track further enhancements of BPMN; 2) several BPMS offerings already use BPMN as an executable design front end, indicating there is room in the notation for all necessary executable detail (possibly in vendor-specific annotations); and 3) several BPMS offerings use XPDL as a container for the complete executable design. So while not all XPDL is BPMN, all BPMN is serializable as XPDL.  Or to put a slightly finer point on it… XPDL won’t make a proprietary implementation portable, but it might make an implementation which is fully described in BPMN portable to other platforms that incorporate the full BPMN semantics.

I agree it may be a leap of faith to say that these three statements in combination imply XPDL = portability. Maybe not today. But I think WfMC has the chance to make it so and will do it.

The writing is on the wall for BPEL and other low-level execution languages: in the future, executable design will be at a higher level, and the BPEL or whatever will be generated under the covers. For that reason, as you say and I have come around to, BPEL doesn’t matter… as long as portability comes from somewhere.

As I’ve posted elsewhere, OMG has given Keith and his XPDL co-conspirators (Mike Marin, Robert Shapiro) an opening to become the de facto BPMN serialization while BPDM makes the world safe for choreography. Seizing that opportunity will put more focus on the metamodel piece of XPDL. More precision in the semantics will lead to portability, I think.

On the business side, this is the non-BPEL vendors’ chance to finally realize their dream — to make BPEL actually not matter! Portability of XPDL is the key, so I think it will happen, if it is not actually there today.

]]> By: David Chappell http://www.brsilver.com/wordpress/2006/05/24/nine-outrageous-things-i-learned-at-think-tank/#comment-83 David Chappell Thu, 25 May 2006 13:40:06 +0000 http://www.brsilver.com/wordpress/2006/05/24/nine-outrageous-things-i-learned-at-think-tank/#comment-83 My limited understanding of XPDL suggests that it's focused on portability of the visual process design, and so it includes things like the ability to specify X/Y coordinates for each on-screen element. Does XPDL really convey enough information to make the complete logic of the process portable? And will major BPM vendors ever support it? There's a reasonable chance, I believe, that full-featured portability of process definitions across different vendor BPM products will turn out to be a pipe dream. What's your view? My limited understanding of XPDL suggests that it’s focused on portability of the visual process design, and so it includes things like the ability to specify X/Y coordinates for each on-screen element. Does XPDL really convey enough information to make the complete logic of the process portable? And will major BPM vendors ever support it? There’s a reasonable chance, I believe, that full-featured portability of process definitions across different vendor BPM products will turn out to be a pipe dream. What’s your view?

]]> By: bruce http://www.brsilver.com/wordpress/2006/05/24/nine-outrageous-things-i-learned-at-think-tank/#comment-81 bruce Thu, 25 May 2006 12:22:10 +0000 http://www.brsilver.com/wordpress/2006/05/24/nine-outrageous-things-i-learned-at-think-tank/#comment-81 David, If BPEL does not even aim for portability as an ultimate goal, I've come around to your viewpoint -- BPEL doesn't matter. But using it just as an import/export format makes it a design language not an execution language, and for that, as pointed out in the other 8 outrageous things I learned at Think Tank, XPDL is better. For one thing, you get accurate roundtripping from BPMN, the modeling tool standard and the emerging design front end as well. If the execution language is always going to be vendor-proprietary, let's just standardize the design language. BPEL is irrelevant, long live XPDL. David,
If BPEL does not even aim for portability as an ultimate goal, I’ve come around to your viewpoint — BPEL doesn’t matter. But using it just as an import/export format makes it a design language not an execution language, and for that, as pointed out in the other 8 outrageous things I learned at Think Tank, XPDL is better. For one thing, you get accurate roundtripping from BPMN, the modeling tool standard and the emerging design front end as well. If the execution language is always going to be vendor-proprietary, let’s just standardize the design language. BPEL is irrelevant, long live XPDL.

]]> By: pvs@flowcentric.net http://www.brsilver.com/wordpress/2006/05/24/nine-outrageous-things-i-learned-at-think-tank/#comment-80 pvs@flowcentric.net Thu, 25 May 2006 11:26:10 +0000 http://www.brsilver.com/wordpress/2006/05/24/nine-outrageous-things-i-learned-at-think-tank/#comment-80 I was at Bruce's table (point 8) and realized that we still have a lot of education to do on what a BPMS (Business Process Management SUITE) is before we can debate the value of using one or not. Then we still have to coss the standards hurdle ... we have our work cut out for us I was at Bruce’s table (point 8) and realized that we still have a lot of education to do on what a BPMS (Business Process Management SUITE) is before we can debate the value of using one or not. Then we still have to coss the standards hurdle … we have our work cut out for us

]]> By: David Chappell http://www.brsilver.com/wordpress/2006/05/24/nine-outrageous-things-i-learned-at-think-tank/#comment-79 David Chappell Thu, 25 May 2006 07:04:16 +0000 http://www.brsilver.com/wordpress/2006/05/24/nine-outrageous-things-i-learned-at-think-tank/#comment-79 Regarding point 5, Bruce: why does it matter whether a product runs BPEL natively or just imports and exports BPEL definitions? Given that BPEL ought to be (and typically is) generated by a graphical tool, can the user even tell the difference? True, some products allow direct programming in BPEL, but this should probably be viewed more as a bug than a feature. (XML-based languages are meant to be generated from tools, not written directly by people.) As long as the BPEL-defined behavior can be executed correctly, why should anyone care how it's accomplished? Regarding point 5, Bruce: why does it matter whether a product runs BPEL natively or just imports and exports BPEL definitions? Given that BPEL ought to be (and typically is) generated by a graphical tool, can the user even tell the difference? True, some products allow direct programming in BPEL, but this should probably be viewed more as a bug than a feature. (XML-based languages are meant to be generated from tools, not written directly by people.) As long as the BPEL-defined behavior can be executed correctly, why should anyone care how it’s accomplished?

]]>