Architecture for a Universal Business Process Model Repository for Process Model Reuse

Mturi Elias, Paul Johannesson

Department of Computer and Systems Science (DSV),Stockholm University (SU), Stockholm, Sweden.

{mturi, pajo}@dsv.su.se

Abstract. Business process management has become one of the most important instruments to help modern organizations meet their business goals in ever more complex environments. Business process management can be efficiently supported by process modeling. However, process modeling is a complex, time-consuming, and error-prone task. Therefore, an attractive alternative to modeling business processes from scratch is deriving them by redesigning existing models. Such an approach requires the use of business process model repositories that provide a location for storing and managing process knowledge for future reuse. In this paper, we start by describing requirements for such process model repositories. Based on the requirements, we propose the architecture of the universal process model repository that would support reuse of process models. In addition, we present a prototype of the repository and demonstrate its feasibility. Finally, we argue how the proposed architecture meets the presented requirements.

1 Introduction

The rapid growth of Internet technologies over the last decade has supported enterprises in building novel infrastructures, setting up virtual organizations, operating in enlarged geographical spaces, and relying on more complex systems than ever. These developments require that the internal processes of enterprises be streamlined and aligned with partner processes. Furthermore, the IT infrastructures need to be centered around processes so that short lead times and high efficiency can be attained. Therefore, the interest in business process management and workflow systems has been steadily increasing [1].

A business process is a “collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers”, [2]. Business processes can be described by process models that are typically given in a graphical notation. A process model describes the activities, events and control flow of a business process, [3], and may also include additional information such as business goals and performance metrics. Abstracting and making the process logic explicit through such models offer several benefits, including [4, 5]: (1) Maintained focus on the business needs. During information systems analysis and design, the focus is kept on the business processes and not their technical realizations. (2) Automated enactment. The explicit representation of the business processes through process models can allow their automated enactment in

1

software. (3) Easy change management. When a business process changes, it is sufficient to capture the change in its graphical model, which will trigger synchronization of underlying systems.

While modeling of business processes offers much potentialsubstantial benefits, it is a complex, time consuming and error prone task [6, 7]. One reason for this is the high inherent complexity of many business processes. Another reason is the difficulty of reaching consensus on how the processes shall be run when many stakeholders with different interests and goals are involved in their design. While the second factor issue can be difficult to address, we believe there are effective solutions for managing process complexity. One possible solution is to collect and share process models and their associated process knowledge through a process model repository. The main benefits of such a repository include process model reuse and knowledge exchange. In addition, a process model repository can play a significant role in fostering innovation.

There exist a number of efforts to build process model repositories, e.g. the MIT Process Handbook [8], SCOR [9], SAP’s Business Map [10], and IBM’s Patterns for E-Business [11]. However, the use of such repositories is still limited and fragmented [12]. In order to investigate the reasons for this limited use, we elicited a number of requirements [13] on business process repositories and then evaluated and compared a number of existing repositories according to the requirements [14]. A main finding is that any repository requires effective instruments for searching and navigating its contents. In addition, most of the repositories are proprietary, i.e. the repositories do not allow users outside their organization to add or update process models, without prior legal permission, thereby making it difficult to achieve a critical mass of process models available for reuse.

The goal of this paper is to propose the architecture of the universal process model repository (UPR) that would increase the probability of process model reuse. The UPR is intended to be extensible, language independent, and publicly open for change and growth. The UPR architecture is designed to provide an effective instrument for searching and navigating its content. In contrast to existing repositories, the UPR architecture has adopted a cloud computing model to enables interoperability and integration with existing repositories to allow users access of process models from heterogeneous data sources.

The remainder of the paper is structured as follows. In Section 2, requirements for a process model repository are established based on literature surveys and interviews. In Section 3, the architecture of the UPR and its components are described and justified with respect to support realize the requirements. In Section 4, we provide the a prototype of the current implementation and describe the application of the repository. In Section 5, the an analytical evaluation of the architecture against the requirements is presented. Finally, the paper is concluded in Section 6.

2 Requirements for a Process Model Repository

Since there is still a lack of knowledge on requirements for process model repositories, we set out to elicit such requirements from two stakeholder groups,

