Processes and Promises

The term “business process” is often understood to mean something that is preassembled and acts as a whole, without considering the constituents that are bundled together in this whole. This way of looking at a “business process” focuses the mind on the irrelevant at the cost of losing sight of the important parts, not dissimilar to   looking at a horse cart only to see a travel vehicle, and ignoring all the associations and interactions of (axle, wheels, cart, driver, horses, and externals such as the road condition, weather etc.) without whose understanding, the cart offers no guarantees of reaching its destination.

When all chafe is removed from a business process, what is left behind is a heap of activities and actors, and the issue promises-1boils down to that of communication, coordination, and collaboration. Of course, the actor is not always a human it may well be a system, a rule-engine, say, but at the end of the day they are all autonomous actors. Although, no actor works entirely alone, and activities are not entirely isolated; there is always some form of dependency, a sharing of information, or a collaboration leading to desired output. An actor is both an autonomous agent with a bundle of competencies and skills that allow her to perform the activities.

Information and context are the threads that weave these activities into processes. On completion each activity primes the next activity, either automatically or through the intervention of the human actor. Looking at the bare bones then, what we have is actors, activities, and where the processes are understood (not pre-ordained) from the crumbs left behind by the completed activities. Actors do the activities that produce the processes for the organisation, and the organisations learn from the actors the associations and interactions that make the processes. For these associations and interactions the rule is performance, and exceptions that decide on the long-term scale and stability, particularly with the ever-present external economic and business forces. If a process is woven by activities (post the achievement of the business goal) then so is it woven by promises or obligations on the part of the actors.
The actor is imposed on to perform the activities by the organisation, which in turn stems from its promise to its current and prospective customers. The actor or more accurately the belonging group (or the more technical ‘role’) is a proxy to this promise. But, the actor is not just a passive onlooker to the promise he is obliged to execute the promise on behalf of the organisation. Although, the obligation is not as demanding as the obligation a samurai feels to avenge the death of his master.


Let’s consider an activity as a unit of a transaction (in the DEMO sense). An activity then consists of the following Modified-Transaction-Promiseconstituents, triggering request, promise, execution, state, and acceptance.

  • Actor (A1) in the figure is the request raiser; he may be external or internal to the organisation.
  • Actor (A2) is the promissory for the execution of the activity, (although this promise is imposed by the organisation). The actor is the owner of the activity from the promise, to the execution, to the statement.
  • Actor (A1) at the end has the option to accept or decline the result, he will accept if it his desired result.

The Full Transaction
Modifying the above figure focuses on the promises as a performative chain of actions. What we loose by doing this is the wait on the on T1/ex, when there is a dependent activity and hence also a promise.If we create a full transaction with all the actors, activities and promises, for a typical insurance application, what we obtain is the following scenario.

The virtue of DEMO for business process design and implementation lies in the feedback loop with the organisations enterprise architecture. Rather than implement each business process in isolation, DEMO provides a sustainable integration with the underlying organisations architecture. The concept of “promise” in DEMO is similar to the definition of promise as set down in “promise theory”, viz. it has a source actor, it has a target actor, and it has a description of the promise. Promise Theory as the name suggests is a formal study of “promise” to be found here. There is much to consider promise theory and business process, but that is for another time. More on DEMO can be found here.

About KM Mukku

Kick-start, build and manage teams in product development (particularly in the financial domain), and enjoy all in adaptive case management, business process design and business process improvement. Currently holding the position of CTO at coMakeIT.
This entry was posted in BPM and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s