Keywords

1 Introduction

The business managers and analysts in organizations increasingly rely on business process modeling to document, understand and improve their business processes. Business Process Modeling [1] refers to the act of representing business operations with an objective to improve organizations current business processes. A business process model describes how the business operates to accomplish its objectives. Traditional activity-centric business process modeling is based on tasks and control-flow constructs, which only define how business processes operate, without revealing details about the data resulted from the business process execution. An “impedance mismatch problem” [2] arises with the separation of application, process, and control data by activity-centric process aware information systems while providing support to imperative procedural models, which eventually affect the flexibility of activity-centric business process modeling approaches.

As opposed to the traditional activity-centric approaches to business process modeling, whose emphasis is completely on tasks and their control flows, a new data-centric approach for modeling business processes has been emerged, namely artifact-centric approach [3], which takes into account data and process aspects in a more comprehensive manner. The modeling approach is centrally based on business artifacts [4] i.e., core business-relevant entities that manage operations of the business, whose content changes in response to the business actions. The artifact-centric modeling becomes popular with its unique advantages such as: (1) it enables business managers to better understand and specify their business operations by providing a more intuitive framework [3]; (2) it provides more flexible and robust structure for business process specification [3]; and it has the potential to improve flexibility, compliance and reduce the complexity of traditional activity-centric business process approaches [5]; (4) it has the ability to help cut down the costs of business transformations [6].

The artifact-centric modeling approach can be laid in a four dimensional framework called BALSA- Business Artifacts, Lifecycles, Services, and Associations [1, 3]. “By varying the model and constructs used in each of the four dimensions one can obtain different artifact-centric business process models with differing characteristics” [3]. Currently there are many concrete artifact-centric modeling approaches such as GSM [7], ArtiNets [8], AXML [9], BPMN Extensions [10], and ACP-i [5]. Though all the proposed models claim to support the artifact-centric approach, their support in specifying BALSA framework was not clearly described in the existing literature.

In this paper, we aim to use BALSA as a reference framework or yardstick and see how each approach can be fit into this framework. To give the reader a concrete feel of each approach, we also use a common motivating scenario and demonstrate how to implement this scenario using each approach. This paper also help researchers and practitioners who have interests in the area of BPM to gain better understanding and knowledge of artifact-centric process modeling.

The remainder of this paper is organized as follows: Sect. 2 provides an introduction to the BALSA Framework with an example. Section 3 discusses artifact-centric modeling approaches and related work. Section 4 discusses and briefly evaluates all the modeling approaches studied against the framework. Finally, the conclusion and future work are given in Sect. 5.

2 BALSA Framework

2.1 BALSA Elements

With the focus on data aspects as its first-class citizens, the artifact-centric approach provides a four explicit, inter-related but separable “dimensions” in the specification of business processes [1, 3], where this four-dimensional framework is named as BALSA- Business Artifacts, Lifecycles, Services, and Associations. Each of these dimensions can be described as follows:

Business Artifacts: The term “artifact” has its own roots in the business domain. In general, we can describe an artifact as, a means to record business information needed to perform business operations. And in the business terminology, an artifact can be better described as a key business-relevant entity responsible for driving overall business operations to achieve business objectives [4]. An artifact serves as a basic building block for business process modeling by aggregating both the information aspects and process aspects in a more comprehensive way. An important aspect of artifact is its type, which can be characterized by its data/information model and lifecycle model, where the data model describes the business data that an artifact captures, and its lifecycle model specifies the possible stages that an artifact navigates through by responding to events and services that act on it. The data model can be specified in many forms, e.g., a name-value notation [4], an XML or ER model [1].

Lifecycle: The lifecycle of artifact can be described as key business-relevant stages, through which an artifact navigates from its initiation to the completion. Different artifacts may differ with their “life expectancies”. In general, the lifecycle may be specified using flow charts, finite state machines, state charts or using declarative mechanisms [1].

Services: A service can be described as a business task or an action performed on the artifact to progress towards business objectives. Service invocation on artifact may result in a state change of the artifact, and/or update artifact’s content. Services can be specified with pre-conditions and post-conditions [11–13].

Associations: Associations specify the association among services and artifacts and their constraints. Here the constraints correspond to the conditions under which services can be executed. The constraints may be specified procedurally [4] or declaratively [11–13], for e.g., using flowcharts or ECA (Event-Condition-Action) rules, respectively.

