Inventing Less, Reusing More and Adding Intelligence to Business Process Modeling [original]

S.S. Bhowmick, J. Küng, and R. Wagner (Eds.): DEXA 2008, LNCS 5181, pp. 837–850, 2008.

Inventing Less, Reusing More, and Adding Intelligence

to Business Process Modeling

Lucinéia H. Thom1, Manfred Reichert1, Carolina M. Chiao2,

Cirano Iochpe2, and Guillermo N. Hess2

1 Institute of Databases and Information Systems,

Ulm D-89069 – Ulm, Germany

{lucineia.thom,manfred.reichert}@uni-ulm.de

2 Institute of Informatics, Federal University of Rio Grande do Sul,

Av. Bento Gonçalves, 9500, 91501-970 – Porto Alegre, RS, Brazil

{cchiao,ciochpe,hess}@inf.ufrgs.br

Abstract. Recently, a variety of workflow patterns has been proposed focusing

on specific aspects like control flow, data flow, and resource assignments.

Though these patterns are relevant for implementing Business Process Model-

ing (BPM) tools and for evaluating the expressiveness of BPM languages, they

do not contribute to reduce redundant specifications of recurrent business func-

tions when modeling business processes. Furthermore, contemporary BPM

tools do not support process designers in defining, querying, and reusing activ-

ity patterns as building blocks for process modeling. Related to these problems

this paper proposes a set of activity patterns, evidences their practical relevance,

and introduces a BPM tool for the modeling of business processes based on the

reuse of these activity patterns. Altogether our approach fosters reuse of busi-

ness function specifications and helps to improve the quality and comparability

of business process models.

Keywords: business function, activity pattern, business process modeling.

1 Introduction

Business processes help organizations to better align their business goals with the

needs of their customers; i.e., business processes constitute the glue between the stra-

tegic and the operational level of the organization [1]. To stay competitive in their

market, organizations and companies are increasingly interested in improving the

quality and the efficiency of their business processes as well as their interactions with

customers and business partners [2].

Process-aware information systems (PAISs) offer promising perspectives to realize

these goals, and a growing interest in aligning information systems (IS) in a process-

oriented way can be observed. To allow for more flexibility, PAISs introduce an addi-

tional layer when compared to traditional information systems, which provides an

explicit description of the process logic. In general, this logic is represented as a proc-

ess model which can be created using a business process modeling (BPM) tool.

838 L.H. Thom et al.

The introduction of PAISs and the adoption of BPM tools offer promising perspec-

tives: (a) companies obtain a precise and unambiguous description of their business

processes; (b) the definition of new business processes and new process models re-

spectively can be speed up significantly; (c) the work between different actors can be

coordinated more effectively; (d) real-time data about in-progress processes can be

gathered and visualized; and (e) business processes can be standardized. Through

Web Service technology, in addition, the benefits of BPM can be applied to cross-

organizational business processes as well [3], [4].

Business processes comprise different business functions with specific and well-

defined semantics, which can be considered as self-contained building blocks. Gener-

ally, a particular business function may occur several times within one or multiple

business process models [3]. As example consider the process for approving the con-

tents of a newsletter (cf. Fig 1). This simple business process includes three activities

with following order: (a) The author sends a request for approving the article to be

published to the editor of the current newsletter edition. (b) The editor reviews the

contents of the article; she either approves it or requests changes from the author. (c)

If the newsletter article is not sent to the editor after a certain period of time, the au-

thor will receive a respective notification. Obviously, this process comprises business

functions with generic semantics, which recur in numerous business processes: Task

Execution Request (a), Approval (b), and Notification (c). As we will discuss later

such recurrent business functions can be described in terms of activity patterns in

order to foster their reuse and to improve the quality and comparability of business

process models.

Author

a] Send newsletter

article to the editor

Editor

b] Review

the article

c] Increase activity priority

and notify delay in its execution

timeout

Changes request

Author

a] Send newsletter

article to the editor

Editor

b] Review

the article

c] Increase activity priority

and notify delay in its execution

timeout

Changes request

Fig. 1. Approval process for newsletter content

Recently a variety of workflow patterns has been proposed focusing on different

process aspects like control flow [5], resource assignments [6], data flow [7], excep-

tion handling [8], domain-specific ontologies [9], service interactions [10], process

change [11,30], and process compliance [12]. Though all these patterns are useful for

implementing BPM tools and for evaluating the expressiveness of BPM languages,

they do not contribute to avoid redundant specifications of recurrent business func-

tions when modeling business processes. Consequently, business process design be-

comes inefficient, complex and time-consuming when being confronted with a large

collection of business functions and business process models. To our best knowledge

there exists no comprehensive work evidencing the existence of activity patterns for

defining such recurrent business functions within business process models. Further-

more, no efforts have been spent on investigating the need, benefits and completeness

Inventing Less, Reusing More, and Adding Intelligence to Business Process Modeling 839

of activity patterns with respect to business process modeling. Finally, contemporary

BPM tools like Intalio, ARIS Toolset and WBI Modeler do not support process de-

signers in defining, querying and reusing activity patterns as building blocks for busi-

ness process modeling.

Related to these problems we proposed a set of seven workflow activity patterns