2

researchers and practitioners. This was done by identifying preliminary requirements through an exploratory study and then validating them through a confirmatory study. The two phases are briefly described below, while a more complete account can be found in [13].

Exploratory Study. The exploratory study aimed at eliciting comments, opinions, suggestions and ideas on process model repositories from both researchers and practitioners with more than 10 years expertise in business process and enterprise modeling. The study was designed to collect as many ideas and suggestions as possible, encouraging the participants not to restrict their responses. Therefore, the study consisted of an open-ended questionnaire that was administered using an oral interview. Finally the collected responses were analyzed and reformulated into propositions that expressed suggestions for requirements for a process model repository.

Confirmatory Study. The confirmatory study aimed at validating the requirements propositions from the previous phase. A larger set of participants was asked to judge the validity of the propositions by assessing them using a 5-point likert Likert scale. A total of 30 participants participated took part in the study while responses from 25 participants (16 researchers and 9 practitioners) were actually used for the study. Incomplete responses and responses from participants who had not marked their profession (researcher and/or practitioner) were omitted. Finally, based on the analysis of the data collected from the confirmatory study, the requirements for a process model repository were suggested. In addition, the requirements definition process also took into account the analysis from the exploratory study.

2.1 Requirements Definitions and Justifications

Primarily based on the analysis of the confirmatory study and secondarily on the exploratory study, the following requirements for a process model repository were defined. These requirements are not claimed to be exhaustive but can be extended and adapted based on the specific purposes of a repository. Standard modeling language support: The repository should be able to store

process models in at least one standard process modelling language. Domain independence: The repository should allow storing process models

regardless of their domain—storing both domain specific and generic process models.

Process representation: Process models in the repository should be represented in both graphical and textual form to enhance understability.

Business model inclusion: The repository should store both business and process models.

Multiple granularity level: In the repository, a business process should be represented by several process models that have different levels of detail.

Versioning: The repository should allow maintaining multiple versions of a process model.

Annotation: A process model should be annotated with information that can facilitate searching, navigating and interpreting process models.

Classification scheme: Process models in the repository should be categorized

3

based on widely accepted classification schemes to facilitate navigation.

While the elicitation process has identified specific requirements for a process model repository, there also exist generic requirements for any repository that should be included in the design and implementation of a process model repository. These generic requirements include access control, change control, check-in and check-out, consistency management, content management, configuration management, interoperability with other repositories, etc. [15].

3 The Universal Process Model Repository (UPR)

The guiding principles behind the UPR design are (1) openness and extensibility—the repository will be open for change and growth by any potential user, (2) language independencet—the repository will allow storing process models regardless of the modelling notations or their format, (3) Integratedintegration—the repository will allows users to access process models from multiple repositories.

The proposed architecture of the UPR is based on the elicited requirements [13], presented in section 2 and the knowledge gathered from the review and analysis of the existing repositories [14]. The analysis indicates that the main challenge that affects their usability is the lack of an effective instrument for searching and navigating the repositories to find relevant process models [14]. This challenge has also been affirmed as the major issues in designing software reuse repositories [16, 17]. Aaccording to [16], one of the major challenges related to designing the reuse-based repository relates to the provision of an efficient mechanism to enable users to find, /select and understand the stored artifacts. Figure 1 provides a high level view of the reuse process. The architecture of the UPR is designed to provide effective instruments for searching and navigating the repository. For addressing the challenge of process model understandability, the UPR is designed to provide both graphical and textual representation of process models. In addition, the UPR is designed to enables

Figure 1: The Reuse Process (adopted from [16])

4

Process models Process Annotation

Process patterns

Repository

Abstract / Organize Understanding

Find and Select

Adapt / Modify

Compose new process model

Uniform description

Standard classification schemes (CPSAM)

Graphical (BPMN) and textual representations (CPSAM)

UPR

integration with existing repositories to allow users access process models from multiple repositories.

