Towards a Business Process Modeling Technique for Agile Development of Case Management Systems

. A modern organization needs to adapt its behavior to changes in the business environment by changing its Business Processes (BP) and corresponding Business Process Support (BPS) systems. One way of achieving such adaptability is via separation of the system code from the process description/model by applying the concept of executable process models. Furthermore, to ease introduction of changes, such process model should separate different perspectives, for example, control-flow, human resources, and data perspectives, from each other. In addition, for developing a completely new process, it should be possible to start with a reduced process model to get a BPS system quickly running, and then continue to develop it in an agile manner. This article consists of two parts, the first sets requirements on modeling techniques that could be used in the tools that supports agile development of BPs and BPS systems. The second part suggests a business process modeling technique that allows to start modeling with the data/information perspective which would be appropriate for processes supported by Case or Adaptive Case Management (CM/ACM) systems. In a model produced by this technique, called data-centric business process model, a process instance/case is defined as sequence of states in a specially designed instance database, while the process model is defined as a set of rules that set restrictions on allowed states and transitions between them. The article details the background for the project of developing the data-centric process modeling technique, presents the outline of the structure of the model, and gives formal definitions for a substantial part of the model.


Introduction
The concept of business process (BP) covers a complex phenomenon that can be considered from several perspectives, e.g.: control flow (also called tasks/activities perspective or workflow) perspective, data/information perspective, resources perspective, including human resources, to name the three most important perspectives.A full-featured Business Process Support (BPS) system * has to handle most, if not all, of these perspectives to provide maximum help to business process participants when they run process instances/cases.There are two approaches to building a BPS, traditional and agile [1].In the traditional approach a detailed business process model is built before starting the development of BPS, and such model is supposed to cover the majority of BP perspectives.In the agile approach, a minimum possible BPS system is created and set into operation before adding details.In this case, a business process model on which a minimum BPS system is built does not require to cover all perspectives of the business process that it aims at supporting.For instance, a system built using only control flow perspective can be useful for scheduling tasks, while adding the human resources perspective may enhance the support to forwarding information on the tasks to be completed by appropriate human participants of the process instance.
Which perspective(s) should be covered in the minimum BPS depends on the nature of the business process to be supported.If the process is workflowable [2], the control flow perspective can be appropriate for implementation in the minimal BPS.However, for non-workflowable business processes, perspectives other than control flow can be more important for using in the minimum BPS system.The most known classes of such processes are the ones that are supported by Case Management (CM) systems, sometimes called case handling systems [3], and Adaptive Case Management (ACM) systems aimed at supporting so-called knowledge workers in processes that are inherently dynamic and unpredictable [4].ACM systems can be considered as a special kind of CM systems, see Section 2.1 for more detailed discussion.
In CM, and especially ACM systems, the sequence of tasks/activities (i.e. the control flow), quite often, is impossible to predict beforehand.The most important functionality of CM/ACM systems is providing means for storing structured information and making it available for the process participants who need it.Based on this information, the participants can themselves decide on which tasks/activities to complete and in which order, at least, when a minimum BPS system is employed.Such functionality, for instance, can be implemented via a built-in structured shared space, as in [5].Accordingly, for CM and ACM systems, the data/information perspective could be more appropriate to be included in the minimum system when agile process development is used.
Though ideas and systems based on ACM are expanding in practice, research in this area only recently started to investigate them, for instance, through the AdaptiveCM workshop [6].Due to CM/ACM only currently got much attention, so far, there is no widely accepted business process modeling technique that would be suitable for executable business process models employed in CM and ACM systems.OMG has suggested a modeling technique for CM [7], but the focus of this technique is still on tasks, while the data/information plays a less central role.This article is an attempt to suggest a formal foundation for creating a process modeling technique in which the data/information perspective is in the focus, and which could be suitable for employment in CM/ACM systems developed in the agile manner.
When coping with the task of devising a modeling technique for CM/ACM systems, we follow a path similar to the one through which the workflow modeling technique went.We start with devising a definition of a process model with the minimum set of concepts that, nevertheless, can be useful for building CM/ACM systems.Then, we gradually extend this definition to include more concepts thus facilitating the extended functionality of BPS systems.We base our design on the hypothesis that the data/information perspective is the best candidate for the starting perspective when building executable models for CM/ACM systems in the agile manner.The main operations for CM/ACM systems are considered to be storing and retrieving pieces of data/information related to the given process instance, or case in the terminology of CM/ACM.Therefore, a process instance/case can be represented as a trace of changes in the data/information related to this instance/case, while a process model can be define as a set of rules identifying allowed traces * .The process model based on this idea substantially differs from the workflow one.It is not based on the notion of task/activity as a basic notion, as there are no specific tasks/activities defined for a given process, except a few general operations related to managing data.
The basis for the modeling technique we suggest is threefold: 1. Reflection made on the so-called form-based case management typical for the public sector practice (at least in Sweden).The management of such processes is not done by specifying activities, but by producing a package of templates/forms mandatory to be used during the handling of cases (see Section 4 for a detailed discussion).This practice was introduced long before the computers were installed in each public office, and it is still applicable when computer based BPS systems are being introduced in practice.2. Our own experience of developing CM/ACM systems and tools to support the development of CM/ACM systems based on the idea of form-based case management.3. Database theory and practice.Based on the three sources above, we suggest a process modeling technique that we call datacentric.In this technique, we differentiate two types of process models: a basic data-centric process model and an extended one.In the basic data-centric business process model, all data related to the process are treated uniformly, independently of what these data represent: subgoals that need to be reached; actors that are engaged in the process; tasks/activities that are planned or completed; or communication between various agents during the process instance life-time.The proposed technique considers that each process instance of the given process type has an instance database that is being filled with data when the instance develops in time.The databases of instances that belong to the same process type have the same scheme.Formally, the process instance is defined as a sequence of database states ending with some final state.A process model is defined as a set of rules that differentiate valid (allowed) sequences of database states from the invalid ones.These rules can also be defined as a procedure that generates all possible valid sequences, similar to the generative grammars that generate all possible language sentences.
In the extended data-centric model, the notion of task/activity appears and helps to introduce rules that further limit the set of allowed traces.The extended data-centric model will semantically interpret some data items, for instance, as a goal, task/activity, agent, plan, etc., in order to enrich the functionality of a BPS system.While enriching the data-centric model with finer grade semantics is in our plans, the focus of the current article is on designing a "pure" data-centric model and show that it may be useful for BPS systems development.
The specific goal of this article is to suggest a formal definition of the data-centric process model that could be useful for developing CM/ACM systems in the agile manner.As with many other formal definitions, it is too mathematical to be used directly when modeling business processes in practice.A more visual notation has to be developed, which is outside the scope of this article.The formal definition suggested in this article is aimed at guiding the development of possible visual notations, as well as developing internal data structure and model interpreters of the future BPS system of the CM/ACM type.
The rest of the article is structured according to the following plan.In Section 2, we explain in more detail the needs for a new business process modeling technique.Firstly, we give a short overview of the state of the art in CM/ACM field (Section 2.1), and explain the main ideas of agile business process development (Section 2.2).Then, in Section 2.3, we present the reasoning behind the design of our data-centric business process modeling technique.In Section 3, we give an overview of the literature related to non-workflow business process modeling techniques.In Section 4, we present the background on which our modeling technique has been built.This section is extended in Appendix A, which presents a description of a tool that motivated current work.Section 5 presents an outline of our basic data-centric business process model.The substantial part of this outline is formalized in Appendix B. Section 6 discusses how the basic data-centric model can be extended to include the new concepts, like activity or task, via assigning semantics to the data elements.Section 7 analyzes a data-centric modeling technique implemented in an existing tool.More exactly, the analysis concerns which parts of the datacentric model are implemented in the tool, and which are missing or implemented in a way that requires improvement.Section 8 discusses methodological issues, summarizes practical and scientific contribution of the article, and draws plans for the future.
This article uses an illustrative example from our experience report presented at BPMDS 2013 conference [8].The report concerned a project of building a data-centric process model of a course preparation process, where the goal of modeling was discovering requirements on a BPS system to support this process.Most of the report [8] is available in Appendix A of this article; the parts of the report that concern the project completion and lessons learned are left outside of this article.We refer the readers interested in the details of the project to the original BPMDS 2013 paper.

