Information Technology and Management 5, 271–291, 2004

 2004 Kluwer Academic Publishers. Manufactured in The Netherlands.

Organizational Management in
Workflow Applications – Issues and Perspectives
MICHAEL ZUR MUEHLEN [email protected]
Wesley J. Howe School of Technology Management, Stevens Institute of Technology,
Castle Point on the Hudson, Hoboken, NJ 07030, USA

Abstract. Business processes automation requires the specification of process structures as well as the def-
inition of resources involved in the execution of these processes. While the modeling of business processes
and workflows is well researched, the link between the organizational elements and process activities is
less well understood, and current developments in the web services choreography area completely neglect
the organizational aspect of workflow applications. The purpose of this paper is to give an overview of the
organizational aspects of workflow technology in the context of the workflow life cycle, to provide a review
of existing work, and to develop guidelines for the design of a workflow-enabled organization, which can
be used by both workflow vendors and users.

Keywords: workflow management, resource management, organizational modeling, process management,

performer profile, role resolution

Workflow management systems coordinate activities, resources, and data according to

the formal representation of the process logic, the workflow model [48]. They can help
realize efficiency potentials through the elimination of transport and wait times between
process activities, and provide a detailed level of control over the assignment of work
to process participants. The importance of human involvement in workflow applica-
tions has recently been pointed out by MOORE, who identified excessive activity au-
tomation and poor design of work assignment strategies as critical issues in workflow
projects [33].
The roots of contemporary workflow management solutions can be found in the
office automation prototypes of the 1970s (compare, e.g., [19,51]), which were ori-
ented towards the automation of human-centric processes. Recent developments in
the area of web services choreography have discounted the organizational aspect of
workflow solution and focus exclusively on the coordination of control flow structures.
For instance, the proposed standards WSCI (a subset of BPML) [4], WSCL [5] and
BPEL4WS [14] do not contain any notion of human activity performers. Instead, they
are focused on the technical coordination of inter-enterprise processes, with little or no
human intervention. This indicates a split in the traditionally diverse field of workflow
management (for a discussion of different technical areas related to workflow manage-
ment refer to [42]). While some vendors focus on the automation of mainly technical
processes, such as the automated data exchange between disparate applications, other
272 ZUR MUEHLEN

vendors stress the organizational aspect of their solutions and focus on human-centric
processes [35].
The purpose of this paper is to give an overview of the organizational aspects of
workflow applications, to provide a review of existing work, and to position this work
in the context of the workflow life cycle. Based on this review we point out design
guidelines that could improve the success of workflow applications.
In the following section we introduce a workflow life cycle model, and outline
which resource-related tasks are performed during the different phases of the workflow
life cycle. The rest of this paper is structured along the phases of this life cycle model.
In section 2 we present a generic meta model for the organizational entities involved
in a workflow application. In section 3 we discuss the specification of assignment and
synchronization policies, and point out the relationship between organizational policies
during build time and run time. In section 4 we present technical integration aspects that
have to be addressed in the transition from build time to run time. Section 5 focuses on
the maintenance of resource information at run time and the evaluation of workflow audit
trail information for resource management purposes. Section 6 reviews related work and
section 7 concludes the paper with a brief summary and an outlook on future work.

1. Resource management in the workflow life cycle

A resource (also known as actor, performer, or process participant [47]) is an entity that
is assigned to a workflow activity and is requested at runtime to perform work in order to
complete the objective of the activity. In this paper we focus only on resources that can
actively contribute to the goal(s) of an activity. Passive resources, such as physical mate-
rials or information are part of the informational perspective of a workflow application.
In this sense, our understanding of resource differs from the view of, e.g., Kwan et al.,
who treat information used within workflow activities as a resource as well [29]. A re-
source model contains the definition of human and technical resources that are involved
in the execution of a workflow model as workflow participants. While the resource
model is a structured representation of organizational 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 workflow management system not only needs to provide a mech-
anism to represent the organizational elements involved in the execution of workflows,
but it also needs to provide mechanisms for continuous change within these elements.
The workflow life cycle reflects the desire to continuously improve the perfor-
mance of business processes by monitoring the present, analyzing the past, and planning
for the future. Procedure models for the design of workflow applications have been
discussed by Kwan and Balasubramanian [29], as well as Weske et al. [46]. These mod-
els represent an extension of system analysis and design techniques and emphasize the
separation between workflow logic and task logic. Explicit workflow life cycles have
been proposed by Galler [21] and Heilmann [23], among others. These models pro-
vide detailed guidelines for the build time aspect of a workflow application, but provide
little information about the system behavior at run time, especially the maintenance of
ORGANIZATIONAL MANAGEMENT IN WORKFLOW APPLICATIONS 273

Figure 1. Workflow life cycle.

resource information. The WISDM methodology developed by Kwan and Balasubra-

manian explicitly refers to an organizational perspective that contains resource informa-
tion (comparable to the organizational aspect of the widely discussed MOBILE archi-
tecture of Jablonski and Bussler [27]), but this perspective is mainly referenced in the
initial analysis phase of the development cycle.
The workflow life cycle shown in figure 1 builds on these approaches and extends
them to explicitly represent the resource perspective during all phases of the workflow
life cycle. The black circles in figure 1 indicate the sections of this paper that refer to the
individual life cycle phases. The cycle starts with an initial analysis of the project goals,
the environment of the future workflow application, and the organizational structures
and rules surrounding the new system. This phase is followed by a process design phase,
274 ZUR MUEHLEN

