The Shared Process Model.

Maintaining different but consistent views on the same process is often necessary in BPM projects. For example, a business analyst typically works on a business process model at a different level of abstraction than an IT architect. These views evolve independently and synchronizing them is not trivial. In this demonstration, we showcase our Shared Process Model prototype that allows different stakeholders to work on different views of a business process model while keeping these views synchronized. In particular, we will look at scenarios where a business view and an IT view are modified and a subset of the modifications need to be propagated from one view to the other. This demonstration targets the general BPM audience interested in ensuring consistency between various level of realisation of a business process model and solving the related round tripping problems. This demonstration will also appeal to people interested in process comparison and process merging — the two core techniques used by our prototype to propagate changes from one view to the other. 1 Relevance to BPM field A business process model is used by different stakeholders for different purposes. For example, a business analyst uses a business process model to document, analyze and communicate a process while an IT architect uses a process model to implement the process on a particular process engine. Both stakeholders use a model that represents the same process but from a different perspective which has different requirements. For example, the IT architect is interested in modeling the service invoked when a task is executed and the exception flow triggered when the service invocation fails. For the business analyst, these implementation details clutter the process and therefore should not appear in his view. Note that the differences are not only IT refinements, i.e., the business view is not just a subset of the IT view. We study the differences between the two perspectives in more detail elsewhere [4]. In this demo, we will showcase our Shared Process Model prototype. The Shared Process Model supports parallel maintenance of different views of a the same BPMN 2.0 model, a capability lacking in major BPM suites [2]. In Sect. 2, we discuss the features, the supported scenarios, and an overview of the implemented approach of our prototype. In Sect. 3, we describe a scenario that we will use as screen-cast to highlight the features of the Shared Process Model. In Sect. 4, we conclude with the limitations of the prototype and future work. 2 The Shared Process Model The Shared Process Model is a research prototype built on top of the BPMN2 Modeler — an Eclipse-based graphical BPMN 2.0 model editor [1]. The Shared Process Model provides to the users two different views on a process, a business view and an IT view as illustrated by Fig. 1. Fig. 1: The Shared Process Model Supported operations: The Shared Process Model supports the independent development of a business-view and an IT view of a process through tree key operations: get returns a copy of the current version of the IT or business view, change allows the user to modify his copy of the IT or business view, and update allows the user to synchronize his copy of the IT or business view with the Shared Process Model. Each change can be either designated as a common or a private change. A common change is automatically propagated by the Shared Process Model to the other view whereas a private change is not. Central features: The Shared Process Model allows a user to modify either the business or the IT view and to propagate a subset of these modifications to the other view. For example, the IT architect might decide to update changes made to the main control-flow of the process as common but to keep private the addition of the exception flow. The IT architect may need to propagate changes to the business view because the initial business model is incomplete, contains modeling errors, contradicts some IT requirements, or does not faithfully represent the actual business process. Propagating changes is also required when the business or the IT requirements change. The reasons and frequency of these updates are presented in more detail in a technical report [4]. It also ensures that the two views remain consistent, i.e., the IT view is a ‘faithful’ representation of the business view and vice et versa. The enxact notions of consistency considered ad how they are ensured or checked is out of scope of this paper but are presented in the technical report [4]. Finally, the Shared Process Model provides a set of model refactoring operations to support the user in modifying a view while retaining its consistency with the other view. For example, it provides refactoring operations to refine an activity into a subprocess or into a set of activities together with the control-flow between them, to specify that an activity is implemented as a script task or a service task, and to simplify a portion of the process into a single activity.