2.2 A Running Example

The figure shown below is adopted from [11], which presents a Customer Order processing scenario, and is used throughout this paper for illustrating the BALSA aspects of each concrete modeling approach. The process starts by receiving an order from the customer and ends with successful delivery. Here the Customer Order forms one of the key entities of the business and interacts with other entities of the business such as Delivery and Invoice to complete its processing (Fig. 1).

Fig. 1.
figure 1

Customer order processing scenario

Full size image

The information model of Customer Order artifact includes attributes such as OrderID, OrderDate, CustID, CustAddr, CPhNum. In the same way, the information model of Delivery artifact may include attributes such as DeliveryID, DDate, and DStatus and the information model of Invoice artifact may include IVDate, Total and IVStatus attributes. The lifecycle model of Customer Order artifact, specify the states as Received, Scheduling, Ready, Delivery, Billing, and Completed. In the same way other artifacts such as Delivery, Invoice also have their lifecycle states, where In Transit and Delivered states form lifecycle model of Delivery artifact and Sent, Unpaid, Paid states form the lifecycle model of Invoice artifact. Services in the above example include Receive Order, Plan Schedule, Cancel Order, Prepare Order, Send Order, Send Invoice and Complete Order are the services that act on Customer Order artifact to change its state. The Receive Order service instantiates a Customer Order instance and puts it in the Received state. Similarly, Prepare Order service puts the artifact in Ready state. Similarly the Send Order and Send Invoice services act on multiple artifacts such as Customer Order and Delivery and Customer Order and Invoice. Association among artifacts and services are represented through arrows that specify which services are acting on which artifacts and when.

Though the example described above is simple, it does not lack of generality and can be used to demonstrate different modeling approaches. The following sections discuss each of the approaches studied in the paper in detail.

3 Artifact-Centric Modeling Approaches

With the emergence of artifact-centric approach, several artifact-centric modeling approaches have been proposed, of which have their own characteristics and provides different ways to specify business operations. Some of the promising modeling approaches are GSM [7], ArtiNets [8], AXML [9], BPMN Extensions [10], and ACP-i [5]. The following section provides details and discussions to those modeling approaches with the running example to demonstrate how each approach can be applied on.

3.1 Guard-Stage-Milestone

In recent years, a declarative style of meta-model for specifying artifact lifecycles, Guard-Stage-Milestone (abbreviated as GSM) [7] has been introduced by IBM. The key constructs of the GSM meta-model used in specifying artifact lifecycles include: (1) information model, that holds all the data about an artifact instance; (2) milestones, specify business objectives that might be achieved by an artifact instance; (3) Stages, represents a set of activities performed by an artifact instance to achieve business objectives; and (4) Guards, simply act as sentries and represent a condition or triggering event to control stages and milestones.

GSM Modeling of BALSA Elements

GSM supports specification of BALSA elements. The following section describes how GSM meta-model represents each element of the BALSA framework.

Business Artifacts (Information Model): GSM specifies information model of artifact with attributes, where the artifact type can be a scalar, or a record type or a collection type. These attributes are categorized into 3 different types such as Data attributes, Event attributes and Status attributes. The Data attributes contain information about the artifacts. The Event attributes represent information about the triggering events. And, the Status attributes are intended to hold status information about the stages and milestones i.e., about the values associated to stages and milestones that change over time and are of type Boolean. The possible values of status attribute may be open/close (active/inactive) for stages and true/false for the milestones.

Lifecycle: The lifecycle of an artifact can be modeled using the constructs stages, milestones, guards. Here stages correspond to the states of the BALSA lifecycle. The stage structures the activities of an artifact instance and becomes true or said to be open when its associated guard becomes true. And the stage will be closed when its milestone is achieved or becomes true. The stage contains a stage body, guards, one or more milestones, and may contain multiple sub stages where stages at the same level can be executed in parallel.

Services: In GSM, the services are specified in the form of events, where event occurrence may result in a state change or modify the value of milestone. There are two types of event types such as external event types and status-change event types. GSM supports 4 kinds of status-change event types where first two are denoted in GSM-L syntax as S.opened() and S.closed() and the other two are denoted as m.achieved() and m.invalidated().