and corresponding design choices (i.e., pattern variants) in previous work [3], [13].

Each of these activity patterns captures a recurrent business function as we can find it

in numerous business processes like the one shown in Fig. 1. Combined with existing

control flow patterns (e.g., sequence, multi instance activity), these activity patterns

are suited to design a large variety of process models in different domains.

In this paper we briefly report on the results of an empirical study in which we

analyze the relative frequency of activity patterns in a collection of 214 real-world

process models from domains like quality management, software access control, and

electronic change management. For selected process categories, we further discuss

results of an additional analysis in which we investigate the frequency of co- occur-

ring activity patterns. The results of this second analysis are also utilized for develop-

ing a BPM tool, which shall foster the modeling of business processes based on the

reuse of activity patterns. Given some additional information about the kind of proc-

ess to be designed, the results of our analysis can be further used by this tool to sug-

gest a ranking of the activity patterns suited best to succeed the last pattern applied

during process modeling.

One of the basic pillars of this BPM tool constitutes an ontology to describe the ac-

tivity patterns. Particularly, this ontology allows to store and retrieve the patterns

(together with their properties and constraints) during process modeling. To obtain

machine-readable specifications, we suggest using a standard ontology language (e.g.,

OWL). Based on this, any BPM model based on the activity patterns can be easily and

automatically transformed to conventional process modeling notations (e.g., BPMN)

or languages (e.g., WS-BPEL, XPDL). Finally, using an ontology allows to make the

relationships between the different activity patterns more explicit, which provides

useful information for process designers.

The remainder of this paper is organized as follows: Section 2 gives an overview of

workflow activity patterns. Exemplarily, we discuss basic principles taking the Ap-

proval Pattern. Section 3 presents the results of our empirical study in which we in-

vestigate the occurrence and relevance of activity patterns in practice by analyzing

214 real-world process models. Section 4 sketches our process modeling tool and

discusses how the user interacts with it. In this context we also describe the ontology

representing the patterns in detail. Section 5 discusses related work and Section 6

concludes with a summary and outlook.

2 Workflow Activity Patterns

In this paper we use the term Workflow Activity Pattern (WAP or activity pattern for

short) to refer to the description of a recurrent business function as it frequently oc-

curs in business process models. Examples include notification, decision, and ap-

proval. Initially, we derived seven activity patterns based on an extensive literature

study [3], [13]. Table 1 gives an overview of these patterns. Generally, these activity

840 L.H. Thom et al.

patterns are close to the abstraction level or vocabulary used within an organization.

This, in turn, fosters their reuse when modeling business processes, and therefore

contributes to more standardized and better comparable business process models.

Each activity pattern is characterized by a short description, an example, a descrip-

tion of the problem context in which it can be applied, and relevant issues. Our

framework considers additional attributes as well like design choices (pattern vari-

ants), related patterns and pattern implementation. However, these attributes are

outside the scope of this paper and are omitted here. Fig. 2 gives a simple example of

the description for the APPROVAL activity pattern (here restricted to a particular pat-

tern variant, namely single approval; i.e., approval is required from exactly one role).

Table 1. Selected variants of activity patterns representing business functions

WAP - Name Description

WAP I:

Approval

An object (e.g., a business document) has to be approved by one or more organiza-

tional roles.

WAP II:

Question-Response

A question which emerges during process enactment has to be answered. This pattern

allows to formulate the question, to identify the organizational role(s) who shall

answer it, to send the question to the respective role(s), and to wait for the response(s)

(single-question-response).

WAP III:

Unidirectional Performative

A sender requests the execution of a particular task from another process participant.

The sender continues process execution immediately after having sent the request for

performing the activity.

WAP IV:

Bi-directional Performative

A sender requests the execution of a particular task from another process actor. The

sender waits until this actor notifies him that the requested task has been performed.

WAP V:

Notification

The status or result of an activity execution is communicated to one or more process

participants.

WAP VI:

Informative

An actor requests certain information from a process participant. He continues process

execution after having received the requested information.

WAP VII:

Decision

This pattern can be used to represent a decision activity in the flow with different

connectors to subsequent execution branches. Those branches will be selected for

execution whose transition conditions evaluate to true.

WAP1: APPROVAL (SIMPLIFIED VARIANT)

Description: An object (e.g., a business document) has to be approved. Depending on the given context the approval is

requested from one or multiple organizational roles. In the latter case, approval is done either sequentially or in parallel.

Example: In an electronic change management process, a particular change request has to be approved concurrently by

all roles concerned by the change. If one of these roles rejects the requested change, it will be not approved.

Problem: During the execution of a business process, object approval by one or multiple organizational roles is re-

quired before proceeding with the flow of control.

Issues:

a) The approval activity is executed only once by a particular organizational role.

b) Approval by multiple roles is needed for processes running in flat and decentralized organizations.

c) Final decision can be made manually (i.e., by a user) or automatically according to some rules.

Solution: The below process fragment illustrates the activity pattern for single approval using BPMN notation; here an

organizational role reviewer performs a document review either resulting in approval or disapproval.

Start End

Activity

Message

Flow

Sequence

Flow

Partition

XOR-Split

BPMN notation

Send request for

document review

Receive result

of the revision

Record approval in

the database

Notify result of

review

