Having read  several papers on artefact-centric business process modelling we have found two approaches [1]: (1) artefacts as finite state machines and (2) focussing on the life cycle of artefacts. Both approaches require business analysts to validate the artefact model. We strive however, to a situation in which not the business analyst, but the business specialist is in control. The business analyst plays no longer a role or at most plays an advisory role.
The business specialist must make his/her artefacts complaisant to other artefacts. Complaisance naturally seeks a balance between leanness and richness. Leanness is required to make data quickly available and richness to make as much data available at once. During design time artefact modellers will look for the primary source of data to quickly transition to a new state but will also look to get as much data as possible in one go to limit the number of states and to limit the number of events it subscribes to. Remember that artefacts subscribe to events which are interesting to them. These events carry the information of the artefact that triggered the event.
Primary sources are artefacts that obtain the data from the end-user. There should always be one primary source. In case a (primary) source is not visible to an artefact, the source may not exist, or the authorisation of the source is limited. In such case, the authorisation may be altered to grant read access or one may create an intermediary artefact whose sole purpose is to make the data available to other artefacts.
One may decide to use intermediary artefacts as an interface to other domains. for example, the financial controllers in a company will by default block access to financial artefacts. Only data that has been approved for disclosure may be shared with other artefacts. To prevent that the ACL of all primary sources are altered to disclose the data, a special intermediary artefact is created which holds only data that may be disclosed.

Therefore, in our case, a business specialist being in control means that he/she must be able to make the artefact complaisant to other artefacts. This requires that the artefact is taken care of, which in a changing world requires constant care. The business specialist has a care duty and therefore must own the artefact.

This brings us to the tuple: complaisance, care duty and ownership. An example implementation of an artefact system was developed by AvenQure [2].

1. Gerede, C.E.: Modeling, Analysis, and Composition of Business Processes. PhD thesis, Dept. of Computer Science, University of California at Santa Barbara (2007)

2. "Conduct by AvenQure | Non-intrusive Workforce Empowerment.", http://avenqure.com/conduct/, AvenQure, May 2016. Web. 18 May 2016.

Silly me. In my previous post The Hole in BPM, I concluded that BPM lacked the concept of an type of business object or document. Little did I know that in 2007 IBM already introduced the concept of artifact-centric business process modelling in [1]. Artifacts are "business-relevant objects that are created, evolved, and (typically) archived as they pass through a business". Artifacts have an information model describing its data i.e. properties, and a lifecycle model describing the states an artifact can go through. The lifecycle is specified following an event-condition-action and/or condition-action style [3]. Indeed it seems that artifacts are the plug for the hole in BPM. 

The idea of artifacts passing through a business [1] can be interpreted as a workflow mechanism where depending on the state, people have or have not access to the artifact. And state being the equivalent of the condition mentioned above. Depending on its state, an artifact is interested only in a limited set of events. After each action the state is re-evaluated as are the set of events. The set is determined by the set of actions that are appropriate for the state. In other words, when an action has been executed, the state is reconsidered. This also implies that the state does not change halfway through an action and that the action is considered atomic.

An artifact must contain a business rule to determine its state, the state business rule. This rule is evaluated after each action. The rule inspects the properties of the artifact to determine the state. Each action must specify during which states it may be executed thus being a pre-condition of the action. In addition to state, an action has another type of pre-condition, namely its access control list. For an action its ACL is simply put those who may execute it. The ACL's of all actions together form the artifact ACL. 

In [2] the actions, or services as they are called, are specified in a declarative way using input parameters, output parameters, pre-conditions and post-conditions. Following the reasoning above an action has the following pre-conditions:

1. state of the artifact
2. set of events
3. its ACL

For read-only actions, the post-condition equals the pre-condition. Otherwise, we expect the post-condition must be defined with the action.

Although [1] does not mention ACL's and does it mention transactionallity, it does appear that artifacts can indeed plug the hole in BPM. More on ACL, transactionallity and inter-artifact relations in a next post.

1. K. Bhattacharya, N. S. Caswell, S. Kumaran, A. Nigam, and F. Y. Wu. Artifact-centered operational modeling: Lessons from customer engagements. IBM Systems Journal, 46(4):703–721, 2007.
2. Deutsch, A., et al., Automatic verification of data-centric business processes, in Proceedings of the 12th International Conference on Database Theory. 2009, ACM: St. Petersburg, Russia.
3. http://en.wikipedia.org/wiki/Event_condition_action

In a previous post I argued that BPM lacks the concept of the data object. I argued that people tend to communicate with other parties based on forms which effectively represent a data object. Consequently, it can be said that when people think of their business, they think of the business data objects, or simply business object, and when and how these objects are used. Therefore, design and modelling should take place at the level of the business object. So, a business object has relations with events (when is the object used), its roles (how is an object used) and from its roles, the relations with other objects (who uses the object). The latter is the field of Business Object Relationship Modelling which I wish to explore in a next blog post. 

The point is that modelling should focus on the business object and its direct surrounding, the events, its roles and its neighbour objects. This is how people think about their business. Put all of these business objects and one will be able to see the business processes i.e. process mining. People do not think, up front, about (lengthy) process chains. Processes do provide valuable information, and can help for example in determining the cause of stagnations.