Int. J. Business Process Integration and Management, Vol. X, No. X/X, 2011 1

Partial Process Models to Manage Business ProcessVariants

Emilian PascalauHasso-Plattner-Institute,University of Potsdam, Germany,E-mail: emilian.pascalau@hpi.uni-potsdam.de

Ahmed AwadHasso-Plattner-Institute,University of Potsdam, Germany,E-mail: ahmed.awad@hpi.uni-potsdam.de

Sherif SakrNational ICT Australia (NICTA),University of New South Wales, AustraliaE-mail: ssakr@cse.unsw.edu.au

Mathias WeskeHasso-Plattner-Institute,University of Potsdam, Germany,E-mail: mathias.weske@hpi.uni-potsdam.de

AbstractToday’s process aware information systems deal often with the problem of variants. Variants of

process models have to be defined frequently due to several reasons such as: the need to targetdifferent customer types, rely on particular IT systems or comply with specific country regulations.Management of process models variants that addresses issues such as consistency between processvariants, uncontrolled redundancy, huge modeling efforts, etc is not adequately supported by currentBusiness Process Management (BPM) tool. Thus an automated maintenance of process variants ableto tackle the mentioned issues is a well coveted goal. This paper presents an approach to addressthe issues of providing consistent mechanisms for managing processes variants consistency andreducing the redundancy between process variants in order to achieve a more efficient and effectivebusiness process modeling Task. Our approach, Partial Process Models (PPM), is a query-basedapproach which maintains the link between the variant process models by means of defining processmodel views. These views are defined using, BPMN-Q, a visual query language for business processmodels and employ a software engineering like inheritance methodology . Thus, dynamic evaluationfor 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. The PPM approach provides a flexible way to dealwith process models variants both via a top-down as well as a bottom-up approach.

Keywords: Business process design, Reuse, Querying business processes, Process variants.

Reference to this paper should be made as follows: Pascalau, E., Awad, A., Sakr, S. and Weske, M.(2011) ’Partial Process Models to Manage Business Process Variants’, Int. J. Business Process In-tegration and Management, Vol. X, Nos. X/X, pp.xxx–xxx.

Biographical notes:Emilian Pascalau is a PhD student in the ”Service-oriented Systems Engineering” Re-

search School at Hasso Plattner Institute in Potsdam, Germany. There he is a memberof the Business Process Technology Group (BPT). He received a Diploma in ComputerScience from the University of Craiova, Romania and a Master degree in ”DistributiveSystems in Internet and Intranet” from Babes-Bolyai University, Cluj Napoca, Romania.

Copyright c© 2009 Inderscience Enterprises Ltd.

2 E. Pascalau et al.

He was associated member in the REWERSE Project, EU funded Network of Excellence (FP6).His research interests concern business processes and business rules on the Web and variability ofbusiness processes.

Dr. Ahmed Awad is a postdoc researcher at the Research School on Service-Oriented SystemsEngineering, the Business Process Technology Group. He received his Ph.D. in 2010 in the samegroup. His research interest is in compliance management of business processes and in queryingrepositories of business processes to support reuse based modeling of business processes.

Dr. Sherif Sakr is a research scientist in the Managing Complexity Group at National ICT Aus-tralia (NICTA). He is also a conjoint lecturer in the School of Computer Science and Engineering(CSE) at the University of New South Wales (UNSW), Australia. He received his Ph.D. degree incomputer science from Konstanz University, Germany in 2007. His research interests is data andinformation management in general, particularly in areas of indexing techniques, query processingand optimization techniques, business process management and graph data management.

Professor Dr. Mathias Weske is chair of the business process technology research group at HassoPlattner Institute of IT Systems Engineering at University of Potsdam, Germany. His research in-terests include business process management, process choreographies, process modeling method-ologies, and service oriented computing. He held a Visiting Professor position at the University ofCalifornia Davis. Dr. Weske has published twelve books and over 100 scientific papers in journalsand conferences. He is on the steering committee of the BPM conference series. He is a member ofACM, IEEE, and GI, and he is the chairperson of EMISA, the German Computer Science SocietySpecial Interest Group on Development Methods for Information Systems and their Application.

1 Introduction

In the last years companies have developed a growing in-terest for better processes, better interactions with their cus-tomers and business partners. There has been an increasedadoption of business process management (BPM) technolo-gies and tools. Nevertheless new technologies bring also newchallenges.

Business Process Management (BPM) [38] aims at the au-tomated support and coordination of business in an integratedmanner by capturing, modeling, implementing and control-ling all activities taking place in an environment that definesthe enterprise. Business processes enable a better understand-ing of the business by facilitating communication betweenbusiness analysts and IT experts. However, because of thevery complex environments of today’s business, business pro-cesses, like many information systems, do not exist only un-der a single version which covers all the issues or the wholemarket. Instead, many variants of a process exist which arespecialized for particular customer types, or for particular ITsystems, or some country-specific regulations. Thus multina-tional companies have to keep variants of business processesin order to be compliant with local regulations or domain spe-cific settings. We can establish an analogy between processvariants on the one hand and object oriented inheritance onthe other hand. A process variant is like a child class, wherea process variant (child) extends or overrides the behavior ofthe parent process. In many cases, these variants are main-tained manually, even in the case of big companies. The riskof inconsistency as well as the efforts required to improveand maintain over time these processes is huge. Inconsistencyappears when a parent process’s behavior is updated withoutupdating the child’s behavior accordingly.

Complex business environment, such as eBay businessenvironment where country regulations, different IT systems

and so forth could produce only for business process morethan 8000 variants require special management methodolo-gies that have to be simple, yet powerful enough to tackle awide range of issues which concern process variants. Currentapproaches that deal with process variants such Provop [11]or C-EPCs [28] can provide only partial support for complexbusiness environments such as the eBay environment.

In this article we discuss at large a query-based approachto tackle the problem of business process variants manage-ment. While our approach is mainly focusing on tackling theissue of automated consistency maintenance between processvariants, several other issues concerning process variants areaddressed as well. In particular, instead of the manual save-asstyle of processes to create variants, we keep the link betweenchild and parent processes by means of defining views inchild processes that reflect the behavior of parent processes.These views are created by means of queries. Thus, a processvariant combines concrete activities that are meant to providethe behavior specific to the new variant and queries that in-herit behavior from parent processes. To model process vari-ants this way, we introduce so-called Partial Process Models(PPMs). For the concrete part of the variant, ordinary processmodeling constructs are used, e.g., BPMN constructs. For theview part, we rely on BPMN-Q, a visual language for query-ing business processes models [2, 29]. In particular, each timea child process is invoked for editing or execution, the de-fined queries (views) of the child process is evaluated againstthe parent process and an up-to-date result is returned to themodeler. This view-based approach has a two fold meaning:(1) Maintaining the consistency between variants of processmodels and (2) Extracting views for different process vari-ants from holistic process models. Moreover, using queries tolink variants to their parent processes provides more flexibil-ity in designing one process variant as a child for more thanone parent (e.g. inheritance chain or multiple inheritance). In

Partial Process Models to Manage Business Process Variants 3

principle, this is a unique advantage for our approach in com-parison to the state-of-the-art of existing approaches [15, 11].

