- BPM is about empowering people. It was co-opted by integration vendors, who took it down an IT-centric path. ? Connie Moore, Forrester. [Note: Forrester has separate analysts and ?waves? for human-centric and integration-centric BPM. Guess which is Connie?s?]
- The ultimate goal of BPM is self-aware processes that can recommend changes to process owners. ? Connie again. [Yeah, I hear businesses asking for that all the time.]
- Portability of process templates was never a goal of BPEL, just interoperability [i.e., abstract process definition]. ? John Evdemon, Microsoft, BPEL TC co-chair. [You mean I?ve been defending BPEL against the haters all this time for nothing??]
- BPEL is not ready for production. ? Evdemon [Because the 2.0 spec could still change in the next 30 days? At least I hope that?s it?]
- BPEL probably got more press than it deserved when it came out because of the vendors supporting it. I probably should be covering up my badge. ? Evdemon again [At least the guy?s honest! Note: BizTalk 06 still doesn’t support it except as an import/export format.]
- OMG can?t finalize the metamodel (BPDM) and schema for BPMN until it works out the complete semantics of choreography (message exchange patterns between multiple collaborating processes). ? Fred Cummins, EDS, OMG BPDM TC. [Translation: don?t hold your breath?]
- The BPDM metamodel and BPMN schema are available today. It?s called XPDL. ? Keith Swenson, WfMC XPDL TC. [That?s basically true. OMG has effectively given XPDL a two-year window to establish itself as the de facto BPMN schema, and make the official OMG epic irrelevant.]
- An easier way to do BPM is to just use modeling and BAM, and forget the process engine and BPMS. That would make it easier to “sell” internally. – Consensus of BPM practitioners at my roundtable. [D’oh!]
- My blog posts are too long. Who has time to read 500 words? – Sandy Kemsley, BPM blogger. [I have no comeback to that one.]
Nine Outrageous Things I Learned At Think Tank
Share This Story, Choose Your Platform!
About the Author: Bruce Silver
6 Comments
Leave A Comment
You must be logged in to post a comment.
This site uses Akismet to reduce spam. Learn how your comment data is processed.
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?
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
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.
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?
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.
[…] 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. […]