1. 1 Patterns and Products Wil van der Aalst Eindhoven University of Technology Faculty of Technology Management Department of Information and Technology P.O. Box 513 5600 MB Eindhoven The Netherlands w.m.p.v.d.aalst@tm.tue.nl See www.workflowpatterns.com!

2. 2 Selection of workflow management systems An approach based on patterns

3. 3 Workflow patterns initiative www.workflowpatterns.com Started in 1996, joint work TU/e and QUT (1999). Different types of patterns: –Control-flow patterns –Data patterns –Resource patterns Some of the people involved: Arthur ter Hofstede (QUT), Marlon Dumas (QUT), Nick Russel (QUT), Petia Wohed (DSV), Bartek Kiepuszewski (QUT), Alistair Barros (SAP), Oscar Ommert (EUT), Ton Pijpers (ATOS), Nataliya Muylar (EUT), Maja Pesic (EUT), Alexander Norta (EUT), Eric Verbeek, et al.

4. 4 20+ Control flow patterns Focus: The routing of work from one activity to another, i.e., a partial order of activities.

5. 5 Classes of control-flow patterns Basic control flow patterns – the five most basic patterns Advanced branching and synchronization patterns – more complicated splits and joins Structural patterns – absence of syntactical requirements that limit the modeler Patterns involving multiple instances – e.g., order lines in an order State-based patterns – states are more than queues in front of activities Cancellation Patterns – removing work-items and cases

6. 6 Basic control flow patterns – Pattern 2 Parallel Split

7. 7 Basic control flow patterns – Pattern 3 Synchronization simple right??

8. 8 Basic control flow patterns – Pattern 4 Exclusive choice XOR- split

9. 9 Basic control flow patterns – Pattern 5 Simple merge simple right??

10. 10 It's not that simple! There are many ways to split! There are many ways to join!

11. 11 Exclusive choice versus Deferred choice Not that simple 1: The moment of choice matters!

12. 12 startregister send_form evaluate process_complaint check_proc process_form time-out archive ready c1 c2 c3 c4 c5 c6 c7 Example: Deferred Choice (Pattern 16)

13. 13 Not that simple 2: There are many ways to join! COSA (Ley): Places have capacity 1. Oracle BPEL/FLOWer: True and false tokens. Staffware (TIBCO): Race conditions. SAP Business Workflow (SAP): split-join block with a minimum or an end condition. Etc. A join B C

14. 14 Staffware: Unintended race conditions

15. 15 Basic Control Flow Patterns Pattern 1 (Sequence) Pattern 2 (Parallel Split) Pattern 3 (Synchronization) Pattern 4 (Exclusive Choice) Pattern 5 (Simple Merge) Advanced Branching and Synchronization Patterns Pattern 6 (Multi-choice) Pattern 7 (Synchronizing Merge) Pattern 8 (Multi-merge) Pattern 9 (Discriminator) More patterns... Structural Patterns Pattern 10 (Arbitrary Cycles) Pattern 11 (Implicit Termination) Patterns involving Multiple Instances Pattern 12 (Multiple Instances Without Synchronization) Pattern 13 (Multiple Instances With a Priori Design Time Knowledge) Pattern 14 (Multiple Instances With a Priori Runtime Knowledge) Pattern 15 (Multiple Instances Without a Priori Runtime Knowledge) State-based Patterns Pattern 16 (Deferred Choice) Pattern 17 (Interleaved Parallel Routing) Pattern 18 (Milestone) Cancellation Patterns Pattern 19 (Cancel Activity) Pattern 20 (Cancel Case)

16. 16 Evaluation

17. 17 39 Data patterns Focus: Data patterns aim to capture the various ways in which data is represented and utilized in workflows.

18. 18 Classes of data patterns Data visibility — relating to the extent and manner in which data elements can be viewed by various components of a workflow process. Data interaction — focusing on the manner in which data is communicated between active elements within a workflow. Data transfer — which consider the means by which the actual transfer of data elements occurs between workflow components and describe the various mechanisms by which data elements can be passed across the interface of a workflow component. Data-based routing — which characterize the manner in which data elements can influence the operation of other aspects of the workflow, particularly the control flow perspective.