This paper improves the approach published in [21]. Themajor contributions of this work are:

• A discussion of a set of requirements extracted fromreal life scenarios to manage business process variants

• An approach to manage variants and their consistencybased on a view-based approach to define variants. Wecall this approach partial process modeling.

• Evaluation and comparison of our approach to existingapproaches that manage process variability.

The remainder of this paper is organized as follows: Wediscuss some background knowledge about business processmodels and BPMN-Q in Section 2. To illustrate the problem,we discuss several real-world use case scenarios (online trad-ing: eBay; business process compliance) in Section 3. Thesections concludes with the set of requirements for our ap-proach. Section 4 describes the details of our approach re-garding the maintenance of variants consistency through thedefinition of process model views. An architectural frame-work that realizes the implementation of our approach is pre-sented in Section 5. Section 6 evaluates our approach in con-nection with current approaches for variants management.The related work is discussed in Section 7 before we concludethe paper in Section 8.

2 Preliminaries

This section formally introduces process modeling and query-ing concepts which form the groundwork for our approach.

2.1 Business Process Modeling

Currently, there is a number of graph-based business processmodeling languages, e.g. BPMN [19], EPC [12], YAWL [36],and UML Activity Diagram [20]. Despite their variance inexpressiveness and modeling notation, they all share the com-mon concepts of tasks, events, gateways (or routing nodes),artifacts, and resources, as well as relations between them,such as control flow. Without loss of generality, we can ab-stract from particular node types as their execution seman-tics are not vital to structural query matching, which is ratherbased on the concept of a process graph.

Definition 2.1: (Process Model) A process model P is aconnected graph (N, E), where N is a non-empty set of con-trol flow nodes and E ⊆ N ×N is a set of directed controlflow edges where •n (n•) stands for the set of immediate pre-decessor (successor) nodes of n ∈ N .

A process model has exactly one start event nstart ∈N with no incoming and at least one outgoing controlflow edge, i.e., | • nstart| = 0 ∧ |nstart • | ≥ 1, and at leastone end event Nend ⊂ N with at least one incoming andno outgoing control flow edge, i.e., ∀n ∈ Nend : | • nend| ≥1 ∧ |nend • | = 0. Each other control flow node n ∈ N \({nstart} ∪Nend) is on a path from nstart to some end eventnode nend ∈ Nend. P is the set of all process models.

A connected sub-graph of a process model is a processmodel fragment. We refer to a specific type of process modelfragments that have a single entry node and at least one exitnode as process model components.

Definition 2.2: (Process Model Component) A connectedsubgraph (N ′, E′) of a process model (N, E), where N ′ ⊆N, E′ ⊆ E, is a process model component PC iff it has ex-actly one incoming boundary node nin ∈ N ′, i.e., •nin ⊆N \N ′ and at least one outgoing boundary node ∃nout ∈N ′, such that, nout• ⊆ N \N ′.

2.2 Business Process Model Querying

Based on the definition of process models and process modelcomponents, we introduce the concept of process modelqueries, as a means to obtain business process componentsfrom a collection of business processes by structurally match-ing a query to each of them. BPMN-Q is a visual processmodel query language designed to help business process de-signers access repositories of business process models [2].The language supports querying all the control and artifactconcepts of business process models. Moreover, it introducesa set of new abstraction concepts that are useful for differentquerying scenarios.

Definition 2.3: (BPMN-Q Query) A BPMN-Q query is atupleQ = (QC, QCF,QP, exclude) where:• QC is a finite set of control flow nodes in a query,• QCF ⊆ QC ×QC is the control flow relation be-

tween control nodes in a query,• QP ⊆ QC ×QC is the path relation between control

nodes in a query,• exclude : QP → 2QC is a function that determines

nodes to be excluded from the paths.

A BPMN-Q model is called a query [2]. A query declara-tively describes a structural connectivity that must be satisfiedby a matching process model. In addition to the core businessprocess modeling concepts, BPMN-Q introduces a new con-cept of Path edges. A path edge connecting two control flownodes represents an abstraction over an arbitrary set of con-trol flow nodes that could exist in-between in the matchingprocess model. Moreover, a path edge has an exclude prop-erty. That is, one might be interested in paths from node A tonode C without visiting node B.

2.3 Matching Queries to Processes.

A BPMN-Q query is matched to a candidate process modelvia a set of refinements to the query. With each refinementnode (edge) in a query is replaced with the correspondingnode (edge) of the matching process model. If one node canhave more than one possible replacement within the processmodel, a new refined copy of the query is created for eachpossible replacement. We call the replacement a resolution ofan element of the query. Figure 1(a) illustrates a sample pro-cess model definition using the BPMN notations, Figure 1(b)illustrates a sample definition of a process model view using

4 E. Pascalau et al.

B

C

D

EA

(a) Sample business process model in BPMN notation

A D//

(b) A BPMN-Q query

Figure 1 An example of process model and query

the BPMN-Q notations. The nodes and edges highlighted ingray in Figure 1(a) illustrate the matching part of the processmodel. To evaluate path edges, we rely on the transitive clo-sure of nodes regarding the control flow relation.

Definition 2.4: (Reachability) Let P = (N, E) be a pro-cess model. Let E∗ be the transitive closure over the controlflow relation E. For each node n ∈ N , we define the set ofreachable nodes from n as [[n]]E∗ = {m : (n, m) ∈ E∗}.

Relying on Definition 2.4, we can define the reachablenodes from some node x under different conditions. Forinstance [[x]](E\{(x,y)})∗ defines the reachable node fromnode x where we removed the edge (x, y) from the controlflow relation E. In light of nodes’ reachability, a path edge(source, target, EXCLUDE) evaluates to a sub-graph inwhich all nodes are: 1) Reachable from source node, 2)target node is reachable from every node, 3) every node e ∈EXCLUDE is not in the sub-graph and every node solelyreachable by e is not in the sub-graph either 4) edges betweennodes in the sub-graph are those between these nodes in theprocess model.

A process model component (N ′, E′) of a pro-cess model (N, E) is a resolution to the path edge(source, target, EXCLUDE), if

• N ′ = {n : n ∈ [[source]]E\(⋃e∈EXCLUDE(e,−))∗ ∧target ∈ [[n]]E\(⋃e∈EXCLUDE(e,−))∗},• E′ = {(x, y) : x, y ∈ N ′ ∧ (x, y) ∈ E},A process model is said to match the query if it satisfies

all control flow and path edges as described in Definition 2.5.

Definition 2.5: (Matching) A process model P = (N, E)matches a queryQ = (QC, QCF,QP, exclude) if:

• QC ⊆ N control flow nodes in the query find re-solvants in the process,• QCF ⊆ E Control flow relations in the query are in-

cluded in the process,• ∀p ∈ QP∃(N ′, E′) : sub-graph(N ′, E′)is not empty,

Customer segment

Sites Payment Department Channel

Mail

Phone

Fax

Letter

Board

CRM system

Casual Seller BE-FR PayPal Safe Harbor BE

iPop

Top Buyer A/B BE-NL Bank Transfer EU Fraud Kana

Top Buyer C Direct Debit Top Customer Care

SAP CRM