Case and Adaptive Case Management
Many researchers have emphasized that workflow based BPS systems have problems in managing change and supporting unpredictable processes [3], [4], [9].As a result, case management (CM) systems have been introduced as a solution to be used in the environment where workflow based BPS systems are too restrictive [3], [10].In [3], the differences between workflow based BPS and CM systems are summarized as the difference in focus and the difference in driving force.
The difference in focus means that actors using workflow based systems focus on individual tasks to be carried out in a case (or process instance), while actors using a CM system focus on the whole case and not only on the individual tasks.An actor of a workflow based system executes work items in his/her in-tray without considering the context of the case, which may be harmful for the case as the whole.An actor of a CM system views data/information related to the whole case when carrying out his/her work tasks and thus can take more informed decisions.The difference in driving force means that while workflow based systems are process driven with the focus on executing the control-flow (i.e.completing tasks/activities in a predefined order), CM systems are both process and data driven.It is the case related data/information and the knowledge workers experience that determine which tasks to carry out, and in which order, when a CM system is in use.Therefore, when using such a system, the process execution is decided predominantly at run-time, and not at design-time, which is the standard for traditional workflow based systems.
The next generation of CM systems is called Adaptive Case Management (ACM) systems.There is no commonly accepted definition of an ACM system, and thereby, the difference between CM and ACM is blurred.One interpretation is that ACM systems support situations that are inherently dynamic and unpredictable [4].An example of such a situation could be a physician receiving a patient in an emergency room.While unsure of the real causes to the health issue, the physician still needs to carry out some treatments.Therefore, the results of decided treatments have to be assessed swiftly and continuously in order to better understand the root causes.As a result of such continuous assessments, new plans of treatments may need to be decided frequently.
From the practical perspective, an ACM system is defined as a BPS system that supports socalled knowledge workers in knowledge-intensive processes [4].The system provides the knowledge worker with the required data/information at the right time, and helps the knowledge worker to handle frequent exceptions that occur in ACM processes by supporting continuous replanning.The knowledge worker should also be able to make changes in the case without possessing any programming and modeling skills.
Based on the analysis of the ACM cases in practically oriented books, like [4], it is reasonable to identify processes that are suitable to be supported by ACM systems based on two characteristics of the process * : (a) the level of uncertainty typical for the instances/cases of this process, and (b) the level of volatility of the surrounding environment.
The level of uncertainty concerns the lack of data/information that exists for making decisions in the beginning and during a typical instance/case of the process.Having high-level of uncertainty means that the actions taken in the case are decided based on some hypotheses, which need to be confirmed based on the analysis of the results from these actions.From the system theory perspective, driving a case with uncertainty constitutes a system with a feedback loop.Actions are planned and corrected based on the assessment of the results produced.With a high-level of uncertainty, one expects a possibility to start over again with a loss of much or all of the results achieved in the previous actions, except lowering the level of uncertainty in the case.
Volatility of environment concerns unexpectedness of changes that are outside the control of the process participants.Volatility may be mixed with high-level uncertainty as defined above, but may also occur in the situations where uncertainty is low.In the latter situations, the actions are taken based on the current situation at hand.Sudden changes in the environment may result in the needs to abandon the current course of actions, and thereby lose the results already achieved.
A typical ACM process has a high level of uncertainty, or volatility, or both.This makes replanning an integral part of the process, which is not the case for the workflow process or the CM process where there exists a fixed plan from the very beginning.As it is hard to provide a predefined plan for the processes typical for ACM, when developing an ACM system, the focus is moved to providing data/information and collaboration support.This can be done by introducing templates as a middle ground between blank slates and a completely specified process [11], or using shared spaces for facilitating collaboration as in [5].More detailed discussion on using shared spaces in BPS is available in [12].
A typical way of using a shared space in ACM is described in [5].The shared space usage is based on a blackboard metaphor, and it aims to facilitate cooperation between different subsystems, called lines of work by the authors.Each line of work has its own goals, experts, responsibilities and work scope.The authors of [5] suggest a shared space divided into several sub-spaces, one for each line of work.The shared space also provides common properties for the whole case, i.e. for all lines of work, such as goals and states of the whole case and general case information.The benefits of the shared space are that all case data/information is visually available to everybody during the case life-time, and, thereby, experts in the different lines of work can be inspired by each other and continuously adapt their work to the work of others, thus being more proactive and ensuring successful conclusion of the case at hand.
One of the main challenges with ACM reported in a recent review [13] is the lack of proper theory and model of ACM, also emphasized in [14].This prevents creating a common understanding of the concept of ACM, and hinders comparisons between different ACM solutions.OMG recently introduced a meta-model [7] for CM/ACM business process modeling.Though this model is based on the fact that a CM/ACM process includes continuous planning and re-planning, it does not set in focus the data/information perspective.Instead, it continues the workflow tradition of having the focus on the task/activity flow.The difference between the suggestions from OMG and the workflow tradition is that task ordering in a CM/ACM process is defined at runtime, not at design-time.The meta-model suggested by OMG is quite new, and its usefulness has not been proven in practice so far.In our view, missing the data/information part will limit the usage of OMG suggestions.

Agile Business Process Development
The difference between the traditional and agile business process development based on the analysis of knowledge transformation in these two kinds of development projects is explained in [1], see also Figure 1.The analysis itself has been done based on the Nonaka's SECI model from [15], where SECI stays for Socialization-Externalization-Combination-Internalization.The SECI model describes how knowledge is transformed between tacit and explicit forms in the process of knowledge generation in organizations.For the sake of analysis of business process development, [1] adds to the two forms of knowledge used in SECI (i.e.tacit and explicit) an additional form called embedded knowledge.Embedded knowledge represents the knowledge built-in in a BPS system.According to [1], the main difference between the traditional and agile business process development are as follows:  In agile process development, depicted on the right hand side of Figure 1, phases of Process modeling, Support system design and Support system manufacturing are merged into one phase Support system manufacturing. The nature of the first phase in the agile development is changed compared to the first phase in the traditional development (see the top right corners of the models in Figure 1).In the traditional business process development, the cycle starts with Externalization, i.e. converting the knowledge of stakeholders (process participants) from tacit to explicit forma detailed process model.In the agile business process development, the cycle starts with socialization, i.e. transferring tacit knowledge on the desired process from the stakeholders (process participants) to the design team. In addition, in the agile business process development, one big cycle is substituted by many smaller and shorter ones.The BPS system is built iteratively starting with the basic functionality that does not limit flexibility of process participants to experiment with the new process.During the usage of the basic system, better understanding of the needs is acquired, which is converted in adding more details to the system in the next cycle.Agile business process development is most suitable when a completely new business process is to be introduced in the organization in question, or an existing process is to be radically changed due to changes in the organization's environment.In both cases, there might not be enough information to design the process in details, and a try-and-error approach needs to be taken.In the agile approach, both the business process and a BPS system to support it are developed in parallel.

Why a New Business Process Modeling Technique is Needed?
In this section we give a line of reasoning that guided us when developing our data-centric modeling technique.This line of reasoning is illustrated in Figure 2 and explained in detail below.
As was discussed in Section 2.2, agile business process development presumes having a highlevel tool for building BPS system * .One, and most probably the only, way to create a tool that satisfies the two requirements from Section 2.2 is by using the principle of separation between the program code and the process description, or process model.This allows making changes in the process description/model without changing the system code.The separation between the process description/model and the program code is referred to as executable process models [16].Implementing the idea of executable business process models in practice means having a tool that can interpret a business process model at runtime † .The tool has to be generic, i.e. capable of interpreting a wide range of business process models, to be practically useful.While executable process models can be successfully used in the traditional business process development, this is not mandatory.Therefore using executable models for the traditional process development is identified as optional in Figure 2, while their usage in the agile business process development is marked as mandatory.
To be used as an executable, a process model has to possess certain properties, the most important of which is formality, as the model is interpreted by a machine.The property of formality is essential here, in difference from process models used for other purposes, e.g. for better understanding of business, or for process improvement.In the latter cases, the model is interpreted by people, who can use their knowledge and experience to fill the gaps missing in the model, or understand "fuzzy" parts of the model.That is why the requirement on formalization is identified as mandatory for executable business process model, and optional for non-executable business process model in Figure 2.
As has already been discussed in Section 1, a business process has a number of different perspectives.To ensure quick iterations when using agile methodology, an additional requirement has to be added on the process model.Namely, different business process perspectives are separated from each other, which makes it easy to make changes in the model, and thus also in the BPS system that executes it.For instance, changing who is completing which activity should not affect which activities are included in the business process, and changing the order of activities does not need to change which data are used in the process, etc. Separation of perspectives is advantageous even when the traditional business process development is in place.It will make it easier to introduce changes in the process and BPS system when the changes in business environment occur.However, as with the previous requirement, for the traditional development method this is a "good to have" requirement, while with the agile method this is a mandatory requirement, as depicted in Figure 2. From the requirements 1 in Section 2.2 (creating the first version of BPS in the shortest time), we can derive the needs to be able to start modeling with the perspective(s) most important for the given process type and given context without bothering to depict other perspectives.This need may require using different business process modeling techniques for different processes, unless a universal technique could be found that covers all perspectives to the required extent and, additionally, allows to start modeling with any of these perspectives.To the best of our knowledge, such modeling technique does not exit.Note that this requirement is most important for the agile development, which is reflected in Figure 2. The traditional development aims at building a full-featured BPS system in one go; therefore all perspectives have to be presented in the model in one way or another.As a consequence, "Having main perspective" is marked as optional for the traditional business process development in Figure 2.
Which perspective to start with depends on the nature of the business process to be supported, see the bottom part of Figure 2. The most spread process modeling technique of today supports workflow thinking, which more or less forces to start modeling with the control-flow perspective that helps to ensure the right flow of tasks/activities in the process.A number of proprietary and open source tools and services use executable process models that have control-flow as the main perspective [17], while implementing other perspectives is often done relatively outside the process model.For instance, the data/information flow is often handled with the help of the notion of forms.For the workflow modeling, there exist a number of formal modeling techniques and notations.These range from simple flowcharts to complex workflow diagrammatic languages such as BPMN, and they are supported by a number of modeling tools.What is more, there exists means that can handle formal semantics of workflow models, e.g.Petri-nets, or Colored Petri-nets [18], [19].
As has been discussed in Section 1 and Section 2.1, for CM and ACM systems, the data/information perspective is more appropriate as a starting point when designing executable models, see the bottom of Figure 2 in the neighborhood of the red circle.The absence of a formalizable modeling technique having the data/information view as the main perspective has motivated us to start developing a business process modeling technique that satisfies the requirements included in the blue circle on Figure 2, while following the plan presented in Section 1.