The basic building block of the UPR architecture is the context-based process semantic annotation model (CPSAM) [18] for semantically annotating process models. The purpose of the annotation model is to facilitate searching and navigating process models in the repositories and to enhance user understanding of process models. The annotation model includes elements for classifying business processes, which implement the searching and navigational mechanisms. In additional, the annotation model includes elements for describing a business process aimed at enhancing understandability of process models stored in the repository. The annotation model (CPSAM) consists of the following annotation elements [18], process type, process area, resource, actor, organizational level, process phase, process relationship, business context, and business goal.

The UPR provides both graphical and textual representation of a business process to enhance process model understandability. The graphical representation will be provided by standard modeling notations (i.e. BPMN, EPC, UML AD, etc). In order to support multiple modeling notations, the UPR adopts the use of stencil sets (language definition for different modeling notations) [19, 20] and plugability mechanisms, thereby achieving the language independence. The textual representation will be provided by semantic process annotation based on the annotation model. Therefore process models (in graphical form) are semantically annotated before they are stored in the repository.

The UPR has adopted the cloud computing model to allow the integration of different process model repositories. By combining the characteristics of process model repositories and the approach of cloud computing, users can access process models from multiple repositories. In addition, users have not to re-design process models from other repositories to satisfy the UPR repository.

In the next subsection, we provide a detailed discussion of the architecture of the UPR.

3.1 Architecture

The architecture of the UPR shown in Figure 2 is composed of four layers: data, mediation, service and presentation. The data layer corresponds to the process knowledge base (process KB), —which stores all the process models, process annotation, annotation model schema, algorithms and user data. The service layer corresponds to the process knowledge reuse (process KR), —which implements the processing logic necessary for manipulating and reusing the process knowledge. It includes modules for process modelling, annotation, search, and navigation as well as a version manager, data manager and user manager. The mediation layer implements the mechanism for accessing and sharing process models from external repositories. The presentation layer encompasses the web services and the applications that use the functionalities provided by the repository through this web service. The web service provides an API that maps to the repository API and interfaces all the functionalities of the repository. The use of the web service as an interface to the repository enables extensibility and integration.

5

3.1.1 Data Layer - Process Knowledge Base (Process KB)

In this section, we present data and the structure of the process knowledge stored in the UPR. The data layer consists of the persistence layer and three data entity entities stored in the UPR. Process Models: The main artefacts stored in the UPR, are the process models. The

process models are stored as XML files in the file systems. The UPR also allows storing process models represented as image files. These are process models originally designed with any standard modelling language (such as BPMN, EPC, etc.), and later converted into image format.

Process Annotation: Bbesides storing process models, the UPR stores process annotation based on the Context-based Process Semantic Annotation Model [18]. The process annotations are the instances of the CPSAM associated with stored process models. The annotations are captured by a semantic annotation module (a component of the service layer), which then indexes and stores them in a relational database.

Context-based Process Semantic Annotation Model (CPSAM) Schema. The UPR maintains the structure of the annotation model (CPSAM), from which the process annotation schema is derived. The mapping of the annotation model (CPSAM) to process annotation schema is achieved through the use of the object relational mapping (ORM) approach. This enables easy update of the process annotation database schema, when the CPSAM is modified.

Persistence Layer. UPR is publicly open for any potential users; it is expected that

6

Figure 2: The UPR Architecture

Process AnnotationCPSAM

Process Modeling

Environment

Repository API

Web application

Repository ServicesSemantic

AnnotationSearch Browse

VersionManager

Annotation Model Editor

Repository

Repository

Wrapper

Wrapper

Query Processor

Persistence Layerr

Process Models

PresentationLayer

ServiceLayer

Data Layer

Repositories in theCloud

Mediation L

ayer

many users will interact heavily with the back-end databases (process knowledge base). To make such interactions possible and make them efficient and fast, the UPR architecture includes a "persistence layer" between the service layer and data layer (process knowledge base). The persistence layer takes care of storing data from the service layer to the database and retrieving it back, alongside updating and deleting it. In the UPR, the persistence layer is based on object-relational persistence in order to achieve the ability to run on any major RDBMS.

3.1.2 Mediation Layer

