This article was downloaded by: [Anadolu University]

On: 28 December 2014, At: 08:52

Publisher: Taylor & Francis
Informa Ltd Registered in England and Wales Registered Number: 1072954 Registered
office: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK

Enterprise Information Systems

Publication details, including instructions for authors and
subscription information:
http://www.tandfonline.com/loi/teis20

Business process architectures:

overview, comparison and framework
a a a
Remco Dijkman , Irene Vanderfeesten & Hajo A. Reijers
a
Eindhoven University of Technology, Eindhoven, Netherlands
Published online: 26 Jun 2014.

Click for updates

To cite this article: Remco Dijkman, Irene Vanderfeesten & Hajo A. Reijers (2014): Business
process architectures: overview, comparison and framework, Enterprise Information Systems, DOI:
10.1080/17517575.2014.928951

To link to this article: http://dx.doi.org/10.1080/17517575.2014.928951

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the
“Content”) contained in the publications on our platform. However, Taylor & Francis,
our agents, and our licensors make no representations or warranties whatsoever as to
the accuracy, completeness, or suitability for any purpose of the Content. Any opinions
and views expressed in this publication are the opinions and views of the authors,
and are not the views of or endorsed by Taylor & Francis. The accuracy of the Content
should not be relied upon and should be independently verified with primary sources
of information. Taylor and Francis shall not be liable for any losses, actions, claims,
proceedings, demands, costs, expenses, damages, and other liabilities whatsoever or
howsoever caused arising directly or indirectly in connection with, in relation to or arising
out of the use of the Content.

This article may be used for research, teaching, and private study purposes. Any
substantial or systematic reproduction, redistribution, reselling, loan, sub-licensing,
systematic supply, or distribution in any form to anyone is expressly forbidden. Terms &
 Conditions of access and use can be found at http://www.tandfonline.com/page/terms-
and-conditions
Downloaded by [Anadolu University] at 08:52 28 December 2014
 Enterprise Information Systems, 2014
http://dx.doi.org/10.1080/17517575.2014.928951

Business process architectures: overview, comparison and framework

Remco Dijkman*, Irene Vanderfeesten and Hajo A. Reijers

Eindhoven University of Technology, Eindhoven, Netherlands

(Received 15 August 2013; accepted 25 May 2014)

With the uptake of business process modelling in practice, the demand grows for
guidelines that lead to consistent and integrated collections of process models. The
Downloaded by [Anadolu University] at 08:52 28 December 2014

notion of a business process architecture has been explicitly proposed to address this.
This paper provides an overview of the prevailing approaches to design a business
process architecture. Furthermore, it includes evaluations of the usability and use of the
identified approaches. Finally, it presents a framework for business process architecture
design that can be used to develop a concrete architecture. The use and usability were
evaluated in two ways. First, a survey was conducted among 39 practitioners, in which
the opinion of the practitioners on the use and usefulness of the approaches was
evaluated. Second, four case studies were conducted, in which process architectures
from practice were analysed to determine the approaches or elements of approaches
that were used in their design. Both evaluations showed that practitioners have a
preference for using approaches that are based on reference models and approaches
that are based on the identification of business functions or business objects. At the
same time, the evaluations showed that practitioners use these approaches in combina-
tion, rather than selecting a single approach.
Keywords: business process; business process architecture; business process model;
enterprise model; case study

1. Introduction
Despite relentless advances in IT (Chui et al. 2013), organisations struggle to create value
and improve their business processes. Process models turn out to be a helpful tool to
improve the understanding of current business operations and are often used as a
foundation for improvement initiatives (Indulska et al. 2009). Yet, any organisation that
engages in modelling its business processes inevitably encounters questions. Which
processes exist in my organisation? Where does one process end and the other begin?
At what level of detail should these processes be modelled? These questions are especially
relevant when an organisation's interest in its processes results in a collection of hundreds
of process models. Consider, for example, the SAP Reference Model (Curran and Keller
1999), which consists of 604 process models, the reference model for Dutch municipa-
lities (Sdu Information Solutions 2013), which consists of over 400 process models, and
the IBM Insurance Application Architecture process models (Huschens and Rumpold-
Preining 2006), which currently consists of over 250 models. Several authors have
proposed the notion of a business process architecture to address questions like the
ones we mentioned, including Green and Ould (2004, 2005), Joosten (2000), Koliadis,
Ghose, and Padmanabhuni (2008) and Scheer and Nüttgens (2000). Such an organised
overview of the processes that exist within an organisational context, along with the

*Corresponding author. Email: [email protected]

© 2014 Taylor & Francis

 2 R. Dijkman et al.

guidelines on how the related models should be organised, is what can help individual
modellers arrive at a consistent and integrated collection of process models. However, the
introduction of a business process architecture clearly begs the question of how in any
given situation it should be established.
Given the variety of views on how to design a business process architecture, we
identify a lack of understanding of the differences between these views and uncertainty
among business users to make the right choices. Yet, it has been recognised that not any
business process architecture is equally effective. In a recent blog post, for example,
Derek Miers notes how some process architectures may actually impede on the process-
centred line of thinking that was behind the initiative to model process in the first place.1
This paper aims to fill the identified gap by investigating which approaches and
guidelines to create a business process architecture exist, which of these are considered
most useful in practice and how they are actually applied in practice. In pursuing this aim,
Downloaded by [Anadolu University] at 08:52 28 December 2014

we focus on the conceptual, modelling-related, challenges involved in organising a

business process architecture, rather than the organisational or socio-political issues that
play a role in the effective use of process models. More precisely, the paper offers the
following contributions:

(1) An overview of the design approaches and guidelines that can be used to design a
business process architecture.
(2) An exploratory comparison of the use and usefulness of these design approaches
and guidelines in practice.
(3) A framework that is aggregated from existing approaches and that can be used as
a basis for structuring a process architecture.

To arrive at these contributions, first, a structured review of the existing literature has
been conducted. This review led to an overview of the design approaches, as well as an
overview of the guidelines and structuring principles that these approaches propose to
create a process architecture. Next, the use and usefulness of the different design
approaches in practice has been explored through a survey that was conducted in a
workshop session with 39 practitioners. This collection of opinions illustrated that practi-
tioners rely on a hybrid combination of approaches, rather than a single approach. This
result led us to investigate the particular combinations of approaches, guidelines and
structuring principles that are mostly used in practice, by investigating process architec-
tures from practice in four case studies. Based on an analysis of the results from the
evaluation, an overview of the most commonly used structuring principles is presented in
the form of a framework. This framework can be used as a basis for structuring a new
process architecture. Although the guidelines and the developed framework remain to be
proven in practice, we argue that they are more than subjective statements because they
are derived from literature and two more in-depth studies.
The remainder of this paper is structured as follows. Section 2 presents a precise
description of what a business process architecture is. Section 3 presents and compares
the approaches to designing a business process architecture, as identified in the litera-
ture. Section 4 presents a survey-based evaluation of the use and usefulness of these
approaches and the guidelines and structuring principles that they propose. Section 5
presents a case study-based evaluation of how approaches and their related principles
are used to design process architectures in practice. Section 6 analyses the results of the
empirical evaluations and proposes a framework for structuring process architecture,
 Enterprise Information Systems 3

based on this evaluation. Finally, Section 7 presents related work and Section 8
concludes this paper.

2. Business process architecture

We define a business process architecture as an organised overview of business processes
that specifies their relations, which can be accompanied with guidelines that determine
how these processes must be organised.
A business process architecture can serve as a tool to design a structure for the processes
that exist in an organisation, before those processes are designed in detail. In this way, it can
be used to help determine which processes exist and where one process ends and the next
process starts. For that reason, it is typically designed before the processes themselves;
Downloaded by [Anadolu University] at 08:52 28 December 2014

however, if it is kept up-to-date with changes to the individual processes, it can also be used
as an overview of all the processes that exist in an organisation.
Purely for illustrative purposes, Figure 1 shows an example of a business process
architecture in the ArchiMate notation (Lankhorst 2005). The figure shows a collection of
business processes, represented by the rounded rectangles with the arrow icon, as well as
the various relations that exist between these business processes.
There is no consensus about all the potential relations that exist between business
processes. However, as Section 3 will show, the following types of relations are frequently
used throughout the literature. The decomposition relation expresses that a process is
decomposed into multiple sub-processes. In Figure 1 this relation is represented by the
graphical containment of sub-processes within the parent process. The specialisation
relation expresses that one process is a specialised version of another. In Figure 1, this
relation is represented by an arrow with an open arrowhead. The trigger relation
expresses that the execution of one process can trigger the execution of another. In
Figure 1, this relation is represented by an arrow with a filled arrowhead. The use relation
expresses that one process provides services that are used by another. In Figure 1, this
relation is represented by a regular arrow.
A business process architecture can be enriched by ‘containers’, such as layers or
columns, along with guidelines for which processes can be contained in a particular
container. For example, a distinction can be made between containers for primary and
support processes (Porter 1985). The container for primary processes can only contain
processes that directly add value for the client; the container for support processes can