Existing Non-Workflow Business Process Modeling Techniques
As has been discussed in Section 2, the control flow perspective is not suitable as a starting perspective for development of CM/ACM systems based on the concept of executable business process models.The needs to have other types of business process modeling techniques besides workflow based ones are well understood in practice and research, and several attempts to switch focus from the flow of tasks/activities to data/information used in these tasks/activities have been made.In this section, we will review and analyze typical examples of such attempts, choosing the ones that have included relatively formal definitions of the process model.More specifically, we consider the following examples of non-traditional process modeling techniques: (a) declarative process modeling that includes the notion of state [20], (b) artifact-centered process modeling [21], [22], (c) data-driven process modeling [23] and (d) state-oriented process modeling [24].
Declarative process modeling [20] is based on the notions of state, activity and constraint.The state is defined with the help of a finite set of variables (i.e. the state is composite).Activities are considered as legitimate transitions from one set of states to another, and are used for moving from an initial state to one of the final states.Execution of activities is controlled by constraints that enables or fire them.Constraints are defined as predicates over the values of state variables.Besides the state, activity and constraint, the model includes the notion of external event that can affect certain state variables.It is suggested that the formalism could be useful for analysis of correctness of process models.At the time of writing, we do not have knowledge on such model being used for practical purposes, e.g. for practical process modeling or building BPS systems.
Artifact-centered process modeling [21] is based on the notion of artifact.[21] defines artifacts as "business-relevant objects that are created, evolved, and (typically) archived as they pass through a business".Examples of artifacts are an air courier package, a deal, a supplier invoice and an asset.Each artifact is described in form of a life-cycle model represented as a kind of state machine.The life-cycle model describes the possible states that the artifact may go through while being alive.Related to each artifact and, thereby, to the life-cycle model, is also an data/information model containing all business relevant data managed by the artifact, including data/information obtained at the beginning of the life-cycle and added during the life-cycle.The benefit of the technique is that it enables modularity and componentization of business processes.
[22], which extends [21], introduces a formalization for the artifact life-cycle model.The technique is called Guard-State-Milestone (GSM).GSM supports parallelism and hierarchy within a single artifact instance.The data model related to each life-cycle model consists of data and status attributes.This model is fully formalized and has the fix-point semantics.It uses a rich set of notions that includes the notions of event, task, milestone and Event-Condition-Action rules.In the works on artifact-centered modeling available at the time of writing, we could not find any examples of practical application of GSM modeling techniques in process modeling projects or for building BPS systems.
Data-driven process modeling [23] is based on the notion on data and states.In the technique, for each object type in the data model, an object life-cycle model is designed.The latter is represented as a kind of state machine, called life-cycle coordination structure.The benefit of the technique is that it supports coordination of many sub-processes of processes that deal with complex products, such as cars.For instance, the data model could consist of a system (e.g. a navigation system in a car) and a number of sub-systems (e.g.components of the navigation system).For each system and sub-system, an object life-cycle model is designed that describes the states of the individual life-cycle model and its communication with other life-cycle models.The modeling technique suggested in [25] was used for analysis of IT systems that were employed for supporting a process of release management at a car manufacture.
State-oriented process modeling [24] is based on the state-oriented view on business processes.The main concept here is a state of the process instance that can be defined as a position in some state space.A state space is considered to be multidimensional, where each dimension represents some important parameter (and its possible values) of the business process.Each point in the state space represents a possible result of the execution of a process instance.If we add the time axis to the state space, then a trajectory (curve) in the space-time will represent a possible execution of a process instance in time.A process type is defined as a subset of allowed trajectories in space-time.Each process instance of the given type has a goal that can be defined as a set of conditions that have to be fulfilled before a process instance can be considered as finished (i.e. the end of the process instance trajectory in the space state).A state that satisfies these conditions is called a final state of the process.The process instance is driven forward through activities executed either automatically or with a human assistance.Activities can be planned first and executed later.A planned activity records such information as type of action (goods shipment, compiling a program, sending a letter), planned date and time, deadline, name of a person responsible for an action, etc.
All activities planned and executed in the frame of the process should be aimed at diminishing the distance between the current position in the state space and the nearest final state.All activities currently planned for a process instance make up the process plan.The plan together with the current position in the state space constitutes a so-called generalized state of the process, the plan being an "active" part of it (i.e. an engine).With regards to the generalized state, the notion of a valid state is defined in addition to the notion of final state.To be valid, the generalized state should include all activities required for moving the process to the next state towards the goal.A business process type/model can be defined as a set of valid generalized states.A business process instance is considered as belonging to this process type if, for any given moment of time, its generalized state belongs to this set of valid generalized states.
The state-oriented modeling was used in practice for both building models of business processes, see, for instance [26], and for building business process support systems based on these models [27].
Summarizing the examples of non-workflow modeling approaches presented above, we can conclude that:  All of them include definition of data-structures in one way or another, e.g. as a multidimensional state, or artifact. All of them also include notions of events, states, tasks/activities in one way or another, e.g.
as labels marking the transitions between the states. Also, it seems that none of them has been tested for starting the design with the data/information perspective and getting a process model that could be effectively used in a BPS system without developing the full featured model that includes other perspectives, at least, to some extent.Moreover, from the descriptions available, it is clear whether they were not designed for this purpose in mind.Therefore, it is not clear that these process modeling techniques could be tweaked to adjust them to our goal, and whether such tweaking makes sense.Based on the deliberations above, we consider it feasible to start defining the new modeling technique from scratch based on our experience instead of trying to modify one of the existing techniques.The fact that none of them were tested for the aim we have in mind makes our decision at least as feasible as starting with any of them.This, however, does not exclude the indirect influence of the works summarized above on our line of thought, especially the influence of the state-oriented perspective on business process modeling.Our approach to data-centered business process modeling has been developed by reconstruction and critical analysis of our experience, especially the experience of building and using a service/tool called iPB aimed at agile development of CM/ACM systems.

Background for the Development of Data-Centric Modeling Technique
As was mentioned in the introduction, our design is based on the analysis of three sources (1) form-based case management in the public sector, (2) our own experience of developing formbased CM systems and tools that support such development, and (3) database theory and practice.As the first two sources are not well known, we present a short description of them in this section.As far as the database theory and practice is concerned, we presume that the reader knows this domain at the extent needed to follow the material of this article.

Form-Based Case Handling as an Example of Data-Centric Process Modeling
Our experience with CM systems started with the analysis of case handling in Swedish municipalities that included general case handling in the Municipality of Motala [26] and case handling in the social welfare office of municipality of Jönköping, e.g.handling applications for child adoption, and later handling cases of suspected child abuse (see Section 4.2).Case handling that we observed in municipalities was template/form driven, rather than task/activity driven.There were templates, often of the type of structured forms, for filling an application, investigation, and decision making.
Template/form driven case handling cannot easily be translated into the task/activity driven one, as the same template/form can be used for several different tasks/activities, e.g. for both application and decision making.Tasks/activities can be represented in such case handling in different ways.For instance, a task/activity of decision making can be represented in the form by three fields: (a) decision, (b) name of decision maker and (c) date when the decision has been taken.A set of tasks/activities can also be represented as a checklist on the form that requires putting a cross beside each task/activity on the list before the form can be considered as properly filled.
In the template-based case handling, there often are no strict rules as when starting to work with a certain template.For instance, the main result of an adoption case is a report that follows a certain template.The report is based on a series of meetings with the applicant(s), but there is no regulation when to start writing the report: directly after the first meeting or after the whole series has been completed.The choice is left to individual case managers.The same applies to the order in which the report is compiled.Though the report concerns 10 different issues placed in a certain order, obtaining and reporting information on them is not to mandatory be done in this order; the investigator can add information that concern any issue as soon as it becomes available.
Swedish public sector is not the only domain where designing forms are the most important part of designing a business process.This, for instance, also applies to designing a process of reviewing journal or conference papers.The two most important forms to be designed here are a submission form that should include the information on the paper, e.g.title, authors, category, and one or several reviewing forms for different categories of papers.The reviewing work is controlled by the latter forms that prescribe the results desired to be achieved and not the tasks that should be completed, e.g.download the paper, read it, think of it critically, write a review, etc., and their order.The tasks that are used for describing the reviewing process, e.g.submit, or review, formally, are equivalent to "fill out a particular form and save its content".The order in which these tasks are completed can be described as rules for filling out the forms.For instance, the reviewing form cannot be filled out before the corresponding submission form, including the text of the submission has been fully filled.Another set of rules could set restrictions on the human resources as follows: none of the authors on the submissions form could appear as a reviewer on the corresponding reviewing form * .
Summarizing the above, for some processes, a package of templates or forms to be filled can serve as a better model of the business process than a flowchart of tasks/activities to be performed.Such a package will say much more about the process than the flowchart.Adding the rules that restrict the ways the forms can be filled can serve as an alternative way of defining the order of tasks (different from the flowcharts).