Perform document

review Send result of

the revision

Workflow

application

Reviewer

review request

Make final decision

approve

reprove

Start End

Activity

Message

Flow

Sequence

Flow

Partition

XOR-Split

BPMN notation

Start End

Activity

Message

Flow

Sequence

Flow

Partition

XOR-Split

BPMN notation

Send request for

document review

Receive result

of the revision

Record approval in

the database

Notify result of

review

Perform document

review Send result of

the revision

Workflow

application

Reviewer

review request

Make final decision

approve

reprove

Send request for

document review

Send request for

document review

Receive result

of the revision

Receive result

of the revision

Record approval in

the database

Record approval in

the database

Notify result of

review

Notify result of

review

Perform document

review

Perform document

review Send result of

the revision

Send result of

the revision

Workflow

application

Reviewer

review request

Make final decision

approve

reprove

Fig. 2. Approval pattern

Inventing Less, Reusing More, and Adding Intelligence to Business Process Modeling 841

3 Evidencing the Existence and Relevance of Activity Patterns in

Practice

To identify activity patterns in real workflow applications we analyzed 214 process

models. These process models have been modeled either with the Oracle Builder tool

or an UML modeler. Our analysis has been based on process models instead of event

logs, since we consider the semantics and the context of process activities as being

fundamental for identifying activity patterns. Altogether, the analyzed process models

stem from 13 different organizations – private as well as governmental ones – and are

related to different applications like Total Quality Management (TQM), software

access control, document management, help desk services, user feedback, document

approval, and electronic change management. In all organizations the respective proc-

ess models have been operationalized, i.e. they were supported by a PAIS. Table 2

summarizes information about involved organizations and analyzed process models.

Table 2. Characteristics of the analyzed process models

Size and Number of

Companies

Kind of Decision-

making

Examples of Analyzed Process Models Number of

Analyzed Models

1 x small Decentralized Management of Internal Activities 17

1 x large Decentralized TQM; Management of Activities 11

6 x large Centralized TQM; Control of Software Access;

Document Management

133

4 x large No information available Help Desk Services, User Feedback;

Document Approval

1 x large Centralized Electronic Change Management 24

3.1 Method Used to Analyze the Process Models

To our knowledge there exist no mining techniques to extract activity patterns from

real-world process models; i.e., contemporary process mining tools like ProM analyze

the event logs (e.g., execution or change logs) related to process execution and do not

extract information related to the semantics and the (internal) logic of process activi-

ties [14], [5], [15]. Therefore, we perform a manual analysis in order to identify rele-

vant activity patterns as well as their co-occurrences within the 214 process models.

For each workflow activity pattern WAP* we calculate its support value SWAP*,

which represents the relative frequency of the respective activity pattern within the set

of analyzed process models; i.e., SWAP*:= Freq(WAP*)/214 where Freq(WAP*) de-

notes the absolute frequency of WAP* within the collection of the analyzed 214 mod-

els; for each process model we count at most one occurrence of a particular pattern.

First, we manually identify and annotate activity patterns in all process models

analyzed. Following this, we determine the absolute frequency of each activity pattern

WAP* as described above. The obtained results are divided by the total number of

analyzed process models (i.e., 214 in our case).

3.2 Frequency of Activity Patterns in Real-World Process Models

Our analysis has shown that five out of the seven activity patterns (cf. Table 1) are not

dependent on a specific application domain or on a particular organizational structure

842 L.H. Thom et al.

(e.g., the degree of centralization in decision making or the standardization of work

abilities). More precisely, this applies to the following five patterns (cf. Table 1):

UNIDIRECTIONAL and BI-DIRECTIONAL PERFORMATIVE (WAP III+IV), DECISION

(WAP VII), NOTIFICATION (WAP V), and INFORMATIVE (WAP VI). We could identify

these five patterns with high frequency in almost all process models we had analyzed.

The latter also applies to the APPROVAL pattern, which can be explained by the high

degree of centralization regarding decision-making within the considered organiza-

tions (cf. Table 2). This high centralization implies the use of approval activities [16].

By contrast, most of the analyzed process models do not contain QUESTION-

RESPONSE activities. Figure 3 graphically illustrates the relative frequency of each

activity pattern with respect to the set of analyzed process models.

Fig. 3. Frequency of activity patterns in real process models

3.3 Identifying Co-occurrences of Activity Patterns

One of the use cases for the ontology of our BPM tool (cf. Section 4) is based on a

mechanism that gives design time recommendations with respect to the activity pat-

terns best suited to be combined with the last used pattern. This mechanism utilizes

statistical data we gathered during our empirical study. We summarize these statistical

findings in this section. To obtain the frequencies for pattern co-occurrences, we ana-

lyze the sequences of activity patterns in 1541 out of 214 studied process models.

Before performing the analysis we classified the business process models into

human–oriented models (i.e., processes with human interventions during their execu-

tion) and fully automated models (i.e., processes without any human intervention).

We verified that certain activity patterns can be find more often in one of the two

categories [17]. This analysis has been inspired by a classification provided by Le

Chair who distinguishes between system-intensive and human-intensive business

processes [18]. System-intensive processes are characterized by being handled on a

straight-through basis, i.e., there is minimal or no human intervention during process

