towards flexible, adaptable & compliant process-aware information systems with dynamic condition...

Towards Flexible, Adaptable & Compliant Process-Aware Information Systems with Dynamic Condition Response Graphs!!Thomas T. Hildebrandt Head of Process and System Models Group IT University of Copenhagen (ITU) Denmark !ZISC Institute Seminar ETH Zurich !!

IT UNIVERSITY OF COPENHAGEN

joint work with S. Debois, T. Slaats, R. Mukkamala & D. Basin


Flexible, Adaptable & Compliant PAIS with DCR Graphs November 27th, 2015

Thomas T. Hildebrandt ([email protected])

A single slide on my background

2

Year 2000: PhD in Computer Science (Formal Process Models)

BRICS & Aarhus University, Denmark

2000 - 2003: Head of Study Program in Internet and Software Technology at IT University of Copenhagen (ITU)

2004-2011: Director of PhD School on Foundations of Innovative Research-based Software Technology (FIRST)

2012-: Head of Process & System Models Group at ITU www.itu.dk/research/models

2007-: Investigator at research projects on trustworthy & flexible process-aware information systems jointly with public & private partners:

!!!!!!!!

2010: Case Studies of Best Practice Workflow and Workflow in Practice Infinit Inovation Network

2007-11: Computer Supported Mobile Adaptive Business Processes Research Foundation for Technology and Production

2008-2012: Trustworthy Pervasive Healthcare Processes (TrustCare) Council for Strategic Research

2011-2014: Flexible Cross-organizational Case Management Industrial PhD

2014-17: Computational Artifacts: Design Oriented Theory of Computational Artifacts in Cooperative Work Practices Velux Foundation, www.COMPART.ku.dk

2012-: EU COST Action IC1201 - Behavioural Types for Reliable Large-Scale Software Systems

2015-16: ProSec: Cyber security and ICT Infrastructure with importance to crucial functions in Denmark - Mapping Emergency and Security Processes in the Danish Public Transport Sector and their Dependency on ICT - the Royal Danish Defence Agency !

mailto:[email protected]

http://www.itu.dk/research/models




Road Map

• Motivation: Flexible, Adaptable & Compliant Process-aware Information Systems (PAIS)

• Dynamic Condition Response (DCR) Graphs

• Tool Demonstration

• Challenges and Extensions

• Conclusion

3





PAIS, eGov, BPM, WFM, ACM,..

4






4

+






4

+ +





Driven by code & processes

5

However, the focus is not on data but on process-related information (e.g., theordering of activities). Process mining is also related to monitoring and businessintelligence [41].

8 ConclusionProcess-aware information systems (PAISs) follow a characteristic life-cycle. Fig-ure 13 shows the four phases of such a life-cycle [7]. In the design phase, theprocesses are (re)designed. In the configuration phase, designs are implementedby configuring a PAIS (e.g., a WFMS). After configuration, the enactment phasestarts where the operational business processes are executed using the system con-figured. In the diagnosis phase, the operational processes are analyzed to identifyproblems and to find things that can be improved. The focus of traditional work-flow management (systems) is on the lower half of the life-cycle. As a result thereis little support for the diagnosis phase. Moreover, support in the design phase islimited to providing an editor while analysis and real design support are missing.

Figure 13: PAIS life-cycle.

In this article, we showed that PAISs support operational business processesby combining advances in information technology with recent insights from man-agement science. We started by reviewing the history of such systems and thenfocused on process design. From the many diagramming techniques available, wechose one particular technique (Petri nets) to show the basics. We also emphasizedthe relevance of process analysis, e.g., by pointing out that 20 percent of the morethan 600 process models in the SAP reference model are flawed [24]. We also

26





Are flow graphs the right approach ?

6






6

Only anticipated paths are described






6


Typically introduces unnecessary dependencies






6



Only describes how not why






6



Difficult to adapt

Only describes how not why





arbejdsgangsbanken.dk

