enabling flexibility in process-aware information...

P R E S E N T E D B Y B A R B A R A W E B E R

U N I V . O F I N N S B R U C K

Enabling Flexibility in Process-aware Information Systems

Challenges, Methods, Technologies

Content

Part 1 – Process-aware Information Systems Part 2 – Flexibility Issues Part 3– Flexibility Support for Pre-specified Process Models Pre-specified process models and flexibility-by-design Process configuration Flexible process execution and handling of anticipated exceptions Handling unforeseen exceptions Process Evolution Process Monitoring, Mining & Analysis

Content

Part 4– Loosely-specified Process Models Loosely-specified process models Constraint-based process models

B A R B A R A W E B E R U N I V . O F I N N S B R U C K

Business Processes and Workflows Process-aware Information Systems

A Retail Process

Mendling 2006

Welcome customer

Offer Clothes

Bill Clothes

Hand over clothes

Business Process Lifecycle

Evaluation

Design &Analysis

Configuration

Enactment

Design: Business Process Identification and

Modeling

Analysis:ValidationSimulationVerification

Configuration:System SelectionImplementation

Test and Deployment

Enactment: OperationMonitoring

Maintenance

Evaluation:Process Mining

Business Activity Monitoring

Administration and

Stakeholders

Fig 1.5. Business process lifecycle

Value to shareholders and competitiveness

Stakeholders

Process modeling

Process execution

Knowledge

Efficiency

IT agility

Compliance & consistency

Process monitoring Business insight

BPM adoption maturity

Transformation

Workers, supervisors, and managers CIO CFO CXO CEO

Lower Higher Higher

Customers and partners Forester 2007 BPM Market Overview

Process Optimization

BPM Value Proposition

Process-aware Information System

... Anwendungen / Application Server

Instance 4 Instance 3

Instance 7

Instance 12

Process-aware Information System (PAIS)

Process Execution Engine

Msg Queuing Time Mgmt Authorization

Late Modeling Web Clnt API Validatíon

Dyn. Change API Modeling API Admin. API

Exceptions Audit Trail ...

Process Engineer

Process Composer

Create Process Schema Modify Process Schema Check Process Schema …

Process Repository

Process Models

Application Components

Simple Process Model

Process Model S

Activity

XOR-Split/Join

AND-Split/Join

Patient Admission

Anamnesis & Clinical Examination

Non Operative Therapy

Sonography

Initial Treatment & Operation Planning

Non Operative Therapy 1

Operative Treatment

Discharge & Documentation

clinicalSuspicionOf CruciateRupture = „Yes“

cruciateRupture = „Yes“ and operationIndicated = „Yes“

Business Function 1

... Business

Function 2 Business

Function 3 Business

Function 4 Business

Function n

business functions

Function Perspective

EXECUTABLE PROCESS MODEL

control flow: order & execution constraints

Behavior Perspective

data objects & data flow

Information Perspective

time constraints (e.g., activity deadlines)

Time Perspective

organizational model (actors, roles,

organizational units)

Organization Perspective

activity implementations & application services

Operational Perspective

Built-time versus Run-time - Process Type versus Process Instance Level -

Business Process – System Perspective

Enabled

Process Schema S

Completed Skipped

Execution Trace: σ1 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „X-ray“>

Execution Trace: σ2 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „Non Operative Therapy“>

Process Instance I1 Process Instance I2

Activity

XOR-Split/Join

AND-Split/Join

Activity States:

Patient Admission

Sonography

Operative Treatment

Activity Lifecycle

Inactive Enabled Running Completed

Skipped Suspended Failed

enable start complete

fail skip disable

suspend resume

Offered Allocated Started Completed

Withdrawn

User Perspective and Work item Lifecycle

Joe Peter

MRT MRT

Process Instance I5

Patient Admission

Sonography

Operative Treatment

Discharge & Documentation x

Withdrawn

User Perspective

Joe Peter

MRT MRT

Process Instance I5

Patient Admission

Sonography

Operative Treatment

Let‘s do the MRT

Withdrawn

User Perspective

Joe Peter Process Instance I5

Patient Admission

Sonography

Operative Treatment

Withdrawn

User Perspective

Patient Admission

Sonography

Operative Treatment

Withdrawn

User Perspective

Patient Admission

Sonography

Operative Treatment

Initial Initial

Business Processes and Workflows Flexibility Issues

Process Spectrum

Process Spectrum From fully predictable and highly repetitive to Fully unpredictable and non repetitive

Processes on the right side of the spectrum are mostly knowledge-intensive

Unpredictability Course of action depends on situation-specific parameters

Non-repeatability Two process instances hardly look the same

Emergence Future course of action depends on knowledge gained

through activity execution

Knowledge-intensive Processes

Flexibility Needs

Variability is typical for many domains and requires that processes are handled differently depending on the particular context

Drivers Product and service variability Differences in regulations Different customer groups Temporal differences

Variability

Knowledge-intensive processes cannot be fully pre-specified, but require loose specifications

Drivers Unpredictability Non-Repeatability Emergence

Looseness

Ability to adapt the process and its structure to temporary events

Drivers Special Situations Exceptions

Anticipation of Adaptation Planned Unanticipated

Adaptation

Ability of the implemented process to change when the business process evolves

Drivers

Evolution

External Internal Changing Business Context

Changing Technological Context

Changing Legal Context

Organizational Learning

Real-world Process PAIS

Design Errors

Technical Problems

Poor Internal Quality

represented in

provide feedback to

Extent of Evolution Incremental Continuous Process Improvement

Revolutionary Business Process Reengineering

Duration Temporary Permanent

Evolution

Swiftness Deferred Ongoing instances are not affected

Immediate Ongoing instances are affected

Visibility Observable Behavior Internal Structure

Evolution

Flexibility Issues along the Process Lifecycle

Instance I1

x x E C

Instance I1

x x E C

Schema S‘:

Traditional Process Lifecycle Support

Process Execution

Process engineer / Process administrator

Process participant

Arbeitsliste Tätigkeit 1 Tätigkeit 2 Tätigkeit 3 Tätigkeit 4

Schema S:

x x E C

Instance I1

x x E C

Execution Log

Process Monitoring

Need for Process Adaptation (Support for Planned and Unplanned Exceptions /

Special Cases)

Need for Process Evolution

Need for Variability Support

Need for Looseness of Process Specifications

[WRW+09] 29

Flexibility Needs and Technological Requirements

Flexibility Need

Dimension Technological Requirement

Variability Configuration Looseness Loosely-specified processes Adaptation Planned

Unplanned Exception Handling Ad-hoc Changes

Evolution Deferred Evolution Immediate Evolution Poor Internal Quality Organizational Learning

Versioning Process Instance Migration Refactoring Monitoring, Analysis and Mining

Business Processes and Workflows Pre-specified Process Models and Flexibility by Design

Basic Control Flow Concepts – Activities

Atomic Activities

Complex Activities

Automated Web services, Java applications, database function

Human Electronic forms

Refer to sub-process models

Basic Control Flow Concepts

Control Connectors (i.e., Gateways) (X)OR-Split / (X)OR-Join AND-Split / AND-Join

Control Flow Edges Sequence Flow Default Path

Transition Conditions

Sequence Flow Default Path

Transition Conditions

AND Gateway Atomic Activity

Basic Control Flow Concepts - Example

XOR Gateway

Basic Data Flow Concepts

Data objects + Data edges Data objects can be linked to activities via data edges

Read access Write access

referenced by transition conditions attached to outgoing messages

Data Object Data Edge – Read Access

Data Edge – Write Access

End Message with Data Obejct

Invoice

Transition Condition references

SparePartsList

Basic Data Flow Concepts - Example

Process Fragments Single Entry

Single Exit regions

Single activities: R2, R3, R4 Nested:

R2, R3, R4, R5 and R12 are contained in R1 Disjoint:

R6 and R7 37

Process Fragments Single Entry

Single Exit regions