Top Seller Credit Card Office of the President

Power Seller Bronce

CoD Overflow Vendor X

Power Seller Silver

... Upload

Walk inPower Seller Gold

Power Seller Platinum

Figure 2 excerpt of eBay taxonomies

3 Motivating Scenarios & Requirements

In this section we discuss a set of motivating scenarios thatencouraged the development of our approach to model andmanage process variants.

3.1 Online Trading: eBay

With more than 90 million active users globally, eBay is theworld’s largest online marketplace. eBay connects individualbuyers and sellers, as well as small businesses in 38 marketsusing 16 languages (see http://www.ebayinc.com/who; June 6th 2010). eBay has huge repositories of businessprocesses. Though, many of these processes are variants ofother processes. We can argue that variability is imposed on avertical axis (represented by different departments within theorganization) and on a horizontal axis (emphasized by dif-ferent business elements and/or business aspects, i.e., regula-tions, IT infrastructure, for example different Customer Re-lationship Management systems, customer types, countries,payment methods).

The number of possible process variations is determinedby the degree of freedom the system has, i.e., the number ofpossible arrangements of different business contexts. A busi-ness process that is influenced by 6 business context elements{b1..b6}, e.g., country, region, etc, that respectively have thefollowing number of subtypes {8, 2, 5, 5, 3, 7}, will end uphaving more than 8000 variants. Figure 2, which contains asmall excerpt from an eBay taxonomy of business elements,exemplifies such a process influenced by six business con-texts. eBay Customer Support provides individual services tobuyers and sellers striving for the best possible individual cus-tomer service [22]. Such a goal requires mass customization.Processes need to support Customer Support Representatives(CSR) with tailored variants. As an example a Spanish busi-ness seller having an issue with mass listings would need acompletely different support than an American casual cus-tomer trying to sell his first item. Although both cases aredealing with the same question on how to list an item on eBay.Both cases would require different service levels, different en-try points such as local phone numbers or web forms and ofcourse different answers in different languages from differentteams [22].

Currently two approaches are basically used at eBay:clean sheet approach and branching approach [22]. With the

Partial Process Models to Manage Business Process Variants 5

clean sheet approach, the process variant gets redesignedfrom scratch. Therefore, this approach gets applied when cur-rent process variants are not considered to be reasonable, i.e.the business elements, the business context is quite different.With the branching (save as) approach, a process variant getscopied entirely and then is modified to fit the business needsof the new variant. It is important to underline that in this casea complete new process documentation is created and man-aged separately.

It should be noted that in both cases the issues of incon-sistency is not addressed. Variants of the same process modelare decoupled from each other, although they are semanti-cally connected. Semantically in the sense that they addressthe same problem but the business context is slightly differ-ent.

To illustrate the inconsistency case, we are going to usethe two processes from Figure 3. These processes are two reallife variants of an eBay process model in the context of cus-tomer support. As the labels in the figures state one of themodels is called a Parent process and the second one iscalled a Child process. A child process can reuse eitherparts or an entire parent process. The terminology of childand 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 fromthe superclasses. Any arbitrary process can be used as a par-ent process. Currently, a child process is derived by making acopy of the parent process and editing that copy, e.g., addingnew activities or arbitrary control flow elements. At this point,there is no connectivity between the parent and the child pro-cesses. That is, a parent process could be edited by anothermodeler who might add new functionality without it beingreflected on the child process, thus causing inconsistency be-tween the child and parent processes. Moreover, overridingbehavior in the parent process is also not tracked.

3.2 Configuration of Reference Models

The concept of reference process models has at least two in-terpretations. According to one interpretation [11] the mean-ing of a reference process model corresponds to a set of poli-cies: (1) the process model in cause is a domain specific stan-dard; (2) is the most used process variant; (3) based on astructural mining of a collection of process variants the refer-ence process model is the one for which the average distanceto the variant becomes minimal; (4) is a superset of all pro-cess variants; (5) is the intersection of all process variants.

The second major interpretation for a reference processmodel is the one defined in [28]. The big picture as it is calledcomprises the entire list of variants into one big model. Thisbig model is reduced later into relevant parts based on theneeds. We rely on this interpretation for a reference processmodel. In the case of the second interpretation, modelers nor-mally start with holistic models that contain the configurablenodes [28]. Variants correspond to specific configurations.Management of process variants by means of holistic mod-els requires basically two major things: (i) the existence ofthe holistic model and (ii) the beforehand knowledge aboutwhich elements can be configured and what will be the out-come of the configuration.

For exemplification Figure 4 depicts two eBay variantsout of which a holistic model needs to be created. There areat least two possibilities to create holistic models from thevariants of processes. One is to purely merge the variants, bysimply ”overlapping processes” and keeping only one copy ofthe elements that are the same (type, label and position in thecontrol flow) in all processes, and adding all other differentelements. The holistic model obtained by such an approachwould not guarantee the maintenance of the initial variants’behavior. Behavior maintenance is a requirement of the ap-proached proposed in [28].

Figure 5 depicts the holistic model of the two variantsfrom Figure 4, created by simple merge. The holistic modelitself created using this approach does not maintain the ini-tial behavior specified in the two separate variants. A secondmodality to create the holistic model would be to add controlflow elements that would allow the holistic model to maintainalso the individual variants’ behavior. Such a holistic modelmaintaining the initial behavior is presented in Figure 6.

Figures 5 and 6 only sketched out how holistic modelscould be created. For an in depth approach that tackles an au-tomatic way to create holistic process models one could referto [25]. Holistic process models by themselves do not resolvethe problem of variants as these have to be extracted from thereference models. Current approach [28] uses configurablenodes and special logical constructs to identify and configure(extract) a proper variant.

Due to the complexity of the eBay context such an ap-proach would be almost an impossible endeavor. The mod-eler would be required each time to traverse the entire processmodel from start to end and to know the configuration pointsand all the variants in order to configure (extract) the requiredvariant(s). Thus the question that arises is: ”How to extractprocess variants from holistic models in a more comfortableand consistent way?”.

3.3 Business Process Compliance

Business processes have to adhere to compliance require-ments enforced by regulations such as SOX [1]. In response,process- and compliance-experts develop process templatesthat are compliant by design [32]. Each newly designed pro-cess model, related to the compliance requirements, must in-herit behavior from these templates. Thus, such new processmodels represent variants over the compliant templates. Anychange to the templates must be reflected in the variants.Moreover, a variant could be related to one or more complianttemplate. That is, multiple inheritance is needed to managevariants.

A newly designed process model contains a view on thecompliant template [33]. So, a systematic approach is neededto manage the templates and complete processes that dependon them. Changes in the templates must be reflected to thedetailed processes and inconsistencies must be located and re-ported. Otherwise, the company might be subject to penaltiesdue to the violation of compliance requirements. One of themajor requirements with managing compliance templates isthat the inherited component of the compliance template mustbe distinguished within the child process. This is required in

6 E. Pascalau et al.

Parent process

Child process (eBay UK)

Figure 3 Parent process vs. Child process

a)

b)

Figure 4 Variants example

Figure 5 Holistic model by simple merge of variants from Figure 4