Today, many process model repositories exist [8, 10, 11]. ConsequentlyFurthermore, there are several ongoing efforts to build such repositories [12, 19, 21]. Our approach intends to enable users to access process models in multiple repositories and not exclusively in its their own. However, each repository uses a different metadata structure to annotate process models and different technologies for storing process modelsthem. This makes it almost impractical to retrieve and reuse process models from external repositories. The characteristics of the cloud computing provide a promising infrastructure to compute and share resources as a service. Therefore, UPR has adopted the cloud-computing architecture to enable interoperability and data integration between UPR and existing repositories. As pointed out by Fang Liu, et al. [22], cloud architecture is about providing everything as a service. In the UPR, the integration to multiple repositories is provided as a service (IaaS). The UPR architecture introduces a mediation layer that implements the mechanisms and a uniform interface for accessing multiple heterogeneous data sources. A semantic-based query-rewriting mechanism enables the connection of new repositories. The mediation layer consists of the following services: Query Processor: To allow users query several process model repositories, the

UPR implements the query processor that accepts queries formulated in a uniform query language and returns the URIs which points to a process model that meets the query. The query processor performs two services, the query distribution and results integration. It receives the user query (in the form of CPSAM) and distributes the query to each wrapper for translation. It then receives and integrates the query results from the wrappers and forwards it to the service layer for the user.

Wrapper: The UPR maintains a wrapper for each connected repository that does the metadata or ontology translation. The wrapper gets the sub-query from the mediator, rewrites it according to the metadata structure of the target repository and submits it to the data source management. The query sent to the wrapper will contain terms from CPSAM [18]. The terms of the CPSAM in the queries have to be replaced with the corresponding terms that a target repository uses to describe its process models. In order to ensure correct substitutions, a mapping between terms of the metadata structure of the UPR (CPSAM) and the terms of the metadata structure of the corresponding repository is defined and maintained in each wrapper.

3.1.3 Service Layer - Process Knowledge Reuse (Process KR)

The service layer implements the processing logic necessary for manipulating and reusing process knowledge. In the UPR, every part of the service layer is

7

implemented as a component or a service. The foundation of the UPR architecture is based on the spring framework [23], a standard enterprise open source framework, which enables easy extensibility and configurability. Below we describe the components and services of the UPR that makes the service layer.

Process Modeling Environment (PME)

The UPR provides a place where potential users can share process knowledge for reuse. Therefore, an environment where users can create new models or modify stored process models is necessary. In the UPR, the process modeling environment (PME) provides a user interface through which process models can be created or modified with standard modeling notation. In addition, the PME is included to enable graphical representation of business processes stored in the repository. In the UPR, we propose to adopt a web based process modeling environment that can be used to author (BPMN, EPC, UML AD, etc.) processes graphically. The provision of stencil sets [19, 21] pluggability mechanism can be used to support multiple modeling notations like BPMN, EPC, etc. The process models in XML format can be stored on a file system, such that they are easily accessible and can be imported without hassles into any Java IDE. The process XML files created in the PME, are the input to the annotation service that annotate, submit and index, the process model in the files system and the annotation in the relational database.

Semantic Annotation and Indexing Service

The UPR requires process models to be semantically annotated before they are stored in the repository. Therefore, a mechanism for annotating, indexing and storing process models is required. The semantic annotation service implements the mechanism to annotate, submit and index new process models in the repository. When a user finishes to model a business process, before it is being saved, the save function invokes annotation service that enables a user to annotate the process based on the CPSAM annotation model. The process model and their associated annotation are then indexed and stored in, the process models (file system) and the process annotation (relational database), respectively. The annotation service is also invoked when a process model (in either XML or image format) is imported.

Process Searching Module

A major goal of reuse is, of course, to "find the artifacts faster than the time it takes to develop them [24]. Therefore, a mechanism to enable faster retrieval of the relevant artefacts is one of the main functional requirements for any reuse-based repository. The search module implements the search mechanism and provides the interface for enabling users to search and retrieve process models stored in the repository. The UPR provides two possible ways to search for a process model: (i) Keyword-based search: a traditional searching method which allows a user to submit keywords and the repository retrieves related process models. (ii) Annotation-based search: People, who model processes, as well as those who formulate the search queries, might use different keywords to express the same concepts. Therefore it is difficult for the user to find the relevant process model by using keywords. In order to enable retrieval of relevant process models, the UPR implements annotation based search, based on the semantic annotation model (CPSAM). It allows users to direct their search by using elements of the annotation model. The repository retrieves all the process models that