Primary Processes

Produce
Operations
goods

Receive Check Store

Logistics
goods delivery goods Legend:

Process
Sell Generate
goods lead Trigger
Sales
Generate Generate Flow
lead via phone lead via e-mail
Specialization

Figure 1. Example business process architecture.

 4 R. Dijkman et al.

only contain processes that do not directly add value, but are necessary for the effective
operation of the primary processes.

3. Business process architecture design approaches

There are a number of approaches to design a business process architecture. This section
presents a classification of the different approaches that we identified through a literature
study.
The literature study was performed using the keywords ‘business process architecture’
and combinations of the words ‘business process’ and ‘identification’, ‘delimitation’ or
‘demarcation’. Google Scholar was used initially as a source. For each approach that was
found, references and citations were used to further identify approaches. As a result, 45
approaches were identified. Of these approaches, 30 originated from a survey by Fettke,
Downloaded by [Anadolu University] at 08:52 28 December 2014

Loos, and Zwicker (2006) specifically aimed at the topic of using reference models to
design a business process architecture. We validated the completeness of our results by
using additional sources, in particular: Scopus, Web of Science, Inspec, ABI/Inform, IEEE
Electronic Library, ACM Digital Library and Springer (in that order). Scopus and Inspec
both returned one additional approach, but after that no other candidates were found.
Reference and citation analysis of the two additional approaches returned one more
approach, leading to a total of 48 approaches to design a business process architecture.
The precise protocol is given in Appendix 1.
The approaches that were collected in this manner were subsequently classified by
answering the question: ‘On what basis are processes and their relations identified according
to this approach?’ This led to five classes of approaches: goal-based, action-based, object-
based, reference model-based and function-based. Table 1 shows this classification. In each
approach (or class of approaches), a business process architecture is designed by first
designing another structure, for example a goal structure. Such a structure should be
designed in terms of the concepts and the relations prescribed by the respective approach.
A business process architecture is subsequently designed based on that structure.
In the remainder of this section we discuss each of the five classes of approaches in
more detail.
Note that the approaches are not necessarily mutually exclusive. For example, a
reference model-based approach can group business processes according to the business
functions that they implement. Thus, it essentially combines a reference model-based and
a function-based approach. In particular the approach by Damij and Damij (2009)
proposes a combination of different structures as a starting point for identifying business
processes. When an approach fits into multiple classes, we used the class that best
described the approach. This was possible, because, except for the reference-model-
based approach, all approaches started from a single structuring principle.

3.1. Goal-based
3.1.1. Brief description
In goal-based approaches (Antón, McCracken, and Potts 1994; Koubarakis and
Plexousakis 2002; Lee 1993; Kavakli and Loucopoulos 1998; Yu and Mylopoulos
1994; Lunn et al. 2003) a goal structure, which consists of business goals and relations
between those goals, is designed first. Subsequently, a business process architecture is
derived from it, based on the definition of a business process as a collection of related
 Enterprise Information Systems 5

Table 1. Classification of business process architecture design approaches.

Class approaches Structure Organising concept Concept relations

Goal-based Goal Goal (various subtypes) Various associations

Antón, McCracken, and structure including:
Potts (1994) – realisation
Koubarakis and Plexousakis (inclusive, exclusive)
(2002) – influence
Lee (1993)
Kavakli and Loucopoulos
(1998)
Yu and Mylopoulos (1994)
Lunn et al. (2003)
Action-based Action Action loop (various Various associations
Medina-Mora et al. (1992) structure subtypes) including:
Downloaded by [Anadolu University] at 08:52 28 December 2014

Lind and Goldkuhl (2003) – decomposition

Lind (1997) – triggering
Dietz (2006) – phasing
Auramäki, Lehtinen, and – specialisation
Lyytinen (1988)
Johannesson (1995)
Object-based Object Business object (various Various associations
Green and Ould (2004) model subtypes including: including:
Joosten et al. (2002) – permanent object – decomposition
– case object) – state transition
– specialisation
Reference model-based Classification Class (various subtypes Decomposition
survey: including: specialisation
Fettke, Loos, and Zwicker – business function
(2006) – industry segment)
Function-based Function Function Decomposition
Scheer and Nüttgens (2000) hierarchy
Aitken, Stephenson, and
Brinkworth (2010)
Eertink et al. (1999)
Aronson (2008)

activities to achieve a certain goal. Figure 2 shows an example of a goal structure and a
business process architecture that is derived from it. The benefit of using the goal-based
approach is that associating goals with processes also helps determine why certain
processes are important or at all needed.

3.1.2. Organising concept

The main organising concept in goal-based approaches is the ‘goal’, but different
approaches distinguish different types of goals. Antón, McCracken, and Potts (1994)
provide an extensive discussion of different types of goals that can be identified.
Subsequently, they show that focusing on different types of goals leads to a different
goal structure and, therefore, potentially to a different business process architecture. In
addition, different types of goals may be translated differently into processes when a
business process architecture is constructed (Yu and Mylopoulos 1994).
 6 R. Dijkman et al.

Figure 2. Example of goal-based design of process architecture.

Downloaded by [Anadolu University] at 08:52 28 December 2014

3.1.3. Concept relations

Different goal-based approaches also distinguish different types of relations between
goals. Four of the approaches within this class consider a realisation relation between
goals, which expresses that a (higher level) goal can be achieved by achieving the (lower
level) realisation goals being related to it (Antón, McCracken, and Potts 1994; Koubarakis
and Plexousakis 2002; Lee 1993; Kavakli and Loucopoulos 1998). Kavakli and
Loucopoulos (1998) also distinguish the influence relation between goals, which
expresses that one goal influences another goal. Lee (1993) allows the modeller to freely
define the types of relations that can be considered within a goal structure.

3.1.4. Deriving a process architecture

Goal-based approaches differ significantly in how they relate a process architecture to the
goal structure. Lee (1993) defines a relatively strict relation between goals and sub-goals
and processes and sub-processes, stating that if goals are related, the processes that help
realise those goals must be related too. Koubarakis and Plexousakis (2002) and Kavakli
and Loucopoulos (1998) state that goals can be used to identify processes, but do not
make statements about how relations between goals influence relations between pro-
cesses. Antón, McCracken, and Potts (1994) and Yu and Mylopoulos (1994) relate
processes only indirectly to goals (i.e. via other concepts).

3.2. Action-based
3.2.1. Brief description
In action-based approaches (Medina-Mora et al. 1992; Lind and Goldkuhl 2003; Lind
1997; Dietz 2006; Auramäki, Lehtinen, and Lyytinen 1988; Johannesson 1995) an action
structure, which consists of business actions and their relations, is designed first. A
business action is an activity loop in which a provider completes some work for an
internal or external customer. Thus, by definition, it is very similar to a business process.
The main difference between a business process and a business action lies therein that
business action theory assumes that all human action, and therefore also business action,
follows certain standard patterns and phases. This makes business action theory particu-
larly suitable for identifying processes, delimiting those processes (i.e. determining where
one process stops and the other starts) and dividing a process into sub-processes and/or
 Enterprise Information Systems 7

i. Action structure ii. Process architecture

Figure 3. Example of action-based design of process architecture.

Downloaded by [Anadolu University] at 08:52 28 December 2014

variants (Lind and Goldkuhl 2003; Lind 1997); the patterns and phases help determine
which (sub-)processes should exist according to a pattern and where a (sub-)process ends
and another begins, because of a transition from one phase to another. Once an action
structure is designed, a business process architecture can be derived from it, using the
strong similarity between business processes and business actions. Figure 3 shows an
example of action structure and a business process architecture that is derived from it.

3.2.2. Organising concept

The main organising concept in action-based approaches is the ‘action’ and different
approaches distinguish different types of actions. Nonetheless, all action-based approaches
use the idea that each action goes through a number of phases. However, the exact number
and definition of these phases differ per approach.

3.2.3. Concept relations

Different action-based approaches distinguish different types of relations between actions.
All of the action-based approaches that we studied have a decomposition, a triggering and
a phasing relation. A decomposition relation between actions represents that an action can
be decomposed into multiple more detailed actions. A triggering relation represents that
the completion of one action triggers the start of another. A phasing relation represents
that one phase of an action is completed and that the next phase starts. Lind and Goldkuhl
(2003) and Lind (1997) also discuss a specialisation relation, in which actions such as
‘apply for car insurance’ and ‘apply for home insurance’ are specialisations of a more
general action ‘apply for insurance’.

3.2.4. Deriving a process architecture

Action-based approaches differ significantly in the way in which a process architecture
relates to the action structure. First, the approaches differ with respect to how they
perceive the role of the business process concept. Most approaches do not distinguish
between actions and processes and develop an overview of the actions that are performed
in an organisation in terms of an ‘action structure’ (Medina-Mora et al. 1992; Dietz 2006;
Auramäki, Lehtinen, and Lyytinen 1988; Johannesson 1995). One approach makes a
distinction between actions and processes and discusses the relation between them
 8 R. Dijkman et al.
