Characteristics for Run-time BP Models

The classifications of elements for general characteristics of run-time models, reviewed in Section2.7.4(Generalisation of Models at Run-time), is a good entry point to identify requirements for such a language. As pointed out in that section, the ratio of prescriptive and descriptive parts are dependent on the purpose of the model, e.g. monitoring MRT vs. executable MRT. But not only the ratio of these parts can be different also the run-time aspect, prescriptive or descriptive, can vary for the same model element types depending on the purpose. That is, an element type, e.g. an activity, can be of a prescriptive na- ture in one run-time BP model, e.g. execution standards like BPEL, but of a descriptive nature in another run-time BP model, e.g. a BP model extracted via process discovery (see Section2.4). In all cases (descriptive, prescriptive, or both) the objective is to allow for or record changes on different abstraction levels (e.g. type level vs. instance level) and across different BP perspectives (e.g. control-flow vs. resources). The current state- of-the-art work classifying thesedimensions of changein the BP domain is discussed in Section2.3. Particularly of relevance with regards to the dimensions of change in the BP domain are the two approaches by Sadiq et al. [202] and by Schonenberg et al. [211], both defining different types of changes from a realisation perspective rather than a context

Run-time BP Model

BP Type Business Process Process Instance State of Process Instance

Sys

te

m

Dynamism Variability Reflectivity

C

a

u

sal

ly

C

o

nn

e

ct

ed

Fig. 4.2 Abstraction Levels of BP Changes

perspective. A summary is depicted in Figure2.11on page31which merges both classifi- cations with regards to their abstraction (type vs. instance) and anticipation (build-time vs. run-time).

Since the focus of this thesis is on techniques that allow changes during run-time, only the associated abstraction level of the change is of importance, i.e. the granularity of a change. There are two abstraction levels of change that can be identified in both classi- fication: (1) The change of the execution path of a process instance (instance level), in the remainder calledVariability, and (2) the change of a complete business process defini- tion (type level), in the remainder calledDynamism. Due to the focus of both approaches on process change, one abstraction level of change has not been regarded, yet: the fine- granular state change in a process instance, in the remainder calledReflectivity. We argue that a language for run-time BP models needs to be able to support these three dimen- sions of change (see Figure4.2) in order to support any business process related purpose from business process monitoring to dynamic process optimisation.

A first conclusion to be drawn after identifying these three different dimensions of change is that reflective business process models, e.g. workflow models like ADEPTflex[191]

that are executable and monitor the state of the system, are technically already adaptive run-time models. The inherent flexibility of BP modelling languages (e.g. via conditional or parallel behaviour) describes execution rules for the individual process instances, i.e. these BP models are adaptive run-time models forprocess instancesbut not for the BP type level. That means in the context of the differentiation between descriptive and prescrip- tive model parts by Lehmann et al. [129] (see Figure2.31on page79), that the prescriptive part specifies the possible states and transitions of one process instance, the descriptive part describes the current state in the process instance, and the valid modifications of the prescriptive parts are the shifts of execution paths for the process instance dependent on

MRT for Process Instance

Activity Sequence = Process Instance

Activity 1 Activity 2 Activity 4

Descriptive Part Prescriptive Part Mod. of Descriptive Part Mod. of Prescriptive Part

Legend

Current Descriptive Part

Reflective Business Process Model

Activity 1

Activity 2

Activity 4 Activity 3

Start Decision Merge

Activity Sequence = Process Instance

Activity 1 Activity 3 Activity 4

Current Prescriptive Part

End

equivalent to

Fig. 4.3 Reflective Business Process Model as Process Instance Model at Run-time

the circumstances. This is shown in Figure4.3. Fully automated workflow languages like ADEPTflex are a good example to show how important the abstraction level of change is,

i.e. in terms of dynamic adaptation: On what level the MRT system captures change of the system and on what level the MRT system is governing modifications for the system.

With regards to general run-time BP models, the requirements are to be able to cap- ture and govern change on the levels ofreflectivity, variability, anddynamism. In addition to the desired change dimensions, run-time BP models also have to support standard business process modelling capabilities which is why the requirement ofexpressibility is essential, as well. Figure4.4shows all four general requirements for run-time BP models in an conceptual overview. In accordance with the distinction between prescriptive and descriptive MRTs discussed in Section2.7.5a similarly distinguished view for the domain of dynamic BPs is highlighted: While the light grey arrows displayprescriptiveconnections between the abstraction levels, the stroked black arrows highlightdescriptiveconnections between the levels. The fundamental difference between these relations is the following: (1) the prescriptive connection represents that the higher abstraction level defines the

potential"solution" space according to which the lower level is substantiated at run-time (i.e., a dynamic BP language or BP type defines via goals, rules, etc. according to which the business process is substantiated; the BP model describes rules for the BP instances; the BP instance defines the parameters of the states it can take), (2) the descriptive con- nection represents the actual as-is situation in a run-time system (i.e. the BP instance state describes the BP instances current state; the monitored BP instances describe the actual BP; the captured BPs describe the evolution of the BP on a type level). While the prescriptive connection represents a definition of the lower level space, the descriptive connection is the concrete monitored substantiation on that level. Note, that on the top level two different abstractions exist: the one on the left (BP Type/Dynamic BP) defines all possible variations and adaptations of the BP model while the one on the right (BP Evolu-

Business Process Models at Run-time Current Business Process Modelling Standards Relations Dynamism Variability Reflectivity BP Type/ Dynamic BP Business Process BP Evolution BP Instance State of BP Instance prescribes describes Expressibility

Fig. 4.4 Business Process Abstraction Levels and the Conceptual Location of the Four Re- quired Characteristics for Run-time BP Models: Dynamism, Variability, Reflectivity, and Expressibility

tion) temporally describes the inhabited states and their development during execution. Also highlighted in Figure4.4is that normal BP standards such as BPMN [168] already inherently meet the requirements of variability and expressibility. Reflective workflow languages like ADEPTflex[191] additionally support the capturing of the lowest level, i.e.

the BP instance state.

In document Descriptive business process models at run time (Page 121-124)