8

have been annotated with instances of one or more of the selected elements.

Repository Navigation Module

Searching involves using an indexing system in which users enter relevant keywords or annotation to locate process models [25]. Navigation (browsing) is a retrieval process that requires users to navigate a repository by following links from one item to another [25]. In the UPR, navigation module implements the navigation mechanism and provides the interface for enabling users to find a relevant process model easily through navigating the repository. A crucial challenge in designing navigation mechanisms is to create a navigation structure. A navigation structure determines the possible sequences for accessing process models, imposes an organized layout on the repository’s content [26]. The navigation structure of the UPR is implemented based on the annotation model (CPSAM). Therefore, the process models stored in the repository are organized by elements of the annotation model. Navigation has two advantages [26]: (i) it allows the user to recognize what is wanted based on his own interpretation of the link. (ii) It allows users to evaluate a large amount of process models rapidly and determine which is useful. Therefore, navigation is particularly useful when users don’t exactly know what they need.

Annotation Model Editor

The annotation model (CPSAM) suggests a number of high-level instances or categories for each element i.e. for resource we have good, services, etc. These categories can be specialized and complemented with additional categories depending on the domain under consideration. Therefore, in order to support extensibility, the UPR architecture includes the annotation model editor that allows users to define additional instances or categories for the included elements. The editor allows changes to be made only to the CPSAM schema in the data layer. The object relational mapping (ORM) function provided in the persistence layer enables automatic update of all repository services that are based on the annotation model. In this way, the extension does not break existing repository services that are oblivious to the extension and also services that are aware of the extension are able to exploit it.

Version Manager

The Version Manager implements the mechanism for managing process model variants and the change history of the process models. In the UPR, versioning is provided when a new process model is stored or an existing process model is modified. To record the change history, every new process model or modified process model is stored as a new version in the UPR. The version management method adopted in the UPR is based on semantic annotation.

Repository API

The Repository API is the central access point for the UPR repository. It provides the typical functions of the repository such as check-in and check-out operations, and views. In addition, the Repository API provides the CRUD and model import / export functions.

9

4 The Prototype Implementation

We have implemented a prototype of the UPR according to the architecture described in the previous section. The current prototype offers the following functionalities: Web-based business process modeling, import/export of process models Semantic annotation of process models Basic and advanced retrieval of process models Annotation model extension at instance or category level

As indicated earlier, UPR repository architecture is based on, spring, an open source application framework for the Java platform. The UPR implementation of the above functionalities is built upon strong open source projects: process modeling environment is implemented using activityi modeler [27], which provides web-based editor to author process models in BPMN. Currently, the process modeling environment only supports BPMN, however, in the feature future it will offer support for EPC, UML AD, etc. by defining a stencil set. Internally, process models are stored in the files system as XML or images files, whereas the process annotations are stored in the an MySQL database. The persistence layer is implemented using Hhibernate [28]. Other services in the service and mediation layer are implemented using the Jjava platform.

In the following section we demonstrate the use of the implemented repository prototype. In this demonstration, an order-to-cash business process is used as a running example. An order-to-cash is the business process where goods are: ordered, delivered and received, and as well as invoiced and paid for. All order-to-cash processes include activities related to invoicing, delivery and payment, however they have several differences. For example, an order-to-cash process for the delivery of goods (e.g., delivery of office supplies) is different from the one for the delivery of services (e.g., delivery of consultancy services). The use of CPSAM for classifying and describing these processes captures their similarities and differences, thus enabling a repository user to find a relevant process model.

An example scenario starts with a business analyst who uses the tool to annotate, an order-to-cash process model for the delivery of goods, and stores it in the repository. The scenario is followed by another user who performs a search in the repository to find an order-to-cash process model for delivery of services.

Task 1: Annotation of a Process Model—a Use Case

Suppose the analyst has already designed an order-to-cash business process using the process modeler provided in the repository. Before storing a process model, the analyst is required to annotate the process model in Figure 3 (a) below using the semantic annotation service. It is assumed that the analyst is the process owner, so he provides the process name