The iPB Project -Developing a Tool for Supporting Loosely Structured Processes
iPB [28] is a tool from Ibissoft AB for developing BPS systems that support loosely structured business processes.The iPB project was initiated in connection to the Swedish National Board of Health and Welfare effort to standardize handling cases of suspected child abuse in Swedish municipalities.The process got the name BBiC, which is the Swedish abbreviation for "Childs' Needs in the Center" ("Barnens Behov i Centrum" in Swedish).The process concerned investigation, decision making, and following up decisions in cases of suspected child abuses, or families that could not take care of their children.The standardization in BBiC was done not by producing a workflow diagram of the process, but by producing a package of templates/forms mandatory to be used during handling cases.Each municipality that licensed the process was free to choose their own way of implementing the forms.They could use the forms as RTF, or Word templates or incorporate them in their case-handling systems themselves or with the help of their ordinary system vendors or integrators.
Having been invited to participate in the project as a system vendor, IbisSoft decided not to start directly with developing a system to support the BBiC process, but to develop a tool that would allow to relatively quickly "configure" such a system by defining a process model.The goal was to be able to use the tool for developing BPS system for other form-driven processes later.One of the main requirements on the tool was that a person with knowledge in the domain, and with the minimum of technical knowledge, could use it for configuring support for a new business process.The development started in 2007 and it resulted in a tool called iPB [28], [29].The theoretical and practical basis for iPB development was the state-oriented view on business processes [24] and prior experience of building business process support systems based on this view [27].
In the iPB project, the BBiC process has served and continues to serve as a pilot for the tool development.The iPB-based system that supports this process went through several major revisions after the first introduction, where the complexity of the process model had been gradually increased.Currently, the iPB-based system that supports BBiC has around 270 active participants, including 80 % of heavy users who work with the system on a daily basis, and 20 % of occasional users who work with it rarely and complete only few tasks.
The first version of iPB included means for form building and user interface design for navigating between the forms.In consequent versions, new functionality was added that allowed introducing of business rules that set restrictions on the usage of forms.The result was a tool based on the concept of executable business process model in which management of data has * More detailed description of this process and forms used in it can be found in [40].
been placed in the focus.iPB is described in more details in Appendix A alongside with an example of a process that can be supported by an iPB-based BPS system.

An Outline of a Basic Data-Centric Business Process Model
In this section, we give an outline of our basic data-centered centric business process model.For this end we will employ an analogy with relational databases, assuming that the reader is familiar with this domain.This outline can be formalized, which is shown in Appendix B, where formal definitions for a substantial fragment of the model are presented.

Data Perspective
Let us assume that each process instance/case has its own relational database which state represents the state of this process instance.The database consists of tables, each table can be considered as related to some form of the type discussed in the previous sections.Each column in the table can be considered as a placeholder for a value of the corresponding field.Naturally, the columns are typed, and a type can refer either to a simple object, e.g.integer or string, or complex object, e.g. a company or person, that can be represented in the form as an area with several fields.
A row in the table represents the content of a form filled out by the user working with the corresponding BPS system.Some tables allow only one row, which means that the corresponding forms can be filled only once.Other tables allow multiple rows, which means that corresponding forms can be filled multiple times.Permitting/not permitting multiple rows represents a special property of a table in our database.
Each row in each table has its own unique identifier.This identifier is not important for the tables that accept only one row, but is useful for the tables that accept multiple rows.The unique identifier corresponds to the concept of surrogate keys in relational databases and the autonumbering data type that exists in some DBMS.Now, we can define a notion of business process state st as a set of rows stored in the instance database.A sequence of the states, called a trajectory tr, represents the development of the instance in time.Having the notions of state and trajectory, we can define rules that govern such development by restricting the set of allowed states, and allowed transitions from one state to another.To create such rules, however, we need to extend the notion of state to include additional components.Besides a set of rows in the database tables, the following components are included in the extended state: 1.A set of locked rows that cannot be updated until unlocked.A locked row represents a form that is no longer available for updating.A sequence of extended states is called an extended trajectory etj.Having a notion of extended state and extended trajectory as a representation of a development of the process instance/case in time, we can define several types of rules that govern such development.The rules can be of general character, i.e. valid for all business process types; or they can be specific for a particular process type.
To the general rules, belong, for instance, the following: The max number will prohibit adding more records than defined by this number.3. Unlocking rulesare conditions that should be fulfilled when an empty table can be unlocked for adding records.At the start of the process, all tables are considered to be empty and locked.If there are no unlocking rules for the given table, an empty table can be unlocked at any moment.An unlocking rule may require that before unlocking the table some conditions are satisfied.Such condition refers to other tables that have to be nonempty and/or locked in order for the condition to be satisfied.The unlocking rules constitute a mechanism of establishing order in which records can be added to the tables.This concept can also be extended to automatic unlocking, when the table is automatically unlocked in case the condition is satisfied.Note that the demand on some other table to be locked will also imposed for all mandatory lock columns in this table to have some values to ensure integrity of the database state.4. Conditions on the final statesare conditions that should be satisfied for the extended trajectory to be considered as properly finished.One general condition that all tables are locked in the last state has already been mentioned.This condition ensures that all mandatory columns have values in all rows of all tables.The specific conditions set requirements which tables should have records and which ones could or should remain empty.5. Table dependenciesis a set of rules related to the dependencies between the rows from different tables.For instance to such rules belongs the requirement that any row r i in table t 1 should have a corresponding row r j in table t2 such that there is a dependency < r i , r j >.Deleting row r j in table t 2 automatically leads to deleting row r i in table t 1 .In Appendix B, we present formalization of the outline discussed above using slightly different terminology.We use term variable instead of column, group instead of table, and record instead of row.We will use this terminology in the rest of the article.The main concepts that are presented in this section and Appendix B, and their analogs in the world of relational databases are summarized in Table 1, the last column of which refers to the sections of Appendix B that discusses the corresponding concepts.