order to give the process modeler and practitioner the aware-ness of the compliance requirements. Thus, it is not possibleto allow editing such parts in the child process. Moreover, asthe operational process model might be subject to more thanone set of compliance requirement, i.e., needs to inherit frommore than one process template, the process model becomespolluted [33] and in specific settings it is necessary to abstractfrom some process details.

Figure 7 shows a compliant template to handle loan ap-plications within a bank. As illustrated, a component of thatmodel, loan application handling, is required to be reused andrespected by operational process models. Similarly, Figure 8shows another template in which the check data completenesscomponent is intended for reuse. Finally, Figure 9 shows anoperational model that is intended to inherit and reuse the twodifferent components from Figure 7 and 8.

Partial Process Models to Manage Business Process Variants 7

Figure 6 Holistic model that maintains also initial behavior of variants from Figure 4

Figure 7 A compliant process template for checking customer data completeness

Figure 8 A compliant process template for handling loan applications

The ultimate goal is to reflect any changes in the inheritedcomponent on the operational model. This use case differsfrom the case of managing variants because it is possible tohave more than one parent process from which behavior isinherited.

3.4 Requirements for Managing Process Inheritance

Based on the three use cases explained above, in this sec-tion, we discuss briefly the major requirements that guidedthe contribution in this paper.• Defining variants as separate process models: As in-

dicated by the use case in Section 3.1, the number ofvariants, based on the context might be huge. Thus, it isunrealistic to keep all variants stored within one model,cf. [11]. Rather, each variant should be maintained as aseparate artifact.• Maintaining Consistency: This is the core requirement.

Each variant must maintain a link with its parent pro-cess(es). Moreover, updates on the parent process thatare relevant to the variant (child) must be reflected onthe child process.• Allowing variants to override parent processes: Vari-

ants can restrict, extend or override the behavior inher-ited from the parent processes.• Multiple level inheritance: The inheritance lattice can

be of arbitrary depth. That is, a variant process c can in-herit from another variant process b that in turn inheritsfrom a parent process a.• Multiple Inheritance: Motivated by compliance tem-

plates discussed in Section 3.3, the modeling of process

variants (child) must provide the chance for a variant toinherit behavior from more than one parent.

• Ability to lock inherited parts against editing: Based onthe compliance templates scenario, there should be thepossibility to mark the inherited part of a template asread only. That is, it is not possible for the designer ofthe child process to edit that part of the process.

• Ability to hide details of parent processes: As a variantcan inherit from more than one parent. It should be pos-sible to abstract from behavior inherited from a specificparent and just showing behvior inherited from others.For instance, there should be a possibility to present theprocess in Figure 9 while hiding the behavior inheritedfrom the process in Figure 8, cf. [33].

• Identification of process models breaking consistency:In case that a (child) variant is inconsistent with its par-ent processes, the reason of inconsistency must be iden-tified. In other words, the modeling environment musthelp the designer locate the process that caused incon-sistency.

• Support for bottom-up and top-down development ofvariants: On one hand, the two use cases discussed inSection 3.1 and Section 3.3 identify the situation wherefirstly basic process models are designed and then theyare refined and tuned for a specific context by meansof creating variants. In both cases, a variant inherits be-havior from a parent process. Yet, it might contain anew functionality to meet a specific context. We callthese scenarios bottom-up development of variants. Onthe other hand, the customization of holistic processmodel, as shown in Section 3.2, is a top-down approach

8 E. Pascalau et al.

Figure 9 A compliant operational process inheriting from templates in figures 7, 8

where the variants are restrictions on the behavior ofthe holistic model.

4 Partial Process Models to Manage Inheritance

In Section 3, we explained two problems that stem from pro-cess variants management and configurable processes whichare: variants consistency and deriving variants from holis-tic processes. In this section, we describe our approach toaddress these two problems by means of defining queries onprocess models. In this sense, we see process queries as ameans to support reuse. We use BPMN-Q to create queries(views) on other processes. However, variants may extend orlimit the behavior inherited from parent processes. Thus, itis necessary as well to give the modeler the means to definenew functionalities in variants. Thus, we see queries as meansto reuse or restrict the behavior of a process in a variant. Inthe mean time, queries maintain consistency between a pro-cess and its variants. Ordinary modeling constructs are usedto define new, overriding, functionality.

Section 4.1 introduces our approach to model variants. Wecall these models partial process models (PPM). Section 4.2explains the evaluation of PPMs and how this maintains con-sistency among processes and their variants or indicates aproblem. Finally, Section 4.3 describes how PPMs can beused to address bottom-up and top-down modeling of vari-ants.

4.1 Defining Partial Process Models

The issue of consistency between variants cannot be managedin an automated way as long as the processes are decoupledfrom each other. Thus to be able to resolve the issue of con-sistency a proper way to relate processes with each other isrequired. We use queries to relate processes to each other.

To maintain the parent-child process consistency, we in-troduce the notion of partial process models, Definition 4.1,that describes a desired process model through a combina-tion of process model components (fragments) and processmodel queries (views). Thus, to derive a child process, insteadof copying the parent process and then editing that copy, themodeler starts with a partial process model. In this partial pro-cess model, ordinary process modeling constructs, e.g., ac-tivities, events, are used to model the new behavior that dis-tinguishes the variant, we call these the concrete elements.On the other hand, to reuse behavior of the parent process,BPMN-Q queries are embedded within that partial process

parent and

child

childQ Q Q

parentQ

parentP1

P2 P3

P4

Figure 10 Partial process modeling approach provides couplingbetween process models

model. Each query declaratively describes the behavior to beinherited from a specific parent process. Next, queries andconcrete parts of the process are connected via control flowedges.

Our approach is inspired by the inheritance relation fromsoftware engineering. Object-oriented design is based on thefundamental concept of reuse, reuse of software components.The Unified Modeling language (UML) [20] has been ac-cepted as the de facto [9] standard in the software industryfor designing, modeling and documenting of object-orientedsoftware systems. Inheritance is a key mechanism to achievereuse. The designer through the inheritance mechanism candesign a class, the subclass, that basically inherits featuresfrom a different class, its superclass. For our approach de-picted in Figure 10 we take into account this basic featurereuse mechanism from Object-oriented design.

The graphical representation of our approach presentedin Figure 10 emphasizes several constructs that we supportthrough partial process models. First, the issue of decouplingis overtaken as the queries refer to processes, and thus childprocesses are related to their parent processes. We call a childprocess a view of the parent process. Process P1 is a par-ent process for process P2. P2 is both a child and a parentprocess: is a child process for P1 and a parent process forP4. Process P3 is a parent process for P4. For our queriesbased approach the basic inheritance feature from softwareengineering works differently. Here opposed to software en-gineering via queries several explicit relationships can existbetween two processes. If, for example, in software engi-neering when defining a class we would be allowed to useonly once the keyword extend (i.e. class B extendsclass A), here we can define several queries that refer tothe same process. Thus saying that class B extendsclass A, extends class A, .... The inheritancebetween processes P4 and P2 exemplifies this. P4 containstwo queries that point to P2. Through this mechanism a child

Partial Process Models to Manage Business Process Variants 9

