BPModelMasher: Manage Your Process Variants Effectively Sherif Sakr1 , Emilian Pascalau2 , Ahmed Awad2 , Mathias Weske2 1 NICTA and University of New South Wales, Australia ssakr@cse.unsw.edu.au 2 Hasso-Plattner-Institute, University of Potsdam, Germany {emilian.pascalau, ahmed.awad, mathias.weske}@hpi.uni-potsdam.de Abstract. Nowadays, modern organizations build large repositories of process models to describe and document their daily business operations. One reason for the large number of process models is the need to adapt with differnt busi- ness contexts, i.e. process variants. Automated maintenance of the consistency between process variants is an important goal that saves the time and efforts of process modelers. We present a query-based approach to maintain consistency among process variants called BPModelMasher. In particular, we maintain the link between the variant process models by process model views. These views are defined using, BPMN-Q, a visual query language for process models. Dynamic evaluation for the defined queries of the process views guarantee that the process modeler is able to get up-to-date and consistent status of the process model. In addition, our view-based approach allows building multiple configurations for a holistic view of related variants of the same process model. The conceptual re- sults are illustrated with a real-world sample process on customer service from eBay. 1 Introduction Business process models play an effective role in providing a better understanding of the business and facilitating communication between business analysts and IT experts. The intensive use of business process models has its flip side. In practice, business processes do not exist only under a single version which covers all the issues of the whole market. Instead, many variants of a process may exist within the same enterprise in order to deal with different business situations such as: targeting different customer types, relying on particular IT systems or complying with specific national regulations. Therefore, we can establish an analogy between process variants on the one hand and object oriented inheritance on the other hand. A process variant is like a child class which extends or overrides the behavior of the parent process. Usually, these variants are maintained manually. A direct result of this manual maintenance is the risk of inconsistency. This inconsistency appears when a parent process’s behavior is updated without updating the child’s behavior accordingly [7,8]. Nevertheless, multinational companies, e.g, eBay, have to keep many variants of business processes in order to deal with the previously mentioned different business situations. Currently, a Save-as approach is followed to create such variants which leads to losing the link between related models and makes it possible to have many redundant models and inconsistent situations. The goal of this demonstration is to present a novel framework for simplifying de- signing and managing business process model variants called BPModelMasher. The framework takes advantage of process model repositories during the design time in order to facilitate the reuse of process model fragments. By means of partial process models, the user can model new variant processes efficiently. Each partial process model is basically using two sets of notations: 1) Common process modeling constructs (e.g., tasks, control routing, control flow edges) which are used to imperatively describe the new functionality provided by the process model. Elements of a partial process model created using this notation are called the concrete parts of the model. 2) A set of nota- tion which is used to create views on the inherited behavior from the parent process. To create these views, we use BPMN-Q [1], a visual language to query business process models. Query elements of the partial process model are called the variable parts. Us- ing partial process models, we replace the manual save-as style of processes to create variants with an approach that keeps the link between child and parent processes by means of defining process views (queries). Our framework is built on top of the open modeling platform and repository Oryx [5], and the BPMN-Q query language [1,10] as a means to access and retrieve process components from the process model repository. In particular, we summarize the main strengths of our demonstrated system as follows: 1) It reduces the time and effort of the business process modeling task [10]. 2) The enabled reuse and view-definition facilities on the process fragment level improve the quality and maturity of the newly devel- oped variant process models and relaxes the learning curve, particularly for novices in a business domain [2]. 3) It facilitates the integration of different process views for a set of underlying low-level process models and automatically maintains the consistency among them [7]. This can be seen as supporting multiple inheritance among process variants. 2 Real-World Use Case of View-Based Management for Process Variants Currently, there are a number of graph-based business process modeling languages (e.g., BPMN and EPC). Despite their variance in expressiveness and modeling nota- tion, they all share the common concepts of tasks, events, gateways (or routing nodes), artifacts, and resources, as well as relations between them, such as control flow. To de- fine views over parent processes, we use the BPMN-Q notation [1,10]. The language supports, by means of visual notations, querying all the control and artifact concepts of business process models. Moreover, it introduces a set of new abstraction concepts that are useful for different querying scenarios. The structural matching of a query against a process results in a process subgraph (process fragment). In case that the subgraph is empty, we know that there is no match. Otherwise, the subgraph represents the matching part of the process to the query. Figure 1(a) illustrates a sample process model defini- tion using the BPMN notations, Figure 1(b) illustrates a sample definition of a process model view using the BPMN-Q notations and that nodes and edges highlighted in grey in Figure 1(a) illustrate the matching part of the process model. With more than 90 million active users globally, eBay is the world’s largest online marketplace. eBay connects individual buyers and sellers, as well as small businesses D A B E A // D C (a) Sample business process model (b) A BPMN-Q query Fig. 1. Example matching process between a sample process model and a BPMN-Q query Parent process end and track call ask for authentify create take call authentication manually via case data CSI add ask for customer issue to case Child process route to end and Help or refer to intercept track call hotline, end and queue create case ask for authentify track call take call manually in authentication manually via iPop data CSI add ask for customer issue ask for item ID to case and assign to case (a) An Example of Parent Process Model vs. Child Process Model Q2 Help or refer to hotline, end and track call Q1 // ask for Route to create case take call authentication intercept queue manually in iPop // data ask for issue ask for item ID and assign to case (b) A Partial Process Model to Express Inheritance Among Process Variants Fig. 2. View-based management of process variants in 38 markets using 16 languages 3 . Therefore, eBay has huge repositories of business processes. However, many of these processes are variants of other processes. The vari- ability is imposed on a vertical axis (represented by different departments within the or- ganization) and on a horizontal axis (emphasized by different business elements and/or business aspects, i.e., regulations, IT infrastructure, customer types, countries, payment methods). In principle, the number of possible process variations is determined by the degree of freedom the system has, i.e., the number of possible arrangements of different business contexts. A business process that is influenced by 6 business context elements {b1 , . . . , b6 }, e.g., country, region, etc, that respectively have the following number of subtypes {8, 2, 5, 5, 3, 7}, will end up having more than 8000 variants. The immense management effort that is required to ensure the consistency of the process models in such a context is a very difficult and complex undertaking. Figure 2(a) illustrates two variants of an eBay process model in the context of cus- tomer support. As the labels in the figure state that one of the models is called a Parent process and the other is called a Child process. A child process can reuse either parts of or the entire parent process. The terminology of child and parent is related to the inheritance concept, as the child (sub) process reuses behavior from the parent (super) process, similarly to how subclasses reuse (inherit) functionality from the super-classes. Any arbitrary process can be used as a parent process. Currently, a child process is de- 3 http://www.ebayinc.com/who; June 6th 2010 rived by making a copy of the parent process and editing that copy, e.g., adding new activities or arbitrary control flow elements. Hence, there is no connectivity between the parent and the child processes. That is, a parent process could be edited by an- other modeler who might add new functionality without it being reflected on the child process, thus causing inconsistency between the child and parent processes. Manual maintenance of process models consistency is quite exhaustive and inefficient. The notion of partial process model has been designed to address the above men- tioned challenges [2,7]. It describes a desired process model through a combination of process model concrete elements and process views (queries). Figure 2(b) shows a partial process model that models how the Child process of Figure 2(a) can be obtained and maintained from the Parent process, depicted in the same figure. In Figure 2(b), the parts with grey background represent new activities that are introduced on the child process. To keep the relationship with inherited behavior, queries are used. Q1 keeps the link with activity "take call" from the parent process model. Also, Q2 keeps the relationship with the behavior of the parent process between activity "ask for authentication data" on the one hand and a termination possibility and activity "ask for issue" on the other hand. Thus, if the parent process behavior is changed by any means of, e.g., adding extra activities between the two activities, this is updated on the child process by reevaluating the queries against the parent process. Once a partial process model is defined, it can be stored in the repository as a sepa- rate artifact that can be invoked in future. Indeed, there are two ways to invoke partial models. The first invocation is to view it. In this case, all queries in the partial model are matched to the respective parent processes. Matching parts are merged with con- crete parts and the modeler is given an up-to-date view on how the child process looks like. In the view mode, the modeler might make changes to the process. In this case, if the change concerns overriding the behavior from the parent process, the modeler is warned and switched to the editing mode. The other invocation is to edit the partial process model. In that case, the modeler is allowed to arbitrarily edit query components or concrete components of the child process. 3 System Architecture The architecture of the BPModelMasher framework is illustrated in Figure 3 and con- sists of the following main components. – Process Modeling, Querying, and Composition Environment provides the pro- cess designer with a user-friendly modeling interface [5]. Users express their in- tention by means of a partial process model. The query interface extracts the set of process model queries from the partial process model, and passes them on to the query processor. – Process Model Repository. Our framework can be connected to several, disparate, repositories to query process models that are stored remotely [10]. – Uniform Language Interface translates process models of specific languages to a common representation that is suitable to process model querying [10]. This allows to query a larger set of process models and can further be used to unify the query interface and processor toward different process definition languages [9]. – Query Processor & Process Model Indexes. The query processor evaluates the queries received from the query interface [10]. It provides support for the relax- R Client results Model Composer current model queryresults R query Query Interface Model Designer HTTP R R Process Server Query Process Model Index Model Processor Indexer R Internal Storage R Uniform Language Interface HTTP R R R Repository1 Repository2 Repositoryn Fig. 3. Framework Architecture ation and refinement of user queries. In case the queries do not return a sufficient results, the query processor is able to relax the query according to some similar- ity notions [3,6]. Similarly, if a query returns too many results, the user needs to be provided with the possibility of refining and improving their request. In order to further improve the searching, process models could be indexed upfront to expedite query evaluations. The model designer component of our framework is the Oryx editor [5,10], an on- line extensible process modeling platform for research. The query interface and query processor for BPMN-Q [1] components have been implemented as a plugin to the Oryx editor and are able to run process model queries against the Oryx online process model repository. The model composer component is implemented as another plugin to the Oryx editor that uses the BPMN-Q query processor to evaluate the results of each query in the partial process model and then returns the composed process view to the end-user. 4 Demonstration The demo will show that the business process modeling task can be very interactive and efficient using the proposed framework. In particular, we will demonstrate that the framework can improve the quality and the maturity of the process modeling task by reusing different process model components which are previously developed by busi- ness experts. Moreover, we will show how process designers can build different pro- cess views over the underlying process models and how the framework can maintain the consistency among these process variants automatically. The framework will be demonstrated using three different datasets: 1) The process model repository of eBay that has a set of innovative and special characteristics. 2) The dataset collected from the online business process modeling repository, ORYX. . 3) The dataset of the SAP reference model [4]. These datasets covers many application domains. Sample partial process models and process views will be ready to run, but users can visually edit and Query Fig. 4. Screenshot of BPModelMasher design editor. design their own ad-hoc views (see Figure 4 for a snapshot). The end users will also be able to view and validate the resulting process models for their ad-hoc definitions2 . Besides the framework demonstration, we will discuss about the design choices that we have made on defining the granularity of process model components, similarity matching scores of process model components and the ranking process of the composed process models. In addition, the results of a user-study evaluation on the precision of the ranking of the composed process models over comprehensive datasets will be exhibited. References 1. A. Awad. BPMN-Q: A Language to Query Business Processes. In EMISA, 2007. 2. A. Awad, M. Kunze, S. Sakr, and M. Weske. Design By Selection: A Reuse-based Approach for Business Process Modeling. In ER, 2011. 3. A. Awad, A. Polyvyanyy, and M. Weske. Semantic Querying of Business Process Models. In EDOC, pages 85–94, 2008. 4. T. Curran and G.Keller. SAP R/3 Business Blueprint - Business Engineering mit den R/3- Referenzprozessen. Addison-Wesley, 1999. 5. G. Decker, H. Overdick, and M. Weske. Oryx - sharing conceptual models on the web. In ER, pages 536–537, 2008. 6. R. Dijkman, M. Dumas, and L. Garcı́a-Bañuelos. Graph Matching Algorithms for Business Process Model Similarity Search. In BPM, pages 48–63, 2009. 7. E. Pascalau, A. Awad, S. Sakr, and M. Weske. On Maintaining Consistency of Process Model Variants. In BPM Workshops, 2010. 8. E. Pascalau, A. Awad, S. Sakr, and M. Weske. Partial Process Models to Manage Business Process Variants. In IJBPIM, 2011. 9. M. La Rosa, H. Reijers, W. Aalst, R. Dijkman, J. Mendling, M. Dumas, and L. Garcia- Banuelos. Apromore: An advanced process model repository. Expert Syst. Appl., 38(6):7029–7040, 2011. 10. S. Sakr and A. Awad. A Framework for Querying Graph-Based Business Process Models. In WWW, pages 1297–1300, 2010. 2 Online demo and screen casts: http://bpmnq.sourceforge.net/BPModelMasher.html