Downloaded by [Anadolu University] at 08:52 28 December 2014

Figure 4. Example of object-based design of process architecture.

(Lind and Goldkuhl 2003; Lind 1997). Second, the approaches differ with respect to the
scope of the action structure that is designed. Where a business process architecture
focuses on structuring all business processes within a certain scope, the scope of an
action structure can vary. Case studies are performed for high-level business functions,
such as purchasing (Dietz 2006), or workflow processes, such as hiring new personnel
(Medina-Mora et al. 1992).

3.3. Object-based
3.3.1. Brief description
In object-based approaches (Green and Ould 2004; Joosten et al. 2002) a business object
model is designed first, for example in the form of a unified modelling language class
diagram. Subsequently, a business process architecture is designed by studying the business
objects that exist in the organisation, as well as their interrelations. Figure 4 shows an
example of an object model and a business process architecture that is derived from it.

3.3.2. Organising concept

The main organising concept in object-based approaches is the ‘business object’ and both
identified approaches consider three types of business objects: ‘permanent objects’, ‘case
objects’ and ‘other objects’. Permanent objects are business objects that have a relatively
long life cycle in the organisation, such as the ‘client’ in most organisations. Processes can
be identified from permanent objects by determining the operations that can be performed
on these objects and defining processes to support these operations. For example, a new
client can arrive or buy something, thus leading to the need for a process to register new
clients and a sales process. Case objects are objects that guide the execution of a business
process and thus directly identify a business process. An example of a case object is an
‘order’ or an ‘application’.

3.3.3. Concept relations

Object modelling is a discipline in itself and the many object modelling techniques that
exist distinguish many different types of relations between business objects. Some of these
 Enterprise Information Systems 9

relations are of particular interest in the context of designing a process architecture. The
relation between permanent objects and case objects can be used to identify a logical
group of processes. A relation between states of one or more business objects can be used
to delimit or relate business processes. For example, a state-change of an object from
‘ordered’ to ‘shipped’ can be used to delimit and relate the ‘order’ and ‘shipping’
processes. A decomposition relation between objects can be used to identify a decom-
position relation between business processes. For example, the decomposition of a
‘mortgage application’ into ‘client details’, ‘mortgage details’ and ‘securities’ can lead
to different sub-processes in the mortgage application process. Finally, a specialisation
relation can be used to identify a logical group of processes. For example, a specialisation
relation between ‘apply for car insurance’, ‘apply for home insurance’ and ‘apply for
insurance’ can be used to identify a logical group of insurance application processes.
Downloaded by [Anadolu University] at 08:52 28 December 2014

3.3.4. Deriving a process architecture

A process architecture is not directly derived from an object model. However, different
types of objects and relations can be used to identify processes and relations between
processes, as described in the previous two paragraphs.

3.4. Reference model-based

3.4.1. Brief description
In reference model-based approaches, an existing business process architecture (the
reference model) is reused and adapted to design a new business process architecture.
Figure 5 shows an example. The benefit of this approach is that much time can be saved
by starting from an existing model. Also, the reference model is meant to present best
practices and may thus lead to better designs. There exist a large number of business
process reference models. Fettke, Loos, and Zwicker (2006) published a survey that
covers 30 of these. However, the focus of these reference models is on presenting a
collection of business process models, not on the business process architecture that
structures the collection itself. In most cases, the business process architecture is a by-
product of the reference model, although in some it is considered and published separately
(APQC 2011; Aitken, Stephenson, and Brinkworth 2010; Malone et al. 1999). In the
context of business process reference models, the business process architecture is

Figure 5. Example of reference model-based design of process architecture.

 10 R. Dijkman et al.

commonly referred to as a business process (architecture) framework (Koliadis, Ghose,

and Padmanabhuni 2008) and takes the form of a classification. What distinguish the
classifications are the concepts that are used for classification, the relations between
elements in the classification and the specification of abstraction levels in the
specification.

3.4.2. Organising concept

Fettke, Loos, and Zwicker (2006) found that the two most-used concepts to classify
business processes in a business process architecture are business function and industry
segment. In addition to that, a classification can be done based on a predefined classifica-
tion that is based on consensus rather than on a single concept. APQC’s Process
Classification Framework defines such a classification (APQC 2011).
Downloaded by [Anadolu University] at 08:52 28 December 2014

3.4.3. Concept relations

The most prominent relations between business processes in reference models are those of
specialisation and decomposition (Malone et al. 1999), which have been explained in
Section 2.

3.4.4. Deriving a process architecture

In a reference model-based approach, the reference model itself is a process architecture.
An instance of that process architecture that is specifically developed for a company is
derived by adapting the reference model.

3.5. Function-based
3.5.1. Brief description
In a function-based approach a function hierarchy is designed, which represents the
decomposition of business functions into more detailed business functions. A process
architecture is derived from the function hierarchy by either considering the functions at a
certain level in the hierarchy as processes or considering functions and processes as
orthogonal and using processes to represent the flow relations between functions.

3.5.2. Organising concept

The main organising concept in the function-based approach is the ‘business function’,
which is defined as a capability of an organisation, such as ‘production’ or ‘procurement’.

3.5.3. Concept relations

The sole relation that is considered in a function hierarchy is the decomposition relation,
which represents the decomposition of a function into a set of more detailed functions.
 Enterprise Information Systems 11

Figure 6. Example of function-based design of process architecture.

Downloaded by [Anadolu University] at 08:52 28 December 2014

3.5.4. Deriving a process architecture

There are roughly two ways in which a function hierarchy can be related to a business
process architecture. First, the function hierarchy can be the primary way of organising the
business processes. In that case, functions are decomposed into more detailed functions
until a chosen level of decomposition is reached from which the functions are further
decomposed into processes (Aitken, Stephenson, and Brinkworth 2010; Aronson 2008).
In this case, business processes are organised according to the functions to which they
belong. Second, functions and processes can both be organised into hierarchical structures
through decomposition relations, which should be closely aligned (Scheer and Nüttgens
2000; Eertink et al. 1999).
Figure 6 shows an example of a function hierarchy and a business process architecture
that is derived from it. The benefit of using business functions to identify processes is that,
compared to business processes, business functions are relatively simple to identify and
stable, because they focus on what an organisation does rather than how the organisation
accomplishes that. Consequently, they arguably form a good starting point for designing a
business process architecture.

4. Survey-based comparison of approaches

As has been hypothesised and empirically proven, the intention to use an IT artefact is
mainly a function of two pervasive beliefs: perceived ease of use and perceived usefulness
(Maes and Poels 2007). This is the reason that for our exploratory evaluation of the
business process architecture design approaches that have been described in the previous
section, we centred on these notions. We extended this view by also acquiring the
perception of respondents on the popularity of these approaches in practice. The outcomes
of the survey should be interpreted as an inventory of opinions and an illustration of the
use, usefulness and popularity of the presented approaches in practice. It is not intended to
prove any hypotheses with this. In this section, first the evaluation setup is presented,
followed by a discussion of the results.

4.1. Setup
The evaluation of the five main classes of approaches was carried out among a group of
39 Dutch practitioners in the area of Business Process Management. They were invited as
 12 R. Dijkman et al.

Table 2. Demographics of respondents.

Experience (years) Number of respondents Percentage

<1 5 13
1–4 6 15
5–10 7 18
> 10 21 54
Industry sector
Professional services 15 38
Research 9 23
Financial services 7 18
Healthcare 4 10
Software 2 5
Logistics 1 3
Government 1 3
Downloaded by [Anadolu University] at 08:52 28 December 2014

Company size
Small 6 15
Medium 3 8
Large 30 77
Job function
Advisor 23 59
Manager 8 21
Student 5 13
Researcher 2 5
Developer 1 3

members of the BPM Round Table,2 a free forum for Dutch BPM professionals that
organises regular meetings at which a BPM topic is discussed. Currently, the BPM Round
Table has 334 members, making for a response rate of around 12%. Demographic
information of the respondents is provided in Table 2. The demographics show a rather
homogeneous group of respondents. The ‘average’ respondent is an experienced advisor
working in a large professional services firm. This is a good group of respondents to give
an opinion on popularity of process architecture approaches in practice, because this
group has seen much of the industry, both because of their experience and because of
their employment as advisors at professional services firms. A threat to the external
validity of the survey, however, is the fact that all respondents were Dutch. We will
comment on that in the conclusions.
The evaluation consisted of three parts. The first part focused on the ease of use,
usefulness and popularity of the approaches in general, while the second part aimed to
investigate the usefulness of specific guidelines, as they exist as part of an overall
approach. A discussion of the results completed the session, which overall lasted for
2 hours.
During the first part of the evaluation, the participants received a brief explanation and
some examples for each type of approaches, similar to the explanations given in the
previous section. After each explanation of an approach, the participants were asked to
give their opinion on the following three statements: (i) this approach is easy to apply, (ii)
this approach is useful to design a business process architecture and (iii) this approach is
popular in practice. We used an electronic voting system to record the scores ‘agree’,
‘neutral’, ‘disagree’ or ‘don't know’ on each of the statements. This operationalisation of
the usefulness of business process architecture design approaches is based on the
 Enterprise Information Systems 13