process inherits exactly the behavior that is needed from theparent process, and not the entire behavior. Here, if we wouldhave used the keyword extends instead of using queries itwould have refereed to a specific element or a fragment fromthe parent process and not to an entire process. The querycontains both the link between processes as well as the mech-anism to perform the inheritance, i.e. the query defines if weoverride behavior or just add new behavior, or restrict behav-ior. A finer granularity can be achieved through this mecha-nism. Figure 10 emphasizes also the possibility to use multi-ple inheritance. Process P4 inherits from both P2 and P3. Wecan say also that P4 is view of both P2 and P3. Our approachsupports also inheritance chaining, thus P3 inherits from P2and P2 inherits from P1.

Definition 4.1: (Partial Process Model) Let P be the set ofall process models. A partial process model P = (F, Q, E)is a connected graph that consists of disjoint sets of processmodel fragments F and process model queries Q connectedthrough directed edges E ⊆ (F×Q) ∪ (Q× F), where eachoutgoing boundary control flow node nout ∈ N of a processmodel fragment F ∈ F is connected to at least one incomingboundary control flow node nin ∈ QC of a process modelquery Q ∈ Q and vice versa. PM is the set of all partialprocess models.

To establish the link between child processes and parentprocesses, each query Q ∈ Q in a PPM P = (F, Q, E) is as-signed a reference to a specific process or another PPM. Thatis refQ : Q→ P ∪ PM. As shown in Figure 10, a partialprocess model may contain an arbitrary number of queries,each assigned a reference, we define a function refP :PM→ 2P∪PM that returns all (partial) process models di-rectly referenced by queries within a specific partial processmodel. To obtain (partial) process models referenced withinthe inheritance lattice, we define ref∗P : PM→ 2P∪PM. Inthis way, the link between the child process and its parentprocess(es) is maintained.

Cyclic relations are not allowed. The partial processmodel P2 contains a query that refers to P3 and P3 containsa query that refers to P2 creating in this way a cyclic rela-tionship between the processes P2 and P3. This is not possi-ble because in order to query a process for a particular flowthe process must exist, this cyclic relationship would generatean infinite loop and hence is a forbidden construct, formally,∀p ∈ PM : p 6∈ ref∗P(p).

As was stated in Section 3.4, it might be required that aspecific group of users are shown only parts of the inheritedbehavior. Thus, in PPM, for each query it is possible to selectwhether to evaluate it, eval : Q→ {true, false}. Similarly,a query result can be defined as whether read-only or ed-itable. That is lock : Q→ {true, false}. If for some queryq ∈ Q : lock(q) = true, at the evaluation, all resolved nodesand edges of the query will be marked as read only and theuser cannot change them.

Figure 11 shows a partial process model that correspondsto the use case illustrated in Section 3. The partial processmodel is intended to show how the Child process ofFigure 3 can be obtained and maintained from the Parentprocess, depicted in the same figure. In Figure 11, the parts

with grey background represent new activities that are intro-duced on the child process. To keep the relationship with in-herited behavior, queries are used. Q1 keeps the link with theparent process and activity "take call" from the parentprocess model is inherited. Q2 keeps the relationship with thesame parent model and the behavior of the parent process be-tween activity "ask for authentication data" onthe one hand and a termination possibility and activity "askfor issue" on the other hand is inherited.

4.2 Evaluating Partial Process Models

Once a partial process model is defined, it can be stored inthe repository as a separate artifact that can be invoked in fu-ture. Indeed, there are two ways to invoke partial models. Thefirst invocation is to view it. In this case, queries in the partialmodel are matched to the respective parent processes, basedon the configuration. Matching parts are merged with con-crete parts and the modeler is given an up-to-date view onhow the child process looks like. In the view mode, the mod-eler might make changes to the process. In this case, if thechange concerns overriding the behavior from the parent pro-cess, the modeler is warned and switched to the editing mode.In this sense, we partially address the problem of overridingbehavior. The other invocation is to edit the partial processmodel. In that case, the modeler is allowed to arbitrarily editquery components or concrete components of the child pro-cess. Here, we elaborate more on how PPM evaluation main-tains consistency or indicates a problem.

Referring to Figure 11, to obtain an up-to-date versionof the variant, both queries Q1 and Q2 have to be evaluatedagainst their referenced process models, in this specific casethey refer to the same parent process in Figure 3 . The evalu-ation yields process components according to Definition 2.5.The resulting process components are composed with con-crete elements in the PPM with respect to the control flowedges between concrete elements and query elements. Fi-nally, the resulting process model reflects the up-to-date vari-ant.

To maintain consistency between parent and child pro-cesses, a change on the parent (partial) process must be re-flected on the child process by means of query evaluation. Onthe parent-process level, a change could be adding new func-tionality, e.g., adding new tasks, removing functionality, orrestructuring the process. Now, we explain how queries re-flect these changes, if the changes happen to be in the partreferenced by queries.

Imagine that a modeler edits the parent process in Fig-ure 3 by adding a new task "Record case" between thetask "authentify manually via CSI" and the suc-ceeding XOR-split. In that case, when the partial processmodel of Figure 11 is evaluated, the newly added task willappear on the evaluation because the newly added task ison a path from "Ask for authentication data" to"Ask for issue". In the same way, if the modeler forsome reason removes the task "authentify manuallyvia CSI" this will be reflected on the evaluation of thePPM. In both cases, the modeler of the PPM gets a consistentview on the parent process.

10 E. Pascalau et al.

Route to intercept queue

take callcreate case manually in

iPop

ask for authenticati

on data

//

ask for issue

//

Help or refer to hotline, end and track call

ask for item ID and

assign to case

Q1

Q2

X

Figure 11 A partial process model to express inheritance among process variants

There might be editing operations on the parent pro-cess that break the consistency. For instance, imagine that amodeler removes the task "ask for authenticationdata" or simply edits its label in the parent process of Fig-ure 3. In that case, matching query Q2 of the partial processmodel of Figure 11 will fail, cf. Definition 2.5. When eval-uation of a query fails, it is replaced with a dummy node inthe resulting variant indicating that the specific query failedto find a match. At this point, the modeler of the variant is in-formed about a change in the parent process and she has toeither adapt the PPM definition to the new change or revokethat change on the parent level. Thus, consistency betweenthe child and the parent process model is restored.

As Figure 10 allows multiple levels of inheritance, it couldbe the case that a parent process is by itself a partial processmodel. Thus, the evaluation of a partial process model mighttrigger recursive evaluations of intermediate partial processmodels. In case any of the intermediate PPMs’ queries fails tofind a match. The recursion is aborted and the user is informedabout the partial process model and its query that failed tofind a match, as discussed in the previous paragraph.

Three concrete process models that inherit behavior fromeach other are depicted in Figure 12. The most simple processis at the top of the figure. Second process model inherits en-tirely parent’s behavior and so does the third process modelwhich inherits behavior from the second process model. Thuswe are dealing with an inheritance chain.

4.3 Deriving Variants from Holistic Models

The problem of deriving variants from holistic process mod-els can also be addressed in the same way. We store the holis-tic process model and a set of partial process models that de-fine how variants can be obtained. The step of obtaining theholistic model is out of the scope of this paper. Currently, weassume that we are able to obtain a holistic process modelfrom a set of variants. Our approach addresses and supportsthe concerns of the steps after the process of obtaining theholistic model. That is, we keep only the holistic model anda set of partial process models that define the variants and getrid of the existing original variants.

