BPMN to BPEL Round-tripping
March 18, 2007
In his otherwise excellent post Sharing the BPEL Love, Ismael gets Oracle’s BPMN story wrong. In this post, I explain how we, at Oracle, are addressing the BPMN to BPEL round-tripping.
In his blog Ismael says:
BPMN is where Intalio and Oracle differ. In Oracle’s case, they do not have their own process modeler, and had to license IDS Scheer ARIS. Problem is, ARIS is not fully integrated with Oracle BPEL Process Manager, hence a lot of code has to be written manually. So if you want BPMN and BPEL—and you should—but do not want to write code, give Intalio a try.
Firstly, part of the misunderstanding is due to the fact that the features outlined in this post have not yet been released; they will be in Beta soon. Nevertheless, it is important to point out that BPMN or no BPMN, Oracle’s BPEL product is a Zero Code solution.
Now to explain how Oracle is integrating the Business Analyst modeling in Aris with its BPEL Process Manager and how that provides compelling value to our customers:
Oracle’s strategy is based on our experience and belief that the business analysts and developers have different perspectives and requirements, and need different tools. However, being an applications company, we also realize the need to seamlessly integrate the life-cycle with continuous iterations. Our solution to achieve this is based on three pillars:
- Shared Logical Model (BPMN): The hand-off from business to IT happens as a shared logical model (expressed in BPMN). This model may be thought of as the contract between the business and IT; it is the lowest level of modeling for business analysts and a high level specification for the IT developer. This model is supported in both Business Analyst tool (IDS Scheer Aris) and Developer tool (Oracle BPEL PM). Although this will be usually created in the Business Analyst tool, we intend to support creation of this within the Developer tooling as well.
- Refinement from Logical to Executable: The Developer makes the logical model executable by refining it with more details. Refinement may involve providing physical bindings and transformations, as well as adding additional processing steps within what the Business Analyst considers one step. Usually, Refinement respects the logical model as a constraint, thus enabling the logical model to evolve in parallel to refinement. However, we also provide Developers the flexibility to change the logical model; such changes are then submitted back to the Business Analyst as a proposal for improvement.
- Bi-directional Sync: As mentioned before, in most cases the Refinement metaphor enables the logical and executable models to evolve in parallel. However, in some situations, conflict may arise; for example, when the Business Analyst deletes a step from the logical model. To facilitate synchronization in such situations, we provide visual diff-and-merge tool. Also, as mentioned above, although the changes are usually synchronized from Business to Developer, we support bi-directional synchronization.
The benefits of this approach are:
- Right Tool for the Right User: Instead of trying to provide an in-between tool that solves neither users’ requirements well, we provide the best tool for each user. Also, Business Analyst modeling is a serious task and tools like IDS Scheer Aris provide significant modeling and analysis capabilities beyond support for BPMN.
- Right Abstractions: BPMN or no BPMN, when you model all the details needed to make a process executable, you have a rather detailed model that loses the business audience. In my experience working with Siebel Product Managers (proxy for Business Analysts), the issue is not of a notation – they will learn whatever you will teach them. The issue is to provide them the right level of abstraction. With our Refinement approach, we are providing the Business Analysts the level of abstraction that they feel comfortable with.
We are very excited about the above features and believe this will address the Business (BPMN) to Developer (BPEL) round-tripping problem in a significant way. These features will be available as Beta soon.
March 19, 2007 at 12:59 am
Manoj,
I agree with the first part of your picture. The gap between models produced by domain analysts and those that go into execution is huge, and we need to clearly distinguish them.
However, I’m not at all sure about your statement regarding “refinement”. I’ve seen BPMN models produced by domain analysts which contain tasks that you would simply not automate at all (i.e. one task in the logical model = zero tasks in the executable model). I’ve also seen cases where a few steps are added in the technical model (especially data extraction steps) which the domain analyst wouldn’t care less about. Moreover, these additional steps in the executable model are not always related to a uniquely identifiable activity in the “logical” model. So the addition of such steps can not be seen simply as “expanding” an activity in the logical model into multiple steps in the executable model. In a perfect world of harmony, the relationship between the logical model and the executable model might be one of refinement. In practice however, things break. And allowing developers to suggest modifications to the logical model in such cases is not always a solution: because the analyst may just reply to the developer with a “no”. I think vendors should acknowledge this and provide tool support for documenting and managing arbitrary differences between the logical and the executable model, not just assume that the executable model is a refinement of the logical one.
Another thing which people seem to ignore (Ismael first in the line), is that BPMN allows for models where activities are connected in arbitrarty manners, with almost no restrictions, whereas BPEL is largely based on block-structured activities. Going from one paradigm to the other usually leads to “spaghetti code”. Do we want developers to start their work with “spaghetti code”? Moreover, BPMN to BPEL transformations (including Intalio’s one), simply fail to translate large classes of BPMN models into BPEL ones. They impose lots of restrictions on the way BPMN models should be set up before you can export them into BPEL. And of course, they’re far from doing any serious round-tripping. Maybe what vendors should do is to clearly document and perhaps even enforce in their tools the restrictions they make on the BPMN models they can round-trip (e.g. classes of BPMN models as discussed in Bruce Silver’s blogs: http://www.brsilver.com/wordpress/2006/10/13/more-on-eclarus-and-class-2/)
May 8, 2007 at 5:18 pm
Manoj
Some evidence has been published showing that the relationship between high-level process models and low-level process models is not necessarily one of refinement. Based on experiences in a project at Danske Bank in Denmark, Steen Brahe reports the following:
“…an activity was described as “create all cards”. When the developer should implement such an activity, he had to consider if a new service should be developed to create a bunch of cards, if an existing service for creating one card should be called several times in a loop structure, and what should be done in case of failures when creating the cards? Such decisions are not implementation issues; it is decisions that should have been modeled in details in the [high-level] model.”
And also that:
“Activities in a process may depend on each other. For instance, an account must be created before creating a card. Such dependencies were not always described explicitly and the developer had to figure out how to organize the control flow. These dependencies should have been described in the [high-level] model.”
And yet another example:
“Some important information was neither defined by the analyst, nor by the architect. The architect had not considered which data to use when defining service invocations or user interface based activities. Both activity types may require data that is not present and that has to be retrieved from somewhere else.”
For further details see:
http://www1.itu.dk/graphics/ITU-library/Internet/Forskning/Technical_Reports/2007/ITU-TR-2007-96.pdf
May 11, 2007 at 11:19 pm
[...] 11th, 2007 Marlon Dumas raises couple of excellent objections to my earlier post BPMN to BPEL Round-tripping. His objections are so worthy of analysis that instead of replying to his comments, I am writing [...]
February 17, 2009 at 9:16 pm
Hello All,
can any one help me to find a algo for transformatiion of BPMN work flow to XPDl.
Plz reply Soon I need it
Thanks
August 3, 2009 at 2:27 pm
Herramienta correcta para el derecho del usuario: En lugar de tratar de proporcionar una herramienta que-entre resuelve ni las necesidades de los usuarios así, ofrecemos la mejor herramienta para cada usuario. Also, Business Analyst modeling is a serious task and tools like IDS Scheer Aris provide significant modeling and analysis capabilities beyond support for BPMN. Además, Business Analyst modelado es una tarea seria y herramientas como Aris IDS Scheer significativos de modelado y análisis de las capacidades más allá de apoyo a BPMN.
Right Abstractions : BPMN or no BPMN, when you model all the details needed to make a process executable, you have a rather detailed model that loses the business audience. Abstracciones derecho: BPMN BPMN o no, cuando el modelo todos los detalles necesarios para hacer un proceso ejecutable, tiene más bien un modelo detallado de la empresa que pierde audiencia. In my experience working with Siebel Product Managers (proxy for Business Analysts), the issue is not of a notation – they will learn whatever you will teach them. En mi experiencia trabajando con los jefes de producto de Siebel (proxy para analistas de negocios), la cuestión no es de una notación – van a aprender lo que les enseñará. The issue is to provide them the right level of abstraction. La cuestión es proporcionarles el nivel de abstracción. With our Refinement approach, we are providing the Business Analysts the level of abstraction that they feel comfortable with. Con nuestro enfoque de perfeccionamiento, que están proporcionando los analistas de negocios el nivel de abstracción que se sientan cómodos.