Single activities: R2, R3, R4 Nested:

R2, R3, R4, R5 and R12 are contained in R1 Disjoint:

R6 and R7

Process Fragment

Process Structure Tree

Decomposition of process model into process structure tree

[VVK09] 39

Control Flow Patterns

Sequence Parallel-Spit (AND-Split) Synchronization (AND-Join) Exclusive Choice (XOR-Split) Simple Merge (XOR-Join) Structured Loop

40 [RHA+06, AHK+03, Wes07]

Activity Lifecycle

Inactive Enabled Running Completed

Skipped Suspended Failed

enable start complete

fail skip disable

suspend resume

Sequence

AND-Split

AND-Join

XOR-Split

XOR-Join

Structured Loop

Deferred Choice

Interleaved Routing

Expressiveness and Flexibility by Design

Flexibility by Design (M

Events Related to the Execution of Activities or Transition Conditions

Examples for Events Explanation

start(A) Activity A started

complete(A:d1=v1) Activity A completed writing data object d1 with value v1

start(cond1) Evaluation of transition condition cond1 started

complete(cond1:true) Transition condition cond1 evaluated to true

start(cond2) Evaluation of transition condition cond2started

complete(cond2:false) Transition condition cond2 evaluated to false

start(B) Activity B started

Enabled

B) Execution Traces

Completed Skipped

σ1 = < start(1), complete(1:d1=v1), start(2), complete(2:d2=v2), start(3), complete(3,d3=v3;d4=v4), start(cond1), complete(cond1:true), start(cond2), complete(cond2:true)>

σ2 = < start(1), complete(1:d1=v5) >

Process Instance I1

Process Instance I2

Process Instance I3

Process Instance I4

Activity States:

A) Process Model Process Model S

C) Process Instances

1: Enter Repair Order 2: Determine Defect 3: Check Availability of Spare Parts 4: Order Spare Parts 5: Repair Car 6: Provide Replacement Car 7: Create Invoice 8: Notify Customer

Running

cond2 + + + +

+ + + +

d1: Repair Order d2: Repair Service Request d3: Spare Parts List d4: Estimated Duration d5: Invoice

σ3 = < start(1), complete(1:d1=v6), start(2), complete(2:d2=v7), start(3), complete(3,d3=v8;d4=v9), start(cond1), complete(cond1:false), start(cond2), complete(cond2:false), start(5), complete(5), start(7), start(8), complete(7:d5=v10), complete(8)>

+ + + +

σ4 = < start(1), complete(1:d1=v11), start(2), complete(2:d2=v12), start(3), complete(3,d3=v13;d4=v14), start(cond1), complete(cond1:true), start(cond2), complete(cond2:false), start(4), complete(4) >

Verification of Process Models

Soundness Option to Complete Proper Completion No dead activities

Data Flow Correctness No missing data No dead activities No lost updates

[WVA+09]

[RAS09]

Example: Option to Complete

Option to Complete A process instance, once started, can always complete.

Example: Proper Completion

Proper Completion When a process instance completes there exists no related activity of this instance which is still running or enabled.

Example: Dead Activity

No dead activities A process model does not contain any dead activity, i.e., for each activity there exists at least one completed trace producible on that model and containing this activity.

Example: Missing Data

Missing Data The data flow schema of a process model might cause missing data at run-time if a data object exists which can be read during run-time without having been written by any preceding activity or provided by the outside environment (i.e., by a start message).

Data Flow Errors: Unnecessary Data

Unnecessary Data A data object written by an activity of process model is called unnecessary if it is not read by any subsequent activity or transition condition or passed to the outside environment via an end message.

Data Flow Errors: Lost Updates

Lost Updates The data flow schema of a process model might cause lost data at run-time if a data object, which is written by an activity, is updated by a subsequent activity, but without reading the data object in between.

Well-stuctured versus Unstructured

A well-structured or block-structured process model is composed of blocks (Single-Entry Single-Exit fragments), which can be nested, but must not overlap

Blocks can be single activities, sequences, parallel branchings, alternative branchings, loop blocks or the entire process model

Unstructured models require advanced verification techniques

Unstructured models are more difficult to understand and are a considerable source of errors

Unstructured vs. well-structured Process Model

References

• [AHK+03] W.M.P van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Workflow Patterns. Distributed and Parallel Databases, 14(3), pages 5-51, July 2003.

• [RHA+06] N. Russell, A.H.M. ter Hofstede, W.M.P. van der Aalst, and N. Mulyar. Workflow Control-Flow Patterns: A Revised View. BPM Center Report BPM-06-22 , BPMcenter.org, 2006.

• [TAS09] Nikola Trcka, Wil M. P. van der Aalst, Natalia Sidorova: Data-Flow Anti-patterns: Discovering Data-Flow Errors in Workflows. CAiSE 2009: 425-439

• [VVK09] Jussi Vanhatalo, Hagen Völzer, Jana Koehler: The refined process structure tree. Data Knowl. Eng. 68(9): 793-818 (2009)

• [Wes07] Mathias Weske: Business Process Management: Concepts, Languages, Architectures, Springer 2007.

• [WVA+09] Wynn, M.T., Verbeek, H.M.W., Aalst, W.M.P. van der, Hofstede, A.H.M. ter and Edmond, D. (2009). Business process verification : finally a reality! Business Process Management Journal, 15(1), 74-92.

Business Processes and Workflows Configurable Process Models

Motivation – Change Management Process

3b) Stm. 3c) Stm.

4) Integration of Stm.

3a) Stm. Develop- ment (Dev.)

5) Permission

Project Leader

2) Request for Statements (Stm.)

Production- Planning (PP)

6) Realization

7) Completion

1) Change request Applier

x Decision Board

x Dev.

Responsible

Standard Process variant I: Quality issues affected

Process variant II: Low risk/costs; long to realize

3b) Stm. 3c) Stm.

3a) Stm. Dev.

5) Permission

Project Leader

PP Pilot

6) Realization

7) Completion

x Decision Board

x Dev.

Responsible <

Responsible

3d) Stm.

Process variant III: Low risk/ costs; fast to realize; affects quality issues

3b) Stm. 3c) Stm

3a) Stm. Dev.

5) Permission

Project Leader

PP Pilot

6b) Undo Realization

7) Completion

Decision Board

Responsible

< 6) Realization

3b) Stm. 3c) Stm.

3a) Stm. Dev.

5) Permission

Project Leader

PP Pilot

6b) Undo Realization

7) Completion

Decision Board

Responsible

3d) Stm.

6) Realization Dev.

Quality Department (QDept.)

Dev. Dev.

QDept.

Reception

Example: Vehicle Repair Process

Standardized Process

Repair Diagnosis Hand Over

Reception Repair Diagnosis Hand Over Final Check

Maintain

Variant 3: Fast Run and Security Critical Repair

Variant 2: Security Critical Repair Repair Hand Over

Maintain

Reception Repair Diagnosis Hand Over Final Check

Variant 1: Fast Run

Diagnosis

Reception

Motivation – Vehicle Repair Process

Conclusion: Many processes with different variants, depending on the process context.

Fzg. Annahme

Reparatur Diagnose

d) Variant 3: Fast Run and security-critical Repair

Fzg. Übergabe

Prüfung Fzg. Annahme

Reparatur Diagnose

c) Variant 2: Security-critical Repair

Wartung

Prüfung Fzg. Annahme

Reparatur Diagnose Dauer = 2 Dauer = 2

b) Variant 1: Fast Run

Fzg. Übergabe

a) Standardized Process

Reception Repair Diagnosis Hand Over

Maintain

Multi-Model Solution

Single-Model Solution

Reception Hand Over

Diagnosis

Maintain

Diagnosis Shortened

Final Check

Variant 2 or Variant 3

Standard or Variant 1

Standard or Variant 2

Repair

Standard or Variant 2 or Variant 3 Standard or

Variant 2

Conclusion: Both approaches can be supported by commercial BPM tools, but do not enable transparent and explicit management of process variants