(in this case order-to-cash), and process description of a process model. The version number is assigned automatically.

Main activities included in this process regards getting buyers to purchase products i.e. selling, therefore the “Process Area” is “Marketing and Sales”.

This process includes day-to-day activities, therefore “Organization Level” is “operational”,

10

The process involves exchange of resources, therefore “Process Type” is “Exchange”,

The process includes activities for preparing and performing the exchange, therefore “Exchange Process Phase” is “Actualization”.

(a)

(b)

(c)Figure 3: Order to cash process models

The reseller receives payment (i.e. cash, cheque) and ship products (goods) to the buyer, therefore the resource being exchanged identified as “Resource Received” is “Financial” and “Resource Provided” is “Goods”.

11

The actors involved in the exchange identified as “Principal Actor” is “Supplier”, whose role is a reseller and “Other Actor” is “Customer”, whose role is a buyer.

This process may have several goals ranging from financial perspective to customer perspective. In this case, let us assume that the “Goal Perspective” is “Customer” and the goal is to “Increase customer satisfaction and retention”

This is a generic order to cash process, not restricted to any domain; therefore it is not annotated with business context information.

Therefore, the analyst will produce the annotation as shown in Figure 4.

Figure 4: Annotation of an order to cash process model (for delivery of goods)

Task 2: Searching a Process Model—a Use Case

In this task, we describe how a repository user uses the CPSAM based annotation to search for an order-to-cash process model (for delivery of service) in the repository. People, who model processes, as well as those who formulate the search queries, might use different vocabularies to express the same concepts. Therefore, it is difficult for the user to find the relevant process model by using only keywords. For example, suppose, a user use the word “order to cash” for the keyword-based search. The result of the query will include any process with either of the word order, to, or cash.

Using annotation-based search, the user looking for an order-to-cash process model for consultancy service delivery, can limit the search to annotation elements. Starting with process area, organization level, process type, and process phase; the result of the query 1 in Figure 5 (a) consisted of 3 process models (shown in Figure 3) from the studied repository. Therefore, a user can take a strategy of stepwise narrowing the query by using more annotation elements. Since the user is looking for an order to cash process model for service delivery, this means the resource provided in exchange is the ‘Service’ and the resource received is ‘Financial’. This way we decrease the search space. The process model from Figure 3 (b) is retrieved as the relevant process following the execution of the search query 2, shown in Figure 5 (b).

12

(a) Query 1

(b) Query 2

Figure 5: Searching Process Model

Suppose query 2 is altered, by changing the Resource Provided from “Service” to “Goods”. After executing the search query the user retrieve 2 process models, that include process model shown in Figure 3 (a) and (b), as the relevant process models. A query may results to any number of process models that are considered as relevant. Therefore the user may identify the relevant process model that meets his or her business need from the number of retrieved models. Otherwise the user may decide to alter, by narrowing, the query for further search. Similarly, the user may decide to expand the query in order to increase search space to find the relevant process model.

13

5 Evaluation

In this section, the UPR architecture is evaluated analytically according to the requirements presented in section 2. In addition we compare, as shown in Table 1, the UPR and the surveyed repositories based on the requirements. The following discussion points out how each requirement is meet by the architecture. Standard modeling language support. In the UPR, a standard modeling language is

provided by the process modeling environment (PME), which currently supports BPMN. An alternative to supporting multiple modeling notations is by defining stencil sets for each modeling language to be added.

Table 1: Comparison of UPR and Existing Repositories (extended from [14])U

PR

MIT

SC

OR

IBM

PR

IBM

-BP

EL

SB

PR

Ory

x

SA

P

Pro

sero

Rep

ox

AP

RO

MO

RE

Openness + - - - - + + - - - +Standard modeling language support + - - - + + + - - + +Domain independence + + - - + + + - + + +Process representation G&T T T G&T G G G G&T G G GBusiness models inclusion - - - - - - - - - - -Versioning + - - - - + - - - + +Goal inclusion + - - - - - - - - - -Classification scheme + + + + - - - + - - -

Where, T stands for textual representation and G for graphical representation

