Comments on: Dialog with Dumas on Roundtripping http://www.brsilver.com/2007/11/30/dialog-with-dumas-on-roundtripping/ Bruce Silver on business process management Thu, 09 Feb 2012 22:38:20 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: CraigH http://www.brsilver.com/2007/11/30/dialog-with-dumas-on-roundtripping/comment-page-1/#comment-485 CraigH Thu, 20 Dec 2007 11:21:46 +0000 http://www.brsilver.com/2007/11/30/dialog-with-dumas-on-roundtripping/br#comment-485 OK, I understand where you were coming from, and yes, if you must use a BPEL engine for BPM then obviously it's good to have a developer-friendly translator. As for Oracle BPA, we did a proof of concept with them and the round-tripping simply did not work in any useful way. And the translation into BPEL required so much coding to get to work that in the end the business analysts could not demonstrate the result to the business users because the final process was quite different from their original ARIS model. OK, I understand where you were coming from, and yes, if you must use a BPEL engine for BPM then obviously it’s good to have a developer-friendly translator.

As for Oracle BPA, we did a proof of concept with them and the round-tripping simply did not work in any useful way. And the translation into BPEL required so much coding to get to work that in the end the business analysts could not demonstrate the result to the business users because the final process was quite different from their original ARIS model.

]]> By: marlon_dumas http://www.brsilver.com/2007/11/30/dialog-with-dumas-on-roundtripping/comment-page-1/#comment-484 marlon_dumas Fri, 14 Dec 2007 09:32:30 +0000 http://www.brsilver.com/2007/11/30/dialog-with-dumas-on-roundtripping/br#comment-484 Hi Craig I agree 100% with you, and our apparent disagreement only comes from the fact that you are reading my comments out of their initial context. I can only agree that, ideally, all stakeholders should be speaking the same language and they should be speaking it in the same way, even if we should acknowledge that different stakeholders are concerned by different aspects. I repeat what I wrote before: If we simply don?t care about the BPEL code, why would vendors not just build an engine that directly executes BPMN models? But that's a question for vendors. Who knows? Maybe in one or two years time, a big vendor is going to release a BPMN execution engine - bypassing BPEL completely. Now that we agree that business analysts, solution architects and even developers should ideally all be talking the same language, let's go back to the original context in which the discussion was raised. The problem is that, as we speak, several projects are using BPMN (or similar notations) at the business level and BPEL at the implementation level. The Danske Bank project is an example, but also in Australia I've seen at least one other project in the same situation. In these projects, BPEL code is not assembly code: there are actual people working on this code. So our question is: what type of tool support can we provide to help projects that are juggling between BPMN and BPEL? This is the context of the discussion, An in this context, I contend that, given the choice between generating unreadable BPEL code vs generating readable BPEL code, I believe vendors should be generating readable BPEL code. Moreover, as we have shown in our work, it is not significantly more difficult to generate readable BPEL code than unreadable one. I also suggest you to take a look at Oracle BPA, which provides functionality to propagate changes in the BPEL code back to the BPMN code and vice-versa. Now, if we were all using BPMN, we wouldn't have this problem. Although I contend that we would have other problems, such as reconciling multiple overlapping views on BPMN models. At this stage, BPMN does not have a notion of "views" or "profiles". We also seem to agree with Bruce that nobody is asking business analyst to write XPath expression, and that's very reassuring. Hi Craig
I agree 100% with you, and our apparent disagreement only comes from the fact that you are reading my comments out of their initial context. I can only agree that, ideally, all stakeholders should be speaking the same language and they should be speaking it in the same way, even if we should acknowledge that different stakeholders are concerned by different aspects.
I repeat what I wrote before: If we simply don?t care about the BPEL code, why would vendors not just build an engine that directly executes BPMN models? But that’s a question for vendors. Who knows? Maybe in one or two years time, a big vendor is going to release a BPMN execution engine – bypassing BPEL completely.
Now that we agree that business analysts, solution architects and even developers should ideally all be talking the same language, let’s go back to the original context in which the discussion was raised.
The problem is that, as we speak, several projects are using BPMN (or similar notations) at the business level and BPEL at the implementation level. The Danske Bank project is an example, but also in Australia I’ve seen at least one other project in the same situation. In these projects, BPEL code is not assembly code: there are actual people working on this code. So our question is: what type of tool support can we provide to help projects that are juggling between BPMN and BPEL? This is the context of the discussion, An in this context, I contend that, given the choice between generating unreadable BPEL code vs generating readable BPEL code, I believe vendors should be generating readable BPEL code. Moreover, as we have shown in our work, it is not significantly more difficult to generate readable BPEL code than unreadable one. I also suggest you to take a look at Oracle BPA, which provides functionality to propagate changes in the BPEL code back to the BPMN code and vice-versa.
Now, if we were all using BPMN, we wouldn’t have this problem. Although I contend that we would have other problems, such as reconciling multiple overlapping views on BPMN models. At this stage, BPMN does not have a notion of “views” or “profiles”.
We also seem to agree with Bruce that nobody is asking business analyst to write XPath expression, and that’s very reassuring.

]]> By: jdubray http://www.brsilver.com/2007/11/30/dialog-with-dumas-on-roundtripping/comment-page-1/#comment-483 jdubray Thu, 06 Dec 2007 16:46:51 +0000 http://www.brsilver.com/2007/11/30/dialog-with-dumas-on-roundtripping/br#comment-483 Craig: Even though the work of this team of researcher is remarkable, I wholeheartedly agree with you. I wrote this article to explain the reason in more details. http://www.infoq.com/articles/seven-fallacies-of-bpm JJ- Craig:

