1 Important issues for the future Adaptive and interorganizational workflows 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 Adaptive workflow Workflows are subject to change. Expected exceptions can be handled in a predefined manner. However, this is very expensive! Unexpected exceptions cannot be handled using predefined mechanisms. Therefore it is important to consider workflows that adapt.

3 groupware adaptive workflow (production) workflow structured unstructured information centric process centric  freedom, flexibility  no support, no control, no MI  support, control, MI  limited freedom, no flexibility

4 Workflow Management task case resource work item = case + task activity = case + task + resource process dimension resource dimension case dimension Focus on process dimension and the interplay between cases and processes in the fourth dimension. change

5 Changes: type, scope, and time changes restart on-the-fly entry time structural individual proceed transfer extend replace re-order scope time type ad-hoc evolutionary

6 Individual changes Just one case is affected (ad-hoc change) Each case has a private process or change description Time of change: entry time –the process is fixed the moment the case starts on-the-fly –the process may change during the execution of the case

7 Structural changes Evolution: all future cases are affected (in principle) Cases share a common process description What to do with existing cases? backward recovery –all cases are aborted and restarted forward recovery –abort and handle outside system proceed (versions) –old cases are handled the old way –new cases are handled the new way transfer (dynamic change) –old cases are moved to the new process –not always possible!

8 Problem 1: Correctness Two types of correctness notions: syntactic –connectedness, termination, absence of livelock and deadlock –does not depend on the contents of tasks –soundness property semantic –contents of tasks is considered –performance: time and quality –conformance to: »specification »template »old process –using notions of structure, (bi)simulation, inheritance, observable behavior

9 Correctness (2) Another criterion to classify errors: transient –does not affect new cases –will disappear by ad-hoc problem solving –can be very expensive permanent –affects all new cases –will not disappear by itself –can be very expensive # # t t

10 Errors resulting from change transient permanent syntacticsemantic Typically, standard verification techniques only work for syntactic & permanent errors! Today’s workflow management systems do no support verification at all!  

11 Permanent/syntactic error

12 Transient/semantic problem

13 Dynamic change problem Structural change with case transfer Transfer of cases is not always possible See: [Ellis/Keddara/Rozenberg9], [Ellis/Keddara/Wainer98], [Agostini/Michelis98], [Voorhoeve/Aalst97], [Aalst/Basten/.. 99].

14 Problem 2: Management information In a workflow management system there are often multiple versions of one process. In case of evolutionary change there are only a few versions but in case of frequent ad-hoc changes thousands of versions (compare with variant BOM) may coexist. There is a need for aggregation: mapping all variants onto one process for a concise view on the workflow, I.e. a greatest common divisor or least common multiple! There is a need for abstraction: abstracting from details of the process(es) but still insight in future developments.

15

16 Interorganizational workflow E-commerce and virtual/extended enterprise result in interorganizational workflows Coordination/collaboration versus autonomy Frequent, distributed, and dynamic changes

17 Example

18 Example (contd.) public workflow

19 Example (contd.) partitioned workflow

20 Example (contd.) A causal relation is added between process_cost_statement and create_specification. From a local perspective this seem harmless. However, the resulting IOWF deadlocks! private workflow of the contractor

21 Example (contd.) An alternative design in harmony with the public workflow. private workflow of the contractor

22 Example (contd.) private workflow of the subcontractor The alternative procedure (procedure_2) may seem harmless from a local perspective. However, the external behavior changes!

23 Example (contd.) private workflow of the subcontractor An alternative design in harmony with the public workflow.

24 Example (contd.) overall workflow Combining the two original (i.e., incorrect) private workflows results in an overall workflow with potential deadlocks and a behavior different as agreed in the public workflow.

25 overall workflow

26 Case study: E-bookstore The processing of customer orders. Four domains: –customer, –bookstore, –publisher, –and shipper.

27 Step 1 public workflow

28 Step 2 partitioned workflow

29 Step 2 (contd.)

30 Step 2 (contd.)

31 Step 2 (contd.)

32 Step 2 (contd.)

33 Step 3 private workflow

34 Step 3 (contd.) private workflow

35 Step 3 (contd.) private workflow

36 The overall workflow is sound and a subclass of the public workflow!