Domain independence: The UPR allows storing both generic and domain specific process models. In order to enable users to identify domain specific process models, the semantic annotation service requires annotating domain specific models with the information about their domain.

Process representation: The UPR stores both process models (graphical) and process annotations (textual). The graphical representation (i.e. BPMN, EPC, etc) is provided by the PME of the UPR, where as process annotations based on CPSAM, are the complementary textual descriptions of the corresponding process models.

Business model inclusion. While not claiming to address the issue concerning business model inclusion, along the lines of research [29, 30], we do claimnote that these can be addressed by extending the annotation model with business model concepts.

Versioning: the UPR architecture includes a versioning manager that tracks and records the history of process models. The UPR uses the annotation to implement the semantic-based version management.

Annotation: in the UPR, process models are semantically annotated by using the semantic annotation service. The process annotations are stored in the process annotation database.

Classification scheme: The semantic annotation service of the UPR implements annotation model that includes a classification scheme. Process models are classified by its process area, process type, organizational level and exchange

14

RepositoriesRequirements

process phases. In addition, a process can be classified by type of resource being exchanged or consumed/produced.

Multiple levels of granularity. This requirement cannot be addressed at the repository design level, because granularity is the process design intentional, however at the repository level, this is met if the repository supports multiple versions of the same process, provided by the version manager in the UPR.

The evaluation provides the evidence that the UPR meets the requirements except the requirement for business models inclusion. We hypothesize envisage that this can be achieved by extending the annotation model to include business model element.

6 Conclusion

In this paper, we proposed the an architecture of the Universal Process Model Repository (UPR) to support reuse of process models. We proposed a 4-layer architecture of the UPR to facilitate the sharing, reusing process models and interoperability among various repository content efficiently. The design of the UPR is based on the elicited requirements [13] as well as a , and review and analysis of existing process model repositories [14]. It integrates the ideas from knowledge representation, business process modeling, cloud computing, databases and software reuse repositories. Among the enhancements, we note the efficient mechanism for searching and navigating repository content to find a relevant process models. Openness, extensibility, language independence and integration have all saved served as the guiding principles forof the architectural design and prototype implementation.

Ongoing experiments with different users seem to indicate that the success of the prototype implementation of the UPR architecture is, in fact, generalizable. However, the implementation of a working repository requires more facilities than those offered by the current prototype. In particular, additional research is needed to address the issue of integration with existing repositories.

References

1. Kirchmer, M.: Management of Process Excellence. In: vom Brocke, J., Rosemann, M. (eds.) Handbook on Business Process Management 2, pp. 39-56. Springer Berlin Heidelberg (2010).

2. http://en.wikipedia.org/wiki/Business_process (last accessed February 25, 2012)3. Recker, J.C., Rosemann, M., Indulska, M., Green, P.: Business process modeling : a

comparative analysis. Journal of the Association for Information Systems 10, 333–363 (2009)4. Dumas, M., Aalst, W.M.v.d., Hofstede, A.H.t.: Process-Aware Information Systems:

Bridging People and Software Through Process Technology. John Wiley & Sons Inc. (2005)5. Indulska, M., Green, P., Recker, J., Rosemann, M.: Business Process Modeling: Perceived

Benefits. In: Laender, A., Castano, S., Dayal, U., Casati, F., de Oliveira, J. (eds.) Conceptual Modeling - ER 2009, vol. 5829, pp. 458-471. Springer Berlin / Heidelberg (2009)

6. Rodrigues, J.A., Souza, J.M.d., Zimbrão, G., Xexéo, G., Neves, E., Pinheiro, W.A.: A P2P

15

Approach for Business Process Modelling and Reuse. In: Eder, J., Dustdar, S. (eds.) Business Process Management Workshops, vol. 4103, pp. 297-307. Springer Berlin / Heidelberg (2006)

7. Markovic, I., Pereira, A.C.: Towards a formal framework for reuse in business process modeling. Proceedings of the 2007 international conference on Business process management, pp. 484-495. Springer-Verlag, Brisbane, Australia (2008)