(empirically validated) observation that the intention to use an IT artefact is mainly a

function of two pervasive beliefs: perceived ease of use and perceived usefulness (Maes
and Poels 2007). In total, 15 evaluation scores were stored per participant (five classes of
approaches times three questions).
In the second part of the evaluation, the participants were presented 18 specific
guidelines as taken from the literature (see Table 3). For each of these guidelines, the
participants were asked to give their opinion on the hypothesis that the guideline is
useful for designing process architectures, by indicating whether they would agree, be
neutral, would disagree or did not know. Each of the five identified classes of
approaches was represented by three guidelines, for example guidelines 5, 13 and
17 were taken from goal-based approaches. In addition, we added three guidelines (i.e.
1, 9 and 15) that could not be classified under one of the five main classes of
approaches. The participants were neither told which guideline belonged to which of
Downloaded by [Anadolu University] at 08:52 28 December 2014

the presented approaches, nor were they aware of the fact that there were three
additional, unclassified guidelines.

Table 3. List of specific guidelines.

Number Guideline

1 Identify logical units within a process (unit of time, place, resource, …), determine which
of these logical units form a sub-process.
2 Identify ‘consists of’ relations between documents, derive from that ‘consists of’ relations
between business processes.
3 Use a reference model to describe processes completely.
4 Identify the start and end of a process by identifying the start and end of the corresponding
transaction.
5 Identify the business goals, then identify the business processes that accomplish these
business goals.
6 Each process belongs to at most one business function.
7 Identify the documents and files that exist in an organisation, then identify the processes
that describe what is happening to these documents.
8 Identify ‘executed within’ relations between transactions, derive ‘executed within’
relations between business processes from that.
9 Identify the value that is created for clients, then identify the processes that describe how
this value is created.
10 Identify the business functions, then identify the processes that are executed within these
business functions.
11 Identify transactions (which are executed by a provider for satisfaction of a consumer),
then identify the business processes that accomplish these transactions.
12 Use a reference model to identify processes.
13 Identify ‘consists of’ relations between business goals, derive ‘consists of’ relations
between business process from that.
14 Identify artefacts that flow through an organisation, then identify the processes that belong
to these flowing artefacts.
15 Graphical properties and relations between processes in a process architecture model have
to have a clear meaning.
16 Identify ‘consists of’ relations between business functions, derive ‘consists of’ relations
between business process from that.
17 A business goal has to be achieved by a business process, or should consist of sub-goals
that are achieved by a business process.
18 Use a reference model to identify relations between processes.
 14 R. Dijkman et al.

Table 4. Overview of business process architecture approaches. Each statement is scored on

whether the participants agree with it (A), are neutral (N), disagree (D) or don’t know (?).

Ease of use Usefulness Popularity

Approach A N D ? A N D ? A N D ?

Goal-based 30% 43% 22% 5% 39% 25% 28% 8% 6% 19% 33% 42%
Action-based 41% 24% 32% 3% 42% 26% 21% 11% 19% 5% 35% 41%
Object-based 37% 29% 29% 5% 57% 24% 19% 0% 29% 18% 18% 34%
Reference model- 67% 21% 8% 5% 62% 16% 8% 14% 56% 13% 10% 21%
based
Function-based 45% 34% 16% 5% 50% 32% 8% 11% 38% 21% 13% 28%
Note: The highest score on an approach is indicated in boldface.
Downloaded by [Anadolu University] at 08:52 28 December 2014

4.2. Results
The results for the first part of the evaluation can be found in Table 4. It can be derived
from this table that the reference model-based approach is considered the most easy to
use, useful and popular; 67% of the participants agreed with the statement that the
approach is easy to use, 62% with the statement that the approach is useful and 56%
with the statement that the approach is popular in practice. In a similar way, it can be seen
that the goal- and action-based approaches are considered the least easy to use, useful and
popular approaches (highest percentage of participants who disagreed with these
statements).
The second evaluation focused on the usefulness of specific guidelines as taken from
the literature. Table 5 summarises the results and shows some surprising outcomes. First,
the guidelines that are identified as being the most useful are guidelines 9 (89% of the
participants find it useful) and 15 (84%). Both are guidelines that cannot be classified
within one of the approaches. Apparently, separate rules of thumb exist that are not part of
a bigger approach to design a business process architecture, but are nonetheless consid-
ered highly useful when designing and defining business processes. Second, the guide-
lines that have been evaluated as the least useful (highest percentage of participants that
disagree) are guidelines 3, 6 and 18. Two of them are from the reference model-based
category and the other one is from a function-based approach. This is remarkable, since
actually the reference model-based approaches were classified most often as useful in the
first part of the evaluation (67%, see Table 4). Third, one guideline (6) was found useful
by none of the participants, while all other guidelines found at least some support. Finally,
guidelines taken from the same approach are not perceived as equally useful, for example
guidelines 6, 10 and 16 are expressed to be useful by 0%, 47% and 26% of the
participants, respectively.
These observations fit in the overall pattern that guidelines do not receive the same
evaluations as the approach of which they are a part; individual guidelines may be
evaluated as more useful or less useful than the approach of which they are a part and
different guidelines belonging to the same approach may be evaluated differently. For
example, of the guidelines that are related to the goal-based approach (guidelines 5, 13
and 17), guidelines 5 and 17 are evaluated as more useful than the goal-based approach
itself. Guideline 13 is evaluated differently from guidelines 5 and 17, and its evaluation is
on-par with the evaluation of the goal-based approach itself.
After the evaluation with the voting system, the resulting patterns were discussed with
the participants. In this discussion it became very apparent that companies often do not
 Enterprise Information Systems 15

Table 5. Overview of business process architecture guidelines. Each guideline is scored on

usefulness by asking the participants whether they agree (A), are neutral (N), disagree (D) or
don’t know (?).

Usefulness

No. Approach Source A N D ?

1 Not classified Lankhorst (2005) 51% 14% 24% 11%

2 Object-based Joosten et al. (2002) 36% 23% 31% 10%
3 Reference model-based Fettke, Loos, and Zwicker (2006) 29% 26% 39% 5%
4 Transaction-based Lind (1997) 51% 16% 22% 11%
Lind and Goldkuhl (2003)
5 Goal-based Koubarakis and Plexousakis (2002) 63% 26% 11% 0%
Lee (1993)
Yu and Mylopoulos (1994)
Downloaded by [Anadolu University] at 08:52 28 December 2014

6 Function-based Aitken, Stephenson, and 0% 3% 95% 3%

Brinkworth (2010)
Aronson (2008)
7 Object-based Joosten et al. (2002) 38% 26% 33% 3%
8 Transaction-based Lind (1997) 11% 26% 24% 39%
Lind and Goldkuhl (2003)
9 Not classified Lankhorst (2005) 89% 6% 3% 3%
10 Function-based Aitken, Stephenson, and 47% 32% 18% 3%
Brinkworth (2010)
Aronson (2008)
Scheer and Nüttgens (2000)
Eertink et al. (1999)
11 Transaction-based Lind (1997) 44% 31% 15% 10%
Lind and Goldkuhl (2003)
12 Reference model-based Fettke, Loos, and Zwicker (2006) 69% 21% 10% 0%
Koliadis, Ghose, and
Padmanabhuni (2008)
13 Goal-based Lee (1993) 26% 32% 24% 18%
14 Object-based Joosten et al. (2002) 68% 16% 16% 0%
Green and Ould (2004)
15 Not classified Lankhorst (2005) 84% 3% 3% 11%
16 Function-based Scheer and Nüttgens (2000) 26% 33% 18% 23%
Eertink et al. (1999)
17 Goal-based Lee (1993) 59% 24% 14% 3%
18 Reference model-based Fettke, Loos, and Zwicker (2006) 32% 24% 37% 8%
Koliadis, Ghose, and
Padmanabhuni (2008)
Note: The highest score on a guideline is indicated in boldface.

use one of the identified approaches fully or even exclusively. Rather, a mixture of ideas
from different approaches is applied. For example, one participant explained that the
approach followed within his institute was to first follow a functional decomposition of
processes, followed by an approach to identify the most important objects. The attrac-
tiveness of a hybrid approach may explain at least to some extent how it is possible that
individual guidelines can be evaluated differently from their encompassing approach. It
was also interesting that despite the broad appreciation of the reference model-based
approach, its usefulness was further qualified by several participants. One of them
remarked: ‘Reference process models certainly provide a tangible starting point, but it
should not be underestimated how much time must be spent on appropriating them to a
specific setting. It’s terrible!’. Also, since we established the relatively poor evaluation of
 16 R. Dijkman et al.