19. 19 Data visibility – Pattern 3 Scope data

20. 20 Data interaction – Patterns 14-17

21. 21 Resource patterns

22. 22 43 Resource patterns Focus: The gap between the creation of a work-item (activity that needs to be executed) and the actual execution by some resource.

23. 23 Classes of resource patterns Creation patterns – design-time work allocation directives Push patterns – workflow system proactively distributes work items Pull patterns – resources proactively identify and commit to work items Detour patterns – re-routing of work items Auto-start patterns – automated commencement Visibility patterns – observability of workflow activities Multiple resource patterns – work allocation involving multiple participants or resources

24. 24 Push patterns – Pattern 17 Shortest Queue push workitem to shortest queue

25. 25 Pull patterns – Pattern 23 Resource Initiated Exec. pull workitem to start working

26. 26 Auto-start patterns – Pattern 38 Piled execution the completion of one activity starts another cf. Pattern 39 Chained execution

27. 27 FLASH Animations of Patterns

28. 28 Evaluation of 5 concrete WFM systems

29. 29 F our types of "workflow-like" systems: 1.Information systems with hard-coded workflows (process& organization specific). 2.Custom-made information systems with generic workflow support (organization specific). 3.Generic software with embedded workflow functionality (e.g., the workflow components of ERP, CRM, PDM, etc. systems). 4.Generic software focusing on workflow functionality Oracle BPEL (Oracle) Staffware (TIBCO) COSA (COSA GmbH) FLOWer (Pallas Athena) SAP Business Workflow/Webflow (SAP AG)

30. 30 Oracle BPEL (Oracle) Staffware (TIBCO) COSA (COSA GmbH) FLOWer (Pallas Athena) SAP Business Workflow/Webflow (SAP AG)

31. 31 Staffware (TIBCO)

32. 32 Staffware: Control flow perspective startstop step (i.e., task) event step automatic step wait (i.e., AND-join) condition (i.e., XOR- split) complex router (OR-join/AND-split)

33. 33 OR-join AND-split

34. 34 Example

35. 35 Staffware: Control flow evaluation Classical problems: –no states –only internal choices Evaluation based on: Workflow Patterns (2002) new features (prediction/fragments) do not influence evaluation

36. 36 Staffware: Data perspective Ability to define forms Variables of different types Evaluated in Workflow data patterns 2005. Weaker than most other systems.

37. 37 Staffware: Resource perspective Concept of work queues Evaluated in Workflow resource patterns 2005. Weaker than most other systems.

38. 38 Staffware: Conclusion Positive Widely used Easy to use High performance Interesting new concepts, e.g., prediction and fragments Negative Limited functionality in all perspectives. Little flexibility. Future within Tibco is less clear.

39. 39 COSA (COSA GmbH)

40. 40 COSA: Control flow perspective Based on Petri nets Lots of functionality

41. 41 COSA: Control flow evaluation Benefits from Petri net basis. Support for advanced synchronization and multiple instances patterns could be better. Evaluation based on: Workflow Patterns (2002)

42. 42 COSA: Data perspective Variables at different levels. Good support through tool agents. Evaluated in Workflow data patterns 2005. Weaker than most other systems.

43. 43 COSA: Resource perspective One of the most powerful tools on the market. Multiple dimensions and rules. Evaluated in Workflow resource patterns 2005.

44. 44

45. 45 COSA: Conclusion Positive Powerful language Unique features in each of the perspectives Negative No integrated forms environment Little operational flexibility Future of COSA is less clear

46. 46 Oracle BPEL (Oracle)

47. 47 Oracle: Control flow perspective Based on BPEL

48. 48 BPEL(4WS) – Business Process Execution Language for Web Services Compromise between IBM and Microsoft. Merges WSFL and XLANG. Two styles of working: graph based and structured. Expressive but complex language. Support by many vendors: IBM Websphere, Oracle BPEL, and at least 16 more products. In April 2003, BEA Systems, IBM, Microsoft, SAP AG and Siebel Systems submitted BPEL4WS 1.1 to OASIS. Version 2.0 will have subtle but significant differences. Two flavors: executable and abstract (non-executable)

