TOWARDS INTEGRATING PERSPECTIVES AND ABSTRACTION
LEVELS IN BUSINESS PROCESS MODELING
Ivan Markovic and Florian Hasibether
SAP Research CEC Karlsruhe, Vincenz-Priessnitz-Str. 1, 76131 Karlsruhe
Keywords:
Business process modeling, Business ontologies.
Abstract:
In process-driven organizations, process models are the basis on which their supporting process-aware infor-
mation systems are built. In this paper, we propose an approach for integrating perspectives and abstraction
levels in business process modeling. First, we propose six process perspectives to adequately organize infor-
mation about a business process. Second, we present the abstraction levels in process modeling and discuss
metamodel projections on each of the levels. Third, we provide a comparison of our approach to other efforts
in the field. With our approach, we make a step towards reducing the complexity of process modeling.
1 INTRODUCTION
In the 1990s, the vision of a process enterprise was
introduced (Hammer and Champy, 1993) to achieve a
holistic view on an enterprise, with business processes
as the main instrument for organizing the operations
of an enterprise (Weske, 2007). Benefits of investing
in business process techniques were demonstrated in
efficiency, increased transparency, productivity, cost
reduction, quality, faster results, standardization, and,
above all, in the encouragement of innovation, lead-
ing to competitive advantage and client satisfaction
(Chang, 2005).
Process orientation considered IT as a key enabler
and thus followed with the introduction of process-
aware information systems (PAIS) (Dumas et al.,
2005) as means to support the knowledge workers in
performing business processes. PAIS are driven by
explicit process models, which enable a better under-
standing of business processes, facilitate communi-
cation between business analysts and IT experts and
serve as a basis for the management and execution of
business processes.
Several issues contributed to the fact that the de-
sign of process models is still a complex task. First, a
broad knowledge must be taken into account when de-
signing a process model. This knowledge is scattered
in various business documents, presentations and the
heads of business people, making it difficult to access
and reuse. Second, process modeling approaches do
not adequately support process perspectives (e.g. mo-
tivational, resource, functional, etc.). One of the ways
to reduce modeling complexity is to provide sepa-
rate process modeling perspectives which allow the
modeler to model only the desired aspect of the pro-
cess. Similar approaches can be found in software
design (Nuseibeh et al., 1994). This way of organiz-
ing and modeling of process information is more intu-
itive, easier to understand, analyze and later navigate
the process landscape based on defined perspectives.
Third, there is no support for “abstraction levels” -
enabling different stakeholders to have their view on
a process model by filtering out irrelevant informa-
tion depending on their role. For example, an ex-
ecutive might want to see how does the process re-
late to enterprise goals and strategies, what are its
key performance indicators (KPI) and how well is it
performing. He would not be interested in detailed
process flow, information systems supporting the pro-
cess, business objects manipulated by the process, etc.
Similarly, a line of business manager might be primar-
ily interested in how a particular process contributes
to a broader business scenario, who is responsible for
it and who is involved. Existing modeling tools for
different stakeholders are often not based on a holis-
tic, unified metamodel which brings many problems
with respect to information integration, redundancies,
traceability and communication between different ab-
straction levels.
On the other hand, Semantic Web (SW) technolo-
gies (Hepp et al., 2005) have shown potential in inte-
grating the knowledge coming from various sources
by means of ontologies (Uschold and Gruninger,
1996). In addition, SW provides concepts and tools
286
Markovic I. and Hasibether F. (2009).
TOWARDS INTEGRATING PERSPECTIVES AND ABSTRACTION LEVELS IN BUSINESS PROCESS MODELING.
In Proceedings of the 11th International Conference on Enterprise Information Systems - Information Systems Analysis and Specification, pages
286-291
DOI: 10.5220/0002017502860291
Copyright
c
SciTePress
for automated inference on the represented knowl-
edge, which enables the provision of additional ser-
vices based on existing process knowledge.
In order to address the listed issues, we present
an approach for integrating perspectives (Section 2)
and abstraction levels (Section 3) in process model-
ing, supported by ontologies. We compare our ap-
proach to other efforts in the area in Section 4 and
summarize our contributions in Section 5.
2 PROCESS PERSPECTIVES
Following (Curtis et al., 1992; Weske, 2007), we de-
fine six key perspectives to adequately organize infor-
mation about a business process. We visualize them in
figure 1, motivated by the “orthographic projection”
paradigm used in mechanical and civil engineering
to create detailed drawings of physical objects. The
main idea is to enable the process modeler to eas-
ily manage and navigate the various perspectives in
process design. In the following, we shortly describe
each of them.
Functional perspective provides a functional
breakdown of activities that an enterprise performs.
Starting from high-level business functions (value
chain), the coarse-grained functions are broken down
into finer-grained functional units by means of func-
tional decomposition. Functional decomposition has
proven to be an important concept for capturing and
managing complexity (Weske, 2007).
Motivational perspective is inspired by the recent
OMG specification, the Business Motivation Model
(BMM) (OMG, 2008). The notion of motivation is
important for business processes because an enter-
prise should be able to say why it executes a particular
process. This perspective is divided in two segments:
intentional and directional.
The intentional segment captures the enterprise
aspirations - the things it wishes to achieve, i.e. goals.
Every business process exists for the purpose of
achieving some goal, which should be made explicit.
When formulating a process goal it is useful to al-
ready think about quantifiable results. The way to do
this is to define appropriate KPIs along e.g. the dimen-
sions time, cost or quality that measure the process.
The directional segment describes the things that
the enterprise will employ to achieve its goals,
i.e. strategies, business policies and rules. A strategy
shapes the way in reaching a goal, i.e. it channels ef-
forts towards a goal. Business policies and rules con-
trol, guide and shape strategies. With respect to pro-
cesses, it is important to know how a particular busi-
ness process fits into the overall strategy (plan) and
Behavioural perspective
Technology
O
bjects
M
edia
Process
Flow
Or
g. Units
Process
Owner
Roles
P
ro
cess
Compliance
Business
Functions
Process
Activities
Goals
Rules
Strategy
K
ey Per
f
ormance
Indicat
ors
P
o
licies
Motivational
perspective
Fu
nctional per
spective
Or
g
anizat
i
onal perspective
Compli
ance perspective
Resource perspective
Figure 1: Process perspectives.
what policies and rules guide (affect) its execution.
Organizational perspective represents by whom
(roles and organizational units) activities are per-
formed. We depict it in figure 1 by a grouping un-
der the label of stakeholders, encompassing organiza-
tional units, roles and process owners. It is important
to stress that processes run across one or more orga-
nizational units within a functional or divisional hi-
erarchy. A role is defined as task and responsibility
bundle which is clearly distinguished from the per-
son that is performing the role. It can be held by dif-
ferent persons and one person can hold several roles.
Talking about roles and processes allows to easily talk
about the tasks that should belong together or should
be separated from a process perspective before map-
ping them to the organizational structure. The process
owner as an accountable manager for the process end-
to-end execution can be seen as a special role.
Resource perspective describes applications and
resources that should be spent when carrying out cer-
tain process activities (e.g. objects, IT systems, or re-
sources needed in order to accomplish the activity)
or that may be results of certain activities. As pro-
cesses essentially are transformations that manipulate
objects (e.g. create, change or delete) it is relevant to
capture information on these and the states they take
on during transformation. Technology acts as an en-
abler for certain steps in the process. In a tight con-
TOWARDS INTEGRATING PERSPECTIVES AND ABSTRACTION LEVELS IN BUSINESS PROCESS MODELING
287
Manager
Executive
Business Analyst
Process
Process
Flow
Business
Rules
Compliance
Purpose &
Goal
Strategy
Resources
Objects
Technology
Media
Key
Performance
Indicators
Stakeholders
Process
Owner
Roles
Organizational
Units
Process
Purpose
& Goal
Resources
KPI
Stakeholders
Process
Owner
Roles
Process
Flow
Compli-
ance
Process
Purpose &
Goal
Strategy
Resources
Compli-
ance
KPI
Stake-
holders
Process
Process Flow
Business
Rules
Purpose
& Goal
Resources
Media
Objects
Techno-
logy
Stake-
holders
Roles
Org.
Units
Additional levels
are possible
Additional levels
are possible
Figure 2: Projections of the metamodel.
nection to objects and data are the media used in a
process.
Compliance perspective represents compliance
requirements within process models. Compliance is
of high importance to nowadays businesses. Compli-
ance regulations especially impact processes as spe-
cific tasks in processes are required in order to fulfill
regulatory requirements. Thus, in process design it is
important to capture and incorporate these tasks.
Behavioral perspective captures process control
flow. It represents the logical ordering of process ac-
tivities and their causal interrelationships. This per-
spective could be seen as the core of a process rep-
resentation and acts as a connection point (Weske,
2007) for the other perspectives.
The authors have presented a process-oriented en-
terprise ontology framework which formally captures
all of the aforementioned perspectives (Markovic
et al., 2009; Markovic and Kowalkiewicz, 2008). Us-
ing the specified relations between the perspectives,
the process modeler can navigate through different
aspects of a process representation and the process
space of an enterprise. Queries such as “What re-
sources are used by process a?”, “What is the goal
of process b?”, “Which processes does the org. unit
c participate in?”, “What processes are currently per-
formed in business function d?”, can be answered us-
ing this ontology framework (Markovic, 2008).
3 ABSTRACTION LEVELS IN
PROCESS MODELING
In this section we discuss abstraction levels in more
detail and motivate why they are important in the con-
text of process modeling.
Executive (Strategic) Level. Here the enterprise
goals and the general strategic direction are set. Key
performance indicators are determined for measuring
the progress in achieving goals. Business policies are
defined in order to govern the enterprise courses of ac-
tion. Typical artifacts on this level may include goal
specifications, strategy documents and policy guide-
lines (cf. fig. 2, left). Artifacts on this level of abstrac-
tion provide the motivation (“why”) for the processes
within the organization, which are defined on further
levels. The modeling techniques are rather informal
or ad-hoc (flip chart techniques or mind maps).
Line of Business manager Level. Based on the
artifacts produced at the executive level, line of busi-
ness managers need to provide quick and intuitive
overview of the business processes of an organiza-
tion. The aim is to depict processes from a high-level
perspective with a focus on understanding key points
of the process. These high-level processes are called
business scenarios and each of them represents a set
of logically related processes performed to achieve
defined and measurable business goals. Models such
as Value Added Chain Diagrams (Porter, 1985) and
SAP Business Scenarios
1
are used for this purpose.
Business Analyst Level. Unlike the other two
perspectives, the business analyst faces a variety of
purposes in modeling. This includes business pro-
cess documentation, process improvement, system re-
quirements specification, etc. Process models cre-
ated at this level detail each of the business scenar-
ios specified and serve as a starting point for the un-
derlying information system implementation (cf. fig.
1
SAP Business Scenarios are delivered with the
SAP Solution Composer, a modeling tool provided by
SAP. http://www.sap.com/solutions/businessmaps/
composer/index.epx
ICEIS 2009 - International Conference on Enterprise Information Systems
288
2, right). There are numerous modeling techniques
(EPC (Keller et al., 1992), BPMN
2
, UML Activity
Diagrams) used in this space.
A major problem today is that the artifacts pro-
duced on each of the abstraction levels are not inter-
connected and integrated. This causes problems in
communication, inconsistencies, redundancies, trace-
ability between the levels and results in a significant
amount of manual work. We argue that the aforemen-
tioned process-oriented enterprise ontology frame-
work can serve as a common metamodel for all ab-
straction levels, as shown in fig. 2. Using metamodel
projection, abstraction level-specific models can be
derived (cf. fig. 2).
We can think of the process-centric knowledge de-
picted in fig. 2 (center) as being present on each level
of abstraction in smaller or greater detail. Parts of this
knowledge tend to grow stronger as we move down
the abstraction levels, e.g. process flow. Of course,
high level knowledge such as strategic goals and core
strategy plans do not vanish as we reach a level of
higher detail. They get refined and superimposed by
a more concrete view. Strategic goals grow to measur-
able and timed operational goals, strategic directions
to detailed plans, etc. For example, the executive ab-
straction level would encompass strongly concepts re-
lated to the motivational perspective (goals, strategy,
KPIs, etc.), while it would not be interested in de-
tailed process flow, information systems supporting
the process or business objects (cf. fig. 2, left). The
metamodel can be reduced (configured) to the execu-
tive level-specific needs and a new model is generated
by metamodel projection.
Using this approach we are also able to derive
abstraction-level specific models for the line of busi-
ness manager and business analyst levels. By having
a unified metamodel, the artifacts created in particu-
lar abstraction levels can be more easily traced and
navigated.
4 FEATURE COMPARISON WITH
COMMON METHODS
Sections 2 and 3 motivated different viewpoints that
business process modeling is concerned with. In
this section we build upon these descriptions and de-
fine criteria for a comparison with common modeling
methodologies, both from academia and industry.
2
http://www.bpmn.org
4.1 Criteria for Comparison
First, we are interested in which part of the process-
knowledge (cf. fig. 1) is covered by the various ap-
proaches. We refer to this criterion as (1) process
perspectives. Section 3 introduced the notion of dif-
ferent (2) levels of abstraction bound to typical roles
in process engineering. Therefore, we secondly in-
vestigate what viewpoints a methodology supports.
Thirdly we deal with what kind of models are pro-
duced, i.e. (3) modeling business knowledge. The last
two criteria discuss the abilities of a methodology to
work with the captured knowledge. Under (4) query-
ing/reuse we ask for what possibilities exist to retrieve
the modeled information, while (5) analysis/inference
asks for: What can be deduced and is not explicitly
modeled? How could weaknesses be detected?
To date there is no predominant modeling ap-
proach for neither enterprise modeling, nor business
process modeling. To give a brief survey on the abil-
ities of today’s modeling techniques we selected the
following, illustrating the broad spectrum of enter-
prise modeling: ARIS (Scheer, 1988), BMM (OMG,
2008), i* (Yu, 1995), TOVE (Fox, 1992).
4.2 Comparative Description
i* framework The i* framework originates from
“early requirements” research and is used to under-
stand organizational processes, in terms of strategic
relationships and goals in order to elicitate the ratio-
nale for software requirements. Since i* is based on
intentionality, the concept of an actor, i.e. any active
entity, is central. The core work for i* (Yu, 1995) pro-
poses two types of diagrams, capturing the strategic
dependency relationships among actors (SD model)
and the strategic rationale model for expressing the
rationale behind dependencies (SR model). Using SD
and SR models, i* provides two levels of granularity:
The former focusing on the relation between actors,
using dependency links and actor aggregations. The
latter connects hard goals to tasks and softgoals (non-
functional goals) to contributing entities, thereby cap-
turing the agent’s intentions and abilities.
i* has been extended by a number of research ef-
forts
3
. A formal description for i* has been proposed,
using temporal logic and model checking for anal-
ysis (Fuxman et al., 2004). The approach can de-
tect self-contradictory specifications, over- and under-
specification using a graphical modeling tool
4
with a
model checker interface. To check the satisfiability of
3
http://www.troposproject.org/
4
http://www.dit.unitn.it/
˜
ft
TOWARDS INTEGRATING PERSPECTIVES AND ABSTRACTION LEVELS IN BUSINESS PROCESS MODELING
289
i*-like goal models, label propagation techniques and
a SAT solvers are applied (Sebastiani et al., 2004).
The i* framework captures mainly information for
the motivational perspective (cf. fig. 1). Although the
concept of goal and softgoals is rather detailed, there
is no concept of strategy or functional decomposition.
Resources and tasks stay on an abstract level. Since
the notion of actors is fairly general it provides no
specific means for modeling organizational structures.
Although tasks are important elements of SR model-
ing, there is no sequential connection between them.
The absence of policies/rules and performance indi-
cators underline, that enterprise modeling is not the
main goal of the i* approach. A number of tools are
provided by the i* community
56
. However, none of
those is capable of querying parts of the model.
BMM The Business Motivation Model is an
OMG standard accepted in 2006 (OMG, 2008).
While i* stems from software requirements research,
BMM has its roots in the business rules community.
Central to BMM is the distinction between means,
ends, directives, assessments and influencers.The
ends state, what the business wants to accomplish, not
how. Means are concerned with how the business in-
tends to accomplish its stated ends. Rules and poli-
cies that constrain and/or govern the available means
are called directives. Influencers capture, who or what
from within or outside the company influences its ac-
tivities. Assessments judge the impact of influencers
and provide impetus for directives. Each of these cat-
egories are further refined, with vision as a high level
statement of a state to reach made operative by some
mission. A desired result is either a goal (strategic)
or an objective (quantified and therefore operational).
Strategies are more general while tactics are more
specific courses of action. Within directives, business
policies are the basis for business rules. OMG sees
BMM as a blueprint for business planning which is
neutral in respect to methodology. It is not a com-
plete business model, nor is it intended to be one, but
should be supplemented by other standards such as
BPMN and UML and thus deals mainly with the mo-
tivational perspective given in fig. 1.
Xactium
7
had BizModeler as the first prototypic
tool supporting BMM. It allowed for drawing of Mo-
tivation Models from different perspectives using a
subset of the modeling elements in each of them.
The tool provided basic modeling aids regarding valid
linkage of elements. Large models could be searched
via string matching. Like BizModeler, KnowGrav-
5
http://www.cs.toronto.edu/km/ome/
6
http://www.cs.toronto.edu/km/openome/
7
http://www.xactium.com
ity’s KnowEnterprise
8
mainly focuses on implement-
ing the specifications in terms of model visualization.
Due to the lack of formality there are limited means
for analysis or inference on BMM models so far.
ARIS The ARchitecture of Integrated In-
formation Systems” is a mature, industry-adopted
method for business modeling. To deal with com-
plexity, the so called ARIS house describes differ-
ent views on processes: Organization view: Who
(e.g. organizations, departments, roles) is involved in
the process? Function view: Which functions are
carried out? Data view: Which objects represented
by data are manipulated? Output/Input view: Which
products or services are produced or consumed? Con-
trol view: How do the views mentioned before inter-
operate in a process? (Exeler and Wilms, 2003)
The functional view deals with hierarchical de-
compositions of business functions. A connection be-
tween the former and goal decomposition diagrams
is given in (Scheer, 1999). The organizational view
operates on organization charts. Data objects can be
modeled using Entity-Relationship-Diagrams. Prod-
uct models, either as a decomposition of different
types of product or as parts decomposition are sug-
gested in (Scheer, 1999) for the Output view. Event-
driven process chains (EPC) link the other views to-
gether within the control flow. The initial notation
(Keller et al., 1992) was later updated to extended
EPCs by adding elements for roles, objectives, tech-
nical terms, organizational units, and others. ARIS
adopts Value Chain Diagrams (Porter, 1985) as a
means of modeling high level processes. Although
VCD capture functions which directly create corpo-
rate output, neither them, nor the an EPC flow model
with additional goals elements do capture the entire
motivational perspective (cf. fig. 1). The toolset grad-
ually evolved to several platforms for various model-
ing tasks. It was recently completed by an strategy
approach making use of cause-and-effect diagrams
and KPIs. The designer tool can filter modeling ele-
ments of a selected model type and provides capabil-
ities to generate reports from the process perspective.
Since all modeled elements are stored in a relational
database it allows for querying model elements and
their related objects (Davis and Brab
¨
ander, 2007).
TOVE Parallel to the early days of BPM in the
area of information systems, organizational modeling
was approached from knowledge management com-
munities. One of the earliest efforts aiming at the de-
velopment of an organizational ontology is the TOVE
initiative (Fox, 1992). It aims at creation of a shared
representation of the enterprise, definition of seman-
tics, development of a set of axioms in order to pro-
8
http://www.knowgravity.com
ICEIS 2009 - International Conference on Enterprise Information Systems
290
vide automatic deduction capabilities and finally def-
inition of symbols depicting defined concepts. The
ontology underwent a large evolution and the current
versions are focused on multidimensional enterprise
modeling, and was converted into a set of tightly con-
nected sub-ontologies (Fox and Gruninger, 1998) de-
scribing many aspects and different aims. Although
the approach knows the concept of roles within the
enterprise model, it does not provide different levels
of abstraction for its usage. The model of the en-
terprise created in this approach, namely Common
Sense Model of Enterprise, distinguishes three lev-
els: a reference model with typical business functions
(finances, sales, ...), i.e. the functional perspective, a
generic model (concepts such as time, causality,...),
and a concept model (e.g. role, property, structure),
covering the organizational perspective. The behav-
ioral perspective is formally described using the situ-
ation calculus. Although rich axiomatization is given,
the lack of a contemporary ontology language the pro-
posed concepts are expressed in, is a drawback. Tool
support is another weak point.
5 CONCLUSIONS & OUTLOOK
In this paper, we proposed an approach for integrating
process perspectives and abstraction levels in business
process modeling. We defined the perspectives neces-
sary to capture and organize information about a pro-
cess. Further, we presented different abstraction lev-
els in process modeling. We use a process-oriented
enterprise ontology framework to formally represent
all process perspectives and enable abstraction level-
specific process modeling views by means of meta-
model projection. Lastly, we provide a comparison of
our approach to influential work in the field. By en-
abling the possibility to create abstraction level- and
perspective-specific views, we reduce the complexity
of process model design. In addition, using the formal
process representation we can perform querying and
automated inference on business process models.
We are currently working on tool-supported gen-
eration of a perspective and abstraction level-specific
modeling editor using the process-oriented enterprise
ontology framework.
REFERENCES
Chang, J. (2005). Business Process Management Systems:
Strategy and Implementation. Auerbach Publication.
Curtis, B., Kellner, M., and Over, J. (1992). Process model-
ing. Commun. ACM, 35(9):75–90.
Davis, R. and Brab
¨
ander, E. (2007). ARIS Design Platform.
Springer.
Dumas, M., van der Aalst, W., and ter Hofstede, A. (2005).
Process-Aware Information Systems. Wiley.
Exeler, S. and Wilms, S. (2003). Change management with
ARIS. In Bus. Proc. Change Management. Springer.
Fox, M. (1992). The TOVE project: A common-sense
model of the enterprise. In Proc. IEA/AIE Conf.
Fox, M. and Gruninger, M. (1998). Enterprise modelling.
AI Magazine, 19:109–121.
Fuxman, A., Liu, L., Mylopoulos, J., Roveri, M., and
Traverso, P. (2004). Specifying and analyzing early
requirements in Tropos. Req. Eng., 9(2):132–150.
Hammer, M. and Champy, C. (1993). Reengineering the
Corporation. Harper Business.
Hepp, M., Leymann, F., Domingue, J., Wahler, A., and
Fensel, D. (2005). Semantic business process man-
agement. In IEEE Int. Conf. on e-Business Eng.
Keller, G., N
¨
uttgens, M., and Scheer, A.-W. (1992). Seman-
tische Prozemodellierung auf der Grundlage Ereignis-
gesteuerter Prozeketten. Tech.R., Uni. d. Saarlandes.
Markovic, I. (2008). Advanced querying and reasoning on
business process models. In Proc. BIS08.
Markovic, I., Hasibether, F., Jain, S., and Stojanovic, N.
(2009). Process-oriented semantic business modeling.
In Wirtschaftsinformatik.
Markovic, I. and Kowalkiewicz, M. (2008). Linking busi-
ness goals to process models in semantic business pro-
cess modeling. In 12th IEEE EDOC Conf.
Nuseibeh, B., Kramer, J., and Finkelstein, A. (1994). A
framework for expressing the relationships between
multiple views in requirements specification. IEEE
Trans. on Software Engineering, 20(10):760–773.
OMG (2008). Business Motivation Model v1.0. http://
www.omg.org/spec/BMM.
Porter, M. (1985). Competitive Advantage. The Free Press.
Scheer, A.-W. (1988). Wirtschaftsinformatik: Referenzmod-
elle f
¨
ur industrielle Gesch
¨
aftsprozesse. Springer.
Scheer, A.-W. (1999). ARIS. Business Process Modeling.
Springer.
Sebastiani, R., Giorgini, P., and Mylopoulos, J. (2004).
Simple and minimum-cost satisfiability for goal mod-
els. In Proc. CAiSE 2004.
Uschold, M. and Gruninger, M. (1996). Ontologies: Prin-
ciples, methods and applications. Know. Eng. Rev.,
11:93–155.
Weske, M. (2007). Business Process Management: Con-
cepts, Languages, Architectures. Springer.
Yu, E. (1995). Modelling Strategic Relationships for Pro-
cess Reengineering. PhD thesis, Univ. of Toronto.
TOWARDS INTEGRATING PERSPECTIVES AND ABSTRACTION LEVELS IN BUSINESS PROCESS MODELING
291