execution and only few exceptions occur. Human-intensive processes (similar to

methods engineering [19]), in turn, require people to get work done by relying on

1 When performing this analysis we had access to only 154 out of the 214 studied process

models.

Inventing Less, Reusing More, and Adding Intelligence to Business Process Modeling 843

business applications, databases, documents, and other people as well as extensive

interactions with them. This type of process requires human intuition or judgment for

decision-making during individual process steps.

When classifying a subset of the studied process models, for which respective in-

formation is available, into these two categories, we obtain 123 human-intensive and

31 system-intensive process models respectively. Note that in this earlier analysis we

consider only 154 of the 214 process models studied in total. In a next step we evi-

dence the occurrence of the seven activity patterns with respect to the two categories

of process models. Figure 4 shows the support value (i.e., the relative frequency) of

the activity patterns in both the system-intensive and the human-intensive process

models. As can be seen, some of the patterns (i.e., APPROVAL (WAP I), INFORMATIVE

(WAP VI), and QUESTION-RESPONSE (WAP II)) do not appear in system-intensive

process models at all. Obviously, these patterns are usually related to human activi-

ties; i.e. they are executed by an organizational role.

75%

73%

63%

71%

27%

73%

0% 0%

68% 68% 65%

87%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

WAPI WAPII WAPIII WAPIV WAPV WAPVI WAPVII

Human-Intensive System-Intensive

Fig. 4. Frequency of activity patterns in human- and system-intensive process models

In another analysis we have identified frequent and recurrent co-occurrences of ac-

tivity patterns within process models. Relying on the results of this analysis, our

knowledge base and BPM tool respectively display to the process designer a ranking

of the activity patterns which most frequently follow the pattern the user applied be-

fore during process design. For example, our analysis has shown that the pattern pair

DECISION Æ NOTIFICATION occurs more often in system-intensiv than in human-

intensive business processes (cf. Fig. 5). Opposed to this, pattern pair DECISION Æ

APPROVAL occurs more frequently in human-intensive process models.

31%

16% 12%

21%

15%

0% 0% 5%

15%

50%

30%

10%

20%

30%

40%

50%

60%

WAPI WAPII WAPIII WAPIV WAPV WAPVI WAPVII

Human-Intensive System-Intensive

Fig. 5. How often does an activity pattern directly follow the DECISION pattern (regarding both

system- and human-intensive processes)?

844 L.H. Thom et al.

4 Towards a Pattern-Based Process Modeling Tool

This section presents basic concepts of our BPM tool, which allows to design process

models based on the reuse of activity patterns. The latter are described by means of an

ontology. In principle, basic concepts behind this BPM tool can be added as extension

to existing BPM components as well (e.g., Intalio [20], Aris Toolset [21], or ADEPT

Process Composer [22]).

Core functionalities of our BPM tool are as follows:

Assisting users in designing process models. First, the process designer selects the

kind of business process (e.g., human intensive) to be modeled, which is then matched

to a set of business functions as maintained in the ontology; i.e., the BPM tool adapts

a set of business functions to be used for process modeling in the given context. Fol-

lowing this, the process designer chooses a business function and provides contextual

data (e.g., about the organization). This information is then matched to an activity

pattern as maintained in the aforementioned ontology. Furthermore, the BPM tool

recommends to use the respective activity pattern and to apply corresponding design

choices; i.e., to configure a concrete pattern variant. Afterwards, the tool recom-

mends the most suitable activity patterns to be used together with the activity pattern

applied before. In addition, it informs the user about how frequently each pair of ac-

tivity pattern (i.e., the previously applied activity pattern plus the recommended activ-

ity pattern) was used in earlier modeling. This module is developed based on the

analysis results presented in Section 3.3.

Construction of an ontology for activity patterns. The ontology for activity pat-

terns does not only maintain the patterns themselves, but also the frequency with

which each pattern has co-occurred with a previously used pattern. Through the

analyses of additional process models (e.g., from the automotive as well as the health-

care domain) we aim at increasing the support value of such pairs of activity patterns

(cf. Section 3.3). Thus, at design time the pattern pairs being recommended will help

to design a process model which is closer to the business process being manually

executed in the organization.

4.1 Architecture of the Process Modeling Tool

Core components of our BPM Tool are as follows (cf. Fig. 6):

• Query Component: It provides a query mechanism for matching the activity

patterns maintained by the ontology with the given kind of business process

(e.g., human intensive), business function (e.g., approval), organizational con-

text (e.g., level of centralization in decision-making), and corresponding de-

sign choice as chosen by the user (if not set automatically).

• Ontology Manager: It comprises an ontology and a query mechanism (Busi-

ness Function Query + WAP Query). The ontology describes the activity pat-

terns (cf. Fig. 6) and their properties (e.g., attributes and relationships with

other patterns). Our query as well as update mechanisms give design time rec-

ommendations with respect to the most suited activity patterns to be combined

with an already used one. An example of a query would be the selection of the

Inventing Less, Reusing More, and Adding Intelligence to Business Process Modeling 845

business functions which occur more frequently in system-intensive process

models. In addition, our update mechanism has to be used to adapt relative

frequency of each pattern pair (e.g., based on the analysis of new process

models) as identified in our process model analysis.