the goal-based approach, a participant noted that this score is caused by the fact that
‘management becomes very quiet when asked for the actual goals that need to be
fulfilled’. This points to a practical barrier of linking goals to process models, as proposed
by this class of approaches. From the approaches that were holding the middle ground
between the most popular and the least popular approaches, the approach that attracted
most discussion was the object-based approach. In particular, the ‘explosion of objects’
was considered troublesome and affecting its ease of use negatively.
In conclusion of the discussion, we invited the participants to identify approaches that
were not covered by the five main classes of approaches that were the subject of the
session. The most important addition here may be coined as the service-oriented
approach. Based on the identification of important business services an organisation
provides, the main processes and their relations can be established as well. Business
services were in particular mentioned as being more concrete than goals by some
Downloaded by [Anadolu University] at 08:52 28 December 2014

participants, even though the approach could also be seen as subsumed by the object-
based approach according to others.
The above observations and the results of the exploratory evaluation illustrate that the
reference model approach is considered most useful, easy to use and popular; the goal-
based and action-based approaches score the lowest. However, none of the evaluated
approaches to business process architecture is considered by practitioners as the perfect or
even a dominant solution to structuring the process landscape in a company. Rather, the
hybrid combination of guidelines seems to best represent the state of the art. While such a
position may have its appeal, it also points at a lack of any approach to satisfactorily deal
with the demands of practitioners to define business process architectures.

5. Case study-based comparison of approaches

Since the survey-based evaluation from Section 4 shows that practitioners do not use a
single approach to design a process architecture, we conducted further research to
determine popular combinations of approaches, guidelines and structuring principles. To
this end we took four business process architectures from practice as case studies and
determined the structuring principles that were used to create them. The case studies
concern theory building (Eisenhardt 1989), where we are interested in answering the
research question: ‘which elements of design approaches are used in practice to design a
process architecture’. The case study protocol that we followed contains the elements
described by Runeson and Höst (2009).
We selected the cases, using the maximal variation principle of Runeson and Höst
(2009), in order to produce a set of cases that is as representative as possible. In doing so,
we assume that process architectures will primarily differ with respect to the goal with
which they are created, and the industry sector for which they are created. Therefore, we
varied the cases with respect to these characteristics. We strictly selected process archi-
tectures for which the authors were not involved in the development, because that would
create a bias in the case selection. Table 6 shows an overview of these characteristics and
the general characteristics of company size, measures in terms of the number of employ-
ees, and company age, measured in terms of the number of years in existence. The
characteristics of the first three cases are approximated to maintain the confidentiality of
the organisations.
We used the literature study from Section 3 as the theoretical frame of reference for
our case study. In particular, we use the elements of the design approaches, as they are
classified in Table 1. Consequently, for each of the four cases we determined:
 Enterprise Information Systems 17

Table 6. Case characteristics.

Case study Sector Purpose Size (nr. employees) Age (years)

Harbour Transport Creating an overview Approx. 100 Approx. 10

of processes
Electronics Manufacturing Identifying processes to model Approx. 200 Approx. 10
Bank Services Re-engineering processes Approx. 25,000 Approx. 25
Municipalities Public Re-engineering processes 134 3

● which basis was used to construct the process architecture;

● which instances of organising concepts are part of the process architecture; and
● which relations are part of the process architecture.
Downloaded by [Anadolu University] at 08:52 28 December 2014

These questions were answered through a document analysis.

Each of the process architectures is described in a document, such as the publicly
available document that describes the process architecture for the municipality (Kwaliteits
Instituut Nederlandse Gemeenten (KING) 2011). In the document analysis, the authors
studied these documents. In addition, unstructured interviews were held by the authors
with people in the organisations in order to improve the authors’ understanding of the
process architectures. Since the documents can be assumed to represent a consensus
between the different people in the respective organisations, no intra-case comparison
was needed.
Each of the process architectures consisted of several ‘groups’ of processes. The
authors identified the names of these groups. These names are presented in more detail
further on in this section. The authors then used the names to determine the structuring
principles behind the groups of processes. This requires a creative step, but that step can
be verified by the reader. Finally, the authors identified the relations between the groups of
processes that were presented in the process architecture.
In the remainder of this section, we will present the document analysis of each of the
process architectures, by presenting the ‘groups’ of processes that were identified in the
documents, the structuring principles that were derived from those groups and the rela-
tions that we identified between the groups of processes. We will also present strongly
simplified versions of each of the process architectures, to clarify the structuring principles
and relations by example. The last subsection then carried out an inter-case comparison of
the structuring principles that underlie the four process architectures.

5.1. Harbour process architecture

The first process architecture is from a department of a large Dutch Harbor and concerns
the primary processes of the harbour as a whole. The process architecture was developed
primarily to provide an overview to all stakeholders of how the different stakeholders (e.g.
harbour master, transporters, terminals and customs) and their processes are related. The
processes that are organised in this way are not explicitly related to the process
architecture.
Figure 7 shows a strongly simplified view of the process architecture. We classified
the structuring principles that were used to design this process architecture as shown in
Table 7. We argue that the process architecture organises processes in two dimensions:
according to mode of transportation and according to business function. The business
 18 R. Dijkman et al.

functions induce a function-based decomposition on multiple levels. First, a distinction is

made between an ‘import’ and an ‘export’ function. These functions are further decom-
posed, for example into ‘departure harbor’, ‘transshipment’ and ‘hinterland transportation’
for ‘export’. These functions are again further decomposed, for example ‘create manifest’
is part of ‘departure harbor’. The modes of transportation induce an object-based organi-
sation, where each of the modes of transportation is a business object. The arrows that are
associated with the modes of transportation provide some information on the order in
Downloaded by [Anadolu University] at 08:52 28 December 2014

Figure 7. Harbour process architecture.

Table 7. Concepts used in process architectures from practice.

Case study Structuring basis Concept instances Relations

Harbour Function-based Import, export Decomposition

Phases of import, export Ordering
Functions related to phases
Object-based Modalities
Electronics Function-based Primary, secondary Decomposition
Manufacturer Common business functions Ordering
Flow
Object-based Product type
Bank Function-based Management, support, customer Decomposition
Common customer functions Ordering
Specialisation
Object-based Product type
Sales channel
Customer type
Municipality Function-based Steering, primary, supporting Decomposition
 Enterprise Information Systems 19

i. Hierarchical organisation

ii. Flow-based organisation

Downloaded by [Anadolu University] at 08:52 28 December 2014

Figure 8. Electronics manufacturer process architecture.

which business functions and, consequently, processes can be performed. Note that the
ordering relations were not originally identified in the literature as potential relations
between processes. Triggering relations are indeed identified, but these are more strict
than ordering: a triggering relation implies an order between the related processes, but
processes can be ordered in time, without having a triggering relation.

5.2. Electronics manufacturer process architecture

The second process architecture is of a single department within an internationally
operating electronics manufacturer. The process architecture was developed as a starting
point in a project that involved the development of models of all processes in the
organisation. The process architecture aims to organise all processes in the organisation
(both primary and secondary). At the time of writing, 213 primary processes are identi-
fied, of which 212 are also modelled in detail, but only 19 secondary processes are
identified, of which 11 are modelled in detail.
Figure 8 shows a strongly simplified view of the process architecture. The process
architecture consists of two separate models: one that represents the hierarchical decom-
position of the processes and one that represents information that flows between the main
processes. We classified the structuring principles that were used to design this process
architecture as shown in Table 7. We argue that the processes are primarily organised
using a functional decomposition. A first-level decomposition into ‘A’ and ‘B’ processes
is made, which can be equated to a decomposition into primary and supporting processes.
Processes are then further decomposed. For the processes of the second-level decomposi-
tion, separate models exist that represent trigger relations between processes from the
third-level decomposition. Therefore, we say that ordering relations are expressed
between processes. In addition, looking at the decomposition of the ‘production’ process,
we argue that an object-based decomposition of this process into sub-processes is used,
where each production process is classified according to the type of product that it aims to
produce. Interestingly, general-purpose processes, such as ‘packaging’, are also identified
on this level. These processes are the same for each of the different types of products.
 20 R. Dijkman et al.

Figure 9. Bank process architecture.

Downloaded by [Anadolu University] at 08:52 28 December 2014

5.3. Bank process architecture