during which the overall process structure is engineered, the resulting workflow model
is designed, and the resources involved in the process execution are specified. This in-
cludes the modeling of organizational structures as well as the definition of assignment
policies and conflict resolution mechanisms. The completed workflow models are input
of the process implementation phase. During this phase, the workflow solution is inte-
grated with surrounding information systems. In terms of resource management, access
to existing resource databases and security mechanisms need to be established. The syn-
chronization of activity responsibilities with application access rights is of paramount
importance in this phase. If errors are made regarding this synchronization, activities
might be assigned to process participants who have insufficient access rights to execute
the applications necessary for the fulfillment of the pending activity.
During the process enactment phase, individual instances of the workflow model
are created and coordinated by the workflow enactment service. Internal process par-
ticipants (which are part of the workflow-enabled organization) are notified of pend-
ing activities through their work list and can select and activate these activities. Upon
completion of an activity, control is handed back to the workflow enactment service.
Depending on the nature of activities, process participants may be human resources,
technical resources, or a combination of both. For internal workflow participants in-
formation about their capacity (in terms of permissible workload) and availability (in
terms of schedule) can be obtained by the workflow engine. Activities that are assigned
to internal process participants can be revoked and reassigned to other participants if
their maximum processing time is exceeded, or if other exceptions occur [44]. Exter-
nal process participants are not under the control of the workflow-enabled organization.
Information about the capacity and availability of these resources is rarely available to
the workflow enactment service. These resources are typically informed about pending
activities through an asynchronous medium, such as e-mail. In this case the revocation
of activities is usually more difficult than for internal workflow participants.
Parallel to the process enactment phase process monitoring takes place. On the
technical side the performance of the workflow management system itself is measured,
while on the organizational side metrics such as the length of work queues, the idle time
of resources, or the wait time of pending activities are supervised.
The process evaluation phase completes the workflow cycle. During this phase the
execution of workflow instances is analyzed from an ex-post perspective, based on the
execution protocols (the so-called audit trail). Results from this analysis can serve as
the basis for the planning of resource capacities (i.e., how many performers are required
to achieve certain quality of service levels). The capacity adjustments might be tested
during an animation and simulation phase, where performance information from past
workflow instances can be used as simulation parameters.

2. An organizational meta model

In order to implement organizational control, workflow management systems maintain a

model of the surrounding organizational structure. This model is typically kept separate
ORGANIZATIONAL MANAGEMENT IN WORKFLOW APPLICATIONS 275

from the workflow model, which focuses on the sequence of activities within a process.
The division between a process model on the one side and a resource model on the other
side fosters the separate evolution of both models, since the life-cycle of the resources
within an enterprise typically varies from the life cycles of the enterprise’s processes. In
addition, the separation enables workflow designers to create workflow models that are
independent of changes in the organizational structure of the enterprise, adding to their
robustness.
Within the reference model of the Workflow Management Coalition [48], the man-
agement of resource information lies within the responsibility of the workflow enactment
service. This reflects the fact that many workflow vendors have implemented proprietary
resource management facilities for their workflow management systems, which are ac-
cessed through the workflow modeling environment, or through an auxiliary application.
In larger organizations managing resources inside the workflow enactment service
may lead to problems if several workflow management systems are used for the imple-
mentation of a complex process [18]. These systems cannot share common information
about enterprise resources, which leads to redundant resource specifications. In addition
to this, information like the workload of single resources can only be determined if the
distributed information of the individual workflow management systems is consolidated.
If this information is not easily accessible, efficient use of the enterprise’s resources can
only be realized on a local level. Within the Object Management Group this fact has
led to the discussion of a resource management facility [13], but to date no standard has
emerged in this area.
During the build time of a workflow application, the workflow application designer
has to design both the structure of the business process to be automated, and the struc-
ture of the resources that carry out the process. These resources may be managed by the
workflow management system, or an external resource management facility. Resources
and workflow activities are linked through the construct role. From a process perspec-
tive, a role represents the capabilities and privileges required for the proper execution
of an activity. Curtis et al. go one step further and define a role as “a coherent set of
process elements to be assigned to an agent as a unit of functional responsibility” (see
[15, p. 76]). For a resource perspective, a role represents the combined capabilities and
privileges of a process participant. Based on these two perspectives, the design of the re-
source model can follow two different directions. Using workflow-driven resource mod-
eling the resource model is created according to the resources required by the workflow
definition. In other words, the structure of the activities in the workflow model deter-
mines the roles of the workflow participants. Using enterprise-driven resource modeling
the existing organizational structure of the enterprise (often captured in organizational
charts) is created in the resource management portion of the workflow application, and
a mapping between existing resources and workflow activities is performed.
In a previous study of commercial workflow management systems we have found
the organizational modeling capabilities of workflow management systems to be very
limited, a fact that has a negative impact on the adaptability of these systems to different
enterprise structures found in actual organizations [34,38]. Figure 2 shows a meta model
276 ZUR MUEHLEN

Figure 2. Reference meta model for organizational structures.

for resource modeling, which serves both the workflow-oriented and the enterprise-
oriented approach. It represents a hybrid meta model, which is based on our previous
analysis of organizational meta models within workflow management systems [34].
ORGANIZATIONAL MANAGEMENT IN WORKFLOW APPLICATIONS 277

