Marlon Dumas provided a thoughtful response to my post on roundtripping. In order to address it point by point, I am reposting Marlon's comment here in a new thread., with my responses inserted:
Bruce, I agree with many of the points you make, but I strongly disagree with the proposition that BPEL is like an assembly language and that the readability of BPEL code generated from BPMN diagrams is unimportant. My three main counter-arguments are: 1) You won?t remove the developer from the BPM lifecycle, simply because no business analyst will ever be willing to write something that resembles an XPath expression, or any other expression language. And how would you otherwise encode in an executable manner all your conditional expressions and data transformation functions which you need to run your processes and move data around? One simply needs to look at the experiences of early adopters of the ?BPM on top of SOA? paradigm, such as Danske Bank which has been running a project in this space for 4-years. They have three roles: business analyst who designs high-level process model is a flowcharting notation like BPMN, the solution architect who refines these models and identifies what parts of the model will be automated and how, and finally the developer who translates them (manually) into an executable process model (see detailed discussion here: http://brahe.org/MamboPHD/index.php?option=com_docman&task=docclick&Itemid=31&bid=27&limitstart=0&limit=5)
Bruce: No one is talking about removing IT from the BPM lifecycle. In fact I even agree with your 3 roles, although I would describe their function slightly differently. The business analyst creates process models in BPMN. The solution architect (IT) makes model activities and gateways executable by configuring them via point-click dialogs and wizards (no code). The developer creates business services using Java, BPEL or whatever, which can also be bound to model activities to make them executable. The developer may be working in the SOA tool, while the business analyst and solution architect are using the BPMS.2) If we simply don?t care about the BPEL code, why would vendors not just build an engine that directly executes BPMN models? If a vendor already has a good BPEL engine, it is not extremely difficult (given the engineering resources available to them) to adapt it so that it interprets BPMN directly. And this would avoid the additional hurdle of maintaining a complex translation between BPMN and BPEL which would only make things harder to trace and to debug. If really a vendor was very keen to translate BPMN into something else, it would make much more sense to translate it into a lower-level language than BPEL, such as for example into a set of event-driven rules that can be executed in a highly scalable Complex Event Processing (CEP) engine.
Bruce: My point exactly. Basically what Lombardi, Appian, and Cordys did. Most vendors have a serviceable engine already, so if it supports the semantics expressed in BPMN, another option is to make BPMN the design surface and hide the proprietary internal language. That would describe Savvion, TIBCO, webMethods, and soon I think BEA and others. Why not a CEP engine? Why not, if it works? The test of an engine is performance, robustness, and cost. Does anyone care what its internal language looks like? My point is that BPEL's strength is there are inexpensive high-performance engines available from multiple sources. That has nothing directly to do with the language itself.3) After investing so much in BPEL, it is unlikely that vendors such as Oracle and IBM will replace it with BPMN. BPMN has to be complementary to BPEL (i.e. at a higher level of abstraction).
Bruce: Not replace BPEL with BPMN, since they don't really compete. I'm saying replace direct BPEL editing (in the BPM suite, not necessarily in the SOA toolset) with BPMN plus point-click wizards, more Lombardi-style. Both vendors you mention have taken baby steps in that direction already, and I predict in a couple years BPM from both Oracle and IBM will be a lot more business-friendly in their tooling, without giving up the underlying BPEL runtime.4) Even if we decide to use BPMN to define executable processes (as various vendors are currently pursuing), we will need two versions of BPMN: ?Business BPMN? and ?Executable BPMN? and these will be targeted at different types of users (e.g. business analysts versus architects/developers). The concerns of the business analyst are not the same as those of the solution architect and those of the developer. The business analyst will want to annotate his/her models with attributes capturing risks, compliance requirements, as well as simulation parameters. The solution architect and the developers are interested in extracting and moving data around, in defining application bindings, in addressing security, scalability and reliability issues,
Bruce: I agree that not all process models have the intention of execution, and also that the BPMN style employed may differ slightly in those two cases, but I think that's a result of the immaturity of BPMN education. Not sure if you are saying this, but I also maintain that BPMN has a lot of attributes put in there just for BPEL generation, and these are generally ignored. If that's what you mean by executable BPMN, I agree get rid of that stuff. Whether intended to create executable or not, there is also the divide between modelers who care about things like event throw-catch, multipool processes linked by message flows, and transaction compensation, and those who don't. These are also the features missing from many BPMN-based tools, so there should be some kind of dividing line related to model portability conformance classes, and I am working with the XPDL guys to promote this idea.If ever you change your mind and are looking for a BPMN-to-BPEL translation which is fairly complete AND produces readable BPMN-to-BPEL code, just point your Firefox browser here: http://www.bpel4chor.org/editor/
Take a look for example at the PriceRequest BPMN model. After opening it, you can export it to BPEL with the fourth button in the menu from left to right (?Export to BPEL4Chor?).
NOTE: This fully online BPMN editor only works with the Firefox browser and it takes about 10 to 15 seconds to load into your browser window. It?s work in progress, If you can not get your favorite BPMN model properly exported into BPEL using this online editor, just drop an e-mail to: gero.decker@hpi.uni-potsdam.de
Bruce: Based on what you say here and also privately, this tool sounds totally cool. I'm going to check it out!