Configuring Process Variants in Existing BPM Tools

Motivation – Handling Medical Examinations 68

Variety of related variants

• Same business

objective • Commonalities

• Differences due

to varying application context

Two Main Approaches

Behaviour-based Approaches for Capturing Process

Variability

Structural Approaches for Capturing Process Variability

Two Main Approaches

Behaviour-based Approaches for Capturing Process

Variability

Configurable Nodes

Main idea: configurable nodes Extension of an existing process modeling language by adding

configurable elements E.g., C-EPC, E-YAWL

Configurable nodes represent variation points and can be associated with configuration alternatives

Possible combinations of configuration alternatives can be restriceted through constraints

Configurable Activities

Included (ON) Excluded (OFF) Conditional (OPT)

Configurable Control Connectors

Configurable OR Configurable XOR Configurable AND

Can be configured to a connector

equally restrictive or less restrictive

Configurable Control Connectors

Configurable OR Configurable XOR Configurable AND

Can be configured to a connector

equally restrictive or less restrictive

Configuration Requirements and Guidelines

Requirements Define constraints

over the configuration alternatives that can be chosen

Guidelines Do not prescribe

mandatory constraints, but serve as recommendations

Configurable Model: Handling Medical Examinations

Hiding and Blocking

Capturing variability in a language-independent way

(1) Represent process model as a labeled transition system (LTS)

(2) Apply hiding and blocking operators for configuring LTL-based reference process models

Expressing Process Behavior through Labeled Transition Sytems

Hiding and Blocking

Blocking: enables encapsulation – execution of an atomic activity (event is disabled)

Hiding: enables abstraction – execution of an event becomes non-observable (activity is replaced by silent activity)

Hiding and Blocking Example

Two Main Approaches

Behavior-based Approaches for Capturing Process

Variability

Deriving Variants through Structurally Changing a Base Process Model

Representing a Process Family

Through a configurable base process model Policy 1: Standard Process Policy 2: Most frequently used process Policy 3: Superset of all process variants Policy 4: Intersection of all process variants

and a related set of pre-specified changes Adjustment points Change options (i.e., a grouping of change operations)

Examples of Change Operations

Constraining Allowed Combinations of Change Operations

Implications Mutual exclusion Hierarchy

Context Model

Context-specific selection of change operations Context variables

The Whole Approach

(1) Select relevant options All change options whose context rules evaluate to true are selected

(2) Ensure compliance of the selected options with option constraints Compliance with option constraints has to be checked

(3) Determine the order in which options shall be applied (4) Configuring the base process by applying the selected

options and their change operations to it

Questionnaire-driven Process Configuration

(1) Questionnaire Model

(2) Using Questionnaire Models for Configuring a Reference Process Model (a) Linking Domain Facts and Configurable Activities

(b) Linking Domain Facts and Configurable Connectors

Questionnaire Model

Linking Domain Facts and Configurable Activities

Linking Domain Facts and Configurable Connectors

Feature Diagram

References

• [GAV+08] Florian Gottschalk, Wil M. P. van der Aalst, Monique H. Jansen-Vullers, Marcello La Rosa: Configurable Workflow Models. Int. J. Cooperative Inf. Syst. 17(2): 177-221 (2008)

[HBR10] Alena Hallerbach, Thomas Bauer, Manfred Reichert: Capturing variability in business process models: the Provop approach. Journal of Software Maintenance 22(6-7): 519-546 (2010)

[HBR09] Alena Hallerbach, Thomas Bauer, Manfred Reichert: Guaranteeing Soundness of Configurable Process Variants in Provop. CEC 2009: 98-105

[HBR08] Alena Hallerbach, Thomas Bauer, Manfred Reichert: Managing Process Variants in the Process Life Cycle. ICEIS (3-2) 2008: 154-161

• [Ros09] M. La Rosa: Managing Variability in Process-Aware Information Systems, PhD Thesis, Queensland University of Technology, Brisbane, Australia. April 2009.

• [RDH09] M. La Rosa, M. Dumas, A.H.M. ter Hofstede: Modelling Business Process Variability for Design-Time Configuration. In J. Cardoso, W.M.P. van der Aalst (editors), Handbook of Research on Business Process Modeling, IDEA Group – Information Science Reference, 2009.

• [RLS+07] M. La Rosa, J. Lux, S. Seidel, M. Dumas and A.H.M. ter Hofstede: Questionnaire-driven Configuration of Reference Process Models. In Proc. CAiSE 2007, Trondheim, Norway. LNCS Vol. 4495, pp. 424–438, Springer, 2007.

• [RoAa07] Michael Rosemann, Wil M. P. van der Aalst: A configurable reference modelling language. Inf. Syst. 32 (1): 1-23 (2007)

Business Processes and Workflows Exception and Compensation Handling

Process Adaptations

Planned Unplanned

Exception Handling Ad-hoc Changes

Exception Handling in PAIS

Activity Failure

Sources for Exceptions

Technical Semantical

Deadline Expiry

Resource Unavailability

Inconsistence real-world / PAIS

Constraint Violations

Upon detection of a particular exception

a suitable handler is chosen

Trying Alternatives

Ordered Unordered

Exception Handler

Add Behavior

Deferred Fixing

Immediate Fixing

Retry Exception-driven Rework

Cancelling Behavior

Reject Compensate Resource Patterns

Delegate Escalate …

Exception Handling

Simple Handler

Exception Handling

Scopes

Exception Handling Patterns - Ordered Alternatives -

101 [LCB+10]

Exception Handling Patterns - Unordered Alternatives -

Exception Handling Patterns - Immediate Fixing -

Exception Handling Patterns - Deferred Fixing -

Exception Handling Patterns - Retry -

Exception Handling Patterns - Reject -

Exception Handling Patterns - Compensate -

Resource Patterns

Exception Handling Patterns (like Deferred Fixing, Reject etc.) focus on behavioral changes

Many exceptions (e.g., resource unavailability or deadline expiry) require changes regarding resource perspective like delegation, escalation or reallocation

108 [RHE+04]

Resource Patterns

Selected Resource Patterns

Flexible Handling of Work Items

Application of Exception Handling patterns often requires changes to the lifecycle of work items.

Work items may have to be Skipped Redone Done ahead of time Canceled Suspended/Resumed

111 [RAH+06]

Flexible Handling of Work items

Flexible Handling of Workitems

A B C D

System Log Bc Cc Ac

Commit Commit Commit

normal processing

Abort!

Rollback

Abort Transaction (Rollback Work)

Compensation of C

Compensation of B

Compensation of A ready!

The SAGAS concept

Compensation Information

[GaSa87]

Compensation Handling - Sagas

Compensation Spheres

process

scope scope

Scopes provide a context which influences the execution behavior of its enclosed activities

Isolated scopes provide control of concurrent access to shared resources

Local declarations: partner links, message exchanges, variables, correlation sets

Local handlers: event handlers, fault handlers, a termination handler, and a compensation handler

Compensation handler to undo persisted effects of already

completed activities

Termination handler to deal with forced scope termination

(external faults)

primary activity

Compensation and Fault Handling in BPEL (1)

process

invoke

fault handler

compensate compensation

handler

compensate

compensation handler

invoke

1. Do some work (successfully invoke two services)

2. Invoke another service (throws fault)

3. The fault triggers the process-level fault handler

4. Compensate previous work

5. Propagate compensation

6. Undo work (in reverse order)

This example shows the default compensation behavior supported by BPEL; i.e., a completed scope is com-pensated by invoking the compensation handlers of its constituting activities in reverse order. How-ver, a more specific compensation handler for a scope may be provided as well (e.g., only com-pensating some of the already completed activities or invoking a specific process dealing with the exception).

Compensation and Fault Handling in BPEL (2)

Exlets

119 [AHA+07]

References