At the heart of this resource meta model, a resource represents a technical or human
workflow participant. The role entity is a named privilege granted to a resource, or a ca-
pability exhibited by a resource. The recursive role structure allows the combination of
capabilities and privileges into more complex roles. Privileges and capabilities describe
the possible actions a resource is permitted and/or qualified to perform. A capability is
a direct property of a resource (e.g., “speaks Spanish”), and remains associated with the
resource, even if the position of the resource in the enterprise changes. A privilege is a
property of an organizational position, which can be occupied by one or more resources,
which then inherit the privileges associated with the position (e.g., “authority to sign ex-
pense reimbursements over $ 50.000”). Organizational positions are the building blocks
of the formal organizational structure of an enterprise, and their holders are granted the
necessary authorities to perform the activities associated with these positions. Groups
of organizational positions form larger organizational units, such as departments (per-
manent units) or project teams (temporary units). As long as there exist tasks within the
enterprise that are not supported by a workflow management infrastructure, formal or-
ganizational positions and units are required to ensure accountability and responsibility
for the execution of these tasks.
It is important to note that there is no single ideal model for a workflow-enabled or-
ganization. Galbraith’s contingency theory [20] states that there is no single optimal way
to organize an enterprise. Instead, external factors such as customer expectations, market
conditions, and regulatory aspects have to be considered. In workflow-based environ-
ments, the structure of the organizational entities as well as the structure of the business
processes can be adjusted to find an optimal mix of resource and process efficiency. It
should be noted that workflow technology does not resolve the goal conflict between
resource and process efficiency, but it may help realize untapped efficiency potentials in
an organization.

3. Definition of assignment and synchronization policies

Assignment policies determine the strategy for work allocation among process partici-
pant candidates. Upon the instantiation of a workflow activity, the workflow enactment
service places work items on the work lists of qualified performers who are determined
using a process of role resolution (sometimes called staff resolution). Figure 3 shows
the typical steps within the work assignment process. In step 1, the workflow enactment
server determines the list of candidate resources based on the assignment policy and
the available resources. A pending activity is placed on a shared worklist as a public
work item. All qualified resources have access to this shared worklist. Once a candi-
date chooses to perform the pending activity (the grey arrow in figure 3), the workflow
enactment service removes the public work item from the shared worklist and places it
on the private worklist of the designated performer. In a centralized workflow solution,
this process can be implemented by manipulating the visibility properties of work items,
similar to the concepts used in role-based access control (see, e.g., [12]). This solu-
tion allows the workflow enactment service to hold a master table of all pending work
278 ZUR MUEHLEN

Figure 3. Role resolution procedure at run time.

items, with access restrictions based on the roles required by the individual activities and
held by the individual performers. In a distributed environment the same effect can be
achieved by sending pointers to work items on a central worklist as notifications instead
of the actual work items. In this scenario, the work items are accessible through a web
page, which is generated by the workflow enactment service for every work item.

3.1. Assignment policies

For the assignment of pending activities, different strategies can be implemented. These
strategies have an impact on how the workflow enactment service prioritizes activities
and notifies candidate performers. Figure 4 shows different work allocation strategies,
and is based on the research of Hoffmann et al. [24, pp. 137–138].
The planning of new work items describes the behavior of the workflow enactment
service, when new activities become executable. A net change strategy would only
determine the assignment for the new work item, while a re-planning strategy would
re-allocate all work items that have not yet been started, possibly removing work items
from some performers’ worklists and placing them on other worklists.
The workflow enactment service can notify performers about pending activities ei-
ther upon the availability of these activities, at the latest start time of the activity, or at an
arbitrary time between these two points. While human performers are typically informed
upon availability of an activity, it may be desirable to delay the assignment of activities
to technical resources, if the workflow management system is capable of optimizing the
activity schedule based on the economic value or the priority of the activities. These
parameters can either be assigned to a workflow instance at the time of instantiation, or
the workflow enactment service can compute the relative importance of activities based
on application data made available to the workflow management system (i.e., workflow-
ORGANIZATIONAL MANAGEMENT IN WORKFLOW APPLICATIONS 279

Figure 4. Assignment policies. Source: modified from [24, pp. 137–138].

relevant data [49]). Example for this type of information could be the (internal) rating
of a process customer or the revenue associated with a process instance.
The queuing of work items can be performed either using a queue, ensuring that
work items are selected in the order in which they become available; a pool, where re-
sources can choose freely between available work items; or a combination of the two,
where resources select a collection of work items at a time. The choice of queuing mech-
anism determines the degree to which the workflow enactment service can optimize the
allocation of work items. If the priority of pending activities cannot be determined au-
tomatically, a pool-type distribution enables human performers to determine the priority
of pending activities, while a queue-type distribution is recommendable if the optimal
schedule of work items can be determined by the workflow enactment service.
The form of activity execution (individual or collaborative) prescribes, how many
resources may select a work item for execution. While many workflow systems sup-
port only activities that are assigned to individual users, some research has been done
on assigning work to teams, see, e.g., [16,17]. As a compromise, Leymann and Al-
tenhuber propose the concept of bundle [30]. A bundle is modeled as a single activity
in the workflow model, which may be instantiated multiple times at runtime, depend-
ing on conditions that are evaluated at runtime (the original IBM FlowMark workflow
management system supported this concept [26], but this feature was dropped in the
transition of this product to MQSeries Workflow and later Websphere MQ Workflow).
While technically each of the bundle instances is assigned to only one resource, the par-
allel instantiation of bundle activities allows the modeling of collaborative activities to a
limited extent.
280 ZUR MUEHLEN

Finally, the decision hierarchy describes, whether an activity can be passed on

