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