Another flurry of updates in the BPMN vs. BPEL discussion: Bruce fires a shot across the bow, and then Keith Swenson makes a response in his own blog, but there is also a pretty good discussion below Bruce's post in the comment section. I think it is either a sign of progress or weariness that the debate has gotten a bit more reasonable, in that no one is arguing BPEL over BPMN or BPMN over BPEL, there is simply a discussion of how to allow the two to live harmoniously. Bruce makes key points I agree with:? we can't make the success of "BPM" dependent on agreement on definitions - its very hard to get a consensus on the definition for something as vaguely termed as "Business Process Management."? Moreover, there is no reason to believe that different organizations can't make these decisions DIFFERENTLY based on their own unique culture, personnel, skills, etc.? In one organization, the business may have members that are technical enough to model valid BPMN diagrams.? In another organization, those skills may go wanting, and the modeling will get done by IT.? In yet another, outsourcing the modeling and developing those models in JAD/RAD sessions may be the right approach.? Does anyone really expect something as broad as BPM to be a one-size-fits-all methodology? Keith raises the point that BPEL isn't enough to represent all the interesting process use-cases, and he's right.? It doesn't mean that BPMN and BPEL can't play nice together, but it does mean that a "native" BPMN xml representation, independent of BPEL, makes sense. Finally, Bruce raises the concern that this portability of models, and fidelity between diagram and XML representation, would likely be a good thing for any BPEL vendor, but the existing BPMN-native vendors might not get on board.? I think if the BPMN-native (my term for BPMS vendors who diagram BPMN processes and then execute those without losing fidelity, without translating into some other representation that doesn't match 1:1 with BPMN) vendors won't play ball with this portability, then it begs for an opensource project to help provide the import/export.? You'll have one common storage (BPMN 2.0 presumably), and you'll have a set of vendors with (potentially) proprietary storage.? That cries out for individuals to create the import/export mechanisms from each of these formats (based on which ones they know) as part of an open source project, if the vendors won't do it on their own. I'm still not sure it commoditizes the runtime however.? It commodotizes the storage definition... but one still has to write the code that will execute these models, and there will be room to compete on several fronts (performance, resource utilization, correctness, platform support, architectural compatibility, etc).? And hopefully the competition will move toward value-added features on top of these models and run-times... Because there is so much more to BPM in our future than just running these diagrams - and yet some of those future states may be hard to get to if we can't make the basic blocking and tackling easier.