from a workflow performer to another delegate performer. This act of substitution is
common during the absence of a resource (when a deputy takes over some or all of the
functions of the assignee). From a security perspective, delegation is a potentially harm-
ful function. If the assignee is free to choose the ultimate recipient of an activity, this
might endanger workflow constraints such as the separation of duty. For example, if
an accounting process requires two separate members of the accounting department to
authorize a purchase, the workflow enactment service would assign the second autho-
rization activity to a member of the department who has not performed the first activity.
However, if this member is allowed to delegate the activity, and chooses the performer
of the first activity (since he or she is a qualified member of the accounting department),
the process constraint “separation of duty” is violated. For this reason some workflow
systems provide flags within their activity specification, which allow excluding activ-
ities from being delegated to performers who are not the original assignees. Wainer
et al. have discussed the security problems of delegation and revocation in workflow
systems in a recent technical report [44]. In a related paper, Ahn et al. have proposed the
use of existing role-based access control mechanisms to secure a web-based workflow
management system [2].
The substitution of performers can be implemented at different levels. If a work-
flow application is deployed in a work environment where many resources share the
same tasks and responsibilities, and workflow-controlled activities cover the majority
of the overall tasks to be performed, the use of roles with multiple role-bearers creates
an implicit substitute relationship, since multiple resources are qualified for the execu-
tion of an activity. If possible, organizational measures, such as the requirement to have
an empty personal worklist at the end of the day, should limit the need for substitution
mechanisms.
In a classic substitution scenario, the deputy can be granted access to the private
worklist of the original performer, if this performer is absent. In some cases it may be
desirable to limit the visibility of work items or create substitution relationships based on
different roles that a process participant plays. For this reason, the meta model in figure 2
contains a ternary substitution relationship between resource (recursive) and role. In this
way, a resource may serve as the proxy for another resource, but this relationship can
be restricted using one or more roles. For example, a manager might designate one
of his subordinates as a substitute for his regular activities, while another manager is
responsible for certain decision-making activities that govern the subordinates.

3.2. Synchronization policies

Once a work item has been placed on a shared worklist, synchronization policies deter-
mine how it can be accessed by individual workflow participants. Figure 5 shows an
overview of synchronization mechanism properties.
The coordination of pending work items can either be hierarchical or market-based.
In a hierarchical scenario, either the workflow enactment service assigns work items to
ORGANIZATIONAL MANAGEMENT IN WORKFLOW APPLICATIONS 281

Figure 5. Synchronization mechanisms. Source: modified from [24, pp. 137–138].

individual performers (eliminating the need for a shared worklist), or in an intermediate

step, a manager receives all pending work items and manually assigns them to the indi-
vidual workflow participants. While the first strategy is useful if the workflow manage-
ment system is capable of performing schedule optimization, the latter strategy reduces
the “mechanistic” assignment of activities by a technical system, which may increase
user acceptance (Action Technology’s Coordinator, one of the first workflow systems,
was criticized for its lack of flexibility, compare [40] for a discussion). If a market-based
allocation policy is implemented, workflow participants compete for the right to perform
a particular activity, either through auctions or other market mechanisms. While market-
based work allocation is not a common feature in commercial workflow systems, it has
been the subject of research studies by Harker and Ungar [22], Tan and Harker [43], as
well as Alt et al. [3]. A very thorough discussion of auction protocols for the scheduling
of decentralized resources was presented by Wellmann et al. [45]. Finally, work items
can be assigned according to a fixed schedule. In the most common case, they are as-
signed to a shared worklist, from where they can be selected by individual performers
on a first-come-first-serve basis. However, other scheduling principles are theoretically
possible.
The allocation of work items can be fully automated by the workflow management
system, i.e. the system automatically determines the qualified performer(s) for an activ-
ity and assigns pending work items to these resources. In a partially automated scenario,
282 ZUR MUEHLEN

the workflow management system may suggest qualified performers, but the ultimate
assignment is performed by another decision instance, e.g., a team leader. In a manual
scenario, the workflow management system would only show pending activities, but not
perform any task allocation. It is up to the workflow-enabled organization to find orga-
nizational measures to ensure the actual execution of pending activities, or an external
resource management application could perform the assignment.
The participant selection can be either direct (at the level of the individual per-
former), or indirect (using a proxy construct like role or organizational unit as the ul-
timate recipient of a work item). During direct assignment, the workflow system may
check the availability of the selected resource, e.g., if the performer is currently logged
into the system. If the resource is absent, the workflow system can determine a substi-
tute and assign the work item to this resource, deliver the work item only to the initially
chosen resource (e.g., if the activity is marked for direct assignment only) or raise an
exception and escalate the process. Indirect selection is based on those elements of the
resource meta model which allow the grouping of individual resources. In the meta
model described in section 3.1, these entities are role, organizational position, and or-
ganizational unit, although other elements such as qualification or competency might be
used as well.
The specification of the resource requirements can be either static or dynamic. Us-
ing the static assignment, an activity is associated with one or more instances of one
or more resource meta model entities. For example, the activity “review customer or-
der” could be assigned to the instance “sales manager” of the entity type “organizational
position”. This assignment is static in the sense that it does not vary with different
workflow instances. Dynamic assignments take data from the current workflow instance
into account for the selection of qualified performers. This data can either relate to the
current workflow instance (e.g., the ID of the process initiator) or to the business ob-
jects processed in the current workflow instance (e.g., the customer number contained
in an order document). Dynamic assignment allows a very detailed specification of as-
signment policies (e.g., all orders from a particular customer are handled by the same
customer service agent), but require the tight integration of the workflow management
system with external data sources. In practice, this type of assignment is found in em-
bedded workflow solutions, where the workflow component has immediate access to all
relevant system data.
The assignment of pending activities can either be performed in a push or pull
manner. Using the push mechanism, resources signal their availability to the work-
flow system, which determines the next activity this performer should work on. This
may be desirable in environments, when the workflow enactment service can optimize
the scheduling of activities, the activities themselves are uniform, and the resources are
mainly technical (without user intervention). In the example of a brokerage application,
workflow participants were not given a choice between different work items, but the
workflow management system prioritized pending activities according to different eco-
nomic criteria and allowed brokers only to request the highest ranked work item [34].
ORGANIZATIONAL MANAGEMENT IN WORKFLOW APPLICATIONS 283

