Chapter 4 Dynamic Workflow

1. Chapter 4Dynamic Workflow Michael Adams

2. Workflow Limitations • 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 exceptionhandling capabilities

3. Flexibility: A Definition • 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.

4. Deviations • "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

5. Migration Issues • "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)? • Versioncontrol: • What to do with current instances (continue / restart / migrate)? • ManagementInformation: • How to aggregate information about the actual states of processes (or the various versions of the 'same' process)?

6. Taxonomy of Flexibility • 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 ? ✗

7. Flexibility and YAWL • YAWL natively supports flexibility by design: • Like most languages: parallel branching, choice, iteration • Unlike most languages: multiple-instance tasks (static and dynamic), cancellation sets

8. Flexibility as a Service • 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

9. Framework • 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

10. www.wfmc.org

11. The Assembly Line Metaphor Workflow Management Coalition, “What is Workflow?”, Introduction to Workflow, http://www.wfmc.org/information/introduction_to_workflow02.pdf, 2002 “Much work, even officeprocedures, can be processed in an assembly line”

12. The Assembly Line Metaphor • 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 aset of inputs, performs a series of functional steps, and, oncompletion, produces some output.

13. Turing's Universal Machine "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.

14. Metaphor Limitations • 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

15. Activity Theory • Activity Theory describes the frameworks associated with human activity. • Originated in USSR in 1920’s as part of the cultural-historical 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.

16. criteria 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 Derived principles of AT vs. criteria for flexible workflow principles

17. The Worklet Service • 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.

18. The Worklet Service • 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 sub-services: • 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

19. A Worklet Is: • a member of an extensible repertoire • contextually chosen at runtime to perform a task • a dynamically substituted sub-process and/or exception compensation process • an implicit part of the parent process model • a small, self-contained, complete workflow process • designed to handle one specific action (task) in a larger, composite activity (process)

20. Context • 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

21. A Taxonomy of Context for Workflow • 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

22. Capturing Contextual Data • 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.

23. Capturing Contextual Data • 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.

24. Worklet Selection • 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.

25. RDR Structure • 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. • In essence, each added child rule is a refinement of its parent. Example of an RDR set for a Treat Patient task in an Casualty Treatment process

26. 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 ✔ ✗

27. A Simple RDR Example Root

28. Suitability of RDR for Worklets • 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.

29. Worklet Service Interface Requirements

30. Secondary Data Sources • 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

31. Worklet Process Log

32. Conclusion • 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