8. http://process.mit.edu/Default.asp (last accessed February 25, 2012)9. http://repository.phios.com/SCOR/ (last accessed February 25, 2012)10. http://help.sap.com/saphelp_sm40/helpdata/EN/5e/c8145e3a9d9340913099159d80fc87/

frameset.htm (last accessed February 25, 2012)11. http://publib.boulder.ibm.com/infocenter/wchelp/v5r6m1/index.jsp?topic=/

com.ibm.commerce.business_process.doc/concepts/processPrice_order.htm (last accessed Feb 25, 2012)

12. La Rosa, M., Reijers, H.A., van der Aalst, W.M.P., Dijkman, R.M., Mendling, J., Dumas, M., GarcÌa-BaÒuelos, L.: APROMORE: An advanced process model repository. Expert Systems with Applications 38, 7029-7040 (2011)

13. Shahzad, K., Elias, M., Johannesson, P.: Requirements for a Business Process Model Repository: A Stakeholders’ Perspective. In: Abramowicz, W., Tolksdorf, R. (eds.) Business Information Systems, vol. 47, pp. 158-170. Springer Berlin Heidelberg (2010)

14. Elias, M., Johannesson, P.: A Survey of Process Model Reuse Repositories. International Conference of Information Systems, Technology and Management, France. (2012).

15. Bernstein, P.A., Dayal, U.: An Overview of Repository Technology. Proceedings of the 20th International Conference on Very Large Data Bases, pp. 705-713. Morgan Kaufmann Publishers Inc. (1994)

16. Constantopoulos, P., Jarke, M., Mylopoulos, J., Vassiliou, Y.: The software information base: A server for reuse. The VLDB Journal 4, 1-43 (1995)

17. Mili, A., Mili, R., Mittermeir, R.T.: A survey of software reuse libraries. Annals of Software Engineering 5, 349-414 (1998)

18. Elias, M., Shahzad, K., Johannesson, P.: A Business Process Metadata Model for a Process Model Repository. In: Bider, I., Halpin, T., Krogstie, J., Nurcan, S., Proper, E., Schmidt, R., Ukor, R. (eds.) Enterprise, Business-Process and Information Systems Modeling, vol. 50, pp. 287-300. Springer Berlin Heidelberg (2010)

19. Decker, G., Overdick, H., Weske, M.: Oryx – An Open Modeling Platform for the BPM Community. In: Dumas, M., Reichert, M., Shan, M.-C. (eds.) Business Process Management, vol. 5240, pp. 382-385. Springer Berlin / Heidelberg (2008)

20. Peters, N.: Oryx Stencil Set Specification {(Bachelor's thesis)}. Potsdam, Germany (2007)21. http://bpt.hpi.uni-potsdam.de/Oryx/WebHome (last accessed February 25, 2012)22. Fang Liu, Jin Tong, Jian Mao, Robert Bohn, John Messina, Lee Badger, Leaf, D.: NIST

Cloud Computing Reference Architecture. In: Commerce, U.S.D.o. (ed.), pp. 35, Gaithersburg (2011)23. http://www.springsource.org/spring-framework (last accessed February 25, 2012)24. Krueger, C.W.: Software reuse. ACM Comput. Surv. 24, 131-183 (1992)25. Huang, A.H.: Effects of multimedia on document browsing and navigation: an exploratory

empirical investigation. Information & Management 41, 189-198 (2003)26. Fang, X., Holsapple, C.W.: An empirical study of web site navigation structures' impacts

on web site usability. Decis. Support Syst. 43, 476-491 (2007)27. http://www.activiti.org/components.html (last accessed February 25, 2012)28. http://www.hibernate.org/ (last accessed February 25, 2012)29. Bergholtz, M., Jayaweera, P., Johannesson, P., Wohed, P.: Process Models and Business

Models - A Unified Framework. Advanced Conceptual Modeling Techniques, vol. 2784, pp. 364-377. Springer Berlin / Heidelberg (2003)

30. Gordijn, J., Akkermans, H., van Vliet, H.: Business Modelling Is Not Process Modelling. In: Liddle, S., Mayr, H., Thalheim, B. (eds.) Conceptual Modeling for E-Business and the

16

Web, vol. 1921, pp. 40-51. Springer Berlin / Heidelberg (2000)

17