Using a pull mechanism, a resource requests the next work item at a convenient time,
but not necessarily upon availability. A combination of push and pull is possible, if a re-
source is assigned a number of activities, but the sequence of execution of the individual
activities is left to the performer.
Finally, participant autonomy determines, whether the workflow enactment service
determines the final recipient of a work item, or whether a workflow participant may
refuse the assignment of a particular work item and send it back to the shared worklist
or the workflow enactment service for reallocation.

4. Resource integration

Integration is regarded as one of the primary goals during information system design.
Literally, integration means to form, coordinate, or blend something into a functioning
or unified whole by ending existing segregation [31]. Two distinct types of integration
can be distinguished [37]:
Integration through connection occurs if a new system is created through the cre-
ation of links between disparate, but logically connected entities or sub-systems. Typi-
cally this is an ex-post integration of existing systems, like the integration of enterprise
applications through a workflow management system. Integration through combination
occurs if similar system elements are combined, thus leading to a decreased number of
elements and relationships within the system (in the sense of abstraction). Typically this
form of integration happens during the conceptual design phase of an information sys-
tem, for example the development of a complex application with an integrated workflow
layer for the transport of application data.
Rosemann names reduction of redundancy, increased system consistency and in-
tegrity, and better decision support through timely information supply as the main goals
of integration efforts [36]. The design of a workflow application creates integration
requirements, which can be differentiated into internal and external integration require-
ments. Internal integration requirements concern those systems a workflow application
needs to connect to in order to ensure the functionality of the core workflow system. Ex-
ternal integration requirements exist with regard to systems that either invoke the work-
flow system from outside (embedded usage) or systems that are invoked by the workflow
application.

4.1. Internal integration requirements

A workflow application coordinates activities, resources, data, and applications. Con-

sequently, all these elements need to be integrated to ensure the functionality of the
workflow systems.
Resource integration is required by the workflow system to keep track of the par-
ticipants available for activity assignment. Since many companies maintain resource
information in organizational directories or similar applications, a fully integrated work-
284 ZUR MUEHLEN

flow application would use this information rather than replicate resource data inter-
nally. For this reason, the organizational elements available during the specification of
the workflow need to be synchronized with the organizational entities found in the actual
enterprise.
Data integration is required to make workflow relevant data accessible to the
workflow system. This can be achieved by connecting the system to databases used
by external application systems. If the workflow system acts as an enterprise appli-
cation integration hub, conversion of data types and field values may be necessary.
From a resource management perspective, data integration is required if field values
of business objects are to be used during the selection of qualified workflow perform-
ers.
Application integration describes the ability of the workflow system to invoke
external application systems during the enactment of a process. For organizational
processes, applications are often called in their entirety (e.g., a word processing ap-
plication), while for software processes the granularity of application invocation is at the
method or function level.
In addition to these three integration requirements, the use of existing security in-
frastructures is another important feature of workflow applications. Security integration
relates to the use of existing authentication and authorization mechanisms through the
workflow system, such as single-sign-on, role-based access control mechanisms and
public key infrastructures.

4.2. External integration requirements

The external integration of a workflow system relates to the fact, that a workflow system
is an application system in itself. External applications may require calling the services
of a workflow engine from outside, invoking workflow instances, querying the status of
activity instances, or handling resource assignments through external scheduling mech-
anisms. Additionally, the workflow system may be required to present work to outside
parties, which are not direct users of the workflow application.
External invocation of the workflow engine is used during B2B process integration,
among other scenarios. The workflow enactment service can exhibit its capabilities as
services to outside parties, allowing them to invoke a process and pass initial data to the
process instance. Examples for an external invocation are e-mail (mail daemon triggers
the workflow), the web (a web server triggers the workflow) or other applications, which
embed the workflow system (a function within an application results in the start of a
workflow).
Presentation of information to outside parties is necessary, if the workflow system
has to notify external participants about the status of “their” workflow instances or if
system load information is passed on to external system management tools. Also, the
use of audit trail information by external applications (e.g., reporting or business activity
monitoring tools) falls into this category.
ORGANIZATIONAL MANAGEMENT IN WORKFLOW APPLICATIONS 285

Figure 6. Integration requirements. Source: modified from [7].

Besides the actual execution of role resolution and allocation, the workflow appli-
cation has to handle the notification of performers and process managers, as well as the
management of unexpected situations (exception handling, compare [11]).

5. Organizational maintenance at run time

While the sequence of activities within a workflow definition is relatively stable, the
resource model needs to be constantly monitored at runtime to reflect the changes in the
organizational population of the enterprise. These changes 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
organization, changes of the association between resources and organizational units, and
the creation of new or the disbanding of existing groups (e.g., project teams). If the
resource information is stored within the workflow application itself, user accounts and
their associated privileges need to be updated for arriving or departing process partici-
pants. In fact, the process of hiring a new staff member can be represented as a workflow
itself, as implemented in the workflow management system Carnot.
Changes at the micro level relate to changes in the authorization profile of re-
sources, e.g., the granting of additional authorizations, or the revocation of temporary
privileges, the establishment of temporary substitute relationships, the acquisition of
286 ZUR MUEHLEN

new capabilities by resources (e.g., through the completion of training classes), and the
change within a resource’s experience levels. If the role resolution process takes indi-
vidual attribute values of resources into account, the integrity of the attributes provided
by the resource model and used by the workflow model(s) has to be maintained.
The change of a user’s experience level can be very useful to track, in order to al-
low an activity allocation at a fine level of granularity. As a simple measure, a workflow
enactment service could keep track of the number of activity executions by a particu-
lar performer, and apply the simple formula more executions = more experience. By
the time a new activity instance of the same type is to be assigned, the workflow en-
actment service could rank the candidate performers according to their experience and
assign the work items in that order, taking additional constraints (such as workload)
into account. Another possibility would be to measure the activity completion time of
individual resources, ranking these resources by their efficiency. Note that if all ac-
tivities are allocated according to this schema without taking further constraints into
consideration, the resulting workload distribution will follow a power-law curve, with
few performers sharing the majority of the workload, while the majority of the per-
formers receive significantly fewer work items [6]. Therefore, it is useful to balance an
experience-based work distribution by taking additional parameters into account, such
as the average length of the worklists and/or the current workload of individual candi-
dates.
In addition to activity assignment purposes, experience data is also useful during
the handling of exceptions, such as overdue activities or processes. Instead of a hard-
coded exception handling scheme, the workflow enactment service could assign an es-
calating activity to a more experienced person, if experience information is maintained
in the system.