• Scheme Translation: This component is responsible for translating a process

model (based on translation algorithms) which uses activity patterns as build-

ing blocks (stored in XML code) to either a conventional notation (e.g.,

BPMN) or an existing process execution language (e.g., BPEL, XPDL). The

use of this translation component is optional, i.e., it will be only applicable if

the user wants the respective process model being translated to another nota-

tion and process execution language respectively.

Kind of

Process

WAP

Ontology

Query Component

Org.

Repository

KP BF list

Business

Function

BF Query

BF list

Org.

aspects

WAP BF,

Org. aspects

Ontology Manager

WAP

configuration

OWL

(XML) Schema

Specification

BPEL/BPMN/XPDL

Translation

Algorithms

Scheme Translation

Legend

WAP Workflow Activity Patterns

BF Business Function

KP Kind of Process

OWL Web Ontology Language

WAP Query

WAP

Update

Kind of

Process

Kind of

Process

WAP

Ontology

Query Component

Org.

Repository

KP BF list

Business

Function

Business

Function

BF Query

BF list

Org.

aspects

WAP BF,

Org. aspects

Ontology Manager

WAP

configuration

WAP

configuration

OWL

(XML) Schema

Specification

BPEL/BPMN/XPDL

Translation

Algorithms

Scheme Translation

Legend

WAP Workflow Activity Patterns

BF Business Function

KP Kind of Process

OWL Web Ontology Language

WAP QueryWAP Query

WAP

Update

WAP

Update

Fig. 6. Architecture of the ProWAP process modeling tool

4.2 Interacting with the Process Modeling Tool

We sketch basic steps of our pattern-based modeling approach: First, the user speci-

fies the kind of process to be designed (e.g., system- vs. human-intensive) (cf. Step 1

in Fig. 7). Taking this information, in Step 2 the BPM tool presents a set of business

functions relevant in the given context (cf. Section 3.2). In Step 3, the user selects a

business function (e.g., approval) and additionally specifies information about the

organizational context within which this function is executed (e.g., organizational unit

with centralized decision-making).

Based on this information and on the defined ontology, the best suited activity

pattern (incl. corresponding design choices) is queried (cf. Step 4 in Fig. 7). More

precisely, the query results in an instance of an activity pattern and a set of related

