Transcript Dynamic Workflow

Y
A W L
Chapter 4
Dynamic Workflow
Michael Adams
a university for the
real world
R
© 2009, www.yawlfoundation.org
Y
Workflow Limitations
Y
• Workflow technologies seek to bring many benefits to organisations
• But proprietary frameworks limit support to rigid and/or idealised
representations of work processes, leading to:
– difficulty representing “real-world” activities
• Keeping it simple means ignoring deviations
• Capturing deviations means complex models
– difficulty evolving with the
work practices they model
– difficulty dealing with
process flexibility
– limited exception handling
capabilities
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
2
Flexibility: A Definition
Y
• In the Process-Aware Information Systems domain, the
term flexibility is used to denote:
The degree to which a workflow system is able to
support or handle expected or unexpected deviations in
the execution of process instances, both from within the
context of the instance or from the external
environment, without negatively impacting on the
essence of the process or its expected completion.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
3
Deviations
Y
• "the enactment of any workcase may deviate significantly
from what was planned/modelled"
• P. Barthelmess and J. Wainer. Workflow systems: a few definitions and a few
suggestions. 1995.
•
Two types (at the control-flow level):
• Expected :– deviations from 'normal behaviour'
• Unexpected :– inadequacies in the process
model
• Johann Eder and W. Liebhart. The workflow activity model
WAMO. 1995.
•
Typically handled off-system
• reduced productivity, increased processing
time
• lost to 'organisational memory', no natural
evolution
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
4
Migration Issues
Y
• "Repairing" the process model incurs costs (downtime,
productivity, efficiency) and introduces migration issues:
– Correctness:
• What kind of changes are allowed?
– Ad-hoc
– Modification of process definition
• Is the changed process definition correct syntactically (e.g. no
unconnected nodes) and semantically (e.g. can existing cases still
complete normally)?
– Version control:
• What to do with current instances (continue / restart / migrate)?
– Management Information:
• How to aggregate information about the actual states of
processes (or the various versions of the 'same' process)?
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
5
Taxonomy of Flexibility
Y
• By Design
– add alternate paths at design time
• By Deviation
– deviate path at runtime without
changing the original specification
• By Underspecification
– incomplete specification, at
runtime completed as needed
?
• By Change
– modify specification at runtime
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
✗
6
Flexibility and YAWL
Y
• YAWL natively supports flexibility by design:
– Like most languages: parallel branching, choice, iteration
– Unlike most languages: multiple-instance tasks (static and
dynamic), cancellation sets
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
7
Flexibility as a Service
Y
• YAWL also supports the potential for other forms of
flexibility through its Service Oriented Architecture:
– means that dedicated custom services can be built that
leverage the power of the YAWL Engine to provide flexibility
for processes in various ways
– each service has its own language, approach
• Processes can be modelled with a mix of styles to
achieve appropriate levels of flexibility
• A service may be a provider and/or a consumer
– i.e. languages and approaches may be arbitrarily nested
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
8
Framework
Y
• The YAWL System provides a useful framework for
FAAS
– Service Oriented Architecture
– Standard Interface
• Currently, two services provide flexibility:
– The WORKLET Service
• supports flexibility by design, deviation and underspecification
– The DECLARE Service
• supports flexibility by design, deviation and change
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
9
Y
www.wfmc.org
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
10
The Assembly Line Metaphor
Y
“Much work, even office
procedures, can be processed
in an assembly line”
Workflow Management Coalition, “What is Workflow?”, Introduction to Workflow,
http://www.wfmc.org/information/introduction_to_workflow02.pdf, 2002
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
11
The Assembly Line Metaphor
Y
• When modelling some aspect of the real world into
a computational form, we use a metaphor to guide
our actions.
•
Traditionally, the
computational metaphor
takes a set of inputs,
performs a series of
functional steps, and, on
completion, produces
some output.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
12
Turing's Universal Machine
Y
"The [universal] machine is supplied with
a “tape”, (the analogue of paper) running
through it, and divided into sections
(called “squares”) each capable of
bearing a “symbol”."
Turing, A., On computable numbers, with an application to
the Entscheidungsproblem. In Proceedings of the London
Mathematical Society, 2:(42), 1937.
"If we wish to have any clear notion of the machine [i.e. technology]
we must think about its psychological as well as its practical origins."
•
Mumford, L., Technics and Civilization. 1934.
"Technological developments are as much affected by fashion as
clothing."
• Holt, A., Organized Activity and Its Support by Computer. 1987.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
13
Metaphor Limitations
Y
• For “assembly-line” type processes, the metaphor works
remarkably well
– But for other work environments, it is more problematic
• Many attempts have been made to extend the paradigm
to meet the needs of the “other” workplaces, but with
limited success
•
Rather than continue to squeeze a
square peg into a round hole, a
different perspective may be needed
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
14
Activity Theory
Y
• Activity Theory describes the frameworks associated
with human activity.
• Originated in USSR in 1920’s as part of the culturalhistorical school of psychology.
•
AT describes human activity as:
– being mediated by artefacts.
– having a strict division of labour.
– transforming both nature and the
worker.
– using “activity > action > operation”
hierarchy to delineate the individual’s
activity from the collective activity.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
15
criteria
principles
Derived
principles of
AT
vs.
criteria for
flexible
workflow
Flexibility
& Re-use
Activities are
Hierarchical
Activities are
Communal
Activities are
Contextual
Activities are
Dynamic
Mediation of
Activity
Actions are
Chosen
Contextually
Actions are
Understood
Contextually
Plans Guide
Work
Exceptions
have Value
Granularity
based on
Perspective
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Adaptation via Dynamic
Reflection
Evolution
Locality
of Change
Y
Comprehens- Exceptions
ibility of
as 'first-class
Models
citizens'
An activity consists of one or more actions
An activity involves a community of participants working towards a common objective
Contextual conditions and circumstances deeply affect the way the objective is achieved in
any activity
Activities are never static but evolve asynchronously
An activity is mediated by tools, rules and divisions of labour
A repertoire of actions is created, maintained and made available to any activity, which
may be performed by making contextual choices from the repertoire
The immediate goal of an action may not be identical to the objective of the activity of
which the action is a component. It is enough to have an understanding of the overall
objective of the activity to motivate successful execution of an action
A plan is not a blueprint or prescription of work to be performed, but merely a guide which
is modified depending on context during the execution of the work
Exceptions are merely deviations from a pre-conceived plan. Deviations will occur with
almost every execution of the plan, and give rise to a learning experience which can then
be incorporated into future executions.
A particular piece of work might be an activity or an action depending on the perspective of
the viewer
Y
A W L
16
The Worklet Service
Y
• From the derived principles of AT comes the notion of a
workflow support system that:
– regards a process model as a guide to an activity's objective,
rather than a prescription for it;
– provides a repertoire of applicable actions to be made available
for each task at each execution of a process specification;
– provides for choices to be made dynamically from the repertoire
at runtime by considering the specific context of the executing
instance; and
– allows the repertoire of actions to be dynamically extended, thus
incorporating unexpected deviations.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
17
The Worklet Service
Y
• The Worklet Service has been implemented as a YAWL
Custom Service
– but it is in no way limited to the YAWL environment, and may
be ported to other environments by making the necessary links
in the service interface
• It comprises two discrete but complementary subservices:
– a Selection Service, which enables dynamic flexibility for
process instances, and
– an Exception Service, which provides facilities to handle both
expected and unexpected process exceptions at runtime
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
18
A Worklet Is:
•
•
•
•
•
•
Y
a small, self-contained, complete workflow process
designed to handle one specific action (task) in a larger, composite
activity (process)
a member of an extensible
repertoire
contextually chosen at runtime to
perform a task
a dynamically substituted subprocess and/or exception
compensation process
an implicit part of the parent
process model
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
19
Context
Y
• Context is what we call the set of factors that combine
to influence a course of action in a particular situation
• Context plays a crucial role in diverse domains
– e.g. philosophy, semantics, psychology, artificial intelligence
• Capturing context involves quantifying and recording
the relevant influencing factors and relations between
the “inner state” and its internal environment
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
20
A Taxonomy of Context for Workflow
Y
• Generic (case independent): data likely to occur in all
cases
– e.g. when created, created by, times invoked, last invoked,
current status, resource attributes (skills, history), execution
states, process log data
• Case dependent with a priori knowledge: data known
to a case when it instantiates
– e.g. customer name & address, freight charges for size &
weight, item names & descriptions, deadlines
• Case dependent with no a priori knowledge: data that
only becomes known when a case is active and
deviations occur
– e.g. incorrect payments, unavailable stock or routes, natural
disasters
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
21
Capturing Contextual Data
Y
• Methods typically involve collecting a ‘complete’ set of
knowledge and representing it computationally
– divide-and-conquer approach, partitioning a global model into
simpler pieces
– depends heavily on the ability of ‘experts’ to describe
abstractions in a non-abstract way
– probably impossible to achieve, and perhaps not even
desirable
In terms of using context in computational decision
making, it is perhaps more judicious to capture only
that subset of the contextual state of a domain relevant
to making a correct and informed decision.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
22
Capturing Contextual Data
Y
• An alternative is compose-and-conquer
– bottom-up approach that holds that there is no tangible global
model to begin with, but only local perspectives
– views context in terms of locality in a (possible or potential)
network of relations with other local perspectives.
• One bottom-up approach to the capture of contextual
data is Ripple Down Rules (RDR), which comprise a
hierarchical set of rules with associated exceptions
– well established, fully formalised, implementations include
systems for reporting DNA test results, environmental testing,
intelligent document retrieval, fraud detection based on
patterns of behavior, personal information management and
data mining of large and complex data sets.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
23
Worklet Selection
Y
• The worklet selection process is achieved through the use of RDR:
– An RDR Knowledge Base is a collection of simple rules conceptually
arranged in a binary tree structure.
– Each rule node may have a false (‘or’)
branch and/or a true (‘exception’) branch
to another rule node
• the root node has a default rule and can
have a true branch only.
– If a rule is satisfied, the true branch is
taken and the rule of the child node is
evaluated
– If it is not satisfied, the false branch is
taken and its child node rule is evaluated.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
24
RDR Structure
Y
• When a terminal node is reached:
– if its rule is satisfied, then its
conclusion is returned
– if its rule is not satisfied, then the
conclusion of the last rule
satisfied on the path to that node
is returned
• If the conclusion returned is found
to be unsuitable for a particular
case instance, a new rule may be
formulated and added as a new
leaf node.
Example of an RDR
set for a Treat Patient
task in an Casualty
Treatment process
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
– In essence, each added child rule
is a refinement of its parent.
A W L
25
Y
Adding a new rule
• If the conclusion returned was that of a
satisfied terminal rule, then the new
rule is added as a local exception to the
exception ‘chain’ via a new true branch
from the terminal node
• If the conclusion returned was that of a
non-terminal, ancestor node (that is,
the condition of the terminal rule was
not satisfied), then the new rule is
added via a new false branch from the
unsatisfied terminal node
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
✔
✗
26
A Simple RDR
Example
Y
Root
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
27
Suitability of RDR for Worklets
Y
• Ripple-Down Rules are well suited to the worklet
selection process, since they:
– provide a method for capturing relevant, localized contextual
data;
– provide a hierarchical structuring of contextual rules;
– do not require the top-down construction of a global
knowledge base of the particular domain prior to
implementation;
– explicitly provide for the definition of exceptions at a local
level;
– do not require expert knowledge engineers for its
maintenance; and
– allow a rule set to evolve and grow, thus providing support
for a dynamic learning system.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
28
Worklet Service Interface Requirements
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
29
Secondary Data Sources
Y
• The conditional expressions in each node can test
values sourced from:
–
–
–
–
The data parameters of the current workitem
The data parameters of the current case
Process state information
A discrete RDRConditionFunction class, which allows the
definition of functions that can use data from any external
source, such as:
• Archival data from process logs
• External databases
• User-defined values
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
30
Worklet Process Log
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
Y
A W L
31
Conclusion
Y
• The Worklet approach has several key benefits:
– A process modeler can describe the standard activities and
actions for a workflow process and the worklets for
particular tasks using the same modeling methodology
– It allows re-use of existing components
– Its modularity simplifies the logic and verification of the
standard model, since individual worklets are less complex
to build and therefore verify than monolithic models
– It provides for workflow views of differing granularity
– It allows for gradual process evolution
– On the occurrence of an unexpected event, an administrator
needs simply to choose an existing worklet or build a new
one for the particular context
– Complexities including downtime, model restructuring,
versioning and migration are avoided
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
32