6. Related work

Resource models have been the subject of scientific study for some years, but only a
few concrete examples have been proposed. The OMM Organization and Role Model
described by Cheng aims at a separation of organization and roles in the context of
electronic commerce applications [12]. It consists of the entity types enterprise, orga-
nization, member and virtual link. While an enterprise is a collection of a number of
organizations, each organization consists of a number of members that share common
attributes. Member objects are the elementary resources that map to the actual resources
of the enterprise. Virtual links provide relationships between members of the same or
different organizations.
A generic organizational meta model has been proposed by Bussler, and was im-
plemented in the research prototype Mobile [8–10]. The meta model is on a very high
level of abstraction and provides agent types that can be addressed directly by workflow
activities, non-agent types that have to be resolved before a workflow activity can be
assigned and attributes, operations and consistency rules on a type and an instance level.
In order to depict a real-world organization the meta model has to be instantiated, i.e.
ORGANIZATIONAL MANAGEMENT IN WORKFLOW APPLICATIONS 287

a domain-specific model has to be derived from the abstract entity types. For example,
in order to depict an organization that consists of users, groups, departments and project
teams the abstract entity type agent would be instantiated as the entity type user, the
entity types group, department and project team would be instantiated non-agent types.
The maximum number of members in a group would be an instance-level consistency
rule and the process of assigning a member to an organization would be implemented as
a type-level operation.
The Organization and Resource Model (ORM) presented by Rupietta is an inde-
pendent repository for organizational structures that has been used by the (discontinued)
workflow management system SNI WorkParty [39]. It provides a semantically rich meta
model that can be modified through the inheritance of the existing entity types. The en-
tity types of the ORM, such as organizational positions, position types, tasks, and units
reflect the German organizational theory. However, some of the entity types provided
cannot be used for the assignment process, such as technical resources or the ownership
relation between users and technical resources.
The resource meta model proposed by van der Aalst et al. consists of a UML
class diagram and a corresponding XML rendition for the specification of workflow re-
sources [1]. This model was developed in the context of the XRL/Woflan project, which
aims at the development of an exchangeable workflow modeling language. The goal of
XRL is the exchange of workflow specifications between different workflow systems.
For this purpose, the resources required by a particular workflow specification can be
expressed in XML.
An independent resource management facility was presented by Huang et al. [25],
and has been implemented in the workflow management system HP Changengine. Their
approach consists of an independent resource manager that integrates existing local and
site resource management systems under a common schema. The proposed system im-
plements an SQL-like language for the querying and assignment of resources. The un-
derlying schema for representation of resources differentiates between resources that can
belong to units and the managing entities of these units.
Momotko and Subieta have stressed the importance of dynamic change within the
workflow participant assignment and have presented a modification to the Workflow
Management Coalition’s WPDL [47] that allows the specification of formal expressions
used during the taks allocation phase of workflow execution [32].
Shen et al. went one step further by discussing and benchmarking different criteria
upon which the activity assignment process should be based [41]. In addition to the static
relationship between the capabilities required by an activity and the capabilities exposed
by a resource, they propose the use of activity relationships between pending activities
and existing worklist entries, as well as social relationships between process performers.
The authors present a fuzzy-logic based approach to measuring the three criteria, which
allows a more precise formulation of properties required by and activity and properties
actually exposed by a resource. Shen et al. propose the pair wise measurement of social
relationships between individual process participants, but do not mention, how these
measurements should be obtained [41].
288 ZUR MUEHLEN

Zhao has classified the knowledge contained within a workflow solution [50]:
Process knowledge relates to the structure of processes and activities, institutional
knowledge relates to the roles, business procedures and regulations of the enterprise,
and environmental knowledge such as governmental regulations. From the perspective
of resource modeling, the maintenance and improvement of institutional knowledge is of
significant importance. Klamma and Schlaphoff have presented a prototype that main-
tains and explicates organizational memory information in a workflow context [28].

7. Summary and outlook

In this article we have outlined the major aspects of resource management within work-
flow applications, following the workflow life cycle. After a discussion of different
workflow stakeholders we presented a generic resource meta model for the initial speci-
fication of the resource structure and its population, which combines workflow-oriented
with organization-oriented modeling concepts. Subsequently, we outlined variations in
the assignment and synchronization policies for the run time allocation of tasks to per-
formers, and presented strategies for the actual activity assignment at run time. In section
5 we discussed the maintenance of resource information during the operation of a work-
flow application at the macro and micro level. Finally, we presented strategies for the
use of workflow audit trail data to improve resource utilization and develop new process
strategies.
While the scientific community has shown some interest in the definition of re-
source structures, and issues related with the actual resource assignment, the later stages
of the workflow life cycle have received significantly less attention. This includes the
implementation of knowledge-based resource allocation algorithms, as well as the con-
tinuous improvement of resource structures and the respective allocation strategies. Only
if these areas are successfully addressed by both researchers and practitioners, the true
potential of workflow-based applications will be realized, and the alignment of process
technology and organizational capabilities will be successful in the long run.
The use of workflow technology for human-centric processes presents both a tech-
nical and organizational challenge. Consequently, it has to be addressed from both the
community of workflow vendors and the community of workflow users. Vendors can
improve their products by providing comprehensive integration mechanism with exist-
ing resource repositories, maintenance interfaces for resource information, and support
for different assignment and synchronization strategies. Workflow users can improve
their applications by aligning the resource models, work allocation strategies, and main-
tenance procedures with the organizational structures and policies that best suit their
company. An evaluation and validation of the different modeling and management ap-
proaches presented in this paper is the next step. Experimental research is needed to
determine the effects of workflow applications on organizational structures and their
management, and to establish the success factors for workflow-enabled organizations.
ORGANIZATIONAL MANAGEMENT IN WORKFLOW APPLICATIONS 289

