IUPC: Identification and Unification of Process Constraints

Business Process Compliance (BPC) has gained significant momentum in research and practice during the last years. Although many approaches address BPC, they mostly assume the existence of some kind of unified base of process constraints and focus on their verification over the business processes. However, it remains unclear how such an inte- grated process constraint base can be built up, even though this con- stitutes the essential prerequisite for all further compliance checks. In addition, the heterogeneity of process constraints has been neglected so far. Without identification and separation of process constraints from domain rules as well as unification of process constraints, the success- ful IT support of BPC will not be possible. In this technical report we introduce a unified representation framework that enables the identifica- tion of process constraints from domain rules and their later unification within a process constraint base. Separating process constraints from domain rules can lead to significant reduction of compliance checking effort. Unification enables consistency checks and optimizations as well as maintenance and evolution of the constraint base on the other side.Comment: 13 pages, 4 figures, technical repor

Schema Evolution in Process Management Systems

Continuously arising new trends in information technology and developments at the (e-business) market let companies crave for automated business process support. Process management systems offer the promising possibility to (electronically) define, control, and monitor business processes. However, if this technology shall be applicable in practice it must be possible to change running business processes even at runtime. Basically, such process changes can take place at two levels - the process type level and the process instance level. If a process type is modified a new version of the respective process type schema is created. Then, at minimum, the process instances running according to the old process type schema version must be able to finish without being disturbed. However, this simple versioning approach is only sufficient for short-running business processes. For long-running ones like, for example, car leasing contracts or medical treatment processes which may last from 3 up to 5 years, it must be possible to apply the process type changes to the collection of running process instances as well, but without causing inconsistencies or errors in the sequel. Apart from process schema evolution and change propagation a flexible process management system must also enable instance-specific (ad-hoc) changes, for example, if exceptional situations occur. If then a process type change takes place the challenging question arises how to adequately deal with the interplay of process type and process instance changes

BPM News - Folge 3

Die BPM-Kolumne des EMISA-Forums berichtet über aktuelle Themen, Projekte und Veranstaltungen aus dem BPM-Umfeld. Schwerpunkt der vorliegenden Kolumne bildet das Thema Standardisierung von Prozessbeschreibungssprachen und -notationen im Allgemeinen und BPEL4WS (Business Process Execution Language for Web Services) im Speziellen. Hierzu liefert Jan Mendling von der Wirtschaftsuniversität Wien in aktuelles Schlagwort. Des weiteren erhalten Leser eine Zusammenfassung zweier im ersten Halbjahr 2006 veranstalteten Workshops zu den Themen „Flexibilität prozessorientierter Informationssysteme“ und „Kollaborative Prozesse“ sowie einen BPM Veranstaltungskalender für die 2. Jahreshälfte 2006

Data Flow Correctness in Adaptive Workflow Systems

Enterprises must be able to quickly adapt their business processes to react to changes in their environment. Needed business agility is often hindered by the lacking flexibility of contemporary workflow systems. In response to this inflexibility, adaptive workflow systems have emerged, which enable the dynamic adaptation of running workflows. One of the most important challenges in this context is to avoid inconsistencies and errors. So far, approaches providing respective correctness criteria for dynamic workflow change have mainly focused on control flow correctness (e.g., avoidance of deadlocks). However, little attention has been paid to data flow correctness even though this is crucial for any application of dynamic workflow change in practice. Specifically, missing or inconsistent input data of workflow activities, for example, can lead to blocking or breakdown of the underlying workflow system. This paper deals with fundamental challenges related to data flow correctness. We revisit and discuss data flow correctness at different phases of the workflow life cycle (i.e., buildtime and runtime), and show how data flow correctness can be ensured in an efficient way when dynamically changing a workflow