The third process architecture is that of an internationally operating bank. It was devel-
oped as part of a project to re-engineer the bank's existing business processes in such a
way that they become more standardised. The bank runs 360 primary processes and
different variants and sub-processes exist for each of them.
Figure 9 shows a strongly simplified view of the process architecture. The bank
organises its processes in ‘process families’. A process family is a process that represents
the tasks that are generally performed in a family of similar processes. Within each
process family, a number of variants can exist. Variants are distinguished for different
products, different sales channels and different types of clients. For example, the ‘advise
customer’ process family represents a general process for providing advice to customers.
A possible variant of this process is advising customers about checking accounts. Ideally,
the variant reuses as much of the general process family as possible, but it can also
specialise, remove and add elements. Both process families and process variants consist of
steps and steps consist of tasks. We classified the structuring principles that were used to
design this process architecture as shown in Table 7. There are three classes of process
families: management, support and customer process families. We argue that these classes
and their subsequent elements constitute a functional decomposition. Process families and
steps are related by means of ordering relations. In addition, there exist specialisation
relations between process families and their variants and also between the elements of
process families (general steps and tasks) and their counterparts in process variants.
Finally, we argue that process variants are classified in an object-based manner, according
to product type, sales channel and customer type.

5.4. Municipalities process architecture

The fourth process architecture is a general process architecture developed by the quality
institute for Dutch municipalities (KING). The Netherlands have 415 municipalities that
perform similar tasks. The process architecture by KING was developed as a reference
process architecture for local governments and aims at improving process quality and
efficiency. It does so by setting an example on how to structure and streamline processes.
Figure 10 shows a simplified version of this publicly available reference process
architecture (Kwaliteits Instituut Nederlandse Gemeenten (KING) 2011). The processes
 Enterprise Information Systems 21
Downloaded by [Anadolu University] at 08:52 28 December 2014

Figure 10. Process architecture for municipalities (adapted from Kwaliteits Instituut Nederlandse
Gemeenten (KING) 2011).

are divided into steering (strategic), primary and supporting processes, based on their nature.
Within each of these categories, a number of clusters of processes are defined. We classified
the decomposition of the processes in the reference architecture as a solely functional
decomposition as shown in Table 7. The division in categories (based on the nature of
the processes) and clusters is driven by the functions that are performed in the various
groups. Processes with a similar function are grouped into one cluster. Arguably, the
decomposition of ‘provide products & services’ is object-based, but this decomposition
only plays a minor role in the whole. We decided that this role was not sufficiently
prominent to claim that an object-based decomposition was used as a structuring principle.

5.5. Results
Table 8 shows a comparison of the types of structuring principles and relations used in the
different cases. The cases are referred to by their first letter H(arbour), E(lectronics
manufacturer), B(ank) and M(unicipality).
The comparison shows that three of the four cases use a combination of a function-
based and an object-based approach and one case uses a purely function-based approach.
This observation is in line with the previous evaluation (see Section 4), which showed
that, in practice, organisations rely on a combination of several approaches to develop a
process architecture. However, interestingly, in the previous evaluation, the reference
model-based approach was deemed the most usable and useful, while none of the cases
used that approach. The reason for this was that the authors of the process architectures
were not aware of the existence of process architecture reference models in their particular
 22 R. Dijkman et al.

Table 8. Comparison of process architectures from practice.

Relation

Approach Decomposition Ordering Specialisation Flow Other

Goal-based
Action-based
Object-based H: 1 dimension H
E: 1 dimension
B: 3 dimensions
Reference model-based
Function-based H: 3 levels H
E: up to 7 levels E E
B: 2 levels B B
M: 3 levels
Downloaded by [Anadolu University] at 08:52 28 December 2014

domain (which is not the same as saying that they do not exist). For the municipality, the
developed process architecture was meant to serve as a reference model.
All cases use decomposition relations in the function and/or object dimension to
organise their processes. The decomposition in the function dimension is hierarchical
and between two and seven levels deep, but three of the four cases have a low number
(two or three) of levels. Looking in more detail at the concepts that are used in the cases,
as they are presented in Table 7, three of the four cases have a first-level decomposition
into primary processes (also called customer processes) and secondary processes (also
called support processes), which is indeed a common distinction to make (Porter 1985).
Two of these cases add management processes (also called steering processes) to the
primary and support processes. The object-based decompositions are orthogonal rather
than hierarchical and based on a low number (one to three) of object classes.
Ordering relations are used in all cases, except in the municipality process architec-
ture. The ordering relation indicates temporal relations between processes without a direct
triggering of one process by the other. This kind of relation seems to be an important
element of a process architecture in practice, while it is not present in any of the
approaches found in the literature. Of the ‘other’ possible relations, which are presented
exhaustively in Table 1, only the specialisation and the flow relations are used and only by
single cases.
While the specialisation relation is only explicitly used in one case, two of the other
cases identify a form of specialisation, as described in more detail in the previous sections.
The harbour process specialises its functions for three of the four different modalities and
the electronics manufacturer specialises its functions for the different product that it
develops. This specialisation principle can easily be explained by a desire to achieve
economies of scale, by enabling resources to be shared between processes as much as
possible.
Based on an analysis of the four cases, we conclude that a process architecture is often
developed based on a decomposition of processes in both the function and object
dimension, using a hierarchical decomposition at approximately three levels in the func-
tion dimension and an orthogonal decomposition in the object dimension. In addition,
ordering relations between the functions at selected levels are often used as well as some
form of specialisation. We also conclude that these rules should merely be interpreted as
guidelines, as they already differ for the four cases and, consequently, can be expected to
differ further for other cases.
 Enterprise Information Systems 23
Downloaded by [Anadolu University] at 08:52 28 December 2014

Figure 11. Process architecture framework.

6. Process architecture framework

Based on the results of both the survey-based comparison of the process architecture
design approaches and the case studies, we created a framework that consists of structur-
ing principles that are commonly used when designing a process architecture. The frame-
work is developed by creating a structure that adheres to the most commonly used
structuring principles as they are identified in the previous sections. In particular, the
framework was developed in such a way that the process architectures from the case
studies in Section 5 can be structured according to the framework. Figure 11 shows the
framework.
In the framework, processes are both organised and can be identified by (a) the
creation of a hierarchical decomposition of the business functions that exist in an
organisation and (b) a classification of the most important, permanent business objects.
A common first-level decomposition to use is the decomposition into primary and support
business functions, potentially enriched with management business functions. The decom-
position of business functions does not go deeper than two or three levels. The classifica-
tion of business objects is also based on a small number of business objects, say one to
three. Processes are then categorised by the business functions that are involved in
executing the processes and the business objects that are affected by the processes.
When processes are executed by the same business functions, but affect different business
objects, they are typically designed in such a way that they are as similar as possible and
only differ with respect to essential differences between the business objects.
Figure 12 shows an example of how the framework could be used to structure the
processes at the harbour (also see Figure 7). The figure shows the decomposition of
business functions on two levels and a classification of permanent business objects, in this
case: modes of transportation. Processes that address the same function for different
business objects are variations of each other, i.e. trans-shipment to the different forms
of hinterland transportation, the subsequent paperwork and leaving the harbour is dealt
with in a similar manner for the different modes of hinterland transportation. This does not
mean that the processes are exactly the same, but rather that an effort is made to keep
them as similar as possible. For example, the manifest can be created in the same way for
the different modes of transportation. Even docking at a terminal can be done similarly,
 24 R. Dijkman et al.

functions
import export

hinterland hinterland
arrival transshipment departure transshipment
transportation transportation

sea sea import sea export

hinterland import hinterland export

rail
objects

(rail) (rail)
hinterland import hinterland export
road
(road) (road)
hinterland import hinterland export
river import export
(river) (river)

Figure 12. Example use of the process architecture framework.

Downloaded by [Anadolu University] at 08:52 28 December 2014

announcing the arrival and reserving of a place can be handled similarly, but the actual
docking will differ.
There are a number of alternatives when creating a process architecture according to
the framework. As explained in Section 3.5 the process architecture can be developed
such that the processes only apply to a single (high-level) business function or such that
they apply to multiple (high-level) business functions. Figure 11 illustrates the first case,
while Figure 12 illustrates the second case. This choice is associated with a choice as to
what level the functional decomposition will drill down to. If the functional decomposi-
tion goes deep enough, processes have to apply to multiple functions, because processes
are specifically meant to relate functions. The same choice that holds for business
functions also holds for business objects. Processes can apply to a single business object
or to multiple business objects. A distinction between different (similar) processes,
depending on business objects, can also be made only for specific functions. For example,
in the process architecture of the electronics manufacturer (see Section 5.2) a distinction
between different processes for different product types is only made for the production
function, not for the other functions. Finally, a choice can be made with respect to
additional relations that are added to the process architecture.
It is possible to include hierarchical relations between business process models as part of
the process architecture. These hierarchical relations can be inspired by (hierarchical)
relations between functions, objects or both. Figure 12 shows such relations, showing an
‘export’ and an ‘import’ super process that are decomposed into sub-processes. While it is
possible to include such a decomposition in a business process architecture, the semantics of
the decomposition must be carefully considered. In particular, the decomposition can
represent either that the child processes together realise the part process (aggregation) or
that one of the child processes can be selected to realise the parent process (specialisation).
A combination of both these types of relations is also possible. For example, in Figure 12 it
can be expected that a combination of ‘sea import’ and one or more of the processes
‘hinterland import (rail)’, ‘hinterland import (road)’ and ‘hinterland import (river)’ realise
the super process ‘import’. Consequently, the super process is realised by an aggregation of
the sub-process ‘sea import’ and the specialised ‘hinterland import’ sub-processes. When
representing a super process as an aggregation, there are again two options, and special care
must be taken concerning the semantics of the aggregation relation. The first option is that
the super process is an aggregation of sub-processes that run relatively independently of
each other. The second option is that the super process is an aggregation of sub-processes
that run consecutively and together form an end-to-end process that realises the goal of the
 Enterprise Information Systems 25