References

[1] W.M.P. van der Aalst, A. Kumar and H.M.W. Verbeek, Organizational modeling in UML and XML
in the context of workflow systems, in: Symposium on Applied Computing (SAC) (ACM, Melbourne,
FL, USA, 2003).
[2] G.-J. Ahn, R.S. Sandhu, M. Kang and J. Park, Injecting RBAC to secure a Web-based workflow
system, in: 5th ACM Workshop on Role-Based Access Control, July 26–27, 2000 (ACM, Berlin,
Germany, 2000) pp. 1–10.
[3] R. Alt, S. Klein and C. Kuhn, Service task allocation as an internal market, in: 2nd European Con-
ference on Information Systems (ECIS 1994), Breukelen, Netherlands, 1994 (Nijenrode University
Press, 1994) pp. 424–432.
[4] A. Arkin, S. Askary, S. Fordin, W. Jekeli, K. Kawaguchi, D. Orchard, S. Pogliani, K. Riemer, S. Stru-
ble, P. Takacsi-Nagy, I. Trickovic and S. Zimek, Web Services Choreography Interface (WSCI) 1.0,
W3C (2002) p. 121.
[5] A. Banerji, C. Bartolini, D. Beringer, V. Chopella, K. Govindarajan, A. Karp, H. Kuno, M. Lemon,
G. Pogossiants, S. Sharma and S. Williams, Web Services Conversation Language (WSCL) 1.0, World
Wide Web Consortium (W3C), Palo Alto, CA, USA (2002) p. 22.
[6] A.-L. Barabasi, Linked: The New Science of Networks (Perseus Pub., Cambridge, MA, 2002).
[7] J. Becker, M. zur Muehlen and M. Gille, Workflow application architectures: Classification and char-
acteristics of workflow-based information systems, in: Workflow Handbook 2002, Future Strategies,
ed. L. Fischer (Lighthouse Point, FL, 2002) pp. 39–50.
[8] C. Bussler, Analysis of the organization modeling capability of workflow-management-systems, in:
Conference of the Pacific Research Institute for Information Systems and Management (PRIISM ’96),
Maui, HI, USA (1996).
[9] C. Bussler, Organisationsverwaltung in Workflow-Management-Systemen (Deutscher Universitäts-
Verlag, Wiesbaden, Germany, 1998).
[10] C. Bussler, Policy resolution in workflow management systems, Digital Technical Journal 6(4) (Fall
1994) 26–49.
[11] F. Casati, Models, Semantics, and Formal Methods for the Design of Workflows and Their Exceptions
(University of Milan, Milan, 1998) 180 pp.
[12] E.C. Cheng, An object-oriented organizational model to support dynamic role-based access control
in electronic commerce applications, in: 32nd Annual Hawai’i International Conference on System
Sciences (HICSS ’99) (IEEE, Wailea, HI, USA, 1999).
[13] F.A. Cummins, Workflow resource management facility request for proposal (Draft), Object Manage-
ment Group, Framingham, MA, USA (1999).
[14] F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte and S. Weerawarana, Business
Process Execution Language for Web Services, Version 1.0, BEA, IBM, Microsoft (2002).
[15] B. Curtis, M.I. Kellner and J. Over, Process modeling, Communications of the ACM 35(9) (1992)
75–90.
[16] H.J. Domingos, J.L. Martins, N.M. Preguiça and S.M. Duarte, A workflow architecture to manage
mobile collaborative work, in: Encontro Português de Computação Móvel 1999 (EPCM 99) (Tomar,
Portugal, 1999).
[17] P. Dourish, J. Holmes, A. MacLean, P. Marqvardsen and A. Zbyslaw, Freeflow: Mediating between
representation and action in workflow systems, in: Proceedings of the 1996 Conference on Computer
Supported Cooperative Work (CSCW’96) (ACM, Boston, MA, 1996) pp. 190–198.
[18] W. Du, J. Davis, Y.-N. Huang and M.-C. Shan, Enterprise Workflow Resource Management (Hewlett
Packard Laboratories, Palo Alto, CA, USA, 1999).
[19] C.A. Ellis and G.J. Nutt, Office information systems and computer science, ACM Computing Surveys
12(1) (1980) 27–60.
[20] J.R. Galbraith, Designing Complex Organizations (Addison-Wesley, Reading, MA, 1973).
290 ZUR MUEHLEN

