1 Analysis of workflows : Verification, validation, and performance analysis. Wil van der Aalst Eindhoven University of Technology Faculty of Technology Management Department of Information and Technology P.O. Box MB Eindhoven The Netherlands

2 Queuing models Basic characteristics: average number of arrivals per time unit: (mean arrival rate) average number that can be handled by one server per time unit:  (mean service rate) number of servers: c arrivals waiting service  c

3 Queuing models (2) Basic relationships: average time between arrivals: 1/ average service time: 1/  occupation rate:  c*  ) average number being served: r   c W,Lq S,L W (S) = average time in queue (system) Lq (L) = average number in queue (system) L = Lq + r S = W + 1/  Lq = * W L = * S (Little’s formula)

4 M/M/1 queue  1 Lq = (  L =  W =  S =  Assumptions: time between arrivals and service time follow a negative expontential distribution 1 server (c = 1) FIFO Also formulas for M/Er/1, M/G/1, M/M/c,... !

5 Exercise Calculate: occupation rates, average waiting time, average throughput time, average number in system. task1b task1a c3 c1 c21 6 difficult cases per hour c23 c22 1 resource, average service time of 8 minutes 1 resource, average service time of 2.66 minutes task2 1 resource, average service time of 2 minutes 18 easy cases per hour difficult cases easy cases Increase the occupation rate until 90%: average waiting time, average throughput time, average number in system.

6 Simulation Random walk through the reachability graph Computer experiment –pseudo random numbers –random generator Validation Statistical aspects –start run –subruns Animation Flexible No proof!

7 Workflow Management Systems : Functions, architecture, and products. Wil van der Aalst Eindhoven University of Technology Faculty of Technology Management Department of Information and Technology P.O. Box MB Eindhoven The Netherlands

8 Focus on "classical" workflow management systems, but... Four 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 (e.g., Staffware, MQSeries Workflow, FLOWer, COSA, Oracle BPEL, Filenet, etc.).

9 Basic idea Separation of control and execution. workflow management system application control (process logistics) execution (task oriented)

10 WfMC Reference model

11 Data inside a WFS

12 Interfaces Published in Handbook Demo’s Weak!

13 Potential problem workflow engine DBMS in-basket (worklist) applications serverclient

14 The ACID-properties, known from transaction processing, should hold. Atomicity (atomic, "everything or nothing", rollback if necessary) Consistency (a completed task results in a proper state of the system) Isolation (tasks do not affected each other, even if they are executed in parallel) Durability (the result of a completed task may not get lost; commit tasks)

15 Users of a WFS

16 Examples of systems COSA (demo) Staffware FLOWer …

17 Staffware Leading workflow management system (typically 25 percent of the global “pure” workflow market). Staffware PLC is headquartered in Maidenhead UK and has offices in 19 countries. Focus on performance and reliability rather than functionality (e.g., infinite scalability, fault tolerance, etc.) In the remainder, we present a small case study that is used to: –introduce the design tool and modeling language of Staffware, –show the management/administrator tools of Staffware, –demonstrate the end-user’s view of Staffware, and –show the need for analysis.

18 WfMC reference model

19 A small case study: Double Check (DC) Processing of insurance claims involving registration, two checks, and a payment of rejection Five tasks: –register (register insurance claim) –checkA (check insurance policy) –checkB (check damage reported) –pay (pay for the damage) –reject (inform customer about rejection) Registration is followed by two checks which can be handled in parallel. Each of the checks results in “OK” or “not OK”. If both are OK, pay otherwise reject. Three roles: register (for task register), checks (for both checks), and pay/reject (for final tasks). register checkA checkB pay reject