Modeling Control Objectives for Business Process Compliance: Modeling Control Objectives for Business Process Compliance Shazia Sadiq, Guido Governatori, Kioumars Naimiri1 School of Information Technology & Electrical Engineering
Brisbane, Australia
Telephone (61-7) 3365 3984, Facsimile (61-7) 3365 4999
shazia@itee.uq.edu.au www.itee.uq.edu.au 1SAP Research Centre CEC Karlsruhe, SAP AG, Vincenz-Prießnitz-Str.1 76131 Karlsruhe, Germany kioumars.namiri@sap.cpm
What is Compliance: What is Compliance Regulatory
Basel II
Sarbanes-Oxley
OFAC (USA Patriot Act)
OSFI “blocked entity” lists
HIPAA
Graham-Leach-Bliley Standards
Best practice models
SAP solution maps
ISO 9000
Medical guidelines Contracts
Service Agreement
Customer Contract
Warranty
Insurance Policy
Business Partnership
A consequence of non-compliance?: A consequence of non-compliance? Acknowledgements: Prof. Michael Ward, School of Medicine, UQ
Compliance Examples from Healthcare: Compliance Examples from Healthcare In patient processes
Data completeness compliance
Pathology product distribution
Time compliance
General practice
Data protection compliance
Acute disease management
Monitoring compliance
Outsourcing
Blocked entities compliance
Post-op care
Medical guidelines compliance - Scope of Consideration -
Evidence of Compliance can be found (or created) in IT Systems!
Compliance Pipeline: Compliance Pipeline Internal (Governance) or External (Regulations/Standards/Contracts) generate compliance requirements Consultants define Control Objectives to fulfill compliance obligations Control Objectives analyzed in terms of risk and necessary internal controls required for “effective and efficient” implementation of control objectives Proposed internal controls are built into business processes / transactions Operational practices are monitored for deviation from prescribed internal controls e.g. prevent unauthorized use of purchase order process e.g. unauthorized creation of purchase orders and payments to non-existing suppliers e.g. the creation and approval of purchase orders must be undertaken by two separate purchase officers Compliance by Design Detection of non-compliance Holistic Compliance Regimen
A Methodology for Compliance by Design: A Methodology for Compliance by Design Controls Directory Management
Ontological Alignment
Modeling Control Objectives
Process Model Enrichment
Event Monitoring
Methodology: Methodology Controls Directory Management
Ontological Alignment
Modeling Control Objectives
Process Model Enrichment
Event Monitoring
Methodology: Methodology Controls Directory Management
Ontological Alignment
Modeling Control Objectives
Process Model Enrichment
Event Monitoring
Methodology: Methodology Controls Directory Management
Ontological Alignment
Modeling Control Objectives
Process Model Enrichment
Event Monitoring
Formal language based on deontic logic to represent and analyze normative positions stemming from compliance requirements
Methodology: Methodology Controls Directory Management
Ontological Alignment
Modeling Control Objectives
Process Model Enrichment
Event Monitoring purchase-to-pay scenario
Process Model Enrichment through Control Tags: Process Model Enrichment through Control Tags Control Tags provide a means of annotating control objectives (and constituent internal controls) on a business process model, thus providing a clear separation from business objectives
Flow Tag: A flow tag represents a control objective that would impact on (the flow of) the business activities, e.g. approval of leave must occur before payment for travel.
Data Tag: A data tag identifies the data retention and lineage requirements, e.g. a medical practice must retain the time of commencement of pathology tests.
Resource Tag: A resource tag represents controls relating to access, role management and authorization, e.g. persons performing cash application and bank reconciliation must be different as it allows differences between cash deposited and cash collections posted to be covered up.
Time Tag: A time tag identifies controls for meeting time constraints such as deadlines and maximum durations, e.g. a water leakage complaint must be investigated within 12 hours of lodging.
Process Model Enrichment tag identification: Process Model Enrichment tag identification
Process Model Enrichment tag visualization: Process Model Enrichment tag visualization
Methodology: Methodology Controls Directory Management
Ontological Alignment
Modeling Control Objectives
Process Model Enrichment
Event Monitoring complete implementation of the BPM lifecycle may not exist
deviations may exist even in the presence of compliance aware process designs
Operational practices are monitored for deviation from prescribed internal controls Ref: Compliance Pipeline
Summary: Summary
What next?: What next? Analysis of enriched process models
Creation of tag views
What next?: What next? Analysis of enriched process models
Measurement of compliance distance
Formal Contract Language (FCL) : Formal Contract Language (FCL) Compliance is a relationship between processes and “normative/regulatory” documents/specifications
FCL is a combination of an efficient non-monotonic formalism and a deontic logic of violations offering the right trade off between expressive power and computational complexity.
The aim of FCL is to capture and reason with the normative notions needed to capture, model and implement processes.
Deontic logic of violation to reason with obligations, permissions, prohibitions, violations (and reparations)
Non-monotonic logic (Defeasible logic) to express normative exceptions
FCL Basics: FCL Basics
FCL is a rule based formalism
FCL expressions (rules) are built from ¬ (negation), O (obligation) P (permission) and (violation operator)
r: A1, …, An O B1 O B2 … O Bm
Violation/reparation chains
GoodShipmentNotice OsSendGood1Day OsRefund2days PpChargePenalty
Expressing exceptions
r: surgery O consent
s: emergency, unconscious P ¬ consent
s > r
FCL Reasoning Phases: FCL Reasoning Phases Merging normative clauses
Making implicit conditions explicit
Remove redundancies
Detect conflicts
Derive conclusions
FCL Tools (prototype): FCL Tools (prototype) Integrated rule editor and engine (the engine can handle 100.000+ rules)
What next?: What next? Empirical testings for FCL
Pilot study based on FDA process for IND – Investigational New Drug Application Coversheet
Encoding of Clause 67 of FIDIC (Project Contract Management Standard)
Related Publications: Related Publications
Process Variance as a Corporate Resource
Ruopeng Lu and Shazia Sadiq (2007) On the Discovery of Preferred Work Practice through Business Process Variants. 26th International Conference on Conceptual Modeling (ER 2007) Nov 05-09, 2007. Auckland, New Zealand.
Ruopeng Lu, Shazia Sadiq (2006) Managing Process Variants as an Information Resource. 4th International Conference on Business Process Management (BPM2006), Vienna, Austria, 2006
Ruopeng Lu, Shazia Sadiq, Guido Governatori (2006) Utilizing Successful Work Practice for Business Process Evolution. 9th International Conference on Business Information Systems (BIS2006), Klagenfurt, Austria, May 31 -June 22, 2006
Shazia Sadiq, Wasim Sadiq, Maria Orlowska (2005) A Framework for Constraint Specification and Validation in Flexible Workflows. Information Systems Volume 30, Issue 5, July 2005. Process Data Quality
Shazia Sadiq, Xiaofang Zhou, Maria Orlowska (2007) Data Quality – The Key Success Factor for Data Driven Engineering. In Frontiers of Data Driven Engineering (FDDE2007) at IFIP International Conference on Network and Parallel Computing. Sep 18-21, 2007. Dalian, China.
Shazia Sadiq, Maria Orlowska, Wasim Sadiq (2007) Induction of Data Quality Protocols into Business Process Management. Proceedings of the 9th International Conference on Enterprise Information Systems (ICEIS2007), Funchal-Madeira, Portugal.
Shazia Sadiq, Maria Orlowska, Wasim Sadiq, Cameron Foulger (2004) Data Flow and Validation in Workflow Modeling. The Fifteenth Australasian Database Conference Dunedin, New Zealand, January 18 -- 22, 2004. Ruopeng Lu, Shazia Sadiq, Guido Governatori (2007) Compliance Aware Business Process Design. 3rd International Workshop on Business Process Design (BPD'07). In conjunction with the 5th International Conference on Business Process Management, 24-28 September 2007. Brisbane Australia.
Shazia Sadiq, Guido Governatori, Kioumars Namiri (2007) Modeling Control Objectives for Business Process Compliance. 5th International Conference on Business Process Management, 24-28 September 2007. Brisbane Australia.
Guido Governatori, Zoran Milosevic, Shazia Sadiq (2006), Compliance checking between business processes and business contracts, Proc. The 10th IEEE Conference on Enterprise Distributed Object Computing (EDOC2006), Hong Kong, 16-20 Oct 2006.
Miao Wang and Guido Governatori (2007). A Logic Framework of Normative-based Contract Management. Formal Methods in Electronic Commerce 2007. Stanford University, Palo Alto, CA. June 4, 2007.
Vineet Padmanabhan, Guido Governatori, Shazia Sadiq, Robert Colomb and Antonino Rotolo. Process Modelling: The Deontic Way. In Markus Stumptner, Sven Hartmann and Yasushi Kiyoki, editors, Database Technology 2006, CRPIT 53. Australian Computer Science Association, ACS, 16-19 January 2006.
Zoran Milosevic, Shazia Sadiq, Maria Orlowska (2006) On Deriving Process Models from Business Contracts. 4th International Conference on Business Process Management (BPM2006), Vienna, Austria, 2006
Zoran Milosevic, Maria Orlowska, Shazia Sadiq (2006) Linking contracts, processes and services: an event-driven approach. IEEE International Conference on Services Computing. SCC 2006, Chicago, USA. Sep 2006.
Generation of Business Process Models for Object Life Cycle Compliance: Generation of Business Process Models for Object Life Cycle Compliance Jochen M. Küster
Ksenia Ryndina
Harald Gall (University of Zurich) 5th International Conference on Business Process Management
September 2007
Presentation outline: Presentation outline Problem statement
Object life cycles are used to standardize object behavior
Business processes are required to be compliant with object life cycles
Q1: When is a process compliant with a given object life cycle?
Q2: How can we achieve compliance?
Tool support and validation
Conclusion and outlook
Object flow in business process models: Object flow in business process models A business process model captures:
coordination of tasks performed to achieve a business goal
flow of data as objects exchanged between tasks
evaluate
claim notify
refusal Process model for
Claim Handling process make
payment close
claim receive
claim granted rejected UML2 Activity Diagram
Objects and object life cycles: Objects and object life cycles An object or a business object is a discrete entity that plays a role in business processes of an organization
Objects can be associated with a number of distinct states
Objects and their states are standardized using data reference models, such as ACORD in insurance
Object life cycles model allowed state transitions, initial and final states
Reference object life cycles represent an established way of manipulating objects in a particular industry, e.g. IBM Insurance Application Architecture
Problem statement: Problem statement Compliance with reference object life cycles is required to ensure:
consistency within processes of one organization
interoperability between industry partners for correct execution of processes that span several organizations
compliance with policy requirements, such as legal regulation, embodied in reference object life cycles
Q1: When is a process compliant with a given object life cycle?
Q2: How can we achieve compliance? compliance
Presentation outline: Presentation outline Problem statement
Object life cycles are used to standardize object behavior
Business processes are required to be compliant with object life cycles
Q1: When is a process compliant with a given object life cycle?
Object life cycle compliance notions
Q2: How can we achieve compliance?
Tool support and validation
Conclusion and outlook
Q1: Object life cycle compliance: evaluate
claim notify
refusal Process model for
Claim Handling process [granted,
rejected] [granted] [rejected] [rejected] [granted,
rejected] [paid in full,
aborted] [granted,
rejected,
cancelled] [closed] [granted] [rejected] [registered] [registered] Induced transitions: registered to granted and registered to rejected Induced transitions: granted to rejected make
payment close
claim receive
claim Q1: Object life cycle compliance Induced transitions: granted to closed and rejected to closed Last states: closed and rejected, paid in full and aborted First state: registered First states: paid in full and aborted
Q1: Object life cycle compliance: Conformance: all induced transitions, first states and last states in process model have corresponding elements in object life cycle
Coverage: all transitions, target states of initial transitions and final states in object life cycle must have corresponding elements in process model
Q1: Object life cycle compliance registered granted rejected settled closed register settle close close grant reject Induced transition: rejected to closed Induced transition: granted to rejected Last state: rejected
Q2: Approaches to achieving compliance: Q2: Approaches to achieving compliance 2. Resolution
of violations 1. Compliance
checking 1. Process model
generation 2. Customization 3. Compliance
checking 4. Resolution
of violations
Presentation outline: Presentation outline Problem statement
Q1: When is a process compliant with a given object life cycle?
Object life cycle compliance definition
Q2: How can we achieve compliance?
Generation of process models from object life cycles
Tool support and validation
Conclusion and outlook
Generation from one object life cycle: For each event labeling a state transition in object life cycle, a task is generated with appropriate input/output pins and object states
Order of tasks is based on matching input/output object states
Control nodes are added for correct control flow
Conformance and coverage are ensured Generation from one object life cycle
Generation from a set of object life cycles: Generation from a set of object life cycles synchronization Identification of synchronization events (manual step)
Composition of object life cycles
Process model generation:
Task generation
Object state relation for tasks
Process fragment generation
Connection of process fragments
1. Identification of synchronization events: 1. Identification of synchronization events A synchronization event is an event that triggers state transitions in more than one object life cycle
Identifying synchronization events is necessary given several object life cycles, to ensure that invalid composite states cannot be reached created authorized refused paid in full partially paid create pay all pay all authorize refuse stopped pay installment stop stop pay installment I2 Object life cycle for Payment object type registered granted rejected settled closed Object life cycle for
Claim object type register settle close close grant reject I1 grantC |
createP grantC |
createP settleC |
pay allP settleC |
pay allP settleC |
pay allP
2. Composition of object life cycles: 2. Composition of object life cycles registerC (I1C,I2P) registeredC
I2P rejectedC
I2P closedC
I2P grantedC
createdP grantedC
refusedP grantedC
authorizedP grantedC
stoppedP grantedC
partially paidP settledC
paid in fullP closedC
paid in fullP rejectC closeC grantC |
createP refuseP authorizeP stopP settleC |
pay allP settleC |
pay allP stopP closeC pay
installmentP pay
installmentP closedC
refusedP closedC
stoppedP
3. Process model generation: 3. Process model generation Transition and first state conformance with respect to both object life cycles are satisfied, but last state conformance is not
All coverage conditions are satisfied here, but this is not guaranteed rejectC closeC refuseP stopP settleC |
pay allP registerC grantC |
createP authorizeP pay
installmentP
Tool support and validation: Tool support and validation Our prototype extends IBM WebSphere Business Modeler:
conformance and coverage checking
generation of a process model from one or several object life cycles
semi-automatic resolution of selected compliance violations
extraction of object life cycles from a process model
Come to tomorrow’s Demo Session for a live demo…
Initial validation performed with IBM Insurance Application Architecture reference models
Conclusion and outlook: Conclusion and outlook Contributions:
object life cycle conformance and coverage notions that can serve as a basis for further refined compliance notions
technique for process model generation facilitates achieving compliance with reference object life cycles
contribution to bridging the gap between process and object modeling
Future work:
extension of conformance and coverage notions (too strict, too relaxed)
generation of “better” business process models
generation technique (identification of parallelism and structure)
user-support for pre-processing of object life cycles (synchronization identification) and post-processing of process models (compliance-preserving customization)
case studies
object life cycle compliance scenario
other top-down and bottom-up scenarios
Questions?: Questions?
Backup slides: Backup slides
Related work: Related work Object life cycles in object-oriented and database design:
object life cycle specialization [Kappel91], [Schrefl02], [Stumptner00]
integration of object life cycles as views [Frank98], [Preuner98]
Synthesis of behavioral models:
synthesis of state machines from scenarios [Uchitel03, Whittle00]
Business process compliance:
process mining [vanderAalst05]
Sarbanes-Oxley compliance [Agrawal06]
contract compliance [Governatori06]
Data flow analysis – Compiler theory [Aho86], [Muchnick97]: Data flow analysis – Compiler theory [Aho86], [Muchnick97] Basic idea:
data flow equations defined for each node in the control flow graph
evaluated repeatedly by calculating output from input for each node
until a fixpoint is reached
Forward flow analysis:
block’s exit state is a function of its entry state
entry state is a function of exist states of block’s predecessors
Can be easily adapted for analyzing objects states in process models
without loops, each task will have to be visited only once
with reverse postorder a node is visited before its successors, unless the successor is reached with a back edge
Generation from one object life cycle: register settle close close reject grant evaluate reject [registered] [rejected] grant [registered] [granted] settle [granted] [settled] register [registered] close [closed] [settled,
rejected] >
Claim Generation from one object life cycle For each event labeling a state transition in object life cycle, a task is generated with appropriate input/output pins and object states
Order of tasks is based on matching input/output object states
Control nodes are added for correct control flow
Conformance and coverage are ensured
Synchronization of object life cycles: Synchronization of object life cycles Synchronization events, synchronized automata (Our work)
Explicit communication among life cycles via signals [Redding et al, 2007]
“External” state transitions between life cycles [Müller et al, 2007]
Implemented in actions associated with state transitions [Nandi and Kumaran, 2005]
Highly Dynamic Adaptation in Process Management Systems through Execution Monitoring: Highly Dynamic Adaptation in Process Management Systems through Execution Monitoring Massimiliano de Leoni, Massimo Mecella and Giuseppe De Giacomo
{deleoni,mecella,degiacomo}@dis.uniroma1.it
Dipartimento di Informatica e Sistemistica
SAPIENZA – Università di Roma
The Rationale / 1: The Rationale / 1 Process Management systems, a.k.a. Workflow Management Systems, are traditionally used in many business scenarios, such as government agencies, insurances, banks, etc.
Besides this static scenario, it is more and more spreading their use in very dynamic scenarios.
For instance in mobile scenarios in order to coordinate the interventions of on-field teams for disaster management.
During war battles to carry on more effective attacks or defences.
The Rationale / 2: The Rationale / 2 In these highly-dynamic scenarios, the execution environment can change over the time in any way.
For instance, involved actors may change in the time
Actors provide specific (possibly unique) capabilities which are required to carry on processes.
Some tasks may require skills which no actor provides any longer. X For instance, in Mobile scenarios:
Devices may run down or break, causing actors fall down.
New devices can come in anytime Actors equipped with mobile devices can move around to perform assigned tasks, causing disconnections from the others or path changes
A many many others, mostly unforeseeable!
The Rationale / 3: The Rationale / 3 In these scenarios, high dynamicity yields to many events which can change the context, avoiding the process’ progressing.
Of course, ignoring deviation is not feasible!
new situation might be such that the PMS is no more able to carry out the process instance.
So adaptation is needed in several scenarios!!
Scenario (Just an example): Scenario (Just an example) Museum Precarious
Bell-Tower Building Church Affected Area Picture Store Operator Operator Team Leader Photo-Camera He has got installed the PMS!
Slide52: A typical cooperative process
Adaptive Process Management: Adaptive Process Management Museum Precarious
Bell-Tower Building Church Operator Bridge Team Leader Photo-Camera Affected Area Picture store
Slide54: New activity for disconnection management
Two ways for adapting… : Two ways for adapting… Anticipating all possible discrepancies.
Most APMSs currently use this approach.
Feasible and valuable in static context, where there are a few exceptions.
In such very dynamic scenarios, too many exceptions would be to consider.
Like the try/catch construct of Java:
try { task1; task2; task3 || subProcess(); }
catch(Disconnection) { … } catch(Devices Down) { … } catch(Exception1) { … } catch(Exception2) { … } catch(Exception3) { … } catch(Exception4) { … } ... The list of all expected exceptions. What if any unexpected happens?
Two ways for adapting…: Two ways for adapting… Devising a general recovery method. This method should be able to handle any kind of event, even unexpected.
The process is defined as if exogenous actions cannot occur (the try block).
Whenever discrepancies are detected leading the process not to be terminable, the control moves to the only catch block.
It activates a general recovery method
It modifies the old process P in a process P0 terminable in the new environment and achieving all P’s goals
Like the try/catch construct of Java:
try { task1; task2; task3 || subProcess(); }
catch(Any Exception) { The generic method! } It analyses the changed environment and automatically adapts
Execution Monitoring: Execution Monitoring Techniques for monitor of anomalies: “sensing” of the real world and aligning of the internal virtual reality.
Possibly predicting misalignments before they actually happen.
Techniques for identification of corrective actions.
Techniques for automatic process restructuring. e Process P is terminable in the context C Process P is NO MORE terminable in the context C1 Process P1 is terminable in the context C1 AND P1 pursues all P’s goals Adaptation 1 2 and 3
The Architecture of our Adaptive PMS: The Architecture of our Adaptive PMS Process Engine GUI for process design Execution Monitor Sensor External World Initial process
initial context Task assignment
Input & Output
Data Changes in process
and in
mental context Adapted Process
Alignment of mental
context with sensed
data It’s the interface used by designers to define the process schema The APMS modules assigning tasks to actors, considering context and actors’ capability For each execution step, it aligns the mental world in “PMS” mind with reality and data retrieved from external world by sensors, possibly adapting the process to unforeseen exogenous events Sensors are intended as any software and/or hardware component able to get contextual information from the external world.
Domain-independent predicates and actions: Domain-independent predicates and actions Some first-order logic domain-independent predicates denote various objects in the framework:
service(a): a is a service, i.e. an actor (humans, softwares or robots) performing tasks.
task(x): x is a task of a workflows.
capability(b): b is a capability
provide(a; b): the service a provides the capability b
require(x; b): the task x requires the capability b
We define four domain-independent actions:
Assign(a; x): the task x is assigned to a service a
Start(a; x; p): the service a is notified to perform the task x on input p
Stop(a; x; q): the service a acknowledges the successful termination of x with output q
Release(a; x): the service a is released with respect to the task x
Environment Definition / 1: Environment Definition / 1 We define anytime the situation si as the formal specification of the environment after the i-th action.
The predicate si+1 = do (t,si ) the situation after the t action on the situation si .
Situation calculus relies on fluents representing properties of the world, such as:
free(a;s): the actor/service a is not busy (no task assigned) in the situation s. It’s defined as:
available(a;s): the actor can get another task assigned. It is true the following but not the vice versa:
Environment Definition / 2: Environment Definition / 2 The fluent available(a;s) is domain-dependent.
For instance, in mobile scenarios, an actor is available if and only if it is not busy and it is connected through multi-hops to the team leader.
We define preconditions as axioms on such fluents.
For instance, the condition stating an actor a must be available in order to get a task x assigned is as follows:
Of course, specific tasks may require some stricter conditions:
That means actors needs provide a GPRS connection in order to perform the task SendDataByGPRS
Definition of schemas: Definition of schemas In our framework Process schema are defined by CONGOLOG programs.
Nevertheless, everything works also through any formal specification language, such as Petri Nets.
CONGOLOG is a logical language allowing actions’ concurrence
widely used to describe robot plans.
Actions are the basic building blocks. Here a sub-program is any CONGOLOG program
A CONGOLOG Example: A CONGOLOG Example Choose an available service/actor a0 for all required capabilities by Compile Here, 1 assignment for two tasks to force them to the same service/actor, that must provide all required capabilities for both
Adaptation : Adaptation As soon as actions are executed, the CONGOLOG program counter progresses.
It is equivalent to say that, after every action, the process δ evolves in δ’, which is obtained from δ by removing the already executed action.
Let be
δ’: the process after each action
s’: the supposed world state (virtual reality)
s’’: the real world state as monitored through sensors.
δ’’: the adapted process executable in s’’
If the differences between s’ and s’’ are not relevant δ’ = δ’’ otherwise δ’’ is an “adapted” version of δ’.
Relevant means δ’ can be carried out even in s’’.
Formal definition: Formal definition Formally:
Let
The predicate SameConfig (δ’,s’, δ’’, s’’) holds if and only if δ’, performed in the situation/environment s’, is bisimilar to δ’’, performed in the context/environment s’’.
The predicate Recovery(δ’,s’,s’’,δ’’) is formally as follows:
Recovery (δ’,s’,s’’,δ’’) “returns” the adapted process δ’’ Relevant (δ’,s’,s’’) states if the change from s’’ to s’ is such that δ’ can’t be carried out If we use the special bisimulation SameConfig(δ’,s’, δ’’,s’’) δ’ = δ’’ SameState(s’,s’’), then we have reduced the problem to the classical AI problem of finding a plan to achieve the formula SameState
Many planners already exist LinearProgram (δ) states δ to have no fork!
Do (δ,s,s’) states δ, when starting in s, can terminate and it does in s’
An example…: An example… Let’s suppose that, while going to Location for taking some photo, the actor is going to disconnect.
That is violated the predicate Connected
It wasn’t supposed to happen!
No predefined rule to handle it APMS analyses every possible action, every task from the predefined set.
It decides that another node should move to the location x where disconnecting actor is
That restores the predicate! Graphically
Conclusion: Conclusion This is a general approach for automatic process adaptation in highly dynamic scenarios.
Based on AI techniques, which are widely used in Robot Planning
Proved correctness and completeness
We are going to implement it through the IndiGolog developed by the Cognitive Robotics Group at Toronto University and Intelligent Agents group at RMIT University, Melbourne
The APMS will be then used in the European project WORKPAD in the context of disaster management.
We are working on improving this approach in defining how assigning properly tasks to actors, giving more evidence to those more “urgent”.
Of course, we have to define how to prioritize (which parameters to take into account)
Slide68: Version Management in the Business Process Change Context Xiaohui Zhao and Chengfei Liu
Swinburne University of Technology
Australia BPM’07, Brisbane 24-27 September
Contents: Introduction to workflow version management
Version management methodology
Version preserving graph
Rules for version numbering
Dynamic modification operations
Advantages
Related work
Review Contents
Motivating Example: Motivating Example Increase production Under maintenance Technical upgrade After maintenance
Motivating Example (cont’d): Motivating Example (cont’d) Technical upgrade Increase production Under maintenance After maintenance
Workflow Evolvement: Workflow Evolvement Workflow evolvement
Process improvement
Consecutive and non-returnable
Temporary adaptation
Ad hoc and returnable
Issues of Workflow Evolvement: Issues of Workflow Evolvement Version representation
Single version vs multiple versions
Single model vs multiple models
Version transformation
Forward only vs (reasonably) free transformation
Version compatibility
Exclusive existence vs co-existence
Version Numbering: Version Numbering Numbering versions Version priority list
( denoting the distance of
version relevance by descending order)
for version x.y.z
x.y.z;
u.v.z (u x or v y);
x.y;
x.v (v < y, v is the closet to y);
u.v (u < x, u is the closet to x, or v is the largest if u is the same);
Rules for Version Numbering: Rules for Version Numbering Horizontal evolvement rule
An evolvement from version x.y1.z to version x.y2.z (y1 y2) can be projected to an evolvement from x.y1 to x.y2; Vertical evolvement rule
For two evolvements from version x.y to x.y.z and from x1.y1 to x1.y1.z1 (z, z1 null, x x1 or y y1), respectively:
z = z1, if the two evolvements are caused by the same temporary change;
otherwise z z1.
Version Preserving Graph (VPG): Version Preserving Graph (VPG) A VPG for a workflow process p, can be defined as a tuple ( N, A, V, f, R ), where,
N is the set of nodes, and each node v N, represents a workflow task of p.
A is the set of arcs, and each arc a A, represents a link connecting two workflow tasks of p;
V is the set of version numbers, such as “1.1”, “1.2”, “1.2.2” etc.;
f : NUA→V is a mapping, which assigns proper version number to each node and arc in the graph;
R is a binary relation { ( a1, a2 ) | a1, a2 A a1 and a2 are in the exclusive relation }.
Node Modification Operations: Node Modification Operations
Arc Modification Operations: Arc Modification Operations
VPG Evolvement: VPG Evolvement
Related Work: Related Work ADEPTflex Project
Rinderle, Reichert and Dadam (JIIS 1998, CoopIS 2004)
Workflow Modification Language (WFML)
Casati et al., (DKE 1998)
Self-Adaptive Recovery Net (SARN)
Hamadi and Benatallah, (WISE 2004)
Specification and Validation of Process Constraints for Flexible Workflows
Sadiq and Orlowska, (Info Sys 2005)
Advantages: Advantages Dynamic updating
Modifications without suspending running instances
Multiple version compatibility
A single workflow process navigates instances of different versions
Co-existence of different versioned workflow instances
Compact model
Lightweight graph model for representing workflow evolvements
Brief review: Brief review Introduction of version management
Version preserving graph model
Run time workflow modification operations
Related work
Advantages
Q & A: Q & A
Thank you
Runtime Version Management ( 1 ): Runtime Version Management ( 1 ) Workflow Extraction Strategies
Backward assembling strategy
Top-down exploration strategy x.y.z;
u.v.z (u x or v y);
x.y;
x.v (v < y, v is the closet to y);
u.v (u < x, u is the closet to x, or v is the largest if u is the same); chain reactions involve irrelevant nodes ver 1.2.2
Runtime Version Management ( 2 ): Runtime Version Management ( 2 ) ignores irrelevant nodes x.y.z;
u.v.z (u x or v y);
x.y;
x.v (v < y, v is the closet to y);
u.v (u < x, u is the closet to x, or v is the largest if u is the same); Workflow Extraction Strategies
Backward assembling strategy
Top-down exploration strategy ver 1.2.2