In this case, each PPM consists solely of a set of queriesthat are connected with control flow edges. These queries ex-tract the behavior inherited by the variant from the parent,holistic, model. No, concrete elements are allowed in the vari-ants. Otherwise, the PPM is extending the behavior of the par-ent process. In this scenario, the inheritance is shallow. The

Server

HT

TP

HT

TP

Repository

Repository Access

Query

Processor

Client

Model DesignerQuery Interface

R R

R

R

current model

qu

ery

re

su

lt Model Composer

R

R

Internal storage

Figure 13 Framework Architecture

holistic model is the parent process and all variants are PPMon the same level as direct children of the parent process.

5 Framework Architecture

In this section, we describe the architecture for the partialprocess modeling of business processes, illustrated in Fig-ure 13, which consists of the following main components.

• Process Modeling, Querying, and Composition En-vironment provides the process designer with a graph-ical modeling interface [7]. Users express their inten-tion by means of a partial process model (see Sec-tion 4). The query interface extracts the set of pro-cess model queries from the partial process model, andpasses them on to the query processor. The matches re-turned by the set of queries will then be composed withthe model fragments from the partial model through themodel composer.

• Process Model Repository is a central storage of busi-ness process models that is accessed in a uniformway [27].

• Query Processor The query processor evaluates thequeries received from the query interface [29] and

Partial Process Models to Manage Business Process Variants 11

Parent process

Parent and child process

Child process (eBay UK)

Figure 12 Inheritance Chain Example

passes the resultant process views to the model com-poser.

The architecture describes a prototype that already ex-ists. The client, particularly the model designer, is the Oryxeditor, an extensible process modeling platform for researchthat has been designed to model and manage process mod-els online [7]. Query interface and query processor forBPMN-Q [2] have been implemented as client-side andserver-side plugins respectively to the Oryx editor1 and areable to run process model queries against the Oryx processmodel repository. The model composer component that in-tegrates the results of queries with the concrete parts of thepartial process model is implemented also as a client-side plu-gin. The running prototype of our approach can be accessedat http://oryx-project.org/try (see Figures 15,16).

6 Approach evaluation

We evaluate our approach in comparison to the state-of-the-art for similar approaches (with respect to requirements,methodology) that are targeting the same problem as follows.

Hallerbach et al. proposed the Provop approach to modelprocess variants[10, 11]. Although the approach is meant tosupport process variants all over the process life cycle, we areconcerned with the support at the modeling phase.

The authors of Provop emphasize also in [11] both that themulti-model approach (variants are defined and maintained inseparate process models, with out being related to each otherin a consistent way) as well as the single-model approach(one model that comprises all the variants) do not constituteviable solutions in many cases.

The set of requirements which stand at the base of theProvop approach [11] touch several directions modeling, con-figuration, execution and maintenance. In Provop differentvariants are represented by a set of change operations (e.g.

insert, delete and move process fragments) that describes thedifferences between the basic process model and the associ-ated variant. In consequence the methodology of Provop orthe Provop lifecycle as depicted in Figure 4 in [11] consistsof three major phases: the process modeling phase, the con-figuration of variants phase and the process execution phase.At the modeling phase there is only one process model (alsocalled a base process or the reference process model) definedand a set of reusable change options which refer either explic-itly to process elements or implicitly to a particular processfragment (by means of adjustment points). In the configura-tion phase the base process model is configured automaticallyinto a variant, based on the set of change options, or a subsetof those change options. The automatic process takes use ofthe context to select the proper change options.

Our methodology is based on inheritance from softwareengineering. Thus we also start with a basic process but incomparison with Provop we have a direct linkage between theprocess variant definitions (here called PPMs) and the baseprocess models. For us a base process model can be a con-crete process model or a PPM, thus allowing multiple inher-itance. As stated before to obtain a variant with the Provopapproach one will always start with the base process modeland will have to apply a set of change operations. One couldargue that with an enough complex set of change operationsthe desired variant could be obtained from the base processmodel. However for complex set ups such as the eBay envi-ronment and not only (Figure 14) it would be much easier ifinaheritance directly from variants would be allowed as thecomplexity will be lower. Similar to software engineering onedoes not have to maintain all the changes from the previoussteps in the inheritance chain but just those for the currentstep. Nevertheless a set of basic change operations is alsoused in our approach. We do not take into account context.

Figure 14 has multiple purposes: (1) to show that our ap-proach can be used successfully no matter the case (we em-ploy an example used to present the Provop approach); (2)

12 E. Pascalau et al.

show inheritance chaining in action; (3) to show the simplic-ity brought by an inheritance chain.

The example addresses the the problem of a productchange. In the upper part of the Figure 14 there is the verybase process model annotated Parent process. The def-inition of the Process Variant 1 is depicted in PPM1.PPM1 is very simple and contains one BPMN-Q query Q1and one activity named d) comments outside of Q1. Theevaluation of Q1 basically returns the Parent process.In order to obtain the Process Variant 1 the Parentprocess requires a new activity d) comments. The twoparallel gateways from Q1mark the spot where the new activ-ity has to be added to the Parent process. Q1 is directlylinked with the Parent process via a direct link which inthe tool is the id of the Parent process. In consequencethe evaluation of PPM1 is Process Variant 1.

In a similar way Process Variant 2 is obtainedbased on the definition depicted in PPM2. Both queries Q1and Q2 are linked to Parent process, however becauseof the layout only one link is depicted in Figure 14. PPM2 isa little bit more complex compared to PPM1.

As it can be easily seen Process Variant 3 is a vari-ant of Process Variant 2. They differ only because ofthe activity d) comments. Query Q1 in PPM3 is linked di-rectly to PPM2, thus we are dealing with an inheritance chainas PPM2 inherits from Parent process. We argue thatPPM3 is much simpler than PPM2 as the modeler is requiredonly to add a new activity to PPM2 and is not required to dealdirectly with Parent process anymore. Thus the designis incremental, and the effort required at each step is compa-rable and manageable.

Table 1 Feature Comparison: Provop, C-EPCs and PPMsFeatures Provop C-EPCs PPMsRequirements for variantsVariants as separate process models - - +Consistency maintenance + - +Variants breaking inconsistency - - +Concerning inheritanceMultiple Inheritance - - +Multiple Level Inheritance - - +OperationsContext + + -Add new elements + - +Allow variants to override parent processes + - +Ability to lock inherited parts against editing - - +Ability to hide details of parent process + + +Process elements that can be configuredControl flow + + +Data + + -TechniqueBottom up + - +Top down - + +

A second major approach for dealing with variants is thesingle-model approach, the holistic model approach. In thiscase the reference model comprises the ”big picture” [28].Such a reference model is later configured (restricted) into amore specific process model.

Configurable Event driven process Chains (C-EPCs) [28]are an example of such an approach that tackles the prob-lem of process models variants starting from a holistic pro-cess model. Functions as well as connectors can be config-ured towards achieving a more refined process model. Theseelements can be configured based on set of configuration re-quirements and configuration guidelines. As in the Provop

