An Extended Analysis of Delegation in Business Processes

Get Complete Project Material File(s) Now! »

Context: Organisational Management in Work-ow Systems

Traditionally, work ows have been used by business organisations for modeling and con-trolling the execution of business processes to achieve a business objective [WFM99]. In the context of a work ow, a process is composed of a number of activities which are connected in the form of a directed graph. An activity describes a piece of work that forms one logical step within a process. During execution, an activity instance includes tasks or services which are human implementations or computerised implementations of an activity [WFM99]. Here, our main concern is human activities (so-called tasks) where a human must be involved in performing manual activities.
Business processes automation requires the speci cation of process structures as well as the de nition of resources involved in the execution of these processes. While the modeling of business processes and work ows is well researched, the link between the or-ganisational elements and process activities is less well understood and does not consider the organisational aspect of work ow applications [Law97, RvdAHW06]. Organisational elements de ne work ow’s resources in terms of tasks, users and data. It re ects human interactions within work ows. The importance of human involvement in work ow appli-cations has recently been pointed out by several work which identi ed excessive activity automation and poor design of work assignment strategies as critical issues in work ow projects [Con02, Sch07].
Moreover, the roots of contemporary work ow management solutions are oriented to-wards the automation of human-centric processes, thereby discounting the organisational aspect of work ow solution and focusing exclusively on the coordination of control ow structures. Proposed standards such as WSCL (Web Services Conversation Language) [Ari02] and BPEL4WS (Business Process Execution Language for Web Services) [Ton03] focused on the technical coordination of inter-enterprise processes, with little or no human intervention. In this chapter, we aim to give an overview of the organisational aspects to support human-centric interactions in the context of a work ow life cycle, and to develop guidelines for the design of a work ow-enabled organisation during the di erent phases of a work ow life cycle. A work ow-enabled organisation is a mean to manage organisational elements (e.g. participants) in work ow systems [ZM04a].

Resource management in the work ow life cycle

As related in the literature review, the work ow is made of tasks, where a task de nes a unit of work that at each invocation performs the binding between di erent resources needed to complete a speci c part of the work ow [RvdAHE05]. The resources that may be involved are di erent. We distinguish material and human resources for business ob-jects and work ow actors, respectively. Generally, the manipulation of material resources is interfaced by one or several entities called applications or services.
A resource model contains the de nition of human and material resources that are involved in the execution of a work ow model [Bal98]. While the resource model is a structured representation of organisational entities, it should be noted that both this model as well as the elements contained therein follow a life cycle and change over time. Therefore, a work ow management system not only needs to provide a mechanism to represent the organisational elements involved in the execution of work ows, but it also needs to provide mechanisms for continuous change within these elements. The work ow life cycle re ects the desire to continuously improve the performance of business processes by monitoring the present, analysing the past, and planning for the future [WGHS99]. The work ow life cycle shown in gure 2.1 is built on the approach proposed by Zur Muehlen [ZM04a]. The black circles in gure 2.1 indicate the upcoming sections that refer to the resource management in the work ow life cycle (see sections : 2.2.2, 2.2.3, 2.2.4 and 2.2.5).
The cycle starts with a goal speci cation and environmental analysis phase that de-nes an initial analysis of the project goals and the organisational structures and rules surrounding the new system. This phase is followed by a process design phase, during which the overall process structure is engineered, the resulting work ow model is designed, and the resources involved in the process execution are speci ed. This includes the model-ing of organisational structures as well as the de nition of assignment policies and con ict resolution mechanisms.
The completed work ow models are input of the process implementation phase. Dur-ing this phase, the work ow solution is integrated with surrounding information systems. In terms of resource management, access to existing resource databases and security mech-anisms need to be established. The synchronisation of tasks responsibilities with applica-tion access rights is of paramount importance in this phase. If errors are made regarding this synchronisation, tasks might be assigned to users who have insu cient access rights to execute the applications necessary for the ful llment of the pending task.

Organisational resources analysis