[AHA+07] Michael Adams, Arthur H. M. ter Hofstede, Wil M. P. van der Aalst, David Edmond: Dynamic, Extensible and Context-Aware Exception Handling for Workflows. OTM Conferences (1) 2007: 95-112

[LCO+10]Barbara Staudt Lerner, Stefan Christov, Leon J. Osterweil, Reda Bendraou, Udo Kannengiesser, Alexander E. Wise: Exception Handling Patterns for Process Modeling. IEEE Trans. Software Eng. 36(2): 162-183 (2010)

[MoSa87] Hector Garcia-Molina, Kenneth Salem: Sagas. SIGMOD Conference 1987: 249-259 [NAH06] N. Russell, W.M.P. van der Aalst, and A.H.M. ter Hofstede. Exception Handling Patterns in

Process-Aware Information Systems. BPM Center Report BPM-06-04 , BPMcenter.org, 2006. [RHE+04] N. Russell, A.H.M. ter Hofstede, D. Edmond, and W.M.P. van der Aalst. Workflow Resource

Patterns. BETA Working Paper Series, WP 127, Eindhoven University of Technology, Eindhoven, 2004.

Business Processes and Workflows Handling Unforeseen Exceptions

Process Adaptations

Planned Unplanned

Exception Handling Ad-hoc Changes

User View on an Ad-hoc Process Change

Explanation Operation Risks

Check Anesthesiology

Examination

Start Examinations

U Wallace, Edgar

U Miller, Anne

U Smith, Karl

U Jones, Isabelle

Exception – We need an additional lab test !

Lab Test

Explanation Operation Risks

Check Anesthesiology

Examination

Behavioral Changes Require Structural Process Model Adaptations

Behavioral Changes Require Adaptations of the Process Instance State

Behavioral Changes Must not Violate Process Model Soundness and Proper Instance Execution

No Proper Completion

ensured. End node can be reached while B is still enabled

Data flow error caused by

missing data

+ + x x x

Process Instance Level

Execution Trace: σ1 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „X-ray“>

Execution Trace: σ2 = < „Patient Admission“>

Process Instance I1

Process Instance I2

x x x + +

Process Type Level

Process Schema S

Activity

XOR-Split/Join

AND-Split/Join

Patient Admission x Anamnesis &

Clinical Examination

Sonography

Operative Treatment

+ + x x

Ad-hoc Changes of a Process Instance Must Not Affect any Other Process Instances

Change Primitives Add node Remove node Add edge Remove edge Move edge

High-Level Change Operations Combines a set of change primitives Referred to as Adaptation Patterns in the following

Structurally Adapting Pre-Specified Process Models

Adaptation Patterns

130 [WRR08]

Adaptation Patterns versus Change Primitives

Change Primitives Process Adaptation Patterns

Operate on single elements of process schema

Provide high-level change operations

Correctness has to be checked after adaptation

Correctness-by-construction

No Assumption regarding structure of process schema

Process schema needs to be block-structured

Dynamic Change Bug

Correctness of Process Instance Changes

Ensuring Dynamic Correctness

Need for general correctness criterion

State Compliance

invoice make invoice

Schema S‘:

send invoice

Schema S:

activated step

May the depicted schema change be propagated to the process instance?

[ReDa98, RRW08a, RRD04a, RRD04b]

Ensuring Dynamic Correctness

invoice make invoice

Schema S‘:

send invoice

Schema S:

activated step

<A> , , <D> Trace reproducible on new schema?

More complicated: loop backs

Further challenges: - How to efficiently check for compliance? - How to efficiently migrate process instances? [RRD04a, RRD04b]

+ + x x x

Execution Trace: σ3 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „MRT“, „X-ray“, „Sonography“>

Process Instance I3

Process Instance Level

Process Type Level

Process Schema S

Activity

XOR-Split/Join

AND-Split/Join

Sonography

Operative Treatment

+ + x x

I3 is not state compliant with change

Delete (I3, MRT)

[ReDa98]

User Assistance & Change Reuse (1)

The ProCycle (= ADEPT + CBRFlow) Approach for Assisting Users in Defining and Reusing Changes:

Annotate ad-hoc changes with information about the reasons for their introduction

Support users in retrieving past ad-hoc changes applied in similar context

Assist users in reusing a past ad-hoc change when coping with an exceptional situation

[RWR+05, WRW+09, WRR+05, WRW06, WWB04]

Patient Admission

Sonography

Operative Treatment

Process Instance I1 Delete(I1,MRT)

pdc1 = The treatment of cruciate ruptures routinely includes a magnetic resonance tomography (MRT), an X-ray and a sonography. However, for a particular patient the MRT may have to be skipped as the respective patient has a cardiac pacemaker. solc1 = <Delete(SI,MRT)> qaSetc1= {(Does the patient have a cardiac pacemaker?, patient.problemList.hasPacemaker = ‘Yes‘)}

freqc1 = 1

Memorization of instance deviations including their application context

Application Context Model

List of Question with Possible Answers

Answer Questions with Answer Expressions

Process participant

Exception for Instance I

Create List of Questions with Possible Answers

Calculate Similarity and Rank Cases

Add answered questions to query qu

Answer Question

Semi-automated retrieval of similar instance deviations using conversational case-based reasoning

Initiate Case Retrieval

Show Ranked Cases +

CCBR Component

qaSetc1 = {(Does the patient have a cardiac pacemaker?, Patient.problemList.hasPacemaker = 'Yes')}

List of Questions with Possible Answers Question Possible Answers

Does the patient have a cardiac pacemaker? {Patient.problemList.hasPacemaker = ‚Yes‘, OTHERANSWER}

Does the patient have fluid in the knee? {‚A significant amount‘, OTHERANSWER}

Does the patient have an acute effusion of the knee? {‚Yes‘, OTHERANSWER}

qaSetc2 = {(Does the patient have fluid in the knee?, 'A significant amount'),

(Does the patient have an acute effusion of the knee?, 'Yes')} Case c1

Case c2

Query qu

Question Given Answer Does the patient have a cardiac pacemaker? OTHERANSWER

List of Retrieved Cases for Query qu Case Appl. Context Similarity

c2 50%