7

• Lov om Aktiv beskæftigelsesindsats

(LBK nr 1428 af 14/12/2009)

• Lov om Aktiv socialpolitik

(LBK nr 946 af 01/10/2009)

• Lov om Arbejdsløshedsforsikring

(LBK nr 574 af 27/05/2010)

• Lov om Integration af udlændinge

(LBK nr 1062 af 20/08/2010)

• Lov om Sygedagpenge

(LOV nr 563 af 09/06/2006)

• Retssikkerhedsloven

(LBK nr 1054 af 07/09/2010)

• Datagrundlag

(BEK nr 418 af 23/04/2010)

(like ech.ch eCH-Prozessplattform)

Compliant?


http://arbejdsgangsbanken.dk

http://www.ech.ch/





7


(LBK nr 1428 af 14/12/2009)


(LBK nr 946 af 01/10/2009)


(LBK nr 574 af 27/05/2010)


(LBK nr 1062 af 20/08/2010)


(LOV nr 563 af 09/06/2006)


(LBK nr 1054 af 07/09/2010)

• Datagrundlag

(BEK nr 418 af 23/04/2010)

CHANGE!!


Compliant?



http://www.ech.ch/





7


(LBK nr 1428 af 14/12/2009)


(LBK nr 946 af 01/10/2009)


(LBK nr 574 af 27/05/2010)


(LBK nr 1062 af 20/08/2010)


(LOV nr 563 af 09/06/2006)


(LBK nr 1054 af 07/09/2010)

• Datagrundlag

(BEK nr 418 af 23/04/2010)

CHANGE!! CHANGE??


Compliant?



http://www.ech.ch/




Like driving in the dark..

8

Fixed route(s) !

If you leave the route, you are on your own !

If the map changes, you have no idea how to update the routes





We want a process GPS

9

The route is calculated from the map and goal !

If you leave the route, a new one can be calculated !

If the map changes, the route can be adjusted

in other words, we want constraint-based systems





Prespecified vs Constraint-‐based

10

12.2 Modeling Constraint-Based Processes 343

b Prespecified Model a Requirements

Desired Behavior

Forbidden Behavior

c Constraint-based Model

Supported Behavior

Unsupported Behavior

Unspecified Behavior

Fig. 12.1 Prespecified vs. constraint-based process models

12.2.1 Constraint-Based Process Models

When formalizing a real-world business process like the fracture treatment processfrom Example 12.1, prespecified process models and constraint-based ones takea fundamentally different approach as illustrated by Fig. 12.1. Irrespective of thechosen approach, requirements imposed by the real-world business process need tobe reflected by the process model. This means that desired behavior (i.e., obligationsand recommendations) must be supported by the process model, while forbiddenbehavior (i.e., prohibitions) must be prohibited [219] (cf. Fig. 12.1a). Therefore,desired behavior refers to what has to be done under certain circumstances; i.e.,events that must be present in execution traces of corresponding process instancesand thus be supported by the process model. Forbidden behavior, in turn, refers towhat must not be done under certain circumstances, i.e., events that must not occurin execution traces.

Prespecified models follow an “inside-out” approach putting an emphasis ondesired behavior, thus avoiding any forbidden one (cf. Fig. 12.1b). Prespecifiedprocess models only cover the desired behavior, while behavior which is neitherdesired nor forbidden remains unsupported (unless the model is changed at theinstance level as described in Chap. 7). On one hand, focusing on desired behaviormakes prespecified process models well suited for guaranteeing compliance withexisting business requirements. On the other hand, this implies rather rigid processmodels and poses the risk of over-constraining as well as over-specification[219, 243].

A constraint-based process model, in turn, takes an “outside-in” approach (cf.Fig. 12.1c) and is created by first identifying the set of relevant activities and addingit to the model [243]. At this stage, without the presence of any constraints, activitiescould be executed arbitrarily often, and in any order. Constraints are then added





