A Survey on the Flexibility Requirements Related to
Business Processes and Modeling Artifacts
Selmin Nurcan
1
,
2
1
Université Paris 1 Panthéon Sorbonne, Centre de Recherche en Informatique; 90, rue de Tolbiac 75634 Paris cedex 13 France
2
IAE de Paris Sorbonne Graduate Business School; 21, rue Broca 75005 Paris France
Selmin.Nurcan@univ-paris1.fr
Abstract
In competitive and evolving environments only
organizations which can manage complexity and can
respond to rapid change in an informed manner can gain a
competitive advantage During the early 90’s, workflow
technologies offered a transversal integration capacity to
the enterprise applications. Today, to “integrate” enterprise
applications -and the activities they support- into business
processes is not sufficient. The architecture of this
integration should also be flexible. Enterprise requirements
highlight flexible and adaptive processes whose execution
can evolve (i) according to situations that cannot always be
prescribed, and/or (ii) according to business changes
(organizational, process improvement, strategic …). More
recent works highlight requirements in term of flexible and
adaptive workflows, whose execution can evolve according
to situations that cannot always be prescribed. This paper
presents the state of the art for flexible business process
management systems and criteria for comparing them.
1. Introduction
Over the two last decades, market changes have led to
a business environment that is constantly evolving.
Companies change to better satisfy customer requirements,
improve internal processes and adapt their products and
services. At the same time, they also experienced the
effects of the integration and evolution of information and
communication technologies. Thus, IT and management
go hand by hand in the way of reacting, adapting and
implanting new ways of doing business. Companies need
(i) to integrate their new solutions with their legacy systems
in a global IT architecture and (ii) to orchestrate the
execution of their activities and the use of the supporting
technological solutions in an integrated environment. The
capacity of quick reaction of organizations is mainly due to
the ability of handling the support systems in favour of the
business evolution requirements.
The production of added value in business value chains
is highly dependent of the quality of their supporting
information systems and the effective strategic use of
information technologies. In all management challenges,
information systems (IS) should be continuously adapted
to changing business practices and needs. As a
consequence, information systems are becoming more and
more complex and shall be conceived in the wider
strategic context of organizations management. This can
be achieved by developing process-centric solutions. The
paradigm of Business Process Management stresses the
importance of integrating entire processes rather than
simply integrating data or applications. The aim is to
design and control the organizational structures in a very
flexible way so they can rapidly adapt to changing
environments. During the early 90’s, Workflow
Management Systems (WFMS) have been positioned as
appropriate technological solutions for integrating process
islands at a high level so that they can collaboratively
provide business solutions that each individual application
is unable to provide. However, the formalisms developed
for the specification of workflow definitions were –and
still largely are- almost systematically activity oriented.
Consequently, process definitions have the advantage to be
easily transformable in executable code but the
disadvantage of being prescriptive and rigid.
Flexibility has been the focus of many researches [42],
[44], [50], [52], [56]. There are many definitions of the
flexibility in literature [54]. It is defined in [42] as “the
ability to yield to change without disappearing”. We
consider the flexibility as the capacity of making a
compromise between, first, satisfying, rapidly and easily,
the business requirements in terms of adaptability when
organizational, functional and/or operational changes
occur; and, second, keeping effectiveness. Processes
flexibility means fast reactivity to internal and external
changes. It reflects the easiness to make evolve business
process schemes (when required). Flexibility is also
reflected by the ability that the support systems have to
take into account business changes.
The objective of the research in progress is to measure
the capacity of the modeling solutions provided in the
literature to represent the flexibility requirements of current
business processes being intra or inter organizations.
This paper is organized as follows: Section 2 presents a
survey on business process modeling, regarding modeling
perspectives, modeling formalisms and the commercial
offer. Section 3 proposes a state of the art for flexible
process modeling and controlling.
2. Business process modeling: a survey
Business processes (BPs) can be roughly classified into
two categories depending on their nature. The first
concerns well-defined and -often- repetitive processes
having important coordination and automation needs. The
second category concerns ill-defined processes. The
essential preoccupation with the latter is the information
and knowledge sharing between the actors implied in the
processes more than the coordination of their tasks.
Business processes of this category require evidently more
flexibility. For many organizations, well-defined and ill-
defined processes coexist and must be handled in the final
business model [40].
2.1. A classification of business process modeling
perspectives
Literature suggests that existing approaches to
enterprise knowledge modeling can be classified into two
categories. In the first category, an organization is
represented as a set of inter-related elements satisfying
common objectives. For instance, VSM [17] allows us to
model an organization as a set of viable sub-systems
representing respectively the operation, co-ordination,
control, intelligence and politics aspects of an
organization. The second category, Enterprise modeling,
refers to a collection of conceptual modeling techniques
for describing different facets of the organizational
domain including operational (information systems),
organizational (business processes, actors, roles, flow of
information etc), and teleological (purposes)
considerations [5], [13], [24], [39], [64]. Commercial
Workflow Models belong also to this category.
Business process
(BP) modeling usually combines three
basic views: (i) the functional view is expressed based on
Data Flow Diagrams [32]; (ii) the behavioral view focuses
on when and under which conditions activities are
performed; this view is described using state diagrams or
interaction diagrams [22]; and (iii) the structural view
focuses on static aspects of processes capturing the
manipulated objects [46].
Five perspectives were proposed in [58] and extended
in [12] with a sixth one: the intentional perspective. The
functional perspective characterizes the activities that have
to be performed during a process. The process perspective
characterizes the conditions to execute a process. The
organization perspective reflects information about the
organizational structure and actors to which the BP is
intended. The information perspective covers data handled
by BPs. The operation perspective describes elementary
operations performed by resources and applications. Last
but not least, the intentional perspective represents goals
and strategies that the enterprise implements in its
processes. A modeling approach does not necessarily offer
concepts to cover the six perspectives. For instance,
IDEF0 covers the functional perspective and touches
lightly on the information perspective [32]; IDEF1 covers
the information perspective and IDEF3 completes them
with the process one. To represent flexible processes, a
modeling solution has to provide a minimum set of
perspectives to represent the enterprise elements that are
potentially impacted by changes.
2.2. Modeling formalisms
Literature provides various process modeling
formalisms that we classify into four categories: activity
oriented, product oriented, decision oriented and
conversation oriented models. Each category has its
underlying paradigm that may be examined in terms of its
appropriateness to flexible process modeling.
Activity-oriented models allow us to prescribe a
process as a set of activities to be performed and their
relationships regarding pre-defined control and data flows
[22], [32]. Those formalisms are useful for representing
the functional view of BPs. Nevertheless, the linear view
of activity decomposition is inadequate for modeling ill-
defined BPs, particularly if the latter suffer frequent
changes and/or alternative choices are based on human
decisions instead of calculable arguments. Activity-
oriented models are still dominant in the literature. It is
stated in [4] that "in a process centered environment, a
process (model) plays the role of a program to be executed
in order to control and manage the process (instance)".
Many activity-oriented models are based on this hypothesis
in despite of the criticism of [29], which argues that process
programming only allows one to represent the well
assimilated parts of processes and not the creative parts.
Product-oriented models do not put forward the
activities of a process but rather the result of these
activities. They model the evolution of the product and
couple the product state to the activities that generate this
state [22]. These models are useful for tracing the
transformations performed and their resulting products, i.e.
business objects, products or services in our case. They are
used for representing the structural and behavioral views
(§2.1) and are more appropriate than activity-oriented ones
for representing ill-defined BPs. However as far as
flexibility is concerned and considering the highly non-
deterministic nature of ill-defined processes, it seems
difficult to write down a realistic state-transition diagram
that adequately describes what has to happen.
The most recent type of process models [14], [18],
[38], [39] is based on the decision-oriented paradigm
according to which the successive transformations of the
product are looked upon as consequences of decisions.
The underlying philosophy is that a process model does
not have only to specify the linking of activities or product
states but also the intention behind the execution of
activities and their linking. Decision-oriented models are
semantically more powerful than the two others because
they explain not only how the process proceeds but also
why. Their enactment guide the decision making process
that shapes the business, help reasoning about the rationale
of decisions [33]. This paradigm seems to be the
particularly appropriate for representing ill-defined BPs
[5] or processes requiring flexibility [38].
Conversation models are based on the speech act
theory and on the principle that each sentence expressed
by someone represents an intention, a commitment [53].
The Action model [34] which is amongst action-
coordination systems seems more appropriate for
modeling ill-structured processes than activity-oriented
models. It defines a structure to represent the conversation
relationship between two participants, customer and
performer. Commitments are contained within these
structures which can be divided into four phases of
interaction: preparation, agreement, performance and
acceptance. This structure can also help to consider
optimization possibilities. In fact, highlighting the
organizational reasons which cause the communications
between some roles can justify changes of processes.
Each of those formalisms uses one or several
perspectives presented in §2.1. For instance, STATEMATE
[22] deals with the traditional “who, what, where, when
and how” perspectives using activity, state and module
charts while IDEF0 [45] employs a data flow perspective
to model processes. Activity and product-oriented models
have similar expressivenesses. However this is not
sufficient for modeling processes where human reasoning
is a major component. Decision-oriented models seem
more appropriate to highlight why decisions are made and
to facilitate the introduction of change.
More recent BP modeling languages still provide
concepts for activity-oriented and product-oriented
representations. The Unified Modeling Language (UML)
allows not only modeling application structures, behaviors
and architectures, but also BPs. Event-Driven Process
Chains (EPC) represent temporal and logical dependencies
between functions, events or connectors which are linked
via control flows. An interchange format for EPCs, EPC
Markup Language (EPML), has been proposed in [35].
The Business Process Management Initiative (BPMI)
developed open specifications to enable the standards-
based management of cross-enterprise processes based on
BPM Systems. The Business Process Modeling Language
(BPML) defines a formal model for expressing abstract
and executable processes that address all aspects of BPs,
including activities of varying complexity, transactions
and their compensation and exception handling. The
Business Process Modeling Notation (BPMN) defines a
BP model as a network of activities and control flows. It is
presented as a notation understandable by all users, from
business analysts to developers and business actors.
A conceptual modeling framework offering the rigor
necessary for modeling well-defined BPs, and the
flexibility and adaptability required for ill-defined BPs
was proposed in [37]. This framework gives the ability to
describe the invariants of the organization in terms of
objectives and strategies before specifying the manner of
making them operational in a particular organizational
situation. The vision of the organization which is promoted
is structured according to three layers of concern. The
objectives of the organization are achieved by implementing
the enterprise processes whose are themselves supported by
the enterprise information systems. The two first layers
focus on intentional and organizational aspects of the
enterprise, i.e. the business objectives and how these are
achieved through the co-operation of enterprise actors
manipulating such enterprise objects. The third one focuses
on system aspects i.e., application components that will
support the enterprise, its processes and its actors in order to
achieve the business objectives.
Despite innovative works proposed by the BP
community, there is a lack of approaches that support
variability according to the contextual requirements of each
BP instance. Due to the economic and technological
progress, customers’ expectations are becoming imprecise
and varied following the context in which expectations are
formulated. Hence, context related knowledge becomes an
essential resource to adapt the behavior of BPs. A
conventional BP model may fit customers’ needs in a given
context and not in another one. The ability to integrate the
context related knowledge allows BP models to be active,
flexible, fine-grained and able to express a variety of
business rules. In [50], a role driven approach for was
developed for supporting context awareness in flexible
BPs. It has two major benefits: (i) it offers flexibility in
assigning functions to roles since a function can be
performed by several possible roles according the
performance context rather than a specific one, and (ii) it
gives to actors some autonomy allowing them to develop
strategies for performing operations, operational goals and
functions. In [51], challenges related to the development of
a new promising paradigm for BP modeling supporting
explicit definition of the ‘context related knowledge’ are
identified. Authors argue that any information reflecting
changing circunstances during the execution of a BP can be
considered as contextual information. The context is thus
defined as “the collection of implicit assumptions that is
required to activate accurate assignments in the BP model
at the process instance level”. In [51], the role-driven BP
modeling approach (RBPM) presented in [50] was extended
to support context awareness.
2.3. Position of workflow softwares for modeling
and enacting processes
The workflow concerns, at first, an activity of
scheduling and coordination of work between actors
implicated in a business process. The aim of workflow
analysis is to find the right division of a given work
process into tasks and an ordering among these tasks
leading thus to the representation of a "procedure".
Thereafter, WFMSs provide mechanisms to execute the
defined flow of tasks [16]. Several classifications have
been proposed for workflow applications. The commonly
used was defined in [30] and divides workflows into three
classes, depending on the nature of the processes they
support and the value these processes have for the
enterprise. An additional category (collaborative) was
mentioned in [2] leading the categorization into four classes.
• Production workflows involve repetitive and
predictable BPs. They implement the core processes of
the enterprise and incorporate access to various ISs
through workflow activities. This is the closest category
to the commercial WFMS solutions and to the generic
workflow product structure adopted by WfMC [63].
• Administrative workflows involve repetitive,
predictable processes with simple task coordination
rules and do not concern the core processes of the
enterprise. They can be automated using a repository-
oriented WFMS as the production workflows but also
message-oriented ones where process definitions can
be part of the messages and not stored in a repository.
• Collaborative workflows include iterative tasks over
the same step until some form of agreement has been
made. It seems very difficult to model those using
classical WFMSs and the underlying activity-oriented
(prescriptive) models since it is impossible to predefine
the steps to follow. Most of the co-ordination is done
by human participants.
• Ad hoc workflows have no predefined structure.
Workflow support is limited to the provision of
communication mechanisms to route case (process
instance) data between workers and possibly some
support for logging and state tracking. Ad hoc
workflows tend to be created to deal with exceptions.
The coordination is controlled by human participants.
A great extend of the process models offered by the
commercial solutions are activity-oriented and are devoted
to the representation of BPs whose execution could be
automatically supported by a WFMS based on the same
paradigm. The Workflow Management Coalition defined
the workflow as ‘The automation of a business process, in
whole or part, during which documents, information or
tasks are passed from one participant to another for action,
according to a set of procedural rules’ [63]. The modeling
formalism adopted by the WfMC is also activity oriented.
In terms of automated support for executing BP
models, commercial WFMS and the underlying control
flow models are useful for well-defined and repetitive
work processes (production and administrative).
Nevertheless, they cannot be used for ill-defined BPs (ad
hoc and collaborative) neither to deal with the dynamic
modification of well-defined ones. Recent works underline
the needs in term of flexible and adaptive workflows [9],
[58,] [62] whose execution can evolve according to
situations that cannot always be prescribed.
Few WFMSs (InConcert, Ensemble and TeamWARE
flow) allow creating and modifying process definitions
during their execution. For instance, Inconcert supports the
definition of process models by discovering, i.e. by
induction from process instances [59]. [10] deals with the
issue of the coordination of cooperative activities and
presents a set of requirements -including flexibility and
dynamicity- for a WFMS that aims to support cooperative
workflow. In [49] a classical workflow model is
combined with some pocket of flexibility that reduces the
constraints on execution. In [6], the artifact of emergent
workflow is proposed to support the adaptation of process
instances at runtime. In [61], the authors suggest a set of
changes patterns and change support features to foster
systematic comparison of existing process management
technology with respect to change support. Based on these
change patterns and features, they provide an analysis and
evaluation of the studied systems.
2.4. Discussion
Since the introduction of the process centered view of
organization management by M. Hammer and J. Champy,
BP modeling gained importance in both the management
community and the system engineering community.
Through a better understanding obtained by an explicit
representation of their processes, the former aims to
improve organization performance via process
reengineering whereas the latter aims to design/redesign
the IT solution that best fit the reengineered processes. In
order to respond to this demand, a large number of process
models were developed as well as tools to support their
definition and management over time. Most of these
models concentrate on Who does What, When, i.e. on the
description of the operational performance of tasks to
produce results. Modeling BPs consists in capturing
processes and highlighting significant aspects of the
business. During the two late decades, several languages
dealing with BP modeling were proposed: traditional
input-process-output languages, conversation-based
languages, languages based on role modeling, system
thinking and system dynamics techniques, and constraint-
based languages.
The literature shows a convergence on a set of
concepts such as procedure, task, role, actor, resource,
decomposition of tasks… and highlights the fact that an
appropriate model for representing BPs should also
provide means to represent ill-structured ones.
The concept of role is common to the studied models.
A role is the definition of an organizational intention
shared by a collection of users, all of whom have the same
privileges and obligations to a set of work processes in an
organization. It seems to be the main concept for the
representation of BPs. Nevertheless approaches dealing
with role descriptions are not satisfactory to meet
flexibility requirements. For instance, Role-Interaction-
Networks [55] and Role-Activity-Diagrams [41], represent
roles as sets of ordered activities or interactions. They
introduce “swim-lines” to indicate responsibilities of
participants. They also describe interactions between
couples of roles, from a source to a target role. In addition,
[3] improves the readability of BP models by making roles
explicitly present. Its main contribution with respect to [41]
and [55] is to represent explicitly physical objects that a role
needs to execute its actions. Nevertheless, it does not allow
this sequence of actions to be performed by actors having
different competencies, according to the situations in hand.
Among modeling techniques found in the literature,
those based on role modeling have the advantage of
supporting the well-known separation of duties principle
(SoD). “The purpose of the SoD is a policy to ensure that
failures of omission or commission within an organization
are caused only by collusion among individuals and,
therefore, are riskier and less likely, and that chances of
collusion are minimized by assigning individuals of
different skills or divergent interests to separate tasks”
[19]. Furthermore, the concept of role not only allows
underlining the responsibility of each actor and reflects the
organizational structure but also improves the
understanding of the way responsibilities are achieved.
Adopting role based methods to represent BPs is useful,
particularly if they are flexible enough to meet BP
flexibility requirements, especially organizational,
functional and operational requirements.
Context-awareness [51] allows expressing a rich set of
business rules and to adjust assignment activation and
deactivation in a flexible way offering practical
alternatives that depend on the context. It provides more
appropriate matching so that only an actor which plays the
appropriate role can perform an operation and only the
suitable functions will be included in a given BP, etc. This
ensures that BP instantiation matches actual usage and
needs. As well, a great amount of flexibility is brought by
the concept of context.
Social and organizational factors take an important
place in any organization. A BP model must capture much
more than the steps of ‘procedures’. The concept of goal
expresses an intention. Goals are high level objectives of
the organization. The more recent goal-oriented
approaches [36], [37] define stable characteristics of the
business that any organization choice must respect.
Compound goals can be decomposed into sub-goals. At
the most detailed level, the way of achieving the
operationalizable or atomic goals should be specified in
terms of actors and activities, i.e. operational concerns. We
argue that knowledge intensive business processes require
modeling artifacts which can represent the organizational
goals, strategies, responsibilities and risks rather than
exclusively actors, operations and activities.
3. Flexible process modeling and controlling :
State of the Art
According to [63], a process definition consists of a
network of activities and their relationships, criteria to
indicate the start and termination of the process, and
information about the individual activities such as
participants, associated IT applications supporting them
and data, etc. A process instance represents a single
enactment of a process definition. The process definition
adopted by WfMC corresponds to a prescriptive process
model in the sense that "how
things must/should/could be
done" should be pre-defined before the enactment of the
process definition. Remind that, in opposite, a descriptive
process model aims at recording and providing a trace of
what
happens during the business process [20].
We studied several flexible/adaptive workflow
approaches of the literature. Figure 1 shows the properties
of these approaches we will discuss below and situates
them in the workflow applications life cycle. Figure 2, at
the end of this section, will summarize the properties we
identified and analyzed with respect to business process
flexibility requirements in a global picture. These
properties are developed underneath.
Analysis and modelling
Control
Implementation
Execution
BUILT TIME
RUN TIME
Business
process
Process
definition
a posteriori
flexibility
(Transition, versioning, evolution
techniques, migration techniques)
a priori
flexibility
(Flexibility
techniques)
(Specification
formalisms)
(nature of impact,
nature of change)
Figure 1: Workflow applications life cycle and
properties about flexibility
The nature of the flexibility drew first our attention.
This defines if the capacity of taking into account the
environmental change should be incorporated in the
process model during the build-time or not.
The flexibility by adaptation (a posteriori) allows