Retrieving similar instance deviations based on the actual context

),(),(*21),( +

qaSetqaSetqudiffqaSetqusamecqusim

Query qu‘

Question Given Answer Does the patient have a cardiac pacemaker? OTHERANSWER

Does the patient have fluid in the knee? ‚A significant amount‘

List of Retrieved Cases for Query qu‘ Case Appl. Context Similarity

c2 75%

Execution Trace: Patient Admission, Anamnesis & Clinical Examination, X-Ray, MRT

List of Retrieved Cases Case Similarity

c2 75% c2 does not have any effect, but is adjustable

c1 0% c1 is not case compliant and not adjustable

Retrieving similar instance deviations based on the actual context + status

Sonography

Operative Treatment

Process Instance I1

Are the instance deviations of these cases compliant with the process instance to be modified?

Is change Δc1

= <Delete(SI,MRT)>

applicable?

Is change Δc2=<Insert(SI, Follow-Up Examination,

Non Operative Therapy, XOR-Join1), Insert(SI, Puncture, Follow-Up

Examination, XOR-Join1>

applicable? YES, but no effect

References

[ReDa98] Manfred Reichert, Peter Dadam: ADEPTflex-Supporting Dynamic Changes of Workflows Without Losing Control. J. Intell. Inf. Syst. 10(2): 93-129 (1998)

[RRD04a] Stefanie Rinderle, Manfred Reichert, Peter Dadam: Correctness criteria for dynamic changes in workflow systems - a survey. Data Knowl. Eng. 50(1): 9-34 (2004)

[RRD04b] Stefanie Rinderle, Manfred Reichert, Peter Dadam: Flexible Support of Team Processes by Adaptive Workflow Systems. Distributed and Parallel Databases 16(1): 91-116 (2004)

[RRW08] Stefanie Rinderle-Ma, Manfred Reichert, Barbara Weber: Relaxed Compliance Notions in Adaptive Process Management Systems. ER 2008: 232-247

[RWR+05] Stefanie Rinderle, Barbara Weber, Manfred Reichert, Werner Wild: Integrating Process Learning and Process Evolution - A Semantics Based Approach. Business Process Management 2005: 252-267

References

[WRR05] Barbara Weber, Stefanie Rinderle, Werner Wild, Manfred Reichert: CCBR-

Driven Business Process Evolution. ICCBR 2005: 610-624 [WRR08] Barbara Weber, Manfred Reichert, Stefanie Rinderle-Ma: Change

patterns and change support features - Enhancing flexibility in process-aware information systems. Data Knowl. Eng. 66(3): 438-466 (2008)

[WRW+09] Barbara Weber, Manfred Reichert, Werner Wild and Stefanie Rinderle-Ma: Providing Integrated Life Cycle Support in Process-Aware Information Systems. In: International Journal of Cooperative Information Systems 18 (2009) 1, pp. 115-165.

[WRW06] Barbara Weber, Manfred Reichert, Werner Wild: Case-Base Maintenance for CCBR-Based Process Evolution. ECCBR 2006: 106-120

Barbara Weber, Werner Wild, Ruth Breu: CBRFlow: Enabling Adaptive Workflow Management Through Conversational Case-Based Reasoning. ECCBR 2004: 434-448

Business Processes and Workflows Process Monitoring, Mining & Analysis

Activity Event User Timestamp

Patient Admission Start Garry 2007/09/08 15:30

Patient Admission Complete Garry 2007/09/08 15:45

Start Helen 2007/09/09 11:00

Complete Helen 2007/09/09 11:45

X-Ray Start Paula 2007/09/09 13:00

Sonography Start Sandy 2007/09/09 13:20

X-Ray Complete Paula 2007/09/09 14:00

Sonography Complete Sandy 2007/09/09 14:30

Start Peter 2007/09/10 09:00

Complete Peter 2007/10/10 09:45

Follow-up Examination Start Helen 2007/10/12 11:07

Follow-up Examination Complete Helen 2007/10/12 11:20

Puncture Start Helen 2007/10/12 11:21

+ + x x x

c.) Execution Log - Process Instance 4711

Process Instance 4711

a.) Process Model

Process Model S

10 4 5

+ + x x x

b.) Process Instances

1: Patient Admission 2: Anamnesis & Clinical Examination 3: Non Operative Therapy 4: x-Ray 5: MRT 6: Sonography

7: Non Operative Therapy 1 8: Initial Treatment & Operation Planning 9: Operative Therapy 10: Discharge & Documentation

Enabled Completed Skipped Activity States:

Insert(S, Follow-up Examination, Non Operative Therapy, XOR-Join 1) Insert(S, Puncture, Follow-up Examination, XOR-Join 1)

Delete (S,MRT)

XOR-Join1

d.) Change Log - Process Instance 4711 Change TX

Applied Changes User Timestamp

001 Delete (S, MRT) Paula 2007/09/09 12:50

002 Insert(S, Follow-up Examination, Non Operative Therapy, XOR-Join 1)

Helen 2007/10/10 09:00

002 Insert(S, Puncture, Follow-up Examination, XOR-Join 1)

Helen 2007/10/10 09:00

Process Instance 4711 2007/09/09 10:30

+ + x x x

XOR-Join1

Execution and Change Logs - Restoring Structure and State of Process Instances -

Execution Log - Process Instance 4711, Log Entries before 2007/09/09 10:30

+ + x x x

XOR-Join1

+ + x x x

XOR-Join1

Change TX

001 Delete (S, MRT) Paula 2007/09/09 12:50

Execution Log: Log Entries between 2007/09/09 10:30 and 2007/09/09 12:45

Change Log: Log Entries between 2007/09/09 10:30 and 2007/09/09 12:45

X-Ray Start Paula 2007/09/09 13:00

Sonography Start Sandy 2007/09/09 13:20

X-Ray Complete Paula 2007/09/09 14:00

Sonography Complete Sandy 2007/09/09 14:30

Start Peter 2007/09/10 09:00

Complete Peter 2007/10/10 09:45

Execution Log: Log Entries between 2007/09/09 12:45 and 2007/10/10 09:46

+ + x x x

XOR-Join1

Change Log: Log Entries between 2007/09/09 10:30 and 2007/09/09 12:45

+ + x x x

11: Follow-up Examination 12: Puncture

XOR-Join1

Change TX

002 Insert(S, Follow-up Examination, Non Operative Therapy, XOR-Join 1)

Helen 2007/10/10 09:00

002 Insert(S, Puncture, Follow-up Examination, XOR-Join 1)

Helen 2007/10/10 09:00

Design-time (a-priori) and run-time (a-posteriori) questions

processdesign

implementation/configuration

processenactment

diagnosis

Run-time Design-time

- process mining - verification - validation - performance analysis

Process mining can be used for: Process discovery (What is the process?) Conformance Testing (Are we doing what was specified?) Log verification (Is there any undesired behavior?)

process mining

Register order

Prepareshipment

Ship goods

(Re)send bill

Receive paymentContactcustomer

Archive order

Process Mining

informationsystem

operationalprocess

processmodels

eventlogs

models

processdiscovery

conformancetesting

records

configures

supports/controls

(un)desiredproperties

log-based verification

refers to

What can Process Mining be used for?

MXML Format

Process Discovery – Reversing the Process

1) basic performance metrics

2) process model Start

Register order

Prepareshipment

Ship goods

(Re)send bill

Receive paymentContactcustomer

Archive order

3) organizational model 4) social network

5) performance characteristics

If …then …

153 [ARS05, ARV+10, AWM04, GGM+07, GGP+06, HeKa04, LRW10, MWA07, Sch04, WWA+10]

A) Original Process Model

Original Process Model S

10 4 5

+ + x x x

1: Patient Admission 2: Anamnesis & Clinical Examination 3: Non Operative Therapy 4: x-Ray 5: MRT 6: Sonography

7: Non Operative Therapy 1 8: Initial Treatment & Operation Planning 9: Operative Therapy 10: Discharge & Documentation

XOR-Join1

B) Discovered Process Model

Activities FollowUpExamination and Puncture are not part of the original model, but appear in 132 traces

Activity MRT is executed less frequently than X-Ray and Sonography, i.e., it has been deleted for some of the instances

[WeAa03]

Conformance Testing

Registerorder

Prepareshipment

Shipgoods

Receivepayment

(Re)sendbill

Contactcustomer

Archiveorder

Materialis released

TO itemconfirmed

withoutdifferences

Warehouse/Stores

Transferorderitem

is confirmed

Paymentmust

be effected

PurchaseRequisition

Requirementfor materialhas arisen

Requisitionreleased

for schedulingagreement

schedule/SA release

InvoiceVerification

Purchaserequisitionreleased

for purchaseorder

Inbounddeliveryentered

Goodsreceived

Goodsreceiptposted

GoodsReceipt

Purchaseorder

created

Purchasing

Invoicereceived

Conformance Testing - Example -

Log based verification

Can there any undesired properties be observed in the log? 157 [ABD07]

Lecture Workflow Management by Will van der Aalst (Univ. of Eindhoven), http://www.workflowcourse.com

Some slides of the process mining part are based on

References

[ABD07] Wil M. P. van der Aalst, H. T. de Beer, Boudewijn F. van Dongen: Process Mining and Verification of Properties: An Approach Based on Temporal Logic. OTM Conferences (1) 2005: 130-147

[ADH+03] W.M.P. van der Aalst, B.F. van Dongen, J. Herbst, L. Maruster, G. Schimm, and A.J.M.M. Weijters. Workflow Mining: A Survey of Issues and Approaches. Data and Knowledge Engineering , 47(2):237-267, 2003.

[ARS05] Wil M. P. van der Aalst, Hajo A. Reijers, Minseok Song: Discovering Social Networks from Event Logs. Computer Supported Cooperative Work 14(6): 549-593 (2005)