case there is a configuration phase when these configurationsare performed.

The management as well the configuration of such a holis-tic process model depending on the number of variants in-volved could be a very difficult task, subject to errors. Thisfact is also underlined by a large number of publications (seefor instance [13], [14]) towards creation of a questionnaireapproach.

Configuration of holistic process models by means ofPPMs is not an issue for the approach. PPMs do not requirethe existence of any specific configurable nodes or functions.With the help of BPMN-Q queries elements or process frag-ments can be skipped for instance.

Requirements such as: (1) support for the entire pro-cesses, functions, control flow, data; (2) configuration madeat different levels are entirely or partially supported by or ap-proach. We do not support data elements. We address the is-sue of configuration at different levels by mens of inheritancechains, thus any process variant can be even more special-ized. The requirement of context based configuration is notsupported by our approach. Interrelationships between con-figuration is supported by our approach via inheritance chain,as child processes that are for example on the third, forth leveldepend on child processes closer to the root of the inheritancechain.

Table 1 depicts a side by side comparison between majorapproaches that tackle the problem of process model variantsand our approach. This comparison is based on a mixture ofrequirements of the presented approaches. Available featuresare represented in the table with the ”+” sign and those miss-ing with ”-”.

7 Related Work

The management of variants has been addressed in vari-ous domains, such as software configuration management[8, 34, 35] and feature diagrams [5, 6, 31]. For process mod-els, different approaches have been defined: configurable ref-erence process models, inheritance based and annotationsbased.

Lu and Sadiq [16] presented a process modeling frame-work that is conducive to constrained variance by support-ing user driven process adaptations. In [17] they describedanother approach for facilitating the discovery of preferredvariants based on the notion of process similarity where mul-tiple aspects of the process variants are compared accordingto specific query requirements. Compared to our approach,we address the issue of maintaining consistency among vari-ants rather than deciding whether two or more processes arevariants of each other.

C-EPCs [28] allows the configuration of process modelsby distinguishing between choices that can be made at run-time and those that have to be made before, i.e., configurationtime. Configurable nodes are used as the means to introduceconfigurability to EPCs. On the other hand aEPC [24] workson the principle of projection [3] and only elements that havea particular label are included in the extracted model. Inher-itance of behavior in workflows [37, 4] is a formal approach

Partial Process Models to Manage Business Process Variants 13

for tackling problems that are related to change. Four inheri-tance rules (protocol inheritance, projection inheritance, pro-tocol/projection inheritance, life-cycle inheritance) are de-fined to tackle dynamic change.

Annotations based approaches, e.g., the PESOA (Pro-cess Family Engineering in Service-Oriented Applications)project [23, 30] defines so-called variant-rich process mod-els as process models that are extended with stereotype an-notations to accommodate variability. Both UML ActivityDiagrams as well as BPMN models can be tackled withthis approach. The places of a process where variability canoccur are marked with the stereotype VarPoint. Severalother stereo types , e.g., Variant, Default, Abstract,Alternative, Null, Optional) are used to specify dif-ferent configuration options. Compared to our approach, wedo not predetermine configuration points.

Variants at execution time are addressed in [18]. The no-tion of process constraints is used to tackle the need for flex-ibility and dynamic change at execution time. Here a variantof a process is considered as an instance of a process.

La Rosa et al. [26] defined a questionnaire based approachto extract variants from C-EPCs. However, to do so, one needsfirst the holistic model (the C-EPC), then it needs a ques-tionnaire model and a mapping between the C-EPC and thequestionnaire model. Our approach, however, does not re-quire an additional mapping. Queries can be applied directlyto the holistic models to derive variants. For us, a holistic ora specific model makes no difference. Because the queriesare expressed with constructs similar to those in BPMN, theeasiness introduced by the questionnaire approach to extractvariants, we argue that it is also maintained here.

8 Conclusion

This article discussed at large a new approach to tackle the is-sue of managing process model variants in a consistent way.The approach is based on the idea of defining Partial ProcessModels by means of BPMN-Q process views. Thus, the pro-cess modeler can define a new process model by specifyingconcrete parts in addition to queryable process views. Eachtime the defined model is invoked for viewing, the processviews are evaluated, which guarantees returning the up-to-date and consistent model status for the process modeler. Inaddition, our view-based approach can promise other benefitssuch as extracting different views for process variants fromholistic process models.

The methodology behind the approach is influenced bythe inheritance mechanism from software engineering. Theparticularities of this methodology are of great advantage inuse cases such as those discussed in this article. Situationssuch as the eBay environment where only for process modelmore than 8000 variants could exist are almost impossibleto address with the current technologies for process variantsmanagement.

A set of requirements and fundamentals of our approachare discussed in strong connection with concrete examples.We have compared our approach with current major approachfor process variants management (Provop, C-EPCs) and un-derlined the fact that our approach can fulfill most of the re-

quirements that make the current approaches, but in additionwe address other issues that have not been touched by thecurrent approaches. Thus we provide support for maintainingconsistency of process models variants, we allow for multi-ple level inheritance, as well as multiple inheritance. Reusingexisting business knowledge materialized in existing processmodels. The reuse is not only on the level of a whole processmodel, but rather on a fine grain level which is in the form ofprocess model components. Configuration of holistic processmodels is also possible with our approach.

Context is an important factor when dealing with pro-cess variants as emphasized also both by the Provop and C-EPCs approach. Thus future work foresees the improvementof the approach discussed here with contextual information.We have already put the bases for towards using contextualinformation for process variants management using also amethodology inspired from software engineering in [22].

Acknowledgements

We would like to thank Clemens Rath from eBay’s EuropeanCenter of Excellence for his support.

References

[1] Sarbanes-Oxley Act of 2002. Public Law 107-204, (116 Statute745), United States Senate and House of Representatives inCongress, 2002.

[2] Ahmed Awad. BPMN-Q: A Language to Query Business Pro-cesses. In Proceedings of the 2nd International Workshop onEnterprise Modelling and Information Systems Architecture(EMISA 2007), pages 115–128, 2007.

[3] Thomas Baier, Emilian Pascalau, and Jan Mendling. On theSuitability of Aggregated and Configurable Business ProcessModels.

[4] Twan Basten and W.M.P. van der Aalst. Inheri-tance of Behavior. Computing Science Report, 99(17),1999. http://is.tm.tue.nl/staff/wvdaalst/publications/p93.pdf.

[5] Don S. Batory and Bart J. Geraci. Composition Validation andSubjectivity in GenVoca Generators. IEEE Trans. SoftwareEngineering, 23(2):67–84, 1997.

[6] Krzysztof Czarnecki, Simon Helsen, and Ulrich Eisenecker.Formalizing Cardinality-Based Feature Models and Their Spe-cialization. Software Process: Improvement and Practice,10(1):7–29, 2005.

[7] Gero Decker, Hagen Overdick, and Mathias Weske. Oryx -Sharing Conceptual Models on the Web. In Conceptual Mod-eling - ER 2008, pages 536–537, 2008.

[8] Jacky Estublier and Rubby Casallas. Configuration Manage-ment. Trends in software., chapter The Adele Software Config-uration Manager. 1994.