Even though the work of this team of researcher is remarkable, I wholeheartedly agree with you. I wrote this article to explain the reason in more details.

http://www.infoq.com/articles/.....ies-of-bpm

JJ-

]]> By: CraigH http://www.brsilver.com/2007/11/30/dialog-with-dumas-on-roundtripping/comment-page-1/#comment-482 CraigH Tue, 04 Dec 2007 10:28:08 +0000 http://www.brsilver.com/2007/11/30/dialog-with-dumas-on-roundtripping/br#comment-482 I think Marlon has the wrong end of the stick. The issue is not generating readable BPEL for developers, the issue is reflecting any changes to the process model made by the developers back to the analysts. So long as the developers are using a different representation of the process there is room for errors of interpretation when the analysts try to put the developer's (BPEL) changes back in to the BPMN model. It means that someone, probably the developer, has to be able to look at the BPEL representation and know which bits of BPEL correspond to which bits of BPMN in order to even know where in the BPMN map the changes have been made. It's error prone, manual and inefficient. But worst of all it perpetuates the us-and-them attitude between analysts and programmers and it's about time we started getting over that. Working together on the same model is a great place to start. I think Marlon has the wrong end of the stick. The issue is not generating readable BPEL for developers, the issue is reflecting any changes to the process model made by the developers back to the analysts. So long as the developers are using a different representation of the process there is room for errors of interpretation when the analysts try to put the developer’s (BPEL) changes back in to the BPMN model. It means that someone, probably the developer, has to be able to look at the BPEL representation and know which bits of BPEL correspond to which bits of BPMN in order to even know where in the BPMN map the changes have been made.

It’s error prone, manual and inefficient. But worst of all it perpetuates the us-and-them attitude between analysts and programmers and it’s about time we started getting over that. Working together on the same model is a great place to start.

]]> By: links for 2007-12-01 « steinarcarlsen http://www.brsilver.com/2007/11/30/dialog-with-dumas-on-roundtripping/comment-page-1/#comment-481 links for 2007-12-01 « steinarcarlsen Sat, 01 Dec 2007 21:18:12 +0000 http://www.brsilver.com/2007/11/30/dialog-with-dumas-on-roundtripping/br#comment-481 [...] Dialog with Dumas on Roundtripping Great discussion on bpmn-bpel roundtripping. Pointer to the amazing oryx(?) tool (tags: bpmn bpel roundtripping) [...] [...] Dialog with Dumas on Roundtripping Great discussion on bpmn-bpel roundtripping. Pointer to the amazing oryx(?) tool (tags: bpmn bpel roundtripping) [...]

]]>