ARIS Community - We Love BPM

Business Process Transformations Revisited

sstein's picture
by Sebastian Stein in ARIS BPM Blog posted on 2008-08-18

HazardThere are many products available on the market promising to automatically transform business process models (like BPMN or EPC) into executable ones (like BPEL or XPDL). Such transformations should help to bridge the gap between business and IT. But are those transformations really helping? Let’s have a closer look!

A business process model, depicted in one of the popular notations like BPMN or EPC, should not contain any technical details. If the underlying IT infrastructure or implementation technology changes, the business process model should remain stable. Your warning bells should ring if you have to change your business process just because you changed the implementation technology used.

Even though this seems to be obvious, it is unfortunately something not supported by most current product offerings. Typical business process management suites (BPMS) feature a nice business process modelling environment. You add your web services to those models and you can execute the models by transforming them into an executable language like BPEL. Often, you also define additional technical attributes. However, web services are already a specific technology and nobody can guarantee that this technology will be still hot in 5 years. Actually, you polluted your business process model with technical details. What you are actually doing here is using BPMN as a graphical notation for BPEL. You are not bridging the gap between business and IT, but instead you are pushing IT artefacts to the business level and forcing your business analysts to cope with technical details.

vertical Transformation of Business Process

A better scenario would be to only add a business description of the functionality required for automating each business function. The transformation would use this functionality to determine the matching web service. If you decide to change the technology, you only have to adapt the transformation, but not your business processes. Such an approach is based on vertical process transformations in contrast to the horizontal transformations used in the first approach.

There are additional requirements for a business to IT transformation to be useful. For example, it is not enough to just transform the structure of the process, but also data descriptions must be transformed as well. Also, merge support is needed, because business process and executable process might evolve at the same time and you might want to preserve changes you already did on both sides.

There are additional requirements, but too many to list them here all. However, together with the business information systems department of University of Leipzig we published a detailed description at the upcoming MDE4BPM workshop. The paper is included in the proceedings of the workshop, which you can find either on the workshop’s homepage or directly here. And if you want to see a product based on a vertical process transformation, make sure to visit the page of ARIS SOA Architect!

20502 Views
0 Likes
5 Comments
Tags
There are no attachments
Site Administrator posted on 2008-08-21

Mike van Aalst said:

Interesting point you make. It does make me wonder however about the collaboration between IDS Scheer and Oracle with the BPA Suite. Are you saying that the BPA Suite (based on Aris) is doomed to fail?

Sebastian Stein posted on 2008-07-21

 

The transformation embedded in the BPA suite is the same as we use in our standalone product. However, the transformation is extended with features used by Oracle. For example, you can define a notification and the belonging Oracle BPEL extension will be generated.

The BPA Suite is not “doomed to fail”, but it is targeting customers who know they are going to deploy their processes on Oracle’s middleware products. If a customer has a heterogeneous platform than it is unlikely to use BPA Suite. Instead, the standalone ARIS SOA Architect should be used, because it is independent of any specific middleware.

So non of the products is “doomed to fail”, but it really depends on the usecase you are going to support.

 

Site Administrator posted on 2008-08-21

Alexsander Dragnes said:

The BPA Suite to SOA Suite transformation addresses some of these concerns. When working on a BPEL process in JDeveloper you can, if you choose, add technical activities without them showing up in BPA Suite later.

Site Administrator posted on 2008-12-23

Process Automation said:

I am also with Mike Van about collaboration between IDS Scheer and Oracle with the BPA Suite. Are you saying that the BPA Suite (based on Aris) is doomed to fail?

Sebastian Stein posted on 2009-01-05

 

@Process Automation:

Did I say somewhere that BPA Suite is doomed to fail??? It has a very specific use case and therefore it is the perfect solution. So if you are in an Oracle environment, I don’t see why you should not go for it.