[ARV+10] Wil M. P. van der Aalst, Vladimir Rubin, H. M. W. Verbeek, Boudewijn F. van Dongen, Ekkart Kindler, Christian W. Günther: Process mining: a two-step approach to balance between underfitting and overfitting. Software and System Modeling 9(1): 87-111 (2010)

[AWM04] W.M.P. van der Aalst, A.J.M.M. Weijters, and L. Maruster. Workflow Mining: Discovering Process Models from Event Logs. IEEE Transactions on Knowledge and Data Engineering 16(9):1128-1142, 2004.

References

[GGM+07] Gianluigi Greco, Antonella Guzzo, Giuseppe Manco, Domenico

Saccà: Mining unconnected patterns in workflows. Inf. Syst. 32(5): 685-712 (2007)

[GGP06] Gianluigi Greco, Antonella Guzzo, Luigi Pontieri, Domenico Saccà: Discovering Expressive Process Models by Clustering Log Traces. IEEE Trans. Knowl. Data Eng. 18(8): 1010-1027 (2006)

[HeKa04] Joachim Herbst and Dimitris Karagiannis: Workflow Mining with InWoLvE. Computers and Industry 53(3): 245-264 (2004).

[LRW10] Chen Li, Manfred Reichert, Andreas Wombacher: The Minadept Clustering Approach for Discovering Reference Process Models Out of Process Variants. Int. J. Cooperative Inf. Syst. 19(3-4): 159-203 (2010)

[MWA07] Ana Karla A. de Medeiros, A. J. M. M. Weijters, Wil M. P. van der Aalst: Genetic process mining: an experimental evaluation. Data Min. Knowl. Discov. 14(2): 245-304 (2007)

References

[PiGo04] S. Pinter and M. Golani: Discovering workflow models from activities' lifespans. Computers and Industry 53(3): 283-296 (2004).

[RoAa08] Anne Rozinat, Wil M. P. van der Aalst: Conformance checking of processes based on monitoring real behavior. Inf. Syst. 33(1): 64-95 (2008)

[Sch04] Guido Schimm: Mining exact models of concurrent workflows. Computers and Industry 53(3): 265-281 (2004).

[WeAa03] A.J.M.M. Weijters and W.M.P. van der Aalst. Rediscovering Workflow Models from Event-Based Data using Little Thumb. Integrated Computer-Aided Engineering, 10(2):151-162, 2003.

[WWA+10] Lijie Wen, Jianmin Wang, Wil M. P. van der Aalst, Biqing Huang, Jiaguang Sun: Mining process models with prime invisible tasks. Data Knowl. Eng. 69(10): 999-1021 (2010)

Business Processes and Workflows Process Evolution

Drivers

Evolution

External Internal Changing Business Context

Changing Technological Context

Changing Legal Context

Organizational Learning

Real-world Process PAIS

Design Errors

Technical Problems

Poor Internal Quality

represented in

provide feedback to

Schema Evolution 164

Change Support Features Schema Evolution, Version Control and Instance Migration

Schema Evolution Changes at the process type level

How to deal with running instances when adapting the original process schema? Scenario 1: No version control Scenario 2: Co-existence of instances of old / new schema Scenario 3: Change propagation and instance migration

Schema is overwritten and instances are migrated

+ + E F X

Type change overwrites schema S

Process Schema S’

Schema Evolution

Process Schema S

Process Instance I1

Change is propagated to

all running process instances

Process Instance I2

Process Instance I1

Process Instance I2

Insert X between A and B Insert Y between C and AND-Join1

AND-Split1 AND-Join1

+ + E F

+ + E F X

Inconsistent state

Scenario 1 - No Version Control 166

Co-existence of instances of different schema versions

Scenario 2 - Version Control

+ + E F X

Type change results into a new version of schema S

Process Schema S’

Schema Evolution

Process Schema S

Process Instance I1

Process Instance I2

Process Instance I4

Process Instance I5

Old instances remain with schema S Instances created from S (before schema evolution) Instances created from S’ (after schema evolution)

+ + E F A B D

+ + E F X

+ + E F

+ + E F A B

+ + E F X

Compliant instances are migrated to the new schema

Scenario 3 – Instance Migration

Type change results into a new version of schema S

Process Schema S‘

Schema Evolution

Process Schema S

Process Instance I1

Propagation of compliant

process instances to schema S’

(incl. state adaptations)

Process Instance I2

Process Instance I1

Migration of compliant process instances to S’

+ + E F A B D

+ + E F X

+ + E F

+ + E F Process Instance I2 not compliant with S’

+ + E F X

[RRD04a] 168

Process Model Refactoring

(1) Identify refactoring opportunities

(2) Determine which refactoring should be applied

(3) Ensure that the applied refactoring preserves model behavior

(4) Apply the refactoring

(5) Assess the effect of the refactoring on the quality characteristics of the process model repository

Catalogue of Process Model Smells

PMS5: Lazy Process Model

PMS8: Frequently Occurring Variant Change

[WeRe08, WRR+xx] 170

Process Model Smells: Example

PMS3: Redundant Process Fragment

PMS1: : Non Intension Revealing Naming of Activity

PMS4: Large Process Model

Catalogue of Process Model Refactorings

RF5: Replace Process Fragment by Reference

RF8: Remove Redundancies

RF9: Generalize Variant Change

RF11: Pull up Instance Change

PMS3: Redundant Process Fragment RF5: Replace Process Fragment by

Reference

PMS1: : Non Intension Revealing Naming of Activity

PMS4: Large Process Model

Process Model After Refactoring

Instance I1

x x E C

Instance I1

x x E C

Schema S‘:

Traditional Process Lifecycle Support

Process Execution

Process participant

Integrated Lifecycle Support for Adaptive and Dynamic Processes (1)

Schema S:

x x E C

Instance I1

x x E C

Execution Log

Process Monitoring

Instance I1

x x E C

Instance I1

x x E C

Schema S‘:

Lifecycle Support in adaptive PAISs

Process Execution

Process Monitoring

Change Log

Instance-specific Change

Exception: Delete (I1, E)

Process participant

Schema S:

x x E C

Instance I1

x x E C

Execution Log

Instance I1

x x E C

Instance I1

x x E C

Schema S‘:

Revised lifecycle for dynamic processes – The ProCycle Approach

Process Execution

Process Monitoring

Change Log

Instance-specific Change

Exception: Delete (I1, E)

Process participant

Memorization and Change Reuse

Case Base

Derive Process Type Change

Schema S:

x x E C

Instance I1

x x E C

Execution Log

Migrate Case Base

181 [WRW+09]

References

• [RRD04a] Stefanie Rinderle, Manfred Reichert, Peter Dadam: Correctness criteria for dynamic changes in workflow systems - a survey. Data Knowl. Eng. 50(1): 9-34 (2004)

• [WeRe08] B. Weber and M. Reichert: Refactoring Process Models in Large Process Repositories In Proc. CAiSE'08 (2008), pp. 124-139

• [WRR+11] B. Weber and M. Reichert and H. Reijers and J. Mendling: Refactoring Large Process Model Repositories Computers and Industry 62(2011) 5, pp. 467-486.

• [WRW+09] Weber B., Reichert M., Wild W. and Rinderle-Ma S.: Providing Integrated Life Cycle Support in Process-Aware Information Systems. In: International Journal of Cooperative Information Systems 18 (2009) 1, pp. 115-165.

Business Processes and Workflows Loosely Specified Processes

Process Spectrum

Process Spectrum From fully predictable and highly repetitive to Fully unpredictable and non repetitive

Processes on the right side of the spectrum are mostly knowledge-intensive

Unpredictability Course of action depends on situation-specific parameters

Non-repeatability Two process instances hardly look the same

Emergence Future course of action depends on knowledge gained

through activity execution

Knowledge-intensive Processes

Loosely specified Processes

To deal with unpredictability, non repeatability and emergence loosely specified processes keep (parts) of the process unspecified during build-time