Not a new idea

• Expert systems

• Logical programming (Prolog)

• Use of temporal logic for execution/monitoring

11

going back (at least) to the ‘70ties





Not a new idea

• Expert systems



11


But….





Not a new idea

• Expert systems



11

Difficult to understand constraint language & routes


But….





Not a new idea

• Expert systems



11

Difficult to understand constraint language & routes


We can see the map, but no longer see the route!

But….




Thomas T. Hildebrandt ([email protected]) 12

10.1 Motivation 299

Sur

gic a

lSui

tedischarge letter

for referring phys.O

utpa

tient

Dep

artm

ent

Sur

gica

lWar

d

MT

AP

hysi

cia n

Phy

sici

anN

u rse

AdmitPatient

PerformCheckup

ExaminePatient

Inform aboutRisks

Inform aboutAnesthesia

MakeDecision

CheckPatient Record

AdmitPatient

ScheduleSurgery

WriteDischarge Letter


MakeLab Rest

CreateSurgery Report

ProvidePostsurgical Care

DischargePatient

TransportPatient to Ward

surgeryok

PerformSurgery

PreparePatient

Send Patientto Surgical Suite

Fig. 10.1 Prespecified process model Smed

Table 10.1 Examples of compliance rules for medical processes

c1 Before a surgery may be performed the patient must be prepared for it and be sent tothe surgical suite.

c2 After examining the patient a decision must be made. However, this must not be donebefore the examination.

c3 After the examination, the patient must be informed about the risks of the (planned)surgery.

c4 Before scheduling the surgery the patient has to be informed about anesthesia.

c5 If a surgery has not been scheduled it must not be performed.

c6 After a patient is discharged a discharge letter must be written.

c7 After performing the surgery and before writing the discharge letter, a surgery reportmust be created and a lab test be made.

particularly crucial for process instances defined or adapted on-the-fly (cf. Chap. 7),i.e., for which there is no fully prespecified process model. Likewise, compliancemonitoring at run-time is required if a priori compliance checking is not feasible,e.g., if the process model is too large or the compliance rules are too complex.Regarding completed process instances, in addition, a process-aware informationsystem (PAIS) needs to be able to determine whether these instances were executedin compliance with given regulations, laws, and guidelines. For this purpose, a

2: Add constraints

1: Identify events & roles

The DCR Graphs Approach





CondiTons & Responses

13

10.1 Motivation 299

Sur

gic a

lSui

tedischarge letter


utpa

tient

Dep

artm

ent

Sur

gica

lWar

d

MT

AP

hysi

cia n

Phy

sici

anN

u rse

AdmitPatient

PerformCheckup

ExaminePatient

Inform aboutRisks


MakeDecision

CheckPatient Record

AdmitPatient

ScheduleSurgery



MakeLab Rest



DischargePatient


surgeryok

PerformSurgery

PreparePatient












c2

c3

c4

Conditions describe what

must have happened in the past before an

event may happen





CondiTons & Responses

14

10.1 Motivation 299

Sur

gic a

lSui

tedischarge letter


utpa

tient

Dep

artm

ent

Sur

gica

lWar

d

MT

AP

hysi

cia n

Phy

sici

anN

u rse

AdmitPatient

PerformCheckup

ExaminePatient

Inform aboutRisks


MakeDecision

CheckPatient Record

AdmitPatient

ScheduleSurgery



MakeLab Rest



DischargePatient


surgeryok

PerformSurgery

PreparePatient












c2

c3

c4

Responses describe what must happen in

the future before the process can

complete





Dynamic Exclusions

15

c2

c3

c4

Exclusions describe that

an event excludes

another event from the

process, i.e. it is no longer

relevantc5: The decision is either to do a surgery or no surgeryc6: Scheduling a surgery is irrelevant if it is decided not to do a surgeryc7: Should only write a discharge letter if it is decided not to do surgery





c2

c3

c4

Inclusions allow an event to make other

