Business Process Transformations Revisited
There 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.
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!