Associations: GSM uses Event-Condition-Action (ECA) rules in the specification of associations. The ECA rules take the form “take an action, when the event occurs under the specified condition”. And in GSM, these ECA rules are formed from the sentries. The sentry here is expressed in the form ‘on< event >if< condition >then< action >.

3.1.1 GSM Representation of the Running Example

The key constructs of the GSM meta-model are illustrated by using the sketch of Customer Order artifact type, described in the running example section. Different kind of nodes in the figure designate GSM constructs like, the rounded-corner rectangles represent stages, the guards are designated using diamonds and the small circles associated to each stage represent a milestone (Fig. 2).

Fig. 2.
figure 2

GSM representation for customer order artifact

Full size image

For Customer Order artifact, the data attributes hold the values of attributes that include customerId, orderId, orderDate, customerAddress, phNumber. For the Delivery artifact the data attributes include deliveryDate, status and invoiceId, total, status are the data attributes of Invoice artifact. In the above figure, the upper portion represents a lifecycle model of Customer Order artifact that includes a set of stages with milestones, which the Customer Order artifact might achieve during its lifetime. The Customer Order artifact moves through its lifecycle with the result of event occurrences. For e.g., the c.'ReceiveOrder'.onEvent() event initiates the Customer Order artifact instance and puts it in Received stage. And in the same way the ‘Cancel Order’ event triggers Cancelled milestone. In similar manner the result of event occurrences lead to the completion of Customer Order artifact. The status attribute of milestone, for example ‘m’ is initially initialized to FALSE and can become TRUE if the milestone is achieved. The status of stage such as ‘s’ becomes open, if its associated guard becomes TRUE and will be closed if its milestone becomes TRUE. The Guard is simply a sentry, when the guard condition such as c.'Send Order for Scheduling’ is achieved, the milestone becomes true, and the artifact instance enters next stage by triggering its guard value to true. Then the corresponding event can be invoked on the artifact instance. Here the variable ‘c’ is used to denote the artifact instance currently under consideration.

3.1.2 Interaction Between Artifacts

The GSM supports interaction among artifacts through conditions and events [14, 15]. The figure below illustrates the interaction between all the artifacts Customer Order, Delivery and Invoice. The dashed lines denote B-steps [14] that correspond to the incorporation of event into the GSM system, for example the ‘Send Order’ event allows interaction between Customer Order and Delivery artifacts, where its result changes the state of Customer Order artifact from Ready to Delivery and also initiates the Delivery artifact instance. Similarly the ‘Send Invoice’ event allows interaction between Customer Order and Invoice artifact (Fig. 3).

Fig. 3.
figure 3

Interaction between artifacts

Full size image

3.2 ArtiNets

ArtiNets workflow model [8], a variant of artifact-centric workflow models introduced to support the specification of artifact lifecycles and their constraints. Inspired by DecSerFlow [16], a Declarative Service Flow Language, ArtiNets also allows declarative style in specifying constraints on artifact lifecycles. The key components of ArtiNet model are: artifacts, services, places, and transitions. ArtiNet framework is closely related to Petri nets [17], but only differs with two aspects: where artifacts form the key constructs of ArtiNet model instead of tokens, and the difference lies in the transition firing rule.

3.2.1 ArtiNet Modeling of BALSA Elements

Business Artifacts (Information Model): ArtiNet model primarily focuses on modeling the lifecycle aspects of artifacts, and their constraints. ArtiNet model may specify artifact’s information model, but these details are not much addressed in its current literature.

Lifecycle: ArtiNet model uses four key constructs in the representation of BALSA Lifecycle such as artifacts, places, services and transitions. A place is a repository that stores artifacts, and transition correspond to the actions/events invoked on artifacts, that may change the location of artifact from one place to another. The transition firing may consume/generate only one artifact though it has multiple input/output places.

Services: A service in the ArtiNet model corresponds to a task performed on the artifacts, where the execution sequence of these tasks is defined by lifecycle constraints.

Associations: In ArtiNet model, the invocation of services on artifacts is limited by constraints (conditions). The constraints here may be the regular constraints, which are expressed using regular expressions [8] or counting constraints, which are expressed using semi-linear sets of Parikh map [8, 18]. Regular constraints specify a condition, under which a service can be invoked on the artifact, and the counting constraints specify how many number of times, the services should be executed.