super process. In Figure 12, it can be expected that the second option is meant; a container
flows end-to-end first through the sea import process and then onward through a hinterland
import process in order to realise the goal of ‘import’.
This implies that hierarchical aggregation and specialisation relations are part of the
framework as well as ordering relations that represent the sequence in an end-to-end
process. Indeed such relations were also identified in the case studies that are presented in
Section 5. The way in which these relations are (graphically) represented remains open.
Modelling languages exist that can be used to graphically represent different relations
between business processes (Lankhorst 2005) and the companies from the case study all
used their own proprietary notations to represent their business process architecture.

7. Related work
Downloaded by [Anadolu University] at 08:52 28 December 2014

Compared to the way we ordered the various approaches for business process architecture
design, three alternative classifications exist. Two of these focus on a subset of the
approaches that we consider, namely the reference model-based approach (Fettke, Loos,
and Zwicker 2006; Koliadis, Ghose, and Padmanabhuni 2008). By being reference model-
based, these approaches have a scope that differs from the one in this paper. In particular,
this paper covers an additional 18 approaches and provides an empirical evaluation of the
use and usefulness of all these approaches. The third classification (Green and Ould 2005)
focuses on presenting the classification itself, according to which it discusses four
approaches. The classification looks broadly at the area of business process architecture,
presenting a plethora of aspects to classify them. Our paper looks specifically at means to
design a business process architecture (an aspect that is also covered in (Green and Ould
2005)) and provides a more detailed discussion of that aspect. In addition, our paper
provides an empirical evaluation of the use and usefulness of the approaches and covers a
larger set of approaches.
In comparison to the process architecture framework that is presented in this paper, there
exist other process architecture frameworks as well as enterprise architecture frameworks.
Existing process architecture frameworks are included in the literature review that is
presented in Section 3. While not every process architecture design approach includes a
framework, many do (Scheer and Nüttgens 2000; Fettke, Loos, and Zwicker 2006; Joosten
et al. 2002; Aitken, Stephenson, and Brinkworth 2010; Aronson 2008). These existing
frameworks use a specific type of approach (goal-based, action-based, object-based, refer-
ence model-based or function-based) or in rare cases a combination of two types of
approaches. In that respect, the framework presented in this paper is more generic.
Enterprise architecture frameworks and design approaches address the design and
subsequent use of an enterprise architecture, which is a description of the components of
the enterprise and their interrelationships. Depending on the approach that is used, business
processes may be included. For example, The Open Group Architecture Framework
(TOGAF) (The Open Group 2009), Zachman (1987) and DYA (Wagter et al. 2001) consider
business processes as part of an enterprise architecture. Although, an enterprise architecture
approach’s ability to address the relation between a business process and other components
of enterprise architecture (such as business goals or functions) would help design a business
process architecture, enterprise architecture approaches do not primarily aim to assist in the
design of a business process architecture. In that respect enterprise architecture frameworks
and design approaches differ from the framework that is presented in this paper. Enterprise
modelling languages can be used (possibly in combination with an enterprise architecture
approach) to graphically represent an enterprise architecture and, consequently, a business
 26 R. Dijkman et al.

process architecture. The distinction between an enterprise modelling language and an

enterprise architecture is not strict. Sometimes enterprise architecture approaches come
with an enterprise modelling language (e.g. ARIS (Scheer and Nüttgens 2000)) and some-
times enterprise architecture approaches are closely related to an enterprise modelling
language (e.g. TOGAF (The Open Group 2009) is closely related to ArchiMate
(Lankhorst 2005)). We use the distinction here to discuss enterprise architecture design
approaches and graphical means to represent the results. An enterprise modelling language
can be used to represent business processes, their relations and their relations to other
concepts. Consequently they can help with, but are not primarily focused on, the design of a
business process architecture.
An area that is related to business process architecture is that of service-oriented
architecture, in which processes are typically expressed as service orchestrations or
service choreographies. However, the design of a service-oriented architecture is typically
Downloaded by [Anadolu University] at 08:52 28 December 2014

considered from a more technological perspective.

8. Conclusion
In this paper, we provided an overview of the current approaches to design a business
process architecture. We identified five different classes of approaches from the literature:
(i) goal-based; (ii) action-based; (iii) object-based; (iv) reference model-based; and (v)
function-based approaches. By means of an exploratory survey that involved 39 practi-
tioners, we explored the actual use and perceived usefulness of the various approaches.
Surprisingly, a hybrid combination of guidelines turned out to be the most popular among
our respondents. To study the characteristics of real-life process architectures in more
detail, we examined four cases across different goals and industry sectors. Based on their
organising concepts and coverage of relations, we proposed a process architecture frame-
work that can be used to support the development of a concrete process architecture.
The unique contribution of our work is that it proposes a concrete approach to design
a process architecture based on both a theoretical and an empirical understanding of the
topic. A solid theoretical basis is provided by an extensive literature study, while an
empirical understanding is provided by an exploratory survey and case studies.
Both the exploratory survey and the case studies suggest that a business process
architecture should combine different structuring approaches, where the function-based
and object-based structuring approaches appear to be the most useful. The practical
evaluations disagree on the usefulness of a reference model as structuring principle,
because it is judged as one of the most useful approaches in the survey, while it does
not appear in the case studies. The case study-based evaluation further suggests that
decomposition of processes in multiple dimensions should be possible in a business
process architecture and that processes should be as generalisable as possible. The
proposed framework is designed based on the theoretical finding and accommodating
for these features derived from the practical evaluations.
Our findings should be seen against a number of limitations. First, the research should
be seen as exploratory and, therefore, the conclusions that are drawn from it should be
used with the necessary caution. While the conclusions are based on literature and
exploratory empirical work, they remain to be validated more rigorously. In particular,
while the coverage of the different types of approaches through our classification can be
considered as fairly inclusive, this is certainly not the case for the empirical evaluation.
The fact that the respondents of the survey were all Dutch is a risk to the external validity
of the results. However, there is reason to assume that our findings for a Dutch sample
 Enterprise Information Systems 27

also hold for other Western populations. In particular, because we see that there is no
strong preference for one particular approach to business process architecture. If this
already holds for a relatively small community of Dutch business process experts, many
of whom know each other and are taught by the same lecturers or consultants, it is likely
that it also holds for larger and less-connected communities. While it would be interesting
to repeat the survey in a broader (geographical) context, we do not expect that this will
lead to new insights. The survey-based evaluation of the existing approaches can be
considered as rather high-level and context-free. To some extent, this limitation is
addressed by the in-depth case studies we carried out, which specifically dealt with the
particular goal behind the development of a process architecture and its industrial context.
Finally, the results presented in this paper and the use of process architecture approaches
in general can be considered to be primarily of interest to large organisations, with a large
number of processes (i.e. more than 100). This is also illustrated by the fact that the
Downloaded by [Anadolu University] at 08:52 28 December 2014

respondents of the survey were mainly (77%) from large organisations. Apparently, small
organisations did not consider the topic to be of interest.
Taking the noted limitations into account, we identify a clear match between our
contribution and the interest in approaches to design business process architectures among
practitioners. However, as the research presented in this paper is exploratory in nature, a
first direction for future work should be further testing and validating of the use and
usefulness of the guidelines, as well as applying, validating and refining the proposed
framework in practice. An attractive way to go forward would be to carry out field
experiments that aim to investigate whether the proposed framework helps design an
industrially useful process architecture in an efficient way. Another venue is the devel-
opment of tool support to ease the framework's application and tie instances of process
architectures to actual process model collections.
The guidelines for business process architecture design that are presented in this paper
are only presented to get a more detailed understanding of the business process architec-
ture design approaches themselves. However, developing guidelines for business process
architecture design is an interesting research topic in its own right. Especially considering
that an important conclusion of this paper is that practitioners compose their own design
approach with guidelines from different approaches. Of particular interest are guidelines
that define the level of detail or aggregation at which a business process in a business
process architecture should be described.
While we aim to present an exhaustive account of the business process architecture
design approaches that exist in the literature, it should be noted that there might exist
business process architecture design approaches that are not covered in the literature and,
therefore, not included in this study. Of particular interest is a service-oriented approach to
business process architecture design, because the absence of such an approach was also
mentioned in the survey. The development of a service-oriented approach to business
process architecture design is therefore a possible topic for future work.