[21] J. Galler and A.-W. Scheer, Workflow-projekte: Vom Geschäftsprozeßmodell zur unternehmensspez-
ifischen Workflow-Anwendung, Information Management 10(1) (1995) 20–27.
[22] P.T. Harker and L.H. Ungar, A market-based approach to workflow automation, in: NSF Workshop on
Workflow and Process Automation in Information Systems (Athens, GA, USA, 1996).
[23] H. Heilmann, Die Integration der Aufbauorganisation in Workflow-Management-Systeme, in: Infor-
mation Engineering, eds. H. Heilmann, L.J. Heinrich and F. Roithmayr (Oldenbourg, München, 1996)
pp. 147–165.
[24] M. Hoffmann, T. Löffeler and Y. Schmidt, Flexible Arbeitsverteilung mit Workflow-Management-
Systemen, in: Verbesserung von Geschäftsprozessen mit Flexiblen Workflow-Management-Systemen,
eds. T. Herrmann, A.-W. Scheer and H. Weber (Physica, Heidelberg, Germany, 1999) pp. 135–
159.
[25] Y.-N. Huang and M.-C. Shan, Policy-based resource management, in: 11th International Conference
on Advanced Information Systems Engineering (CAiSE ’99) (Springer, Heidelberg, Germany, 1999)
pp. 422–428.
[26] IBM, FlowMark – Modeling Workflow, Release 2.1 (IBM Deutschland Entwicklung GmbH, Vienna,
Austria, 1995).
[27] S. Jablonski and C. Bussler, Workflow Management. Modeling Concepts, Architecture and Implemen-
tation (International Thomson Computer Press, London, 1996).
[28] R. Klamma and S. Schlaphoff, Rapid knowledge deployment in an organizational-memory-based
workflow environment, in: 8th European Conference on Information Systems (ECIS 2000) (Vienna,
Austria, 2000) pp. 364–371.
[29] M.M. Kwan and P.R. Balasubramanian, Adding workflow analysis techniques to the IS development
toolkit, in: 31st Annual Hawai’i International Conference on System Sciences (IEEE, Kohala Coast,
HI, 1998) pp. 312–321.
[30] F. Leymann and W. Altenhuber, Managing business processes as an information resource, IBM Sys-
tems Journal 33(2) (1994) 326–348.
[31] Merriam-Webster, Integration (2002).
[32] M. Momotko and K. Subieta, Dynamic changes in workflow participant assignment, in: 6th East-
European Conference on Advances in Databases and Information Systems, ADBIS’2002, Bratislava,
Slovakia (2002).
[33] C. Moore, Common mistakes in workflow implementations, Giga Information Group, Cambridge,
MA (2002) 2 pp.
[34] M. zur Muehlen, Resource modeling in workflow applications, in: 1999 Workflow Management Con-
ference (University of Münster, Münster, 1999) pp. 137–153.
[35] M.E. Orlowska, Current issues in workflow management, in: 2003 SAP Innovation Congress (SAP
AG, Miami, FL, USA, 2003).
[36] M. Rosemann, Gegenstand und Aufgaben des Integrationsmanagements, in: Integrationsmanage-
ment, eds. A.-W. Scheer, M. Rosemann and R. Schuette (University of Muenster, Muenster, Germany,
1999) pp. 5–18.
[37] M. Rosemann, Komplexitätsmanagement in Prozessmodellen. Methodenspezifische Gestaltungsem-
pfehlungen für die Informationsmodellierung (Gabler, Wiesbaden, 1996).
[38] M. Rosemann and M. zur Muehlen, Evaluation of workflow management systems – A meta model
approach, Australian Journal of Information Systems 6(1) (1998) 103–116.
[39] W. Rupietta, Organization and role models for workflow processes, in: Workflow Handbook 1997,
ed. P. Lawrence (Wiley, Chichester, UK, 1997) pp. 165–172.
[40] A. Sellen and R. Harper, Can workflow tools support knowledge work? A case study of the Interna-
tional Monetary Fund, Rank Xerox Research Center, Cambridge, UK (1996) 21 pp.
[41] M. Shen, G.-H. Tzen and D.-R. Lio, Multi-criteria task assignment in workflow management systems,
in: 36th Hawai’i International Conference on System Sciences (HICSS 2003) (IEEE, Waikoloa, HI,
USA, 2003).
ORGANIZATIONAL MANAGEMENT IN WORKFLOW APPLICATIONS 291

[42] A. Sheth, From contemporary workflow process automation to adaptive and dynamic work activity
coordination and collaboration, SIGGROUP Bulletin 18(3) (1997) 17–20.
[43] J.C. Tan and P.T. Harker, Designing workflow coordination: Centralized versus market-based mech-
anisms, University of Pennsylvania, Department of Systems Engineering, Philadelphia, PA, USA
(1997).
[44] J. Wainer, A. Kumar and P. Barthelmess, Security management in the presence of delegation and
revocation in workflow systems, Universidade Estadual de Campinas, Campinas, Brazil (2001).
[45] M.P. Wellman, W.E. Walsh, P.R. Wurman and J.K. MacKie-Mason, Auction protocols for decentral-
ized scheduling, Games and Economic Behavior 35(2) (2001) 271–303.
[46] M. Weske, T. Goesmann, R. Holten and R. Striemer, A reference model for workflow application
development processes, in: International Joint Conference on Work Activities Coordination and Col-
laboration (WACC ’99) (ACM, San Francisco, CA, 1999) pp. 1–10.
[47] Workflow Management Coalition (WfMC), Interface 1: Process Definition Interchange Process
Model (Workflow Management Coalition, Winchester, UK, 1999).
[48] Workflow Management Coalition (WfMC), Terminology and Glossary, 3rd edn. (Workflow Manage-
ment Coalition, Winchester (ID), 1999).
[49] Workflow Management Coalition (WfMC), Workflow Management Coalition Terminology & Glos-
sary, Document No. WFMC-TC-1011, WfMC, Winchester, UK (1999).
[50] J.L. Zhao, Knowledge management and organizational learning in workflow systems, in: 1998 Amer-
icas Conference on Information Systems (AIS ’98) (AIS, Baltimore, MD, USA, 1998).
[51] M. Zisman, Representation, Specification, and Automation of Office Procedures (Wharton Business
School, University of Pennsylvania, Philadelphia, PA, 1977).