During the design time, the work ow application designer has to design both the structure of the business process to be automated, and the structure of the resources that carry out the process. Resources and work ow’s tasks are linked through the construct role [CKO92]. From a process perspective, a role is a subject to authorisations that dene permissions (operations) for the execution of a task. From a resource perspective, a role represents a granted authorisation for a work ow actor (so-called user). Based on these two perspectives, the design of the resource model can follow two dierent directions namely the material and human resources. Material resources dene business objects and the way to use them. Human resources dene the actors of the work ow.
From a material resource perspective, we dene permissions as functions with operations to manipulate business objects. From a human resource perspective, we dene a subject as an assigned user who is member of a role to claim a task instance. The task execution is added to the subject worklist. It denes the set of task instances claimed by this subject. The access to resources will be dependent on the execution model of the task. Figure 2.2 shows a meta model for task-based resource model, which analyses the possible ways the resources access can be dened during the task execution.

READ  Astrophysical and nuclear uncertainties of dark matter direct an indirect detection constraints

Denition of assignment and synchronisation policies

Assignment policies determine the strategy for work allocation among process participant candidates [ZM04a]. Candidates dene users who may perform a task. A task corresponds to a single unit of work. Each executing task is termed a work item [RvdAHE05]. Upon the instantiation of a work ow task, the work ow enactment service places work items on the worklists of users who are determined using a process of role resolution (see gure  2.3). A pending task is placed on a shared worklist as a public work item. All qualied users have access to this shared worklist. Once a user (performer) chooses to perform the pending task (step 1 in gure 2.3), the work ow enactment service removes the public work item from the shared worklist and places it on the private worklist of the designated user (steps 2.a and 2.b in gure 2.3). This solution is based on the meta model for taskbased organisational structure dened in gure 2.2. It allows the work ow enactment service to hold a master table of all pending work items, with access restrictions based on the roles required by the individual tasks and held by the users.

Organisational maintenance at runtime

While the sequence of activities within a work ow denition is relatively stable, the resource model task-based needs to be constantly monitored at runtime to re ect the changes on the organisational level (see gure 2.2). Zur Muehlen [ZM04a] identied two categories of changes. It can be either macro changes at the entity level, or micro changes at the attribute level.
Changes at the macro level include the arrival and departure of members of the organisation, changes of the association between users and their roles, and the creation of new units within an organisation. If the resource information is stored within the work ow application itself, user accounts and their associated privileges need to be updated in the organisational policies. Changes at the micro level relate to changes in the authorisation prole of users such as the granting of additional authorisations, or the revocation of temporary privileges. This can be the case when delegating a task and so granting new privileges for the delegatee [GSFC08].
In addition to task assignment purposes, experience data is also useful during the handling of exceptions due to constraints such as workload, lack of human resources or deadlines that may overdue tasks. Instead of a hard-coded exception handling scheme, the work ow enactment service could assign an escalating task to a more experienced user or a substitute, if experience information is maintained in the system. Therefore, it is useful to leverage an experience-based auditing by taking additional parameters into account, such as the current workload of potential performers or their performances ranking to ensure task completion and to optimise work ow execution [Bar03].

Table of contents :