Notes
1. See http://bit.ly/fBnfzI, Accessed January 31, 2014.
2. http://bpmroundtable.nl/
 28 R. Dijkman et al.

References
Aitken, C., C. Stephenson, and R. Brinkworth. 2010. “Process Classification Frameworks.” In
Handbook on Business Process Management, Vol. 2, edited by J. vom Brocke and M.
Rosemann, 73–92. Berlin: Springer.
Antón, A., W. McCracken, and C. Potts. 1994. “Goal Decomposition and Scenario Analysis in
Business Process Reengineering.” In Proceedings of CAiSE, Utrecht, 94–104.
APQC. 2011. APQC Process Classification Framework (PCF), Version 5.2.0. Technical report.
Houston, TX: APQC.
Aronson, B. 2008. Enterprise Designer – Building a Conscious Organization. Raleigh, NC: Lulu.
Auramäki, E., E. Lehtinen, and K. Lyytinen. 1988. “A Speech-Act-Based Office Modeling
Approach.” ACM Transactions on Information Systems 6: 126–152.
Chui, M., J. Manyika, J. Bughin, B. Brown, R. Roberts, J. Danielson, and S. Gupta. 2013. Ten IT-
Enabled Business Trends for the Decade Ahead: Updated Research. McKinsey Global Institute.
Curran, T., and G. Keller. 1999. SAP R/3 Business Blueprint. Bonn, Germany: Addison-Wesley.
Damij, N., and T. Damij. 2009. “Business Process Identification Technique.” In Proceedings of
Conference on Cooperation and Promotion of Information Resources in Science and
Downloaded by [Anadolu University] at 08:52 28 December 2014

Technology, Beijing, 31–34. IEEE.

Dietz, J. L. G. 2006. “The Deep Structure of Business Processes.” Communications of the ACM 49:
59–64.
Eertink, H., W. Janssen, P. Oude Luttighuis, W. Teeuw, and C. Vissers. 1999. “A Business Process
Design Language.” In Proceedings of FM, Toulouse, 76–95.
Eisenhardt, K. M. 1989. “Building Theories from Case Study Research.” The Academy of
Management Review 14 (4): 532–550.
Fettke, P., P. Loos, and J. Zwicker. 2006. “Business Process Reference Models: Survey and
Classification.” In BPM Workshops, Vienna, 469–483.
Green, S., and M. Ould. 2004. “The Primacy of Process Architecture.” In CAiSE Workshops (2),
Riga, 154–159.
Green, S., and M. Ould. 2005. “A Framework for Classifying and Evaluating Process Architecture
Methods.” Software Process: Improvement and Practice 10 (4): 415–425.
Huschens, J., and M. Rumpold-Preining. 2006. “IBM Insurance Application Architecture (IAA) –
An Overview of the Insurance Business Architecture.” In Handbook on Architectures of
Information Systems, edited by P. Bernus, K. Mertins, and G. Schmidt, 669–692. Berlin/
Heidelberg: Springer.
Indulska, M., J. Recker, M. Rosemann, and P. Green. 2009. “Business Process Modeling: Current
Issues and Future Challenges.” In Proceedings of Conference on Advanced Information Systems
Engineering, Amsterdam, 501–514. Springer.
Johannesson, P. 1995. “Representation and Communication – A Speech Act Based Approach to
Information Systems Design.” Information Systems 20: 291–303.
Joosten, S. 2000. “Why Modellers Wreck Workflow Innovations.” In Proceedings of BPM, 119–131.
Joosten, S., E. Baardman, J. van Beek, W. Borneman, R. Dijkman, M. de Mol, M. Koopmans, et al.
2002. Praktijkboek Voor Procesarchitecten. Assen, The Netherlands: Koninklijke van Gorcum
B.V.
Kavakli, E., and P. Loucopoulos. 1998. “Goal-Driven Business Process Analysis – Application in
Electricity Deregulation.” In Proceedings of CAiSE, Pisa, 305–324.
Koliadis, G., A. Ghose, and S. Padmanabhuni. 2008. “Towards an Enterprise Business Process
Architecture Standard.” In IEEE Congress on Services, Hawaii, 239–246. IEEE.
Koubarakis, M., and D. Plexousakis. 2002. “A Formal Framework for Business Process Modelling
and Design.” Information Systems 27: 299–319.
Kwaliteits Instituut Nederlandse Gemeenten (KING). 2011. GEMMA Process Architecture, 2.0. [In
Dutch] Technical Report, Den Haag, The Netherlands.
Lankhorst, M. E. A. 2005. Enterprise Architecture at Work – Modelling, Communication and
Analysis. Berlin: Springer.
Lee, J. 1993. “Goal-Based Process Analysis: A Method for Systematic Process Redesign.” In
Conference on Organizational Computing Systems, Milpitas, CA, 196–201. ACM.
Lind, M. 1997. “Reconstruction of Different Business Processes – A Theory and Method Driven
Analysis.” In Workshop on Communication Modelling, Veldhoven, 87–104.
Lind, M., and G. Goldkuhl. 2003. “The Constituents of Business Interaction – Generic Layered
Patterns.” Data and Knowledge Engineering 47 (3): 327–348.
 Enterprise Information Systems 29

Lunn, K., A. Sixsmith, A. Lindsay, and M. Vaarama. 2003. “Traceability in Requirements through
Process Modelling, Applied to Social Care Applications”. Information and Software Technology
45 (15): 1045–1052.
Maes, A., and G. Poels. 2007. “Evaluating Quality of Conceptual Modelling Scripts Based on User
Perceptions.” Data & Knowledge Engineering 63 (3): 701–724.
Malone, T. W., K. Crowston, J. Lee, B. Pentland, C. Dellarocas, G. Wyner, J. Quimby, et al. 1999.
“Tools for Inventing Organizations: Toward a Handbook of Organizational Processes.”
Management Science 45: 425–443.
Medina-Mora, R., T. Winograd, R. Flores, and F. Flores. 1992. “The Action Workflow Approach to
Workflow Management Technology.” In Conference on CSCW, Toronto, ON, 281–288. ACM.
The Open Group. 2009. The Open Group Architecture Framework, Version 9. Technical report, The
Open Group.
Porter, M. E. 1985. Competitive Advantage. New York: The Free Press.
Runeson, P., and M. Höst. 2009. “Guidelines for Conducting and Reporting Case Study Research in
Software Engineering.” Empirical Software Engineering 14 (2): 131–164.
Scheer, A. W., and M. Nüttgens. 2000. “ARIS Architecture and Reference Models for Business
Downloaded by [Anadolu University] at 08:52 28 December 2014

Process Management.” In Business Process Management, Models, Techniques, and Empirical

Studies, edited by W. M. P. van der Aalst, J. Desel, and A. Oberweis, 376–389. Berlin: Springer.
SDU Information Solutions. 2013. Documentair Structuurplan [online]. Amsterdam, The
Netherlands: SDU Information Solutions. Accessed August 14, 2013. http://www.model-dsp.nl/
Wagter, R., M. J. B. K. van den Berg, J. Luijpers, and M. E. van Steenbergen. 2001. DYA: Speed
and Cohesion in Business and ICT Architecture. [In Dutch.] Den Bosch: Tutein Nolthenius..
Yu, E., and J. Mylopoulos. 1994. “Using Goals, Rules, and Methods to Support Reasoning in
Business Process Reengineering.” Proceedings of HICSS 4: 234–243.
Zachman, J. 1987. “A Framework for Information Systems Architecture.” IBM Systems Journal 26:
276–292.
 30 R. Dijkman et al.

Appendix 1.

Structured literature review protocol

Review step Procedure

Primary search Automated search using Google Scholar Terms used:

• ‘business process architecture’
• ‘business process identification’
• ‘business process delimitation’
• ‘business process demarcation’
• ‘business process architecture’
Investigated first five pages of results.
104 papers found.
Downloaded by [Anadolu University] at 08:52 28 December 2014

Primary selection Select papers based on title and abstract.

Inclusion criterion:
Paper describes approach for architecture design.
15 papers selected.
Secondary selection Scan references and citations in 15 selected papers.
Select papers based on title.
Inclusion criterion: as above.
30 additional papers selected.
Search verification Automated search using: Scopus, Web of Science, Inspec,
IEEE-IET, ACM-DL
Terms used: as above.
102 papers found.
Select papers based on title and abstract.
Inclusion criterion: as above.
Two additional papers selected.
Scan references and citations in two selected papers.
Select papers based on title.
Inclusion criterion: as above.
One additional paper selected.
Data extraction and Extract:
analysis • basis for identifying processes and process relations in the
architecture.
• concepts used for organising processes in the architecture.
• types of relations identified between these concepts.
• relation between concept structure and process architecture.