events relevant again, i.e.

redoing the decision

Dynamic Inclusions





c2

c3

c4




Dynamic Inclusions

This is a Dynamic Condition Response (DCR) graph![PLACES2010,Phd11, SEFM2011,DEBS12,EDOC2013,JLAP82,2013,BPM2013-15,PhD15,FM15]





c2

c3

c4




Dynamic Inclusions

This is a Dynamic Condition Response (DCR) graph![PLACES2010,Phd11, SEFM2011,DEBS12,EDOC2013,JLAP82,2013,BPM2013-15,PhD15,FM15]

Flexible, adaptable & captures “why” (the system can compute “how”)


Tool Demonstration




DCR Graph Design & SimulaTon

18





DCR Graphs for execuTon

23

Workflow engine





Seamless & safe distribuTon

24

Workflow engine Workflow engine

Papers: [SEFM2011,FHIES2011,BPM15]





Monitoring & Compliance

25


Run-time monitor





Policy enforcement

26


Policy enforcement point





What is special for DCR graphs?

27






• Formal and close to natural language: Conditions, Responses, Inclusions and Exclusions

27







• Expressive and decidable: Can express all regular safety and liveness properties

27








• Operational and understandable: Run-time state as “check-list” on events

27








• Operational and understandable: Run-time state as “check-list” on events

• Efficient monitoring/enactment & adaptable: Local, linear-time decision of enabled events & effect

27





Work so far• Tools (DCRGraphs.net, tiger.itu.dk)

• Verification, Time & Dynamic Subprocesses

• Distribution & Independence

• Search Path & projections [BPM14], traceability

• Applications to case studies [FHIES2011,ACM14,BPM15](Healthcare, case & emergency management)

• Run-time adaptation & refinement [EDOC2013][ACM14][FM15]

• Programming Language/Calculi

28

[SEFM2011,BPM15]

[JLAP82,2013, BPM14,FM15]

[DEBS2012,REBLS15]


http://DCRGraphs.net

http://tiger.itu.dk




Challenges & ongoing work

!

• Verification & state-space explosion

• Help users understand & validate

• Extensions: data, time & dynamic sub processes

• Applications: case & emergency management, security, …

29





Dealing with state space explosion

• Inferring concurrency and distribute

• Refinement and static analysis of constraint graph

30

[SEFM2011,BPM15]

[FM15]

vs





User validaTon of constraints

31

Searching for paths like Google Maps:





User validaTon of constraints

32





Timed DCR Graphs

33

Eventually is often not good enough….

and delays may be required





Timed DCR Graphs

33

Eventually is often not good enough….

Timed DCR Graphs introduce delays on conditions, and deadlines on responses

!

and delays may be required





Delays & Deadlines

34

“After eating you must wait 12 hours before surgery” !

!

!

!

“After surgery, a checkup must be done within 7 days”





Enforceability & EscalaTon

35

Some events are uncontrollable

in particular human activities

But time is unstoppable….

Need compensation/Escalation

tiger.itu.dk/post2016Try research-prototype at


http://tiger.itu.dk/post2016




Sub processes• Dynamically created sub processes

!

!

!

• Supported in theory and tools - but makes the model Turing complete

• Turing completeness not a problem for enactment, run-time monitoring & static analysis

36

[FM15]





Conclusions

37





Conclusions• Flow-graphs: A GPS with fixed routes & no map

37






• DCR graphs define the map of a “process GPS”

37







• Tool support & applied with success in industry

37








• Still challenges! But promising initial work on understandability, refinement and static analysis

37









• Current work: Security monitoring & enforcement, process mining, collaborative design, simulation and training e.g. for crisis management

37









• Current work: Security monitoring & enforcement, process mining, collaborative design, simulation and training e.g. for crisis management

37

Thanks - please join us in the research!


towards flexible, adaptable & compliant process-aware information systems with dynamic condition...

Presentations & Public Speaking