[9] Giancarlo Guizzardi. Ontological Foundations for StructuralConceptual Models. PhD thesis, Telematics Instituut, En-schede, The Netherlands, 2005. Telematica Instituut Funda-mental Research Series No. 15, ISBN 90-75176-81-3.

[10] Alena Hallerbach, Thomas Bauer, and Manfred Reichert.Managing process variants in the process life cycle. In ICEIS(3-2), pages 154–161, 2008.

14 E. Pascalau et al.

[11] Alena Hallerbach, Thomas Bauer, and Manfred Reichert. Cap-turing variability in business process models: the provop ap-proach. Journal of Software Maintenance (SMR), 22(6-7):519–546, 2010.

[12] G. Keller, M. Nuttgens, and A.W. Scheer. SemantischeProzessmodellierung auf der Grundlage “EreignisgesteuerterProzessketten (EPK)”. Technical Report 89, Institut furWirtschaftsinformatik, Saarbrucken, 1992.

[13] Marcello La Rosa, Marlon Dumas, Arthur H.M. ter Hofstede,and Jan Mendling. Questionnaire-based Variability Modelingfor System Configuration. Software and Systems Modeling(SoSyM), 8(2), 2009.

[14] Marcello La Rosa, Marlon Dumas, Arthur H.M. ter Hofstede,and Jan Mendling. Configurable Multi-Perspective BusinessProcess Models. Information Systems, 36(2), 2011.

[15] Ruopeng Lu, Shazia Sadiq, and Guido Governatori. On Man-aging Business Processes Variants. Data & Knowledge Engi-neering, 68(7), 2009.

[16] Ruopeng Lu and Shazia Wasim Sadiq. Managing Process Vari-ants as an Information Resource. In Proceedings of the 4thInternational Conference on Business Process Management(BPM), pages 426–431, 2006.

[17] Ruopeng Lu and Shazia Wasim Sadiq. On the Discovery ofPreferred Work Practice Through Business Process Variants.In Conceptual Modeling (ER), pages 165–180, 2007.

[18] Ruopeng Lu, Shazia Wasim Sadiq, Guido Governatori, and Xi-aoping Yang. Defining Adaptation Constraints for BusinessProcess Variants. In Proceedings of the International Confer-ence on Business Information Systems (BIS), pages 145–156,2009.

[19] OMG. Business Process Modeling Notation 1.2 (BPMN 1.2)Specification, Final Adopted Specification. Technical report,OMG, 2009.

[20] OMG. UML 2.0 Superstructure Specification. http://www.omg.org/spec/UML/2.0/Superstructure/PDF/, August 2005.

[21] Emilian Pascalau, Ahmed Awad, Sherif Sakr, and MathiasWeske. On Maintaining Consistency of Process Model Vari-ants. In Proceedings of the 8th International BPM Workshops(BPMN Workshops 2010), 2010.

[22] Emilian Pascalau and Clemens Rath. Managing Business Pro-cess Variants at eBay. In Proceedings of the 2nd InternationalWorkshop on BPMN (BPMN), 2010.

[23] Frank Puhlman, Arnd Schnieders, Jens Weiland, and MathiasWeske. Variability mechanisms for process models. TechnicalReport 17/2005, Hasso-Plattner-Institut, June 2005.

[24] Hajo A. Reijers, R. S. Mans, and Robert A. van der Toorn. Im-proved Model Management with Aggregated Business ProcessModels. Data Knowledge Engineering, 68(2):221–243, 2009.

[25] Marcello La Rosa, Marlon Dumas, Reina Uba, and Remco Di-jkman. Merging Business Process Models. In Proceedings ofthe Confederated International Conferences: CoopIS, IS, DOAand ODBASE, 2010.

[26] Marcello La Rosa, Johannes Lux, Stefan Seidel, Marlon Du-mas, and Arthur H. M. ter Hofstede. Questionnaire-drivenConfiguration of Reference Process Models . In Proceedingsof the 19th International Conference on Advanced InformationSystems Engineering (CAiSE), pages 424–438, 2007.

[27] Marcello La Rosa, Hajo A. Reijersb, Wil M.P. van der Aalst,Remco M. Dijkman, Jan Mendling, Marlon Dumas, and Lu-ciano Garcıa-Banuelos. Apromore : An advanced processmodel repository. http://eprints.qut.edu.au/27448/, 2009.

[28] Michael Rosemann and Wil M. P. van der Aalst. A Config-urable Reference Modelling Language. Information Systems,32(1):1–23, 2007.

[29] Sherif Sakr and Ahmed Awad. A framework for queryinggraph-based business process models. In Proceedings of the19th International World Wide Web Conference (WWW), pages1297–1300, 2010.

[30] Arnd Schnieders and Frank Puhlmann. Variability mechanismsin e-business process families. In Proceedings of the Inter-national Conference on Business Information Systems (BIS),pages 583–601, 2006.

[31] Pierre-Yves Schobbens, Patrick Heymans, and Jean-Christophe Trigaux. Feature Diagrams: A Survey and aFormal Semantics. In Proceedings of the 14th IEEE Inter-national Requirements Engineering Conference (RE), pages138–148, 2006.

[32] David Schumm, Frank Leymann, Zhilei Ma, ThorstenScheibler, and Steve Strauch. Integrating compliance into busi-ness processes: Process fragments as reusable compliance con-trols. In Proceedings of the Multikonferenz Wirtschaftsinfor-matik, MKWI’10, 2325 February 2010, G’ottingen, Germany.Universit’atsverlag G’ottingen, 2010.

[33] David Schumm, Frank Leymann, and Alexander Streule. Pro-cess views to support compliance management in business pro-cesses. In EC-Web, pages 131–142, 2010.

[34] Eirik Tryggeseth, Bjørn Gulla, and Reidar Conradi. ModellingSystems with Variability using the PROTEUS ConfigurationLanguage. In Software Configuration Management Workshop(SCM) collocated with ICSE, pages 216–240, 1995.

[35] Emre Turkay, Aniruddha S. Gokhale, and BalachandranNatarajan. Addressing the middleware configuration chal-lenges using model-based techniques. In ACM Southeast Re-gional Conference, pages 166–170, 2004.

[36] W. M. P. van der Aalst and A. H. M. ter Hofstede. YAWL: yetanother workflow language. Information Systems, 30(4):245–275, 2005.

[37] W.M.P. van der Aalst and Twan Basten. Inheritanceof Workflows: An approach to tackling problems re-lated to change. Computing Science Report, 99(06),1999. http://is.tm.tue.nl/staff/wvdaalst/publications/p85.pdf.

[38] Mathias Weske. Business Process Management: Concepts,Languages, Architectures . Springer-Verlag Berlin Heidelberg,2007.

Partial Process Models to Manage Business Process Variants 15

Pare

nt p

roce

ss

Proc

ess V

aria

nt 1

PPM

1

PPM

2

Proc

ess V

aria

nt 2

PPM

3

Proc

ess V

aria

nt 3

link to “Parent process”

link to “Parent process”

link to “PPM2”

Figure 14 Product change use case. Variants based on Figure 1 from [10]

16 E. Pascalau et al.

Figure 15 Running Prototype - Query

Figure 16 Running Prototype - Query Result