=Paper=
{{Paper
|id=Vol-236/paper-3
|storemode=property
|title=A Role-Based Approach for Modeling Flexible Business Processes
|pdfUrl=https://ceur-ws.org/Vol-236/paper5.pdf
|volume=Vol-236
|dblpUrl=https://dblp.org/rec/conf/caise/SaidaniN06
}}
==A Role-Based Approach for Modeling Flexible Business Processes==
https://ceur-ws.org/Vol-236/paper5.pdf
BPMDS'06 111
A Role-Based Approach for Modelling Flexible
Business Processes
Oumaima Saidani * , Selmin Nurcan *+,
(*) (+)
Université Paris 1 - Panthéon - Sorbonne IAE de Paris
Centre de Recherche en Informatique Sorbonne Graduate Business School
90, rue de Tolbiac 75634 Paris cedex 13 France Université Paris 1 - Panthéon - Sorbonne
21, rue Broca 75005 Paris France
Tel: 33 - 1 53 55 27 13 Fax : 33 - 1 53 55 27 01
Email: Oumaima.Saidani@malix.univ-paris1.fr, nurcan@univ-paris1.fr
Abstract: As organisation environments become more complex, business process models have
to provide means to suit the flexibility and adaptability requirements at any given time. A role-
based approach for modelling business processes is a natural way to reflect organisational
structures and to highlight responsibilities assigned to actors. The purpose of this paper is to
improve this kind of approach in order to support flexible business processes modelling. This
can be done through introducing the concept of mission. In addition, to make the approach
more flexible in changing organisational and functional contexts, we investigate issues related
to the delegation and the constraint aspects.
Keywords: Business Process Modelling, Flexibility, Role, Mission, Delegation, Constraint
1. Introduction and motivation
A business process (BP) is defined in [3] as a set of logically related tasks
performed to achieve a defined business outcome. [15] extends the above definition
by introducing the concept of role, stating that a BP is a set of one or more linked
procedures or activities that collectively realize a business objective or policy goal,
normally within the context of an organisational structure which defines functional
roles and relationships. Modelling BPs consists in capturing processes and
highlighting significant aspects of the business. During the two late decades, several
sorts of techniques and tools dealing with BP modelling were proposed [2]: traditional
input-process-output techniques, conversation-based techniques, techniques based on
role modelling, system thinking and system dynamics techniques, and constraint-
based representations techniques. Among these techniques, those based on role
modelling 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 organisation 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” [6]. Furthermore, the concept of role not only allows to underline the
responsibility of each actor and reflects the organisational structure but also improves
112 Business Process Modeling, Development, and Support
the understanding of the way responsibilities are achieved. Adopting role based
methods to model BPs is useful, particularly if they are flexible enough to meet BP
flexibility requirements, especially organisational, functional and operational
requirements.
Nevertheless approaches, dealing with role descriptions, which are used in BP
modelling, are not satisfactory to meet flexibility requirements. These approaches, for
instance, Role-Interaction-Networks [14] and Role-Activity-Diagrams [11], represent
roles as sets of ordered activities or interactions: they introduce “swim-lines” to
indicate responsibilities of participants; and describe also interactions between pairs
of roles, from a source to a target role. In addition, [1] improves the understandability
of BP models by making explicit roles present in BPs. Its main contribution with
respect to [11] and [14] is to represent explicitly physical objects that a role needs to
execute its actions. [1] represents a role with a rectangle that includes a set of actions,
sequential constraints between them, tools and materials that a specialist needs in his
craft to perform the actions. Nevertheless, it does not allow this sequence of actions to
be performed by actors having different competencies, according to the situations in
hand.
There are many definitions of the flexibility in literature [13]. Flexibility is defined
in our approach as the capacity of making a compromise between, first, satisfying,
rapidly and easily, the business requirements in terms of adaptability when
organisational, functional and/or operational changes occur; and, second, keeping
effectiveness. We aim to provide an effective approach for modelling BPs that
realizes this compromise. As discussed previously, the concept of role is an
expressive means for modelling BPs. Therefore, our reflection will be based on this
concept.
This paper is organized as follows: section 2 presents the core of the proposed
approach for flexible BP modelling based on roles and missions. Section 3
investigates some issues related to delegation aiming to increase flexibility. Section 4
provides mechanisms controlling relationships defining flexibility, in order to keep
effectiveness of business processes. Section 5 concludes the paper.
2. A role-based approach for flexible business processes modelling
One of the major limitations of the current techniques, based on role and activity
modelling, is that a BP is considered as a set of operations or activities with a pre-
order. We believe that this feature increases rigidity by imposing an order to perform
operations. A significant amount of flexibility can be reached by providing a set of
extension mechanisms based on the concept of role.
Organisations are structured as networks of BPs in order to achieve their business
goals. BP can be first analyzed in term of roles played by actors and holding missions.
During the execution of a BP, actors perform missions that specify the responsibilities
and the work included in swim-lines in classical activity-oriented representation
formalisms. A mission is similar to the concept of task in OSSAD [4], i.e. the cross-
selling between a BP and a role. A business goal is reached by executing a BP which
comprises many roles and consequently many missions.
During the execution of a BP, it is an actor who performs operations.
Organisation’s roles and missions are usually more static than actors and operations
BPMDS'06 113
are. The central concepts in our approach are the role and the mission. For our point
of view, a role is a semantic construct about which business rules and other concepts
can be formulated. It can represent competency to realize particular missions, e.g. “an
engineer”, and can embody authority and responsibility, e.g. “a project supervisor”.
As shown in Figure 1, each actor belongs to at least one organisational units and is
assigned to appropriate roles based on his responsibilities and qualifications. The
concept of mission serves as a link between roles and operations: A mission is defined
as a collection of operational goals satisfied by achieving operations. A mission can
comprise several operational goals because it is not achieved performing
straightforward and continuous operations without any interaction with other roles.
The set of operations allowing a role (played by an actor during the process
occurrence) to achieve an operational goal is defined by the concept of activity in
[15]. The difference in our proposition is the following: we propose (i) to define this
piece of responsibility of a role in the intentional level (operational goal), then (ii) to
go deeply in the specification of this operational goal (dealt with as a black box in
usual workflow formalisms), and finally (iii) to specify the operations which
performance acts on the business objects and allows to achieve the operational goal.
Organisational
Unit Performed (iii) * Operational
goal satisfies
* Performed * 1
Belongs to comprises
* * * * 1 *
Actor Can play Role Can hold Mission Operation
* * 1(i) *
* * * (ii) *
Taked-part-in *
* Acts on
Business * participates *
Process Comprises Business
1 object
1
Reachs
1 (i) : without flexibility
Business goal (ii) : with flexibility
(iii) : only in the case of delegation of operational goal
Figure 1- The meta-model of our approach to model flexible business processes
Regarding organisational, operational and functional perspectives, the position of
missions as an intermediary provides a more flexible way to allow an actor to perform
an operation than in the opposite one in which roles are directly linked to operations.
As new policies are incorporated, actors can be easily reassigned from one role to
another as usually, but also from one mission (the responsibility of a role in a specific
BP) to another which is not possible using other approaches; roles can be associated
with new missions; and missions can be associated with new operational goals and
operations. In addition, missions can be dissociated from roles; operations and
operational goals can also be split-up from missions if needed.
In order to hightlight our motivation behind the use of the concept of mission, let
us consider the following situations:
114 Business Process Modeling, Development, and Support
• Situation 1: a new organisation is set up and it proves to be necessary to
distribute the responsibilities of each actor differently.
• Situation 2: a responsibly has to evolve.
For dealing with Situation 1 and Situation 2, classical approaches require checking
all operation-to-role assignments and modifying them if necessary. This task is time
consuming and includes risk of error. However, competitive environments require
quick reactions to changes and do not tolerate inaccuracies.
In our approach, to deal with Situation 1, we just have to modify only some
mission-to-role assignments, while actors keep their roles, with new assigned
responsibilities. For dealing with Situation 2, we just have to modify some operational
goal-to-mission and/or operation-to-operational goal assignments, while roles keep
their missions, with new assigned operations.
Our approach allows adaptation with organisational, functional, behavioral and
operational changes easily, rapidly with less error..
In addition, conventional role based approaches define processes in such manner
that a given operation op1 should be executed by a specific role r1. However, in
special cases, op1 could not be performed by r1. Based on this observation, we
identified an additional aspect of flexibility: in a particular process instance, a mission
should be able to be performed by selecting one of the roles provided rather than a
fixed role. Accordingly, we consider that a BP should be relied to missions rather than
operations. So, instead of defining the pre-order of the operations involved in the
process, we just have to precise which missions are required for the BP performance.
Each process can be considered as a mapping of many roles and many missions with
respecting a number of constraints. Each instance of BP is considered as a mapping of
many actors and many missions, respecting also some constraints. A mission can be
held by several roles in several contexts for flexibility purposes. Several dependencies
exist between operations like synchronisation. They can be expressed by using the
concept of constraint which will be discussed in the following section.
3. Support of delegation
In this section, we explore the delegation aspect by which the approach we
described in section 2, can be enhanced to address better flexibility requirements. We
describe in the following the impact they would have on the flexibility capabilities of
the existing model.
There has been a considerable work dealing with various aspects of delegation in
the literature. For instance, [12] and [10] address delegation in a security context, [5]
addresses user-to-machine delegation, [10] addresses process-to-process delegation in
the distributed object environment, [7] deals with delegation as an attribute of role,
and [12] addresses delegation among the role administrators. Table 1 shows the
various forms of delegation we identified. In this paper we focus on actor-to-actor
delegation in the context of flexible business process modelling.
One of the main objectives of companies is to better and more quickly meet with
the customers’ requirements. In a changing environment, assuming that participants
will always act as predefined is inaccurate, because it limits their autonomy and
flexibility when changes make inapplicable some predefined conditions. For instance,
BPMDS'06 115
unforeseen circumstances, such as unplanned absences (illness, leaves), require to
change actors. It is possible to deal with these situations using delegation mechanisms.
Relationship Delegator Delegate Unit-of- The relationship means Example – Figure 2
delegation that :
Actor Actor Actor Role an actor a1 can George can delegate his
-Can-delegate- delegate a role r to role “loan manager” to
Role-to-Actor another actor a2 Maria
Actor- Actor Actor Mission an actor a1 can George can delegate the
Can-delegate- delegate a mission m mission “Loan handling”
Mission-to- to another actor a2 to Maria
Actor
Actor- Actor Actor Operational an actor a1 can George can delegate
Can-delegate- goal delegate a goal g, to “Preparing the offer” to
Goal-to-Actor another actor a2. Maria
Actor- Actor Role Role an actor a can delegate George can delegate his
Can-delegate- a role r1 to another role “loan manager” to
Role-to-Role role r2, e.g. to any actor
any actor who is able to
being able to play r2. play “loan manager’s
assistant”
Actor- Actor Role Mission an actor a can delegate George can delegate
Can-delegate- a mission m to a role r, “Loan handling” any
Mission-to- e.g. to any actor being actor who is able to play
Role able to play r. “loan manager’s
assistant”
Actor- Actor Role Operational an actor a can delegate George can delegate
Can-delegate- goal an operational goal g “Preparing the offer” to
Goal-to-Role to a role r, e.g. to any any actor who is able to
actor being able to play “loan manager’s
play r. assistant”
Role- Role Role Role any actor being Any actor playing “loan
Can-delegate- member of a role r1 manager” can delegate
Role-to-Role can delegate the role r1 this role to any actor who
to any actor a member is able to play “loan
of a second role r2 manager’s assistant”
Role- Role Role Mission any actor being Any actor playing “loan
Can-delegate- member of a role r1 manager” can delegate
Mission-to- can delegate a mission “Loan handling” to any
Role m held by the role r1 to actor who is able to play
any actor a member of “loan manager’s
a second role r2 assistant”
Role- Role Role Operational any actor being Any actor playing “loan
Can-delegate- goal member of a role r1 manager” can delegate
Goal-to-Role can delegate an “Preparing the offer” to
operational goal g any actor who is able to
included in the role r1 play “loan manager’s
to any actor a member assistant”
of a second role r2
Table 1 - Various forms of delegation
Delegation is often defined as a substitution mechanism of all or a subset of actor’s
roles to one or more other actors. No actor can delegate a piece of role. However, in
many cases an actor may want to delegate some missions from his/her role. What is
more, in some cases, role-to-role delegation is needed. For example, if the “loan
manager” is ill, loan manager’s missions and/or operational goals can be delegated to
other employees based on role rather than based on actor. For instance, “Evaluating
the conditions” and “Preparing the offer” can be delegated to the “loan manager’s
116 Business Process Modeling, Development, and Support
assistant”, “Drafting the offer” can be delegated to the “agent”, and “Preparing the
loan financial evaluation” can be delegated to the “financial responsible”.
Actor Role Role Mission
Jane Customer Customer To submit a loan request
John Agent Agent Loan request handling
Maria Loan manager’s assistant Loan manager Loan handling
Steve Loan manager’s assistant
Smith Financial responsible
George Loan manager
Smith Loan manager
Mission Operational Goal
Loan request handling Registration of the loan request
Preparing the loan financial evaluation
Evaluating the conditions
Loan handling Preparing the offer
Drafting the offer
Examples of actor delegation :
Case of role level delegation
- Case 1: George wants to delegate his role “loan manager” to Maria
Case of mission level delegation
- Case 2: George wants to delegate only the mission “Loan handling” to Maria
Cases of operational-goal level delegation
- Case 3: George wants to delegate “Preparing the offer” to Maria and “ Drafting the offer” to John.
- Case 4: George wants to delegate only “Preparing the financial evaluation” to Smith
Examples of role delegation
Case of role level delegation
- Case 5: Any actor able to play the role “loan manager” can delegate the mission “loan handling” to
any actor able to play the role “loan manager’s assistant”. Here, both George and Smith can delegate
the mission “loan handling” to both Maria and Steve.
Figure 2 : Examples of role level, mission level and operational goal level delegation
Role delegation is more general than actor delegation. In the example of Figure 2,
actor delegation allows George to delegate the mission “loan handling” to Maria,
whereas role delegation allows both George and Smith to delegate the mission role
“loan handling” to Maria or to Steve.
A flexible delegation model, which provides multiple forms of delegation, and
supports flexible role, mission and operational goal level delegation, is needed.
We define delegation as a mechanism that allows an actor who is member of a role
r to give all or part of his responsibility to another actor.
For constructing an effective delegation model, we start by identifying various
forms of delegation for instance actor-to-actor, actor-to-role and role-to-role
delegation. Each of them can be based on roles, missions and/or operational goals as
shown in Table 1. Figure 2 shows several cases of delegation. In Case 1, unit-of-
delegation is role. Case 2 needs that unit-of-delegation has to be mission rather than
role. In Case 3 and Case 4 unit-of-delegation is operational-goal.
Table 2 explains briefly a collection of delegation facets that we identified. These
facets will be useful to us for build our delegation model; they can also be used as
basis for detailed evaluations of delegation approaches.
BPMDS'06 117
Facets Values Explanation
An actor may choose to delegate one or more roles
Temporal to another actor. This might be for a limited period
of time, such as a vacation, or under specified
Duration circumstances, such as when the former actor is
unavailable. The actor may want to, permanently,
delegate some roles and/or missions to others
Permanent actors, in order not to have to renew this capacity
unceasingly.
Instance In the case of an instance level delegation, a
delegate receives the capacity to carry out a set of
Level of abstraction Type operations (operational goal or mission) to execute
particular instances of a BP. In the case of a model
level delegation, this is applicable to all instances
of a BP.
Transitive A delegatee can delegate some of the missions
Transitivity Non-transitive he/she received by delegation from a first actor to
a third actor and so on.
Depth Limited It is possible to define the maximum value for the
Unlimited levels of sub-delegation.
Role Unit of delegation can be a role, a mission or an
Unit of delegation Mission operational goal.
Operational goal
Total A delegator may want to delegate the total package
Totality of missions embodied in a given role. He can also
Partial delegate some of his missions and preserve, for
example, only the most complex cases.
Table 2 - The facets of delegation
4. Constraints on the relationships defining flexibility
This section discusses various types of constraints which are relevant to business
processes modelling. In particular, we focus our discussion on numerous constraints
(i) applied to the relationships between the concepts of our approach’s core
(introduced in section 2) and (ii) related to delegation (introduced in section 3).
• Constraints on the relationships between the concepts of the approach’s core
In order to deal effectively with the BP flexibility, relationships between the
concepts of our model (c.f. Figure 1) should be controlled to ensure the usability of
the provided flexibility mechanism. Figure 3 shows the constraints proposed for the
control mechanism. Even if our concepts add flexibility, controlling relationship
between them is necessary to keep effectiveness of processes. Indeed, no one can do
everything. For instance, it is indispensable to avoid situations in which, an employee
gets to approve his own loan request.
Constraints controlling separation of duties: separation of duties is a business
technique trying to minimize fraud by dispersing the authority and responsibility for
an action over multiples actors. This can be ensured by defining mutually disjoint
actor-to-role assignments with respect to sets of roles [9]. If two roles are recognized
as mutually exclusive, the same actor is not allowed to play both roles in order to
118 Business Process Modeling, Development, and Support
avoid (or minimize) risks fraud. We believe that constraints restricting mission-to-
role assignments can provide additional guarantees for the separation of missions.
These constraints require that the same mission can be assigned at most to one role in
a set of mutually exclusive roles. We can in addition distinguish between:
(i) Occurrence-dependent separation-of-duties allowing to support requirement as
dealt wit previously (an employee should not approve his own loan request). It allows
an actor to play both roles that do not cause conflict of interest when acted on
independently, but that produce policy concerns when played simultaneously. This
provides enterprise with greater flexibility.
(ii) Occurrence-independent separation-of-duties principles prohibiting the actor
to play both roles in any process occurrence enabling to solve potential conflicts of
interest issues.
Constraints can apply to actor-to-role, mission-to-role and operational-goal-to-
mission assignments. They can limit, for instance, the number of members or missions
of a role or the number of operational goals for a mission.
Constraints can also apply to processes, and to taked-part-in and participates
relationships associated with a BP. Constraints on BPs can limit the number of
occurrences of a BP in which an actor can realize missions simultaneously.
Constraints can precise if an actor or a role may participate to multiple business
processes at the same time. They can limit the number of process occurrences
(belonging to distinct process models) an actor or a role is allowed to participate to,
simultaneously.
Constraints
Organisational
Unit Operational satisfies
*
Performed (iii) goal
* Performed 1
Belongs to *comprises
* * * * Operation *
1
Actor Can play Role Can hold Mission
1(i) *
* * *
* * (ii) Acts on
* *
Taked-part-in
participates *
*
Business
object
Business *
Process
Comprises
1
1
Reachs Constraints
1
Business goal
(i) : without flexibility
(ii) : with flexibility
(iii) : only in the case of delegation of operational goal
Figure 3 : Constraints on the relationships between concepts of the approach’s core
BPMDS'06 119
• Constraints in delegation model
While delegation can allow dealing with almost all unforeseen circumstances
successfully, it has also the potential to lead to chaos if it is applied incorrectly and
excessively. Hence, it is highly advisable to provide control mechanisms which limit
the undesirable delegation actions according to actor’s competences. For example, a
loan manager could be allowed to delegate the mission “validate a loan offer” to his
assistant but not to a financial responsible. In addition, the loan manager’s assistant,
to whom the responsibility to validate the loan offer was previously delegated, is not
authorized to further delegate this mission to someone else. This constraint deals with
multi-level delegation.
As mentioned in Table 2, delegation can be transitive. This feature may lead to the
risk that an actor, who is unaware of the qualifications of John, (e.g. Maria) can
delegate some missions (e.g. Loan handling) delegated from an initial actor (e.g.
George) to a third actor (e.g. John) that may not be qualified for these missions,
without the initial actor’s notice (i.e. George). Constraints should be applied to most
of the model components and relationships to ensure effectiveness of the provided
flexibility mechanism. BP models should thus be extended to support the expression
of rules controlling the delegation of roles, missions and operational goals. In our
future work, we will study in-depth the constraints applied to the delegation model,
such as separation-of-duties in actor-to-actor, actor-to-role and role-to-role
delegation.
5. Conclusion and future work
In this paper we have investigated the concept of role in the context of flexible BP
modelling. We have introduced the concept of mission, in addition to role and
operation. This concept is missing (except in OSSAD) in existing approaches that
deal with roles as the ability to perform a set of operations. We identified a number of
challenging issues that we wish to discuss in detail in our future works.
Let us resume the kind of flexibility that our approach introduces with respect to
the taxonomy proposed in [8]. Changes in roles, missions, and operational goals can
be done at the BP type and instance level. The subject of change can be associated
with organisational, functional, behavioral and operational perspectives. Finally, the
proposed approach has actually the ability to deal with the duration property; indeed,
temporal (respectively permanent) delegation can cope with temporal (respectively
permanent) changes.
Dealing with delegation mechanisms we have proposed in this paper raises many
questions which need further research such as: In which circumstances and contexts
those mechanisms can be applied? How to distinguish between delegable and non-
delegable roles and missions? How to control that delegation is not ill-advisedly
used? How delegation can be revoked? By whom should the delegation authority be
managed? Constraints, particularly, constraints related to delegation, needs also to be
studied in depth.
Finally, other aspects for flexible BP modelling need to be discussed, like
monitoring, delegation across organisational boundaries, role activation during a
120 Business Process Modeling, Development, and Support
process and inheritance relationships, whereby one role inherits missions assigned to
a different role.
Heretofore, we have exposed some issues concerning flexibility around the
concepts of delegation and constraints. The work presented in this paper is the first
attempt to model delegation based on roles, missions and operational goals for
modelling flexible BPs. We have probably not identified all important facets of
delegation, but we believe that we identified some significant ones. A comprehensive
flexible delegation model for BP will be defined in our future work.
References
[1] Balabko, P., Wegmann, A., Ruppen, A. and Clément, N. (2004) The Value of
Roles in Modelling Business Processes. BPMDS’04. Riga, Latvia.
[2] Carlsen, A., Klein, M. and Malone, T.W. (1997) Conceptual Modelling and
Composition of Flexible Workflow Models. Norwegian University of Science and
Technology, PhD Thesis.
[3] Davenport, T., Short, J. (1990) The new Industrial Engineering: Information
Technology and Business Process Redesign. Sloan Management Review.
[4] Dumas, P. and Charbonnel, G. (1990) La méthode OSSAD – Pour maîtriser les
technologies de l’information – Tome 1 : Principes, Les Editions d’Organisation.
[5] Gasser, M. and McDermott, E. (1990) An Architecture for practical Delegation in
a distributed System, 1990, IEEE Computer Society Symposium on Research in
Security and Privacy.
[6] Gligor, V., Gavilla, S., and Ferraiolo, D. (1998) On the Formal Definition of
Separation-of-Duty Policies and their Composition. In: Proc. of the IEEE Sym. on
Sec. and Priv.
[7] Goh, C. and Baldwin, A. (1998) Towards a more Complete Model of Role. Proc.
Of 3rd ACM Workshop on Role-Based Access Control.
[8] http://lamswww.epfl.ch/conference/bpmds06/taxbpflex
[9] Kuhn, D.R. (1999) Mutual Exclusion of Roles as a Means of Implementing
Separation of Duties in a Role-Based Access Control System. ACM Trans. Inf. and
Sys. Sec., 2(2):177-228.
[10] Nagaratnam, N. And Lea, D. (1998) Secure Delegation for Distributed Object
environments, USENIX Conference on Object Oriented Technologies and Systems.
[11] Ould, M.A. (1995). Business Processes : Modelling and analysis for re-
engineering and improvement, John Wiley & Sons.
[12] Sandhu, R., Bhamidipati, V. and Munawer, Q. (1999) The ARBAC97 Model for
Role-Based Administration of Roles, ACM Transactions on Information and System
Security, Volume 2, Number 1.
[13] Shi, D. and Danies, R.L. (2003) Asurvey of Manufacturing Flexibility:
Implications For E-Business Flexibility”, IBM Systems Journal 42(3), p.414-427.
[14] Singh, B. and Rein., G. (1992) Role Interaction Nets (RINs): A process
Description Formalism, MCC.
[15] Workflow Management Coalition. (1995) WfMC-TC-1003 v1.1 The Workflow
reference Model.