Loosely specified processes are characterized by decision deferral Decision on how the process exactly looks like are deferred to the

run-time

Taxonomy of Decision Deferral

Decision Deferral Patterns

Late Selection Pattern

Late Selection – The Worklets Approach

190 [AHE+06]

Late Selection – Static Process-based Composition

191 [CPE+08, AVM+04, CaSh01, Kli00]

Late Modeling

Late Modeling – Pockets of Flexibility

193 [SSO01, SSO05]

Late Modeling – Interleaved Routing

194 [RHA+06]

Late Modeling – Dynamic Process-based Composition

195 [SuWe03, ZNB+08]

Ad-hoc Composition - Declare

196 [AaPe06, PSS+07]

Iterative Refinement - Alaska

197 [WZP+09]

Iterative Refinement – Hierarchical Task Networks

198 [ELM+01]

References

[AaPe06] van der Aalst, W., Pesic, M.: DecSerFlow: Towards a Truly Declarative Service Flow Language. Tech. Rep., BPMcenter.org (2006) [AHE+06] Adams, M., ter Hofstede, A., Edmond, D., van der Aalst, W.: A Service-Oriented Implementation of Dynamic Flexibility in Workflows. In: Proc. Coopis’06 (2006) [AVM+04] R. Aggarwal, Kunal Vernal, John Miller and William Milnor : Constraint-driven Web Service Composition in METEOR-S: In Proc. SCC‘04, pp. 23-30. [CaSa01] Fabio Casati, Ming-Chien Shan: Dynamic and adaptive composition of e-services. Inf. Syst. 26(3): 143-163 (2001) [CPE+08] Gerardo Canfora, Massimiliano Di Penta, Raffaele Esposito, Maria Luisa Villani: A framework for QoS-aware binding and re-binding of composite web services. Journal of Systems and Software 81(10): 1754-1769 (2008) van Elst; Andreas Lauer; Heiko Maus; Sven Schwarz; Michael Sintek, A.A.A.B.L.: Frodo: A framework for distributed organizational memories. milestone 1: Requirements analysis and system architecture. Dfki document (2001). URL http://www.dfki.unikl.de/dfkidok/publications/D/01/01/abstract.html [Kli00] Justus Klingemann: Controlled Flexibility in Workflow Management. CAiSE 2000: 126-141

References

[PSS+07] Pesic, M., Schonenberg, M., Sidorova, N., van der Aalst, W.: Constraint-Based Workflow Models: Change Made Easy. In: Proc. CoopIS’07, pp. 77–94 (2007) [RHA+06] N. Russell, A.H.M. ter Hofstede, W.M.P. van der Aalst, and N. Mulyar. Workflow Control-Flow Patterns: A Revised View. BPM Center Report BPM-06-22 , BPMcenter.org, 2006. [SSO01] Sadiq, S., Sadiq, W., Orlowska, M.: Pockets of flexibility in workflow specifications. In: Proc. ER’01, pp. 513–526 (2001) [SSO05] Sadiq, S., Sadiq, W., Orlowska, M.: A Framework for Constraint Specification and Validation in Flexible Workflows. Information Systems 30(5), 349 – 378 (2005) [SuWe03] Hilmar Schuschel, Mathias Weske: Integrated Workflow Planning and Coordination. DEXA 2003: 771-781 [ZNB+08] Liangzhao Zeng, Anne H. H. Ngu, Boualem Benatallah, Rodion M. Podorozhny, Hui Lei: Dynamic composition and optimization of Web services. Distributed and Parallel Databases 24(1-3): 45-72 (2008)

Business Processes and Workflows Declarative Processes

Declarative Processes

Declarative approaches allow for Late Composition of business processes and are thus highly flexible

Advantages commonly attributed to declarative processes Support for partial workflows (Wainer et al. 2004 [WBB04])

Allow users to defer decisions to run-time (Weber et al. 2008 [WeRR08])

Absence of over-specification (Pesic et al. 2007 [PSSA07])

More maneuvering room for end users (Pesic et al. 2007 [PSSA07]),

Declarative Processes

Instead of describing exactly how a business process should be executed, declarative processes describe the activities to be executed and constraints prohibiting undesired behavior (e.g., selection

constraints, ordering constraints, resource constraints)

203 [PSSA07]

Modeling Declarative Processes

B A B C

Declarative Process Model S

A B NOT CO-EXISTENCE A and B are mutually exclusive

A RESPONSE If A is executed, B needs to executed afterwards

Execution trace producible on S: σ1 = < A, A, D, E, A> σ2 = < B, C, F, E, B> σ3 = < B, E, F> Execution trace not producible on S: σ4 = < A, C, E, A> σ5 = < B, D, C> σ6 = < A, D, B, F, E>

Activities A

Constraints C

Legend

C2 C2 C1

Modeling Declarative Processes

5 Major Categories Selection Constraints Relation Constraints Branching Constraints Negation Constraints Choice Constraints

Activity a must occur at least n times in every trace

existence(a, n) a

Activity a must occur at most n times in every trace

at_most(a, n) a

Activity a must occur exactly n times in every trace

exactly(a, n) a n

Example: existence(A,1) Supported traces, e.g.: <A>,<A,A,A> Unsupported trace, e.g.: <>

Example: at_most(A,3) Supported traces, e.g.: <>,<A>,<A,A>,<A,A,A> Unsupported trace, e.g.: <A,A,A,A>

Example: exactly(A,2) Supported trace, e.g.: <A,A> Unsupported traces, e.g.,: <A>,<A,A,A>

Activity a must be the first executed activity in every trace init(a)

a init

Example: init(A) Supported trace, e.g.: <A,C,D,B> Unsupported trace, e.g.: <D,C,B,A> SE

If a is executed, b needs to be executed afterwards (but not necessarily directly after)

response(a, b) Example: response(A,B) Supported traces, e.g.: <A,B>,<A,A,A,B>, Unsupported trace, e.g.: <A>

Activity b needs to be preceded by activity a

precedence(a, b) Example: precedence(A,B) Supported traces, e.g.: <A,B>,<A,B,B,B>,<A> Unsupported trace, e.g.:

If a is executed, b needs to be executed afterwards (but not necessarily directly after); activity b needs to be preceded by activity a

succession(a, b) Example: succession(A,B) Supported traces, e.g.: <A,B>,<A,A,A,B>,<A,B,B,B> Unsupported traces, e.g.: <A>,

b a If activity a is executed, activity b needs to be executed either before or after a

respondedExistence(a, b) Example: respondedExistence(A,B) Supported traces, e.g.: <A,B>,<B,A>,<A,B,A>, Unsupported trace, e.g.: <A>

RELATION CONSTRAINTS

If a is executed, at least one activity from set {b1,..,bn} has to be executed afterwards (but not necessarily directly after)

response(a, {b1,..,bn}) Example: response(D,{E,F}) Supported traces, e.g.: <D,E>,<D,F>,<F>,<D,E,F> Unsupported trace, e.g.: <D>

If one activity from set {a1,..,am} is executed, at least one activity from set {b1,..,bn} has to executed afterwards. To execute an activity from set {b1,..,bn}, at least one activity from set {a1,..,nm} has to be executed before. succession ({a1,..,am},

{b1,..,bn})

Example: succession({D},{E,F}) Supported traces, e.g.: <D,F>,<E,F>,<D,E,F> Unsupported traces, e.g.: <D>,<E>,<F>

… b1

BRANCHING CONSTRAINTS

Activity a and b cannot co-occur in any trace

neg_coexistence(a, b)

Example: neg_coexistence(A,B) Supported traces, e.g.: <A>, Unsupported traces, e.g.: <A,B>,<B,A>

If activity a is executed, activity b must not be executed afterwards anymore

neg_response(a, b) Example: neg_response(A,B) Supported traces, e.g.: <A>,,<B,A> Unsupported trace, e.g.: <A,B>

NEGATION CONSTRAINTS

