Our ambition was to develop a technology for process-aware information systems,which is broadly applicable, i.e., not only to simple administrative processes, but also to highly dynamic and complex ones (e.g., diagnostic and therapeutic processes in hospitals). The challenge was to develop a technology which supports “correctness
by construction” and a “plug & play” style (cf. Fig. 1) during process composition and which guarantees correctness in the context of  ad-hoc changes at the process instance level.

 

 

Fig. 1: Composition of correct processes using plug & play

This challenge was probably the most influential one when developing AristaFlow. It had significant impact on the development of the AristaFlow process meta model as well as on our work on process flexibility and process adaptivity. It meant, in essence, the following:

1. We have to hide the inherent complexity of process-orientation (especially in conjunction with flexibility) as
   far as possible from system administrators and application programmers; i.e, we have to perform all complex things “beneath the surface” in the process management system.


2. We have to provide powerful, high-level interfaces to application programmers, based on which they can implement easy to use end user interfaces.

When developing the AristaFlow process meta model we were in a dilemma. On the one hand our analyses had shown that real-world processes can be complex structured; e.g., comprising alternative/parallel branchings and loops. A process meta model should therefore provide appropriate concepts to represent these structures adequately, i.e., it should be expressive enough. On the other hand our goal was to enable comprehensive and efficient correctness checks during process modeling as well as in conjunction with ad-hoc instance changes at runtime.

Expressiveness of a process meta model has two major aspects: One is the ability to model a large variety of control flow structures in terms of process patterns. Another one is how easy the semantics of the meta model constructs or the resulting control flows can be understood by users. First experiences indicated that process modeling based on states and transitions (as used in Petri Nets for example) is not very easy to understand for end users (i.e., doctors and nurses in a hospital). Another issue was that this notation quickly leads to large process models due to many symbols.

Opposed to that, Activity Nets as used in IBM FlowMark were much easier to understand, but this approach had other weaknesses, including the missing support of loops and the context-dependent execution semantics of nodes; e.g., depending on its context the syntactic symbol for an activity node may represent a normal (sequential)  node, an XOR split/join, or an AND split/join.We also elaborated other formalisms (e.g., state and activity charts, rule based approaches), but considered them not being appropriate for our purpose. Altogether the procedure of defining the AristaFlow process meta model was no easy task and lasted several months during which we evaluated manyaspects and their impact on the meta model and vice versa. Most headaches were caused by two partially conflicting goals: expressiveness and formal verification. All ideas were evaluated against the clinical processes we had acquired in our hospital projects.