Human Resources Perspective
Human resources perspective has two dimensions.The first dimension is to define which participants have rights and/or obligations to participate in the process instances and in what capacity.The second dimension concerns who are assigned to do what in the frame of a particular process instance/case.To reflect these two dimensions in the frame of our data-centric business process model, we follow the database practice and introduce the concept of roles and users to represent these dimensions accordingly.Roles are defined on several levels: 1. Global, were the role correspond to the position of the user in the given organization, e.g.manager.2. Process instance, were the role defines what a given user does in the frame of the whole process instance/case, e.g.owner, secretary.3. Group (or table) in the given process instance, where the role defines the responsibilities of the user in relation to this group, e.g.author (the person who adds data), or controller (the person who is responsible for checking the data in this group before the group is locked.4. Record (or row) in the given group of the given process instance, where the roles are similar to the ones of the group but the actions are limited to a particular record in the group.A user is assigned a role on the Global level as soon as he/she can potentially become a participant of the process.Assigning the role on the lower levels is done for a particular process instance and particular groups and records in this instance database.
Two types of information are connected to each role: 1.Which roles at the lower levels a user with a particular role on the upper level can have.For instance, a user with the manger role on the global level (level 1) can be assigned the owner role on the process instance level (level 2). 2. Which access rights to the components of the instance database a given user has if he/she has been assigned a certain role.Access rights are defined on three levels (1) process instance database, (2) group (table) and ( 3) record (row).Detailed description of possible access rights is presented in Table 2.A user can have several roles in relation to a particular database component through different levels of engagement in the given process instance.For instance, a user can be an owner of the given process instance database, an administrator of a particular group in this database, and have some role on the global level.Each role can bring certain access rights to a particular database component.In this case, the actual access rights to the database component are defined as a union of access rights from all different roles for this user in relation to the database component.

Data Presentation Perspective
Besides tables, relational databases introduce the concept of views where data from several tables are combined to create a new virtual table.This helps in achieving more flexible access control, and independence of data usage from the structure of storage.A concept of views can be helpful for data-centric process modeling for the same reasons as for the databases.Views can be used instead of groups (tables) when defining the state and trajectory (extended state and trajectory) for a given business process instance.They can be subjected to unlocking rules instead of tables.They can also be subjected to the same rules of access control as tables.The latter allows creating completely different views on the same process for different categories of users.It also allows hiding some information from some users, while giving full access to others.
The following ways of creating views can, for instance, be employed for the basic data-centric business process model: 1. Group projection on a subset of variables that belong to the group, which corresponds to choosing only some columns from a table.This is the simplest way of creating a view that can be used for hiding some variables from some users.2. Combination of group projections for two or more non-repeated groups that creates an aggregated view.This type of view can be used for providing easy access to the information already available to the users who need to add extra information.Suppose we have two groups g 1 and g 2 that according to the unlocking rules are to be filled with records in a sequential order, first g 1 and then g 2 .Suppose also that the user that deals with g 2 needs some information from g 1 .Instead of the user going back and forth between the records in these two groups, we can provide him/her with a view that includes all variables from g 2 and relevant variables from g 1 making the latter read-only in the view.3. Combination of group projections for two or more repeated groups for which one-to-one record dependencies are established.This is a variation of 2 above, but the view created will be with repeated records, part of the variables coming from one record, other parts from the other(s).This type of views can be used for the same purpose as in point 2 above.4. Master-detailed view, a combination of projections of one or more non-repeatable groups and one or more repeatable groups with or without dependencies between them.This type of views helps to group data with which a user completing a certain task has to deal.Some of the projections can be read-only (filled via other views), others are filled when working with this particular view.Another way of using such views is creating a kind of reports related to the progress of the whole process instance.

Pragmatic Mechanisms Outside the Process Model
Besides a good theoretical basis, the field of (relational) databases gives examples of pragmatic mechanisms implemented in modern DBMS that are widely used for developing database-centric software systems.Similar mechanisms can also be employed in connection to our data-centric business process model.A typical example of such mechanisms is triggers that allow adding actions to any attempt to change the database state.Such actions can be of internal nature, i.e. result in additional changes in the database or preventing changes in the database, or completely external, i.e. invoking an external function or service.Though triggers may not become part of the theoretical process model, they can be useful when building a BPS system based on the execution of the data-centric business process model.For instance, a trigger can be set on any action of assigning a user some role on the instance, group or record level to inform the user, e.g.via email or SMS, about his/her new assignment.Another trigger can be set for any change of any record or group informing the users having some roles on this record or group level about changes related to their current assignments.

Extending the Basic Data-Centric Process Model by Adding New Semantic Concepts
One of the distinctive features of the basic data-centric process model from the previous section is that no semantics is assigned to the variables (columns) in the model, except that the values of the given variable should belong to some predefined domain.A variable can represent pure data, or an action to be or already completed in the frame of the given business process instance.While the basic data-centric model can be extended in different ways, its extension without identifying the semantics of data has limitations.For instance, the condition of unlocking introduced in the basic model is expressed in terms of groups having no records and locked.In principle, the unlocking rules can be extended so that any kind of logical expressions that include predicates defined over the content of the instance database can be used as conditions for unlocking.In this case, we can introduce data-dependent unlocking rules.However, while such extension greatly increases the expressive power of the modeling language, it will also makes it difficult for business people to define and understand such rules.To avoid the latter, the rules have to take into consideration the semantics of data included in various groups and views.The idea is discussed in more details below with the reference to the example presented in Appendix A.
Analyzing the iPB model presented in Appendix A, we can see that data can represent different things, e.g.:  Artifacts, such as Lecture presentation in Figures A3 and A4 . Artifacts characteristics, such as Title in Figures A3 and A4. Resources assigned to an action, e.g.Teacher 1, Teacher 2 in Figures A3 and A4. Time for action, e.g.Start and Finish in Figures A3 and A4.Taking into consideration the meaning of data and connection between groups and records we can create rules that would facilitate some automation.For instance, group Lecture/Lessons Teacher Feedback (see Figures A2 and A5 in Appendix A) can be automatically unlocked when the real time becomes equal to the start time of the first planned lecture.Moreover, at the time of the lecture start, a new form for recording feedback can be added to the Feedback group, In addition, Teacher 1 and Teacher 2 can become responsible (role) for completing the feedback form of Figure A9.More detailed discussion on this matter see in [14].
The example above demonstrates that adding semantics to data elements can make rules of data-dependent automatic unlocking and user assignment easy to understand from the business point of view.This example is typical for ACM processes where planning is followed up by execution of the plan, see the discussion in Section 2.1.As the semantic relationships between the groups representing planning and executing plan are quite general for the ACM processes, it is worth to include this relationship in the model in an explicit form, like linking variable in one group to the condition (time) of unlocking of another group.
Another important issue of business process modeling is process decomposition that allows invoking subprocesses common for several processes.Process-subprocess relationships can formally be represented via introduction of variables that take values of process instances.These variables require special treatment, as it should be allowed to include the values of the subprocess variables in the views that belong to the main process to reflect the changes taking place in the subprocess.From the data-base point of view this is analogous to having views over several databases.

Implementation of the Data-Centric Model in iPB
The fact that the design of our formal data-centric model was inspired by analysis of iPB does not mean that the model just formalizes what has already been built-in in iPB.iPB has been built in a pragmatic manner in several iterations that extended the initial design in several directions, while testing the tool in several practical projects.The formal data-centric model has been built based on the database theory that helped to generalize and formalize the features implemented in iPB.The goal of formalization has been to give exact semantics to practical modeling techniques implemented in the tools like iPB.This model can be used to guide further development of the existing tools, like iPB, and/or development of completely new tools based on this model.In other words, the formal model is to be used by the tool developers to analyze existing tools in order to find the areas of improvement, and/or create new tools.
As iPB is a practical tool created through experimentation, it does not implement the datacentric business process model exactly as defined in Section 5 and Appendix B. In particular:  iPB "mixes" internal structure of the database with data representation to the end-user in the concepts of process maps and forms. iPB uses business terms, such as map, step, form, widget, open, close, business rule, etc., while formal model uses more abstract notions, such as variable, group, record, scheme, state, locked, unlocking rules, etc.Still, iPB implements many of the concepts introduced in Section 5 and Appendix B, though some time this is done indirectly or in a mixed features manner.In Table 3, we present the correspondence between the concepts of the formal model and iPB to highlight similarities and differences between them.

Form Field
Form Field defines both the variable, i.e. the name and a set of values, and its visualization in the web form.See Figure A3.

B.1
The value that the end-user inputs in a Form Field See Figure A4.
Form Form defines both a set of variables and visualization of them.In addition, Form allows including references to the fields in another form.The latter means that Form is also used for defining a view that combines records from more than one group.See

Filled form saved by the user and marked as write protected
See the Write protect button in the tool menu of Figure A3 (with lock icon to the left of it).

B.2
Step in the process map that is marked as gray (cannot be started yet), or blue (finished) The gray color corresponds to the empty locked groups.The blue color corresponds to the non-empty locked groups.See Figure A5.

B.2
Filled and saved forms that belong to synchronized steps Synchronization means that two steps have the same number of filled forms represented as tabs in Figure A9.Dependencies are shown in two ways: (a) through having the same tab labels, and (b) through reference fields showing the values from the ordinary fields that correspond to the parent form.For instance, reference fields Title and Type in Figure A9 shows the values from the corresponding field in the Seminar form.The views functionality is limited in a way that all fields that refer to other forms are defined as readonly.

Notification to participants on instance and group level
Any assignment of a role to a particular user can result in this user getting an email message.The same happens when there is the change in the data related to the step in which the user has some role.

Assigning semantics to variables 6
The first step made: the relationship between the process instances of process-subprocess type has been implemented The only feature implemented from the extended model is process variables (fields in iPB) that refer to other process instances.
8 Discussion and Plans for the Future

Notes on the Research Paradigm Used in the Project
The research reported in this article has been completed in the frame of Design Science (DS) paradigm [30], [31], [32].Although normal practice is to discuss methodological aspects in the beginning of the article, we have chosen to put it at the end in order not to distract the readers unfamiliar with DS to follow the ideas and arguments * .DS is related to finding new solutions for problems known or unknown [33].To count as a DS solution, it should be of a generic nature, i.e. applicable not only to one unique situation, but to a class of similar situations, cf.Principle 1 of [34].DS research can be considered as an activity aimed at generating and testing hypotheses for future adoption by practice [35].DS, as a way of generating and testing hypotheses for generic solutions, requires researchers to act in two different worlds: (a) the real world of specific situations, problems and solutions in local practices, and (b) the abstract world of generic situations, problems and solutions [35].DS does not impose any particular order of movement in the two worlds.A researcher can start with a specific problem in a specific situation, find a solution for it (situation to-be that solved the problem), and then generalize all three parts of his/her test case: situation, problem, and solution.Classification of the ways of working in this manner is presented in [33].The researcher can also * On the problems that can arise when wrapping the text in methodology, see [39].
start from the other endwith finding a generic solution for a known generic problem and then try to find and implement a test case for its demonstration.A kind of "shuttling" between the two spaces is suggested in [34] in the Formalization of Learning stage of Action Design Research (ADR), which aims at transforming situated learning results into classes of field problems and generically applicable solutions.
This research was initiated by a practical problem of incremental (agile) development of BPS systems of the CM/ACM kind.This problem has been formulated on the general level as a having a business process modeling technique that complies with the following requirements (see Section 2.3): 1. Different business process perspectives are separated from each other in the model, which makes it easy to make changes in the process model, and thus in the BPS system that executes it.2. Process modeling can start with the perspective most important to support in a minimal BPS for a given process.For CM/ACM processes, the data perspective is the one that can help in building a minimal BPS.The general solution as a data-centric business process model was sought through analysis of a local practicethe iPB tool in our case.This analysis followed by designing an outline of the data-centric business process model based on the database theory and practice as presented in Section 5 and Section 6.A substantial fragment of this model has been formalized in Appendix B. Other parts can be also formalized, but this task is beyond the scope of this article.
DS also sets a requirement of a generic solution being practically useful, so that it can be used for solving specific problems.This issue is discussed in the next section.

Practical Usefulness
As was discussed in Section 4.2, iPB development was started as a reaction on a concrete practical task of developing CM systems based on the idea of executable business process models.As the commonly accepted workflow modeling techniques were not suitable for our task, we devised a practical modeling technique implemented in iPB.The development had several iterations in which new features were successively added to the process modeling technique and iPB.For instance, such features as the step start rules (see Figure A3 in Appendix A) and step synchronization rules (see Figure A7 in Appendix A) appeared quite late in the development, when the iPB-based BBiC system was already running at the municipality of Jönköping.
The data-centric process model presented in this article is a reaction on the needs of having a scientific base for development of iPB to avoid ad-hoc solutions that might be reversed at the later stages of development.The model suggested in this article gives formal semantics of iPBbased modeling and can be used to analyze the features already implemented in iPB, and guide further development.Even in its incomplete form as in Section 5, Section 6 and Appendix B, the formal model can be used for this end, as it is more general than the model built-in in iPB.For instance, unlocking rules in the formal model are of a more general nature that can be expressed in the matrix of Figure A7 in Appendix A, which may lead to extending the ways the unlocking rules are defined in iPB.Another example is the rules on the final states that are currently absent from iPB.
Analysis of roles and access control presented in Section 5.2 gives better understanding of what is missing in iPB and how to make access control more elaborated.Also, the idea of views helps to understand the conceptual mixture crawled in the iPB design, and how to separate different concepts to make this design cleaner.It also gives directions to new extensions, where different users can have different views on the process.This can be especially useful for interorganizational processes where there is a need to hide details pertained to each individual organization revealing only information that can be useful for others.
Note that iPB is not the only tool that takes form-based perspective on business processes.Other tools, like IBM Forms Experience Builder [36], also try to combine forms with process management, though built on the workflow perspective.We believe that our data-centric model, especially extended with the concepts discussed in Sections 6, could be of help for analysis and further development of the existing form based tools, as well as building new tools from scratch.Moreover, even traditional workflow based vendors as Bizagi started to look for database related business process theories, as has been expressed in their keynote at BPM 2015 conference [37].

Research Contribution
The main goal of this article was to suggest a formalizable data-centric business process model that would be suitable for agile development of CM/ACM systems.This has been done in Section 5 and Appendix B where the main concepts of such model have been outlined and partly formalized in a step-wise manner based on the following two ideas: 1.A business process instance is viewed as a sequence of this instance database states called a trajectory.2. A business process model is viewed as a database scheme that includes rules of correctness of allowed trajectories.Such a scheme, called extended scheme, includes rules that ensure integrity of the database state and sets restrictions on transitions from one state to another.In addition to the basic data-centric process model of Section 5 and Appendix B, the article discusses its possible extensions via introduction of semantics of data that could enhance the expressive power of the model (see Section 6).
The approach to business process modeling suggested in this article radically differs from the traditional approaches.A traditional approach, normally, starts with the notion of task/activity and tasks/activities flow, and only later the concept of data/information flow might be added.Our approach starts from the opposite end, i.e. with defining data structures to be used when running the process instances, and data/information flow (through the rules of unlocking).Only after that, the notion of task/activity might be introduced through assigning semantic interpretation to some data elements, e.g.considering them as tasks/activities planned or executed.Our approach also differs from other non-traditional approaches to business process modeling, which introduce both the notion of data and task/activity at the same time, see Section 3. To the best of our knowledge, an approach similar to ours has not been discussed in the contemporary research literature.
Our approach has its roots in practice.It was built based on the analysis of the existing ways of case management in the Swedish public sector, and practical experience of development of BPS systems of the CM/ACM type based on the idea of separation of code from the description/model of the business process to be supported.More specifically, our formal model was built based on the analysis of iPB and BBiC projects presented in Sections 4.2 and 4.3.
We envision that the formal data-centric process model would be useful for analysis of the existing CM/ACM systems and tools for building such systems.This can be done by mapping the concepts built-in in the given CM/ACM system/tool to the ones of the formal model in order to better understand the system/tool properties and have a scientific base for planning further development of this system/tool.This procedure has been applied to iPB in Section 7 and 8.2, which constitutes the first proof of the formal model usefulness.We believe that such mapping could be of use for planning further development of other existing ACM systems/tools, and for the development of new BPS systems and tools that support such development.
In our view, the following features of our data-centric business process model make it potentially useful for BPS system development aimed at supporting processes of CM/ACM type: 1.It has the focus on data structures and data flow which is of importance in this kind of systems, especially for the ACM systems aimed at supporting knowledge workers in knowledge intensive processes.In this kind of support, providing different views on the data/information obtained or created in the process is of utter importance.2. The model has a theoretical and experience-based ground from the database theory and practice, which is a mature discipline with a long history of practical usage.This gives the possibility to continue the development of the model by "borrowing" the concepts from the database domain, as we have demonstrated in Section 5.2 and Section 5.3.The existing experience of building Database Management Systems (DBMS) could also be helpful for building tools that supports CM/ACM development (see Section 5.4).The model is built using the idea of separating different concerns from each other as much as possible.The extended scheme that defines the process model consists of seven elements, which can be changed relatively independently from each other.For instance, new variables can be added to a group without any need to change the unlocking rules.This separation of concerns was systematically followed in iPB, where form design is separated from the step start rules, and from step synchronization rules.What is more, even inside one component of the model, e.g.unlocking rules, rules are separated from each other; adding or deleting a rule does not necessarily affects other rules * .The latter is also respected in iBP, changing a cell in the step start rules matrix in Figure A6 (Appendix A) on its own does not warrant changes in other cells.
The separation of concerns is important for achieving three practical goals when using our formal model for building CM/ACM systems/tools: 1.It is possible to start developing a BPS system and especially a tool that supports development of CM/ACM systems with implementing only some concepts of the formal model, while leaving the rest of them to be implemented in the next iterations of the development.Having such a possibility is especially important if the agile method of software development has been chosen.As our experience from iPB and BBiC projects shows, it is possible to develop a useful system/tool without implementing all concepts of the formal model.For instance, as has already been mentioned, the step start rules that implements the unlocking rules of the model were introduced in iPB at a relatively late stage.2. The separation of concerns makes it easier to develop new processes in an agile manner when the process development is conducted concurrently with the BPS system development [1].Using a tool with separation of concerns allows to start with very loosely defined process, e.g. as a set of forms to fill when running process instances.Then, based on the gathered experience, some restrictions on the order in which the forms are to be filled are introduced and/or some fields are made mandatory for save or locking.This can be done and redone without any or with only minor restructuring of the process that is already in operation.3.Even without employing the agile development, separation of concerns makes it easier to maintain the system when changes in the business environment require changing the process, and thusthe BPS system that supports the process.

Plans for the Future -Challenges to Overcome
The formal definitions presented in Appendix B formalize the substantial fragment (that corresponds to the ideas from Section 5.1) of the basic data-centric business process model outlined in Section 5. Other components of the basic model, i.e. access control and views presented in Section 5.2 and 5.3, still need formalization.Also, our suggestions for the extended data-centric process model discussed in Section 6 need, firstly, further analysis and, secondly, formalization.Both formalizing the rest of the basic model and working on the extended model are included in our plans for further research.However, extending and formalizing the model, on its own, does not guarantee the model being adopted by practice.As discussed in Section 5, the data-centric business process model is too formal to be of use for business people, and even for majority of software developers.Therefore, the main challenge for promoting the data-centric process modeling is in creating a more suitable notation for depicting process models.
Fully understanding the main challenge above, we include the development of a practically oriented notation for data-centric process models in our plans.Such notation should be graphical and expressed in business related terms.In developing this notation, we hope to get help from the experience obtained in the iPB project in which graphical means were used for representing various formal concepts.Though the iPB-based notation is not ideal from the research point of view, it proved to be useful for non-academics and non-technical people.The executable model for the BBiC project discussed in Section 4.2 was built by one domain specialist who continues to develop the BBiC system having only the second-tier support from IbisSoft.The person is a professional in the domain of the social welfare who acquired some technical knowledge to become a go-between between technical and business people.Besides building and supporting the executable BBiC model, he used iPB for creating IT support for about a dozen of other processes in the office of social welfare of Jönköping municipality.version of relatively sequential execution of activities in the course process in the format of UML activity diagrams so it can be compared with a data-centric model presented in the next section * .

Figure A1. A possible workflow model for the course process
The workflow-based way of preparing and giving a course was predominant in the past.However, according to the latest research on university teaching [38], the landscape of university teaching has changed in the last few decades.The main characteristic of the new landscape is the diversity of students, which requires adjusting the course to their level and background.This is especially true when giving a completely new course or an old course to a different or unknown audience.In the latter cases, there might be a need for changing the teaching/learning activities, material used in them, or the schedule when the course has already been started.In the "worst" case, the preparation before the course can be limited to devising an introductory lecture or/and a test to identify the level of preparedness of the students.Everything else is designed on the fly during the course.
The worst case described above corresponds to the high-level of uncertainty discussed in Section 2.1 of the article, therefore the course preparation process could be considered as a good candidate for being supported by an ACM system.Note that in the authors' own department, based on the practice of which we designed an iPB-model presented in Section A.2 and Section A.3 † , many courses are prepared and run in non-sequential manner.

A.2 Business Process Modeling Built in iPB
As was noted in Section 4.2 of the article, iPB was designed as a tool for developing business process support systems/services for loosely structured business processes.iPB consists of two components -Design studio, and Runtime environment.Design studio is used for building a process model, while Runtime environment interprets (executes) this model while helping process participants to run their process instances/cases.
Process modeling in iPB is based on four main abstract concepts: Process map, Process step, Step form, Form field (additional concepts are described later).The basic relationships between these main concepts are as follows.
 A process map consists of a collection of named process steps arranged on a twodimensional surface called process layout.The layout consists of two areas -(a) the upper row called flow-independent steps, and (b) a two dimensional matrix underneath the upper row called flow-dependent steps, see Figure A2 * . Each process step in a process map has a step form attached to it. A step form consists of a collection of named form fields arranged in a two-dimensional matrix called form layout, see Figure A3.Each field belongs to a certain type.There are simple types, like, text, multi-text, date, date-time, option list, checkbox (Boolean), etc., and complex types, such as uploaded file, journal, person, organization.In addition, field collections that belong to different step forms can intersect.The latter is done by defining fields in one form, and then referring to them in other forms.A process map with underlying step forms defines a kind of a database scheme for the given process type.This scheme is then used by the runtime system for "creating" an "instance database" for each new instance/case of the process defined by this process map.The runtime system also interprets step forms as web forms for inputting, viewing and changing information in the instance database, see Figure A4.The process map is used for creating an instance map, see Figure A5, that serves as a mechanism for user navigation through the web forms.To open a web-form, the user just clicks on the step in the instance map.As we can see from Figure A4, some steps are allowed to have multiple forms at runtime (see the tabs for each lecture in Figure A4).In this case, besides filling a form, the user can also add and fill new exemplars of the form, or delete existing exemplars.Besides filling a form and saving it, the user can mark the form as write-protected, or close the step.In the latter case, the step will be marked as finished in the instance map, see steps with the blue background in Figure A5.Besides the main concepts described above, there are some auxiliary concepts implemented in iPB to provide additional capabilities, e.g.:  Step properties, such as permission to have more than one form (as in Figures A4 and A5). Mandatory fields that establish when data in a step form can be saved or made writeprotected.Such rules are expressed via defining some fields on the form as mandatory for save, or close. Step start rules that control whether the user can open a particular step form based on the states of completion of other forms.Steps that cannot yet be clicked on are colored grey, see Figure A5.Such rules are specified with the help of a square matrix where both rows and columns correspond to the steps defined in the process, see Figure A6.In this matrix, the content of a cell can, for instance, determine that the row step can be started only after the column step has been completed (blue color in Figure A5), or started (green color in Figure A5). Step synchronization rules for steps with multiple forms.When step A is synchronized with step B, a form in step A cannot exist without being connected to a corresponding form in step B. For instance, step Lecture/Lesson teacher feedback in Figures A2 and A5 is synchronized with step Lecture/Lesson, thus each feedback form is connected to the corresponding lecture/lesson form.These rules are defined by a square matrix where a checked box means that the row step is synchronized with the column step, see Figure A7. User profiles that specify categories of users and their access rights to view and change information in each step form. Visual properties assigned to the fields that define their look and feel at runtime.This part of iPB is not related to process modeling, but to system development. Notifications send to the users when they become participants of the process or a particular process step; or when data has been changed in a form of a step for which they are registered as participants.Though iPB is built on the few basic concepts, it is powerful enough for representing various aspects/perspectives of business processes.Below, we give some examples of how different aspects of processes are represented when building a process model in iPB:  Structure of data/information created and utilized in the process is defined through creating step forms. Data/Information flow in the process is defined by including references to the form fields from the previous step forms into the form where this information is used. Participant collaboration in the frame of process instances is defined by inserting complex fields of the type Journal in the step form; see the field "Forum for discussing …" at the bottom of Figures A3 and A4.Users working with the same form add records to the journal registering questions, answers, comments, etc. relevant to the particular step. Tasks/activities included in the process and restrictions on the order in which they can be completed are specified in the following manner.The concept of step is used for representing larger chunks of workwork-packages; if smaller tasks are needed they are represented in the step forms as checklists in the way accepted for case management/adaptive case management systems.The order of steps is represented by (a) process layout that gives a recommended sequence of steps (from left to right and from top to bottom), and (b) by business rules that restrict the possibility to "jump over" some steps.On the lower level, a possibility of making task checklists mandatory gives an opportunity to prevent finishing the step to which they belong until all tasks have been completed.The latter can prevent starting the next step if it is forbidden by business rules that require finishing the previous step first.
 User rolescategories of users engaged in the process and limitations on the data/information they can access (read, write, or modify).They are defined with the help of user profiles.

A.3 The iPB-Based Course Model
The iPB process map for the course process from Section A.1 is presented in Figures A2, A5 and  A8. Figure A2 presents the map in the design studio in the form convenient for model developers.Figure A8 presents the map in the form convenient for discussion with business people.Figure A5 presents a process instance map in the form used for navigation in runtime.Figures A3 and A4 demonstrate a step form typical for this process, more exactly the form for step "Lecture/Lesson".Figure A3 presents the step form as viewed in the design studio, and Figure A4 at runtime.
As follows from Figure A8, the process map for the course process is clearly divided in two parts: (1) preparation of the course to the left and including Exam, and (2) giving the course.The first part is structured according to the artifacts that need to be prepared for the course, each component being represented as a step in the model (see Figure A8).This part includes (a) general components: Course general description (mandatory), Course book (optional), Course compendium (mandatory), Article compendium (optional), Exam (questions, and instructions for assessment), and (b) specific components that correspond to teaching and learning activities: Lecture/Lesson, Seminar, Lab, and Assignment/Project.
Each step has a step form attached to it that defines the data structure for this step.A typical form, the one for step Lecture/Lesson, is presented in Figure A3 (the design studio view), and Figure A4 (runtime view).It includes the descriptive fields, like: Title, Type, Description, Lecture presentation, and the administrative fields, like: Teacher, Start, Finish, and Location.In addition, it has a journal like widget named Forum for discussing under preparation were the teachers preparing this teaching/learning activity can leave comments for themselves and for each other.Note that the form in Figure A4 allows multiple forms at runtime (see tabs)one for each teaching/learning activity.Multiple forms are also allowed for all other steps except Course general description, Course compendium, Exam, and Evaluation.
The second part of the model, all steps on the right of step Exam, deals exclusively with getting feedback for course activities from the teachers and students.More exactly, the steps that end with "teacher feedback" are aimed at gathering feedback from the teachers immediately after  The feedback steps are synchronized with corresponding preparation steps.When step A is synchronized with step B, the former will automatically get the same number of forms as the latter.If there are references on the A's form to the fields on the B's form, then the references are also synchronized so that they show the contents from the corresponding forms.For instance, fields Seminar title, Teacher 1, Start and Finish in Figure A9 are references to the fields on step form Seminar, and show their content from the form Open House Seminar.
The order of steps in the process model given via the layout represents only the recommended order.We found that it is almost impossible to establish a strict order to which all teachers in our department would abide.Although it is highly recommended to have all material ready before the start of the course round, it happen that changes in some materials and in the schedule are done very late, sometimes after the course has already been started.This is especially true when the course is given for the first time.
Step start rules where used in this model mainly in their "soft" formsome steps cannot be started unless some others have already been started.The effects of these rules at runtime can be seen in Figure A5 in which steps with gray background cannot be started.

and
 for any <st i , lr i , lg i , d i >, i = 1,…,m-1, and group g from lg i (g  lg i ): st i  R(g)  lr i and st i  R(g) = st i+1  R(g), i.e. all records in a locked group are locked, and no records of the type represented by the group can be added or deleted until the group is unlocked.Locking records and groups allow controlling the order in which records are added to or changed in the database.Locking groups has two different meanings.If the group is empty and locked, it means that conditions to start adding records have not been yet fulfilled * .If the group is non-empty and locked, it means that adding information related to this group has been completed, and no new information is expected to be coming.
Note that in the last state of the trajectory, which is called a final state, all groups and records are locked, thus it runs as <t m , st m , st m , S, d m >.The latter indicates the fact that no more information can be added to the finished process instance.
An extended version of the example trajectory from Section B.1 can look like: In the first extended state of the trajectory above, groups Lecture and StudentFeedback are locked, which means that no records can be added to these groups.In the second state, the record that defines the book is added and locked, group Lecture becomes unlocked, but group Book becomes locked (group StudentFeedback continues to be locked).In the third element, both record for book and record for the first lecture are locked, but there is no change in the set of locked groups.
Relationship d i , which is called record dependencies, is included in the extended state to show that a particular record in one group is connected to a particular record in another group.For instance, this type of connection is needed for the course preparation process to express relationships between the records that represent lectures, and feedback on them after the lectures.Without connecting a lecture record to a particular feedback record it would be impossible to know which feedback concerns which lecture.
Introduction of general rules of validness related to record dependencies can help in reducing the complexity of the model, and with it, the complexity of BPS systems that interpret them.For instance, the following rules could reduce the model complexity by introducing some restrictions on record dependencies:  One parent only.For any <st i , lr i , lg i , d i >, i = 1,…m-1, if <r 1 , r 2 >  d i there is no r 3 ≠ r 1 , such that <r 3 , r 2 >  d i . Prohibition to change a parent.For any <st i , lr i , lg i , d i >, i = 1,…m-1, if <r 1 , r 2 >  d i and r 2  st i+1 , then r 1  st i+1 and <r 1 , r 2 >  d i+1 . One child only.For any <st i , lr i , lg i , d i >, i = 1,…,m-1, if <r 1 , r 2 >  d i there is no r 3 ≠ r 2 , such that <r 1 , r 3 >  d i . Prohibition to abandon a child.For any <st i , lr i , lg i , d i >, i = 1,…,m-1, if <r 1 , r 2 >  d i and r 1 , r 2  st i+1 , then <r 1 , r 2 >  d i+1 .Note, however, that having the rules like above is not mandatory.
Set Ms sets restriction on records allowed in the database independently whether they are locked or not.In the term of procedural semantics from Section B.3.1, this is a set of rules that prohibit saving a record that does not have values for variables in Ms; the rule corresponds to not allowing null values in the standard relational DBMSs.Set Ml sets restrictions on which records can be locked.In procedural semantics, this is a prohibition to lock a record if certain variables are not defined; the rule does not have a prototype in the theory and practice of DBMS.Mandatory for lock fields are the rules that define the minimum information to be entered for the record to be considered good enough for the final state.
Note that the definition of extended trajectory in Section B.2 requires all groups and records to be locked in the final state of the trajectory.This implies that in the final state of the trajectory, all mandatory variables both for save and for lock should have values in all records in the database.

B.3.4 Non-Repeatable Groups
This section explains the fourth component of extended scheme <S, Ms, Ml, N, U, fc, D>, which is a set of non-repeatable groups from S, N  S. A state st  St(S) is considered to be n-valid in respect to a set of groups N if for each group g  N there is no more than one record in state st.
Continuing our simplified example, we can set N = {Book}, which means that only one book can be defined for a course.
Adding N to the scheme allows setting restrictions on the number of records allowed in each group.In this section, we demonstrated the simplest rule that limits the maximum number of records to one.This rule can be easily extended, for instance, by defining up to two numbers for each group: maximum number of records and minimum number of records.In procedural semantics, the maximum will prevent adding a record over the maximum allowed, while the minimum will prevent locking the group until the minimum number of records has been entered.

B.3.5 Rules for Unlocking Groups
This section explains the fifth component of extended scheme <S, Ms, Ml, N, U, fc, D>, which is a set of unlocking rules U. First, we introduce some additional definitions.Let g be a group from S, g  S, denote as Nempty[g] a predicate over St(S) such that: First, we introduce some additional definitions.Let S be a scheme, and D is an asymmetric binary relationship defined on S that does not have loops, i.e. its transitive closure D + does not include tuples of type <g, g> for any g  S (i.e.<g, g>  D + ).The elements of D are called dependencies.When a pair of groups g i , g j from S, g i , g j  S, is a dependency, i.e. <g i , g j >  D, we say that g j depends on g i ; g j is a dependent of g i .
Extended state est, est  ESt(S) and est = <st, lr, lg, d> is considered to be d-valid in respect to D if : (a) for each pair of records r 1 , r 2  st, such as < r 1 , r 2 >  d : <group(r 1 ), group(r 2 )>  D, (b) for each r such that there exists <g i , g j >  D, and group(r) = g j there exists at least one record r 1  st such that <r 1 , r>  d (existence of at least one parent if parents are possible).
In terms of procedural semantics, a record that belongs to a dependent group can only be introduced together with its relation to its parent.Furthermore, it cannot continue to exist unless there is at least one parent.In addition, if established rules, (a) -(c) above introduce even more stringent restrictions on relationships between parent and child records.
Note that in relational databases, the concept of record dependencies is represented through the foreign keys and rules of integrity attached to them.In our formalization, there is no notion of keys, as records are uniquely identified, thus we use explicit ways of expressing the rules of record dependencies.

Figure 1 .
Figure 1.Models of knowledge transformation for the traditional business process development on the left and the agile business process development on the right.Adopted from [1].

Figure 2 .
Figure 2. A rational behind the modeling technique suggested in this article

Figure A2 .
Figure A2.A process map

Figure A3 .
Figure A3.Step form for step Lectures/Lesson preparation from FigureA2

Figure A5 .Figure A6 .
Figure A5.Instance process map from Figure A2 as a user navigation mechanism

Figure A8 .
Figure A8.The process map of course preparation in the form suitable for discussion with stakeholders

Figure A9 .
Figure A9.Step form for Student comments on Seminars Nempty[g](st) = true if st contains at least one record r (r  st) for group g, i.e. group(r) = g, false otherwise Denote as Closed[g] a predicate over the set of extended states ESt(S) such that: Closed[g](<st, lr, lg, d>) = true if Nempty[g](st) = true and g  lg, false otherwise Some examples: predicate Nempty[Book] evaluates to true for states in which a record for group Book exists, while predicate Closed [Book] evaluates to true for states in which a record for group Book exists and the group is locked.
2. A set of locked tables.A locked table means that no rows can be added to or deleted from the table.In terms of forms, locking a table means that the user is not allowed to work with the forms related to the locked table.This can happen when the table is empty, which means it is not yet possible to work with the form, or when the table has some rows, which means that the work with the forms related to the locked table has been finished.Note that if the table is locked, all its records (if any) are also locked.3. A set of row dependencies in the form of pairs <r 1 , r 2 >, where r 1 , r 2 are rows in two different tables.Such a pair represents a dependency of row r 1 on row r 2 .Dependencies are important for tables that allow multiple rows.If forms filled at one stage need to be complemented with other forms later, then there is a need to establish which of the latter forms correspond to which of the former ones.In terms of relational databases, a dependency is just an additional table (or set of tables) with two columns.It represents relations (or associations in terms of UML) between objects stored in other tables.
in a specific table is locked in a given state st, and it exists in the next state st 1 , than all its fields in state st 1 have the same values as in state st. If a table t is locked in a given state st, then all rows in this table are also locked in state st. If a table t is locked in a given state st, then its content cannot be changed in the next state st 1.  In the last state of the extended trajectory all tables are locked.The specific rules can be introduced by assigning certain properties to tables, columns or relations between the tables.Examples of such rules are as follows: 1. Mandatory columns.We introduce two types of mandatory columns in a tableone for saving, and one for locking.Each row in the table should have values in the columns mandatory for save; if some of them are missing, the record could not be saved.In the same way, each locked row in the table should additionally have values in the columns mandatory for locking; if they are missing, the record cannot be locked.The latter will even prevent locking the table, as in a locked table all records should be locked.2. Multiple rows is a Boolean property of a table (which has already been discussed earlier) that allows/forbids inserting more than one row in the table.If a table does not allow multiple records, then in any state st there can be at the maximum one row in this table.This property can be enriched by having a pair <min, max> of integer numbers as a value that defines the minimum and maximum number of records in the table.The min number can be used for prohibiting locking the table that has less than required minimum number of records.

Table 1 .
Main concepts of the formal data-centric business process model

Table 2 .
Access rights

Table 3 .
Correspondence between Formal and iPB modeling concepts For instance, field Title in FigureA3and A4 has property Required set to Required on save, while fields Type, Mandatory, Start have property Required set to On close.One form only corresponds to non-repeatable groups.For instance, step Course general description in FigureA2has One form only set to Yes.Step startSee the matrix in Fig A3.The matrix limits the unlocking expressions to the ones that include operators OR only or AND only.