At least m distinct activities out of n activities from set {a1,…,an}, m ≤ n must be executed

m of n

Example: choice(2-of-3, {A,B,C}) Supported traces, e.g.: <A,B>,<B,C>,<A,C>,<A,B,C> Unsupported traces, e.g.: <A>,<B,B>

choice(m-of-n, {a1,..,an})

Exactly m distinct activities out of n activities from set {a1,…,an}, m ≤ n must be executed

m of n

Example: choice(2-of-3, {A,B,C}) Supported traces, e.g.: <A,B>,<B,C>,<A,C> Unsupported traces, e.g.: <A>,<B,B>,<A,B,C>

exact_choice(m-of-n, {a1,..,an})

CHOICE CONSTRAINTS

Enabled Activities

B A B C

Declarative Process Model S A B NOT CO-EXISTENCE

A and B are mutually exclusive

Activities A

Constraints C Partial Trace Set of Enabled Activities

< > {A, B, C, D, E, F}

<A> {A, C, D, E, F} B is not included since partial trace <A, B> violates constraint C1

<A, C> {A, C, D, E, F} B is not included since partial trace <A, B> violates constraint C1

A B C D E F

Execution Termination

Process Instantiation

Process Termination

Activities A

Constraints C

Activities A, B, C, D, E, F and G are enabled

Instance I can terminate, i.e., no

termination constraints violated

A B C D E F

Process Termination

Activities A

Constraints C

A A started A completed

As A is executed B cannot be executed

any longer

No termination constraint violations, i.e., I can terminate

A B C D E F

Process Termination

Activities A

Constraints C

C started C completed C

Constraint violations, i.e., I cannot terminate

A B C D E F

Process Termination

Activities A

Constraints C

E started E completed E

Constraint violations, i.e., I cannot terminate

A B C D E F

Process Termination

Activities A

Constraints C

F started F completed F

No constraint violations, i.e., I can

terminate

Overriding of Constraints

A B C D E F

Process Termination

Activities A

Constraints C

Warning “F not executed after C”

Soft constraints can be ignored during

process execution

Users terminating process instance I are

informed about constraint violation

Execution trace Instance I1: σ1 = < A, C>

S [ΔS>S ‘ with ΔS = <addConstraint(exactly_1(A)), addConstraint(respondedExistence(D,E))>

EXACTLY_1 A must be executed exactly once A

σ1 is producible on S‘

Migrate

Execution Trace Instance I2: σ2 = < A, C, A, F>

Execution Trace Instance I3: σ3 = < A, D, F>

σ2 not producible on S‘

Migrate

Don‘t Migrate

Activities A Constraints C

Declarative Process Model S‘

1 A C3

Legend

B A RESPONDED EXISTENCE If A is executed, B needs to executed either before or after A

Ad-hoc changes and Schema Evolution

Execution trace Instance I1: σ1 = < A, C>

S [ΔS>S ‘ with ΔS = <addConstraint(exactly_1(A)), addConstraint(respondedExistence(D,E))>

EXACTLY_1 A must be executed exactly once A

Migrate

Execution Trace Instance I2: σ2 = < A, C, A, F>

Execution Trace Instance I3: σ3 = < A, D, F>

σ2 not producible on S‘

Migrate

Don‘t Migrate

Declarative Process Model S‘

1 A C3

Legend

B A RESPONDED EXISTENCE If A is executed, B needs to executed either before or after A

Ad-hoc changes and Schema Evolution

Changed regulations require a

modification.

Modification may refer to a single instance (ad-hoc

change) or all process instances (schema

evolution)

Changes are only applied to instances which are compliant with change

The Declare System

van der Aalst, Pesic and Schonenberg 2009 [APS09]

Composing Declarative Processes with Declare

Executing Declarative Processes with Declare

Late Composition in Alaska Simulator (1)

Declarative Process Model

Calendar

Process Instance I1

New Process Instance I1 is created

Available Actions B

User can partially model the process

instance

Current Problems

Calendar

Process Instance I1

Available Actions B

Process Instance is incrementally

validated

Current Problems

F must be executed

Calendar

Process Instance I1

Available Actions B

Current Problems

User resolves problems A

Calendar

Process Instance I1

Available Actions B

Current Problems

User starts execution of Instance I1

Calendar

Process Instance I1

Available Actions B

Current Problems

Instance I1 can be altered at all times

Calendar

Process Instance I1

Available Actions B

Current Problems

Execution of Instance I1 is proceeded

The Alaska Simulator

Is an interactive planning tool providing support for late composition

Uses journey as a metaphor for business processes

Actions, accommodations and routes correspond to

activities

Selection, ordering and resource constraints are relevant in both settings

Information on benefits (i.e., business value), cost and duration are essential for

decision making

Effectively handling uncertainty is

fundamental in both domains

http:\\alaskasimulator.org

Weber, Zugal, Pinggera and Wild 2009 [WZP+09]

Both the planning of a journey and the

execution of a business process is oriented

towards a goal

Declarative workflows provide a lot of flexibility to the end user, but on the other hand require adequate user support

Schonenberg, Weber, Aalst and van Dongen 2008 [SWD+08]

Process-aware Information System (PAIS)

Process Engine

Recommendation Service

Partial case, enabled activities

Recommendation result (ordered enabled activities)

Event Log logs

Optimization Goal

Plugin

Assistance and Support for Declarative Workflows 228

References

[AaPe06] W.M.P. van der Aalst and M. Pesic : DecSerFlow: Towards a Truly Declarative Service Flow Language. In WS-FM 2006, 2006, pp 1-23.

[APS09] Wil M. P. van der Aalst, Maja Pesic, Helen Schonenberg: Declarative workflows: Balancing between flexibility and support. Computer Science - R&D 23(2): 99-113 (2009)

[PSS+07] Pesic, M., Schonenberg, M., Sidorova, N., van der Aalst, W.: Constraint-Based Workflow Models: Change Made Easy. In: Proc. CoopIS’07, pp. 77–94 (2007)

[SWD+08] Helen Schonenberg, Barbara Weber, Boudewijn F. van Dongen, Wil M. P. van der Aalst: Supporting Flexible Processes through Recommendations Based on History. BPM 2008: 51-66

[WRR08] Barbara Weber, Manfred Reichert, Stefanie Rinderle-Ma: Change patterns and change support features - Enhancing flexibility in process-aware information systems. Data Knowl. Eng. 66(3): 438-466 (2008)

References

[WBB04] Jacques Wainer, Fábio de Lima Bezerra, Paulo Barthelmess: Tucupi: a flexible workflow system based on overridable constraints. SAC 2004: 498-502

[WRZ+09] Barbara Weber, Hajo A. Reijers, Stefan Zugal, Werner Wild: The Declarative Approach to Business Process Execution: An Empirical Test. CAiSE 2009: 470-485

--- Coming soon ---

Enabling Flexibility in Process-aware

Information Systems Challenges, Methods, Technologies

Springer 2012

Manfred Reichert and Barbara Weber

enabling flexibility in process-aware information...

Documents

best in class efficacy enabling optical flexibility with...

enabling fast it - dell emc · 6/16/2014 · enabling fast...

creating and enabling environment for power plant...

enabling flexibility of business processes by...

10 good reasons - govdatadownload...good reasons netapp for...

enabling flexibility with intelligent file virtualization |...

datapath download documents - user manual€¦ ·...

flexible working and work-life...

enabling connectivity with service oriented...

enabling 5g from start to finish · • high thermal and...

creating and enabling environment for power plant...

microgrid enabling resilient and cost effective access to...

enabling agility, flexibility and innovation - … ·...

extended split-issue: enabling flexibility in the hardware...

interoperable, secure group communication · solution for...

design scienceresearch in information systems andsoftware...

every device. every network. every team. connected...

flexibility, velocity and customer centricity€¦ ·...

extended split-issue: enabling flexibility in the hardware...

foster wheeler cfb technology - enabling fuel flexibility...