attributes (e.g., kind of approval, list of reviewers in case of concurrent or iterative

approvals, application-specific details about the approval like approval conditions,

etc.). In Step 5, the user then customizes the activity pattern to the given context (e.g.,

kind of approval (iterative approval by a hierarchy of organizational roles); list of re-

viewers (#id): 101, 106, 200; Approval activity description: paper review; conditions to

approve: at least 2 strong acceptances). In Step 6, the BPM tool creates an instance of

the corresponding pattern according to this customization. Afterwards, the BPM tool

recommends a list of activity patterns (with corresponding statistics regarding the use

846 L.H. Thom et al.

Start

Customize WAP

Create an instance

of the corresponding

pattern according

to user’s customization

Sugest subsequent

WAP

End

Yes

Inform

kind of process

Choose BF

Kind of process

∈{system-intensive,

human-intensive}

E.g.: Business Function

∈{notification,

task request with answer,

task request without answer,

decision-make,

information request,

approval,

question-response }

Inform

org. aspects

E.g.: Org. Aspect

∈{centralization on

decision-make,

function, skill }

Query corresponding

pattern and respective

design choice(s)

Yes

Query the

corresponding

Legend

WAP Workflow Activity Patterns

BF Business Function

KP Kind of Process

4 5 6

suggested

WAP?

Design

another

WAP?

Start

Customize WAP

Create an instance

of the corresponding

pattern according

to user’s customization

Sugest subsequent

WAP

End

Yes

Inform

kind of process

Choose BF

Kind of process

∈{system-intensive,

human-intensive}

Kind of process

∈{system-intensive,

human-intensive}

E.g.: Business Function

∈{notification,

task request with answer,

task request without answer,

decision-make,

information request,

approval,

question-response }

Inform

org. aspects

E.g.: Org. Aspect

∈{centralization on

decision-make,

function, skill }

E.g.: Org. Aspect

∈{centralization on

decision-make,

function, skill }

Query corresponding

pattern and respective

design choice(s)

Yes

Query the

corresponding

Legend

WAP Workflow Activity Patterns

BF Business Function

KP Kind of Process

44 55 66

suggested

WAP?

suggested

WAP?

suggested

WAP?

Design

another

WAP?

Design

another

WAP?

Design

another

WAP?

Fig. 7. Procedure showing how the user interacts with the BPM tool

of these patterns in other process models) to follow the previously modeled activity

(cf. Step 7 in Fig. 7). For example, APPROVAL is followed by NOTIFICATION in 24% of

the 154 process models we analyzed. The user must then state whether another activ-

ity pattern shall be designed and whether the pattern suggested by the BPM tool shall

be used (cf. Steps 8 and 9).

4.3 Ontology of Workflow Activity Patterns

We now introduce our ontology for workflow activity patterns (cf. Fig.8). Particu-

larly, this ontology has been used when implementing the recommendation mecha-

nism of our BPM Tool. The ontology represents the structure of the activity patterns,

related design choices (e.g., single and iterative approval), and their relationships.

Altogether, the main goal of this ontology is to better define the structure of activity

patterns, their attributes, and their relationships. In addition, the ontology maintains

the use statistics for each activity pattern (in the context of process modeling) as well

as the co-occurrences of pattern pairs based on the empirical study reported in Section

3.3. Our ontology also integrates information about the organizational context in

which the activity patterns are usually applied. Such information is matched with the

business function to identify the most suitable activity patterns to be used together

with the activity pattern designed before.

Approval Question-

Response

Organization

al Structure Single-

Question-

Response

Multi-

Question-

Response

Task Request with

Answer

Informative Decision

Multi-

Decision

Single-

Decision

Workflow

Activity Pattern

Single-

Request-

Response

Multi-

Request-

Response

Bi-directional

Performative

Task Request

without Answer

part-ofpart-of

Notification Unidirectional

Performative

Single-

Notification

Multi-

Notification

Single-

Request

Multi-

Request

Single-

Informative Multi-

Informative

is-a

Single

Approval

Iterative

Approval Concurrent

Approval

is-a

is-a is-a

isInherent to

is-a

part-of

ApprovalApproval Question-

Response

Question-

Response

Organization

al Structure

Organization

al Structure Single-

Question-

Response

Single-

Question-

Response

Multi-

Question-

Response

Multi-

Question-

Response

Task Request with

Answer

Task Request with

Answer

InformativeInformative DecisionDecision

Multi-

Decision

Multi-

Decision

Single-

Decision

Single-

Decision

Workflow

Activity Pattern

Single-

Request-

Response

Single-

Request-

Response

Multi-

Request-

Response

Multi-

Request-

Response

Bi-directional

Performative

Bi-directional

Performative

Task Request

without Answer

Task Request

without Answer

part-ofpart-of

NotificationNotification Unidirectional

Performative

Unidirectional

Performative

Single-

Notification

Single-

Notification

Multi-

Notification

Multi-

Notification

Single-

Request

Single-

Request

Multi-

Request

Multi-

Request

Single-

Informative

Single-

Informative Multi-

Informative

Multi-

Informative

is-a

Single

Approval

Single

Approval

Iterative

Approval

Iterative

Approval Concurrent

Approval

Concurrent

Approval

is-a

is-a is-a

isInherent to

is-a

part-of

Fig. 8. Ontology of Workflow Activity Patterns (simplified and partial views)

Inventing Less, Reusing More, and Adding Intelligence to Business Process Modeling 847

The diagram depicted in Fig. 8 represents the Workflow Activity Patterns ontology

(partial view). It describes the taxonomy of the activity patterns, i.e. a conceptual

hierarchical structure that relates classes and sub-classes to each other. The most gen-

eral class is WORKFLOW ACTIVITY PATTERN. This concept has two main components:

TASK REQUEST WITH ANSWER and TASK REQUEST WITHOUT ANSWER. The first

component is composed by the following concepts, which represent the Workflow

Activity Patterns: APPROVAL, QUESTION-RESPONSE, INFORMATIVE, DECISION and BI-

DIRECTIONAL PERFORMATIVE. The TASK REQUEST WITHOUT ANSWER concept is

composed by the two patterns NOTIFICATION and UNIDIRECTIONAL PERFORMATIVE.

The APPROVAL and QUESTION-RESPOND patterns are related to organizational

structure aspects. In the context of an APPROVAL pattern, an object approval is always

performed by specific roles inside an organization. The QUESTION-RESPONSE pattern

is applied when an actor might have a question in order to work on the process or on a

particular process activity. The question is forwarded to a specific organizational role

that has the appropriate expertise to answer it.

As aforementioned each workflow activity pattern has specific design choices. For

example, the design choices of task execution pattern allow expressing at design time

if the task execution is requested from a single actor or from multiple actors. In Fig. 8

such variants are represented as subclasses of the pattern concepts, i.e. as specializa-

tions. The Approval concept, for example, has three specializations: Single Approval,

Iterative Approval and Concurrent Approval. They represent the Approval pattern

design choices. Single Approval is associated with exactly one reviewer. Iterative

Approval is handled by a loop based on a list of reviewers. This list can be often re-

lated to vertical organizations where there is a hierarchical organizational structure.

Regarding Concurrent Approval, the approval request is sent to the whole group of

reviewers simultaneously. The final decision is then made after all reviewers have

performed their evaluation.

Our ontology (complete view) also considers system- and human-intensive proc-

esses. In addition, we have defined attributes for each class and sub-class of our on-

tology; e.g., way of notification (e.g., by e-mail or as work item in the participants’

worklists), organizational role, and activity status.

5 Related Work

Recently, numerous approaches on workflow patterns have been proposed to support

both the conceptual and the implementation level of business processes. One of the

first contributions in this respect was a set of process patterns to be used in the context

of software processes within an organization [23].

Russell proposes 43 workflow patterns for describing process behavior [24], [5].

Each pattern represents a routing element (e.g., sequential, parallel and conditional

routing) which can be used in process definitions. In the meantime these workflow

patterns have been additionally used for evaluating process specification languages

and process modeling tools [25], [26].

A set of data patterns is proposed by [7]. These patterns are based on data charac-

teristics that occur repeatedly in different workflow modeling paradigms. Examples

are data visibility and data interaction. In another work, Russell presents a set of

848 L.H. Thom et al.

resource patterns of which each one describes a way through which resources can be

represented and utilized in process models [6]. A resource is considered as an entity

capable of doing work. It can be either human (e.g., a worker) or non-human (e.g.,

equipment). Examples of resource patterns include Direct Allocation and Role-Based

Allocation. Finally, process change patterns and change support features have

emerged to effectively deal with (dynamic) process changes [11], [30].

Recently, Russell has presented a pattern-based classification framework for char-

acterizing exception handling in workflow management systems [8]. This framework

has been used to examine the capabilities of workflow management and BPM systems

and to evaluate process specification as well as process execution languages. As a

result, the authors emphasis the limited support for exception handling in existing

workflow management systems.

Barros proposes a set of service interaction patterns, which allow for service in-

teractions, pertaining to choreography and orchestration, to be benchmarked against

abstracted forms of representative scenarios [10]. As example consider the Send pat-

tern and the Send/Receive pattern. Altogether Russell and Barros provide a thorough

examination of the various perspectives that need to be supported by a workflow

language and BPM tool respectively. However, none of these approaches investigate

which are the most frequent patterns recurrently used during process modeling and in

which way the introduction of such activity patterns eases process modeling.

SAP has developed a cross-application engine called SAP Business Workflow

[27]. This tool enables the process-oriented integration of business objects and appli-

cations including a workflow wizard with workflow templates and process reference

models. Related to that is the Supply-Chain Operations Reference-model (SCOR)

which is based on best practices as well [28].

Finally, PICTURE proposes a set of 37 domain-specific process building blocks.

More precisely, these building blocks are used by end users in public administrations

to capture and model the process landscape. The building blocks have been evaluated

in practice [29].

6 Summary and Outlook

In this paper, we identified seven workflow activity patterns necessary and in many

cases also sufficient to model a large variety of process models. Moreover we dis-

cussed results of an empirical study where we had analyzed how often activity pat-

terns as well as co-occurrences of them (i.e. pairs of activity patterns) are present in a

large collection of real process models.

We additionally proposed an approach for process modeling based on workflow

activity patterns. Basic to this tool is the reuse of the presented activity patterns. Re-

spective functionality can be added as extension to existing process modeling compo-

nents as well. Our goal is to increase the reuse of recurrent business functions and to

better assist users in the design of high-quality process models; i.e., by providing

context-specific recommendations on which patterns to use for process modeling

next. It is important to mention that our patterns can be used together with other pat-

terns related to control flow [5] or process change [11], [30]. In this paper we have

given first insights into the architecture of our BPM tool as it is implemented in the

ProWAP project.

Inventing Less, Reusing More, and Adding Intelligence to Business Process Modeling 849

The main advantages of our approach can be summarized as follows: (a) the com-

pleteness and necessity of the activity patterns for process design have been empiri-

cally evidenced; (b) a small set of parameterizable activity patterns is sufficient to

model a large variety of processes, which reduces the complexity with respect to

pattern usage; (c) the concepts realized in our process modeler are tool-independent

and can be adapted for any process modeling tool; and (d) the sketched recommenda-

tion mechanisms can be useful to reduce complexity in process design as well as to

improve semantical model correctness.

In future work, we intend to identify variants of each pattern concerning specific

application domains. For example, we want to figure out what kind of approvals occur

most frequently in the healthcare and in the automotive domain. Furthermore, we will

perform additional analyses considering process models from different application

domains (e.g., health insurance and automotive engineering). Our goal is to identify

more common occurrences of pairs of activity patterns. We also aim at extending the

tool with a mechanism to learn from designer actions. Last but not least, we intend to

investigate how to transform process models defined with our tool (and being based

on the activity patterns) into conventional notations and languages respectively.

Acknowledgements

The authors would like to acknowledge the Coordination for the Improvement of

Graduated students (CAPES), the Institute of Databases and Information Systems of

the University of Ulm (Germany), and the Informatics Institute of Federal University

of Rio Grande do Sul (Brazil).

References

1. Rummler, G., Brache, A.: Improving Performance: How to Manage the White Space on

Organizational Chart. Jossey-Bass, San Francisco (1990)

2. Lenz, R., Reichert, M.: IT Support for Healthcare Processes – Premises, Challenges, Per-

spectives. Data and Knowledge Engineering 61, 39–58 (2007)

3. Thom, L., Iochpe, C., Amaral, V., Viero, D.: Toward Block Activity Patterns for Reuse in

Workflow Design. In: Workflow Handbook 2006, pp. 249–260 (2006)

4. Mutschler, B., Reichert, M., Bumiller, J.: Unleashing the Effectiveness of Process-oriented

Information Systems: Problem Analysis, Critical Success Factors and Implications. IEEE

Transactions on Systems, Man, and Cybernetics (Part C) 38(3), 280–291 (2008)

5. van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszewski, B., Barros, A.: Workflow

Patterns. Distributed and Parallel Databases 14(3), 5–51 (2003)

6. Russel, N., Aalst, W., Hofstede, A., Edmond, D.: Workflow Resource Patterns: Identifica-

tion, Representation and Tool Support. In: Pastor, Ó., Falcão e Cunha, J. (eds.) CAiSE

2005. LNCS, vol. 3520, pp. 216–232. Springer, Heidelberg (2005)

7. Russel, N., Hofstede, A., Edmond, D.: Workflow Data Patterns. In: Delcambre, L.M.L.,

Kop, C., Mayr, H.C., Mylopoulos, J., Pastor, Ó. (eds.) ER 2005. LNCS, vol. 3716, pp.

353–368. Springer, Heidelberg (2005)

8. Russel, N., Aalst, W., Hofstede, A.: Workflow Exception Patterns. In: Dubois, E., Pohl, K.

(eds.) CAiSE 2006. LNCS, vol. 4001, pp. 288–302. Springer, Heidelberg (2006)

9. Ohnmacht, A.: Development of a Collaborative Process Modeling Methodology for Do-

main Experts. Master Thesis, University of Ulm (2007)

850 L.H. Thom et al.

10. Barros, A., Dumas, M., ter Hofstede, A.: Service Interaction Patterns. In: van der Aalst,

W.M.P., Benatallah, B., Casati, F., Curbera, F. (eds.) BPM 2005. LNCS, vol. 3649, pp.

302–318. Springer, Heidelberg (2005)

11. Weber, B., Rinderle, S., Reichert, M.: Change Patterns and Change Support Features in

Process-Aware Information Systems. In: Krogstie, J., Opdahl, A., Sindre, G. (eds.) CAiSE

2007. LNCS, vol. 4495, pp. 574–588. Springer, Heidelberg (2007)

12. Namiri, K., Stoganovic, N.: Pattern-Based Design and Validation of Business Process

Compliance. In: Proc. CoopIS 2007, pp. 59–76 (2007)

13. Thom, L.: Applying Block Activity Patterns in Workflow Modeling. In: Proc. 8th Int’l

Conf. on Enterprise Information Systems (ICEIS 2006), Paphos, Cyprus, pp. 457–460

(2006)

14. Ellis, C.: Workflow Mining: Definitions, Techniques, Future Directions. In: Fischer, L.

(ed.) Workflow Handbook 2006. Lighthouse Point: Future Strategies, pp. 213–228 (2006)

15. Günther, C.W., Rinderle-Ma, S., Reichert, M., van der Aalst, W.M.P., Recker, J.: Using

Process Mining to Learn from Process Changes in Evolutionary Systems. Int’l Journal of

Business Process Integration and Management (2008)

16. Davis, M.R., Weckler, D.A.: A Practical Guide to Organization Design. Crisp Publica-

tions, Boston (1996)

17. Chiao, C., Thom, L.H., Iochpe, C., Reichert, M.: Verifying Existence, Completeness and

Sequences of Workflow Activity Patterns in Real Process Models. In: IV Brazilian Sym-

posium of Information Systems (SBSI), Rio de Janeiro, Brazil (2008)

18. Le Clair, C., Teubner, C.: The Forrester Wave: Business Process Management for Docu-

ment Processes, Q3 (2007)

19. Wiley, J.: Methods Engineering, United States of America (1962)

20. Intalio. Creating Process Flows (2006), http://bpms.intalio.com

21. IDS Scheer: Aris Platform: Product Brochure (2007), http://www.ids-

scheer.com/set/82/PR_09-07_en.pdf

22. Reichert, M., Rinderle, S., Kreher, U., Dadam, P.: Adaptive Process Management with

ADEPT2. In: Proc. Int’l Conf. on Data Engineering (ICDE 2005), Tokyo, Japan, pp.

1113–1114. IEEE Computer Society Press, Los Alamitos (2005)

23. Ambler, S.W.: An Introduction to Process Patterns (1998)

24. Russell, N., Hofstede, A.H.M., ter Aalst, W.M.P., van der Mulyar, N.: Workflow Control

Flow Patterns: A Revised View. BPM Center Report BPM-06-22, BPM center.org (2006)

25. van der Aalst, W.M.P.: Patterns and XPDL: A Critical Evaluation of the XML Process

Definition Language. QUT Technical report, FIT-TR-2003-06, Queensland University of

Technology, Brisbane (2003)

26. Wohed, P., Aalst, W.M.P., van der Dumas, M., ter Hofstede, A.H.M., Russell, N.: Pattern-

based Analysis of BPMN - An extensive evaluation of the Control-flow, the Data and the

Resource Perspectives. BPM Center Report BPM-06-17, BPMcenter.org (2006)

27. SAP. SAP Business Workflow (2008), http://www.sap.com

28. SCOR. Supply-Chain Operations Reference-model (2008)

29. Becker, J., Pfeiffer, D., Räckers, M.: Domain Specific Process Modelling in Public Ad-

ministrations – The PICTURE-Approach. In: Wimmer, M.A., Scholl, J., Grönlund, Å.

(eds.) EGOV. LNCS, vol. 4656, pp. 68–79. Springer, Heidelberg (2007)

30. Weber, B., Reichert, M., Rinderle-Ma, S.: Change Patterns and Change Support Features -

Enhancing Flexibility in Process-Aware Information Systems. Data and Knowledge Engi-

neering (accepted for publication, 2008)