Chapter 1 Introduction
1.1 Background and Motivation
1.2 Thesis Objectives
1.3 Thesis Structure
Chapter 2 Context and Problematic
2.1 Introduction
2.2 Context: Organisational Management in Workow Systems
2.2.1 Resource management in the workow life cycle
2.2.2 Organisational resources analysis
2.2.3 Denition of assignment and synchronisation policies
2.2.4 Resource integration
2.2.5 Organisational maintenance at runtime
2.2.6 Summary
2.3 Problem Statement : How to ensure a secure task delegation in workow systems ?
2.3.1 Motivating example : e-Government workow scenario
2.3.2 Problem statements
2.4 Principles, Approach and Thesis Contributions
2.4.1 Principles
2.4.2 Our approach
2.4.3 Contributions
2.4.4 Published results
2.5 Conclusion
Chapter 3 State of the Art
3.1 Introduction
3.2 Business Processes and Workows
3.2.1 Workow management systems
3.2.2 Organisational model in WfMS
3.2.3 Business process management vs. Work ows
3.2.4 Business process modelling
3.2.5 Summary
3.3 An Overview of Security Concepts
3.3.1 The ve pillars of information security
3.3.2 Access control approaches for security policies
3.3.3 XACML : a policy language
3.3.4 Summary
3.4 Level of Access Control within Workows
3.4.1 Organisational goals
3.4.2 Secure workow approaches
3.4.3 Summary
3.5 Analysis of Delegation in Secure Workows
3.5.1 Delegation in workows
3.5.2 Delegation in access control models
3.5.3 Summary
3.6 Conclusion
Chapter 4 Modelling Task Delegation in Work ows
4.1 Introduction
4.2 Motivation Factors for Delegation
4.2.1 Organisational
4.2.2 Business process
4.2.3 Resource
4.2.4 Link with the case study
4.2.5 Summary
4.3 Organisational Flexibility in Workows
4.3.1 Flexibility constraints
4.3.2 Organisational exibility in practice
4.3.3 Requirements for organisational roles
4.3.4 Summary
4.4 An Extended Analysis of Delegation in Business Processes
4.4.1 A workow model
4.4.2 Basic task delegation model
4.4.3 Securing task delegation within a workow
4.4.4 Summary
4.5 Modelling Task Delegation for Human-centric Workows
4.5.1 Delegation kind
4.5.2 Delegation of privileges
4.5.3 Task delegation model
4.5.4 Negotiation in user-to-user delegation
4.5.5 Delegation protocol supporting negotiation
4.5.6 Summary
4.6 Access Control Over Task Delegation in Workows
4.6.1 Task execution model
4.6.2 Task-oriented access control model
4.6.3 Access control over task delegation using TAC
4.6.4 Revocation
4.6.5 Summary
4.7 Conclusion
Chapter 5 Securing Task Delegation in Access Control Systems
5.1 Introduction
5.2 Modelling Task Delegation Using Access Control Systems
5.2.1 Context for dynamic delegation policies
5.2.2 Access control framework
5.2.3 General control process
5.2.4 Delegation protocols
5.2.5 Access control enforcement
5.2.6 Summary
5.3 Event-based Task Delegation Policies
5.3.1 Problem statement (part I)
5.3.2 Security requirement for delegation
5.3.3 A secure framework for task delegation
5.3.4 Summary
5.4 Integrating Event-based Delegation Policies
5.4.1 Problem statement (part II)
5.4.2 Monitoring and securing task delegation
5.4.3 Modelling task delegation in event calculus
5.4.4 Building policies for delegation
5.4.5 Modelling delegation policies in event calculus
5.4.6 Delegation automation
5.4.7 Summary
5.5 Conclusion
Chapter 6 Deployment Environment
6.1 Introduction
6.2 The Development Environment
6.2.1 Project overview
6.2.2 Collaboration infrastructure
6.3 Delegation for Human-centric Workows
6.3.1 Administrative communication layer
6.3.2 Collaborative workow runtime
6.3.3 ACL plugin supporting delegation
6.3.4 Email-centric task delegation tool
6.4 Delegation Policies Enforcement
6.4.1 A secure delegation protocol
6.4.2 Authentication management component
6.4.3 Authorisation decision component
6.4.4 Deployment and evaluation
6.5 Conclusion
Chapter 7 Conclusion and Perspectives
7.1 Thesis Summary and Contributions
7.2 Limits and Perspectives
Appendix A Discrete Event Calculus Reasoner
A.1 Introduction
A.2 Discrete Event Calculus Reasoner Language
A.2.1 Sorts
A.2.2 Formulas
A.2.3 Options
Appendix B Commonsense Reasoning for Task Delegation
Appendix C List of Acronyms


Related Posts