49. 49 Constructs Primitive activities invoke, invoking an operation on some web service; receive, waiting for a message from an external source; reply, replying to an external source; wait, waiting for some time; assign, copying data from one place to another; throw, indicating errors in the execution; terminate, terminating the entire service instance; and empty, doing nothing. Structured activities sequence, for defining an execution order; switch, for conditional routing; while, for looping; pick, for race conditions based on timing or external triggers; flow, for parallel routing; and scope, for grouping activities to be treated by the same fault-handler. Activities can be nested. Can be connect though links.

50. 50 Oracle: Control flow evaluation Support similar to BPEL (2 exceptions). Evaluation based on: Pattern-based Evaluation of Oracle-BPEL (v.10.1.2), N.A. Mulyar, 2005. few ratings have been changed to make a fair comparison possible

51. 51 Oracle: Data perspective Similar to BPEL, e.g. scope (create and scope data), assign (copy and modify), invoke (exchange with external entities), etc. XML based. Powerful but complicated. See Pattern-based Evaluation of Oracle-BPEL (v.10.1.2), N.A. Mulyar, 2005.

52. 52 Oracle: Resource perspective Not part of BPEL (cf. BPEL4people). Oracle specific task implementations. Close to programming. See Pattern-based Evaluation of Oracle-BPEL (v.10.1.2), N.A. Mulyar, 2005.

53. 53 Oracle: Conclusion Positive Based on BPEL (emerging industry standard) Powerful language Negative Based on BPEL (close to programming and a bit immature)

54. 54 SAP Business Workflow/Webflow (SAP AG)

55. 55 SAP: Control flow perspective Two views: native view and EPC view. Block structured. e.g. sequence:

56. 56 Routing elements

57. 57 parallel routing three types of choices

58. 58 join can hove a condition and/or lower bound two types of loops

59. 59 SAP: Control flow evaluation Classical language with classical capabilities. See Pattern-based Evaluation of SAP Business Workflow, 2005.

60. 60 SAP: Data perspective Data is stored in containers holding values or references to (SAP) objects (e.g., documents, masterdata, etc.). Workflow containers and task containers are linked through bindings.

61. 61 SAP: Resource perspective Organizational units have positions that may or may not be occupied. Positions may be associated to multiple jobs (kind of role). You can assign a task to –an organizational unit, if it is to apply to all subordinate positions –a job, if it is to apply to all positions described by the job –a position, if it is to apply to those persons (employees) or users who hold the position –a person (employee), if it is to apply to this person

62. 62 Logging in SAP Workflow

63. 63 SAP: Conclusion Positive Integration in SAP environment (for those that have SAP): –free –support –solid future (although technology may change towards BPEL) Negative Integration in SAP environment (for those that do not have SAP). Limited functionality in all perspectives. Little flexibility.

64. 64 FLOWer (Pallas Athena)

65. 65 FLOWer: Control flow perspective Block structured (similar to BPEL) but with excellent support for multiple instances. Can be generated from Protos. Case handling principle.

66. 66 Partly block structured: choices, loops, etc. require an additional level

67. 67 FLOWer: Control flow evaluation Powerful language. Many +/- because of case handling concept. Evaluation based on: Workflow Patterns (2002) more recent releases also support synchronizing merge.

68. 68 FLOWer: Data perspective Case handling concept: data driven. Forms play inportant role. Multiple instance data. Evaluated in Workflow data patterns 2005.

69. 69 FLOWer: Resource perspective Three roles for step in the process (execute, redo, skip). Hierarchies can be defined independent of process. Various was to view/distribute work. Evaluated in Workflow resource patterns 2005.

70. 70 Forms

71. 71

72. 72 FLOWer: Conclusion Positive Highly expressive language More flexible Powerful forms environment Strong presence in The Netherlands Negative Complicated organizational model and more work needed to restrict people (if needed).

73. 73 Other aspects important for evaluation Price Reliability/stability vendor Product support (training, etc.) Implementation support Performance (load and response times) Application integration Technical constraints (e.g., databases, etc.)...