3.2.2 ArtiNet Representation of the Running Example

An ArtiNet workflow representation of Customer Order artifact is given below, where the rounded rectangles represent the services (tasks) that act on Customer Order artifact and the circles represent the places (states) that the artifact exists. The arrows correspond to the transition of artifact from one place to the other place (Fig. 4).

Fig. 4.
figure 4

ArtiNet representation for custer order scenario

Full size image

The service invocation on artifact leads to a transition of artifact from one state to other state. In the above figure, ‘Receive Order’ service creates a CO instance and puts it in the ‘Received’ state. Then with the invocation of ‘Plan Schedule’ service the artifact enters into the ‘Scheduled’ state. In similar manner the artifact exist various other stages with response to service invocations, and can be archived when it finishes its completion. Association among the three artifacts is clearly illustrated in the above figure. And CO here is the Customer Order artifact instance which flows through the lifecycle, where the other artifacts may acquire it for processing, when required.

3.3 The AXML Artifact Model

The AXML artifact model [9] is a data-centric workflow approach that has been introduced to encapsulate data and workflow activities in a distributed environment. The AXML Artifact model is built based on Active XML [19], which is a declarative framework developed to tackle web services for distributed data management, and is designed to work in a peer-to-peer architecture. The AXML artifact model is designed to capture various aspects of artifacts such as their states, evolutions, interactions, and history [9, 20]. And the state of an artifact is represented with an AXML document, represented in a tree structure with XML data and some function calls.

3.3.1 AXML Modeling to BALSA Elements

Business Artifact (Information Model): AXML represents the artifact’s data in the form of nodes in an artifact tree (AXML document). These nodes may be element nodes, content nodes. Peer act as a repository to store artifacts, supports interaction and provides computing resources for the artifacts they hold. The artifacts of one peer may exchange data (in the form of strings) with the artifacts of other peers, which can be reconstructed at the receiving peers.

Lifecycle: AXML supports modeling of artifact lifecycle, where the state of an artifact is represented with an AXML document that contains some nodes. These nodes may be element nodes, content nodes, function calls and sub artifacts.

Services: A service is a function call in AXML artifact model, which is specified with the function nodes in the AXML document. Here the services may be internal services or external services. Similar to GAXML, the function call in AXML has 4 components: call guard, which controls the activation of a function call, argument query, which computes call argument, return guard, that controls the result of the call, and result query, that computes the result of the call. The guards, arguments and return queries are specified using Boolean combinations of tree-patterns (BTPQ) [9] queries over the documents.

Associations: The association among services (function calls) and artifacts is restricted by constraints, which are expressed in the form (event, precond, postcond). The event here may correspond to a function call activated on the peer, the call received at some other peer, result sending and the reception of that result. Other events such as the artifact creation, state change or archiving may correspond to function calls. The precond and postcond are the conditions specified as formulas (BTPQ) over the artifacts states.

3.3.2 AXML Representation for Customer Order Artifact

An AXML document, which represents Customer Order artifact tree is shown below, that contains different kinds of nodes such as element nodes, content nodes, function nodes and some sub artifacts. The nodes such as cname, id, address, date are the element nodes, and the content nodes include Sam, 1001, 3214. The “creditCheck” element denotes a sub artifact, created by Customer Order artifact in order to check the details of the customer. And a function “warehouseCheck” is activated to check the availability of the order in the warehouse (Fig. 5).

Fig. 5.
figure 5

AXML representation for customer order artifact

Full size image

3.4 BPMN Extensions

The BPMN (Business Process Modeling Notation) standard has been extended to support artifact-centric business process modeling. Various BPMN Extensions [10] proposed to model different aspects of artifact-centric approach include as artifacts, object lifecycles, location information, access control, goal states, and policies [21]. Artifacts form the key constructs of the model, lifecycle specifies the possible states of artifacts, location information specifies how the location of artifacts is changed, and access control specifies that the artifacts are accessed remotely. The extensions such as goal states and policies are mainly used in removing undesired behavior of artifact.

3.4.1 BPMN Modeling to BALSA Elements

Business Artifact (Information Model): BPMN uses a data objects representation for artifacts, where a placeholder symbol can be used to hold the data object and its name appears in the upper left corner of the place holder symbol. Representing information model of the artifact is out of scope of the current literature.

Lifecycle: The lifecycle of each artifact is modeled using the constructs like tasks, events and gateways, where the initial (start event) and final (end event) states of the artifact is denoted by standard BPMN symbols. The task here is simply a service, which changes the state of the artifact. And an event represents current state of the artifact. Goal states define desired final states of the data objects, and represented using parallel gateways which connect these states.

Services: The service corresponds to a task in BPMN, which is triggered by an agent. Here the agent can be a role or organization or location. Before executing a task on the artifact, the agents need to acquire it. The agent can acquire an artifact by knowing its location (e.g., URL) or by using any other addressing mechanisms.

Associations: BPMN supports associations among services and artifacts through policies, which restrict the execution sequence of tasks in different artifacts. Policies are also used in the specification of dependencies among tasks of one or two artifacts and are modeled using the constructs tasks and gateways.

3.4.2 BPMN Representation for Customer Order Processing Scenario

The figure below illustrates an artifact-centric BPMN model of the Customer Order processing scenario, where all the three artifacts are depicted using placeholder symbols with their names appear in the top left corner. The lifecycle of each artifact is modeled using the constructs like tasks, events and gateways, where the task is represented by rounded rectangle, which contain name of the task and the agent who triggers the tasks on artifacts, for e.g., Receive Order, Plan Schedule are the tasks with agents Customer and Employee (Fig. 6).

Fig. 6.
figure 6

Artifact-centric BPMN model of the customer order scenario

Full size image

Events are represented in the model with double rounded circles, and denote current state of the artifacts like Received, Scheduling and Completed etc. The initial and final state of an artifact is represented by using BPMN symbols. Similar to the lifecycle representation, the location information is also included in the upper portion of the artifact with a stick figure, where each agent is assumed as a location, which specifies the current location of the artifact. Arrows between the agents represent message channels through which they exchange artifact instances.

The policy 1 in figure specifies the dependencies between the tasks of two artifacts Customer Order and Delivery, which can also be modeled using the constructs tasks and gateways. Here this policy describes that the “Prepare Order” task of Customer Order artifact should be executed before the “Send to Customer” task of Delivery artifact. We assume that an Invoice artifact has goal states as “Pay by Credit/Cheque” and “Pay by Cash” which are connected through a parallel gateway, to present two payment options for the customer. The customer can pay through any of the two modes, which completes processing of Invoice artifact.

3.5 ACP-i Model

The ACP-i model [5], an artifact-centric business process model is an extended version of ACP model presented in [22, 23], has been proposed to support inter organizational business process modeling. The core components of this approach include: roles, artifacts, tasks and business rules. The roles are the organization roles participate in the collaboration, an artifact here is a business entity or object that exists in the collaboration, a task is an operation (read/update) on artifacts performed by the organizations in the collaboration, and a business rule specifies a set of constraints on tasks in a Condition-Action style.

3.5.1 ACP-i Modeling to BALSA Elements

Business Artifacts (Information Model): The information model of an artifact is represented by using a name-value pair notation, where each attribute is of type scalar or by using an array list of nested attributes.

Lifecycle: Lifecycle of an artifact is represented using a state machine with set of states, where state transitions of the artifact is based on business rules. Label Transition System (LTS) is used in ACP-i model to capture these lifecycles.

Services: A service in ACP-i model is specified as a task (action) that performs read/update operations on the artifacts, which is constrained by the conditions, defined in the business rules. The organizations involved in the collaboration perform these tasks according to the defined business rules.

Associations: Associations are specified through business rules, which specify conditions, under which the task should be invoked on artifacts. The conditions here are the constraints expressed in Condition-Action style as pre-conditions and post-conditions. Here the business rules are classified into two types, where the first type of business rules are used to change the state of single artifacts, whereas the other type of business rules called synchronization rules can be used for expressing synchronization dependencies among artifacts and are used to change the states of multiple artifacts.

3.5.2 ACP-i Representation of the Running Example

The ACP-i model distinguishes artifacts into two types such as local artifacts, and shared artifacts. The local artifacts are the artifacts owned by the organizations and shared artifacts, correspond to the commonly agreed artifacts used for coordination among parties in the collaboration. To demonstrate ACP-i model let us assume the artifacts described so far are the shared artifacts such as Customer Order (CO), Delivery (D), Invoice (IV). We consider the other artifacts such as Stock Check (SC), Schedule Delivery (SD), Bill (B) in the figure as local artifacts whose details are kept private by the organizations, which own these artifacts and not revealed to the external parties in the collaboration (Fig. 7).

Fig. 7.
figure 7

ACP-i representation for customer order processing scenario

Full size image

Once the order is received from the customer by executing the task receiveOrder(co), the employee interacts with the SC artifact to find the availability of the stock. If the stock is available, the employee prepares the order, where the SC artifact enters the Order prepared state to complete its processing. When the SC artifact enters the Order prepared state with the result of task prepareOrder(sc) task, which automatically triggers the state transition of CO from Scheduling to Ready state. The employee cancels the order if the stock is unavailable. When the order is ready, the employee interacts with Schedule Delivery (SD) artifact to schedule the delivery, this process ends when the DS artifact enters the state Sent, which consequently triggers the delivery state of CO artifact and initiates the artifact D.

For this scenario, the business rule can be expressed as (pre-condition : instate(co, ready)^instate(sd,prepared); Task: sendOrder(sd,co); post-condition: instate(sd,sent) ^instate(co,delivery)^instate(d,init)). Similarly the employee interacts with Bill artifact to prepare bill for the order, this process ends when the B artifact enters the state Sent, which consequently triggers the Billing state of CO artifact. The entire CO process ends when it enters the completed state. The dashed lines represent the interactions among artifacts, which are specified through synchronization dependencies.

4 Discussion

The concept of business artifacts and the notion of modeling business processes in terms of artifact lifecycles were introduced in the literature by Nigam and Caswell [4]. This data-centric approach can be laid in a four dimensional framework called BALSA [1, 3] for defining business processes. This data-centric approach also formed foundation for various artifact-centric meta-models in recent years, where all the approaches support modeling of BALSA elements. The following table presents a quick overview of the above discussed approaches like, how each approach represents the four dimensional framework (Table 1).

Table 1. Comparison framework for all the artifact-centric modeling approaches studied in this paper
Full size table

GSM [7] has been introduced with the key motivation to aid business stakeholders in specifying and managing their business operations by using intuitive natural constructs that closely resembles the ideology of business stakeholders about their business operations. The GSM contrasts with procedural approaches such as BPMN by following a declarative approach, and supports parallelism within artifact instances and modularity through hierarchical constructs [15]. GSM supports modeling of BALSA framework, where programming data types are used in the specification of artifacts’ data model and follows a declarative style in the specification of all the other aspects.

ArtiNets [8], also enables the declarative specification of constraints on artifact lifecycles in the spirit of DecSerFlow [16] language. ArtiNets, allow the integration of lifecycles in one model, where the coordination is acquired through transitions on multiple artifacts. But here the declarative style is followed only for specifying associations, and all the other aspects of the BALSA framework are specified procedurally.

The AXML artifact model [9] also supports declarative lifecycles based on Active XML [19], by taking the hierarchical structure in data representation with XML elements and supports implementation of artifacts, which can be accessed among organizations in the collaboration. When compared to the GSM, that mainly focuses on managing data aspects, the AXML artifact model gives higher priority to structural aspects.

The standard BPMN [10] approach, has also been extended to support artifact-centric modeling, but follows a procedural style in representing all the aspects of BALSA framework and provides limited support to data aspects.

The other approach, ACP-i [5] also supports artifact-centric modeling, but mainly developed for modeling inter-organizational business processes. Similar to GSM and ArtiNets, the ACP-i model also focuses on behavior aspects, where Label Transition System (LTS) is used to capture these behavior aspects. Similar to GSM and AXML, the ACP-i also follows a declarative style in the specification of BALSA framework, but it uses a name-value pair notion to represent data model.

5 Conclusion and Future Work

In this paper, some key artifact-centric modeling approaches have been reviewed and discusses by using a four-dimensional framework called BALSA as a reference framework. A running example has been used to help illustrating each approach. We also present an initial evaluation and comparison of the approaches discussed in this paper. In the future, we plan to do more thorough evaluation of the approaches through both real-life case study and in-lab experiments.