BPMN, Business Rules, and the Free Will — A New Way to Look at Models
In this article I claim that the OMG's Business Process Model and Notation (BPMN) includes a well-known symbol that represents the free will. By relating process models to free will, I will explain why there is often a big gap between designed business process models and how such processes are executed by humans in reality. In this context, I will also show how the free will and business process models relate to structural and operative business rules, as defined by the OMG specification Semantics of Business Vocabulary and Business Rules (SBVR).
A Simple Business Process
A business process model is "a defined set of business activities that represent the steps required to achieve a business objective. It includes the flow and use of information and resources." To illustrate the subject, I'll use the fragment of a business process shown in Figure 1.
Figure 1. Business Process Fragment for Credit Check.
Based on this simple business process, let us imagine a concrete scenario:
John Smith is a credit clerk in a bank, and his friend Greg Miller applies for credit. John receives a credit application form from Greg and determines his credit rating. This is done by means of a decision table that considers various criteria such as monthly income, gender, marital status, and more. Unfortunately, the outcome is 'problematic'. Nevertheless, since Greg is John's friend and an important customer to John's bank, John decides not to perform a detailed analysis but to continue the process by creating a contract with Greg.
What is going on here?
At the decision symbol, John deliberately decided against the recommendation given by the credit rating decision table. John believes that he has good reasons for doing so and takes the risk to violate the process prescribed by the process model. Is this good or bad? Regardless, this was a utilization of John's free will.
For humans, business process models (such as the example introduced above) are some kind of recommendation. They might well represent a strong recommendation but, nevertheless, they remain a recommendation that might be deliberately violated by humans responsible for performing those processes. Usually, humans violating such recommendations are aware of the consequences of doing so. These consequences come from the enforcement of those recommendations — for example, in an enterprise employees not adhering to these recommendations might be reminded to behave more compliantly, might be sanctioned, and (if they repeatedly violate these recommendations) they might even be fired.
There is a special variant of formal logic that deals with these kinds of models: deontic logic. Deontic logic introduces three special operators that amend the meaning of sentences:
- It is obligatory that <some statement>
- It is prohibited that <some statement>
- It is permitted that <some statement>
The OMG specification "Semantics of Business Vocabulary and Business Rules" employs deontic logic to formalize a special kind of business rules called 'operative rules' (sometimes also called 'behavioral rules'). Operative rules are prescriptions that express what is allowed and what isn't. Furthermore, in SBVR operative rules are also tightly coupled to the notion of 'enforcement level' — an explicit statement of how adherence to these rules is enforced. As examples, SBVR suggests the following different enforcement levels:
- Strictly enforced: If you violate the rule, you cannot escape the penalty.
- Deferred enforcement: Strictly enforced, but enforcement may be delayed — e.g., waiting for resource with required skills.
- Pre-authorized override: Enforced, but exceptions allowed, with prior approval for actors with before-the-fact override authorization.
- Post-justified override: If not approved after-the-fact, you may be subject to sanction or other consequences.
- Override with explanation: Comment must be provided when the violation occurs.
- Guideline: Suggested, but not enforced.
In our example, 'post-justified override' might be the appropriate enforcement level for the credit rating decision; in other cases, different enforcement levels might be more appropriate. Deontic statements give room for free will: they give freedom and flexibility to the agent responsible to follow the given recommendations.
Free will is tightly related to the agent's motivation, i.e., his goals and objectives. These goals and objectives may be the personal goals and objectives of the agent or the intent to achieve corporate goals and objectives. And these goals and objectives may force an agent to act against the given recommendations, while accepting potential consequences.
I have taken the decision symbol of BPMN to introduce the notion of deontic statements. However, when we look at any business process model, almost every model element might be subject to deontic interpretation. For example, the task determine credit rating could be read as an obligation to determine the credit rating after receiving a credit request. Therefore, it is very useful to be clear about what kind of deontic semantics the elements of a business process model have: are they obligations, permissions, or even prohibitions? Furthermore, making the corresponding enforcement level explicit may also be helpful in business processes where humans are involved.
Knowledge and Decisions
There is another interesting task, determine credit rating, in our simple process model. As mentioned above, this task is specified by means of a decision table that considers criteria such as requested credit amount, monthly income, gender, marital status (and more) and determines the three possible credit ratings: good, bad, or problematic.
A decision table is a set of rules that SBVR calls 'structural rules' (sometimes also called 'definitional rules'). Structural rules define how different statements relate to each other — for example, how the statement credit rating is 'problematic' relates to the statements gender is male and monthly income is greater than $5000 (and others). In contrast to operative rules, structural rules cannot be violated — they are simply knowledge that might be used to derive new information from available information. To summarize, the entire process may be divided into the following four steps:
- First, a "credit request" is received from an applicant.
- Then, the responsible agent performs the task determine credit rating, which is a "knowledge task" as it determines the credit rating by applying knowledge represented by a set of structural rules.
- The result of this knowledge task is then taken into consideration by the subsequent decision credit rating? in order to determine the further action.
- Depending on the outcome of the decision, one of the three succeeding actions is performed: create contract, inform customer, or perform detailed analysis.
Interestingly, those four steps of the process may easily be mapped to a pattern — developed by Robert Kowalski — that describes how motivated agents work, i.e., to agents exhibiting free will. This pattern is composed of the four stages depicted in Figure 2: "perceive" (corresponding to Step-1 above), "think" (corresponding to Step-2), "decide" (corresponding to Step-3), and "act" (corresponding to Step-4).
Figure 2. Kowalski's Pattern of How Agents Work.
In Kowalski's pattern, free will takes place in the "decide" stage, which corresponds to the credit rating? decision in our simple example. And by the way, by 'agent', Kowalski refers to human as well as to non-human agents (such as IT systems).
IT Systems and the Free Will
It will blindly follow the process, i.e., will always decide according to the determined credit rating. These kinds of systems certainly don't exhibit any kind of free will. However, if a process automation system operates goal-driven, it may consider different competing tactics and automatically choose those outcomes of decisions that it believes most likely to achieve its goals. In other words, it exhibits some kind of free will. An example of a commercial goal-driven business process management system is "LSPS" from Whitestein Technologies.
Similar considerations may not only be applied to the runtime of IT systems but also to their design. The requirements of an IT system may be considered as a deontic ruleset: a set of obligations, permissions, or even prohibitions on the capabilities of the future IT system. It is then at the discretion of the requirements engineer, in collaboration with the project sponsor and the project leader, which of those requirements will be realized and which will not. Deciding against mandated requirements usually implies some consequences (or even risks) that must be carefully evaluated with respect to the benefits of not realizing those requirements. This process is usually called "prioritization of requirements."
When designing business process models (e.g., using BPMN), it is highly recommended that there be an explicit and deliberate distinction between knowledge tasks delivering the inputs for decisions and the actual decisions. Knowledge tasks may be specified by means of decision tables or SBVR's formalism for structural business rules. Decisions (as well as task sequencing in general) represent deontic statements that may be subject to the free will of the responsible execution agent. They correspond to operative business rules with a (potentially explicit) enforcement level.
Treating decisions as operative business rules on fully-automated, goal-driven business processes introduces a new level of flexibility for these kinds of systems. Finally, the notion of treating requirements on a new IT system as deontic statements makes the decision process on the requirements selection and prioritization more explicit and more apparent to the involved stakeholders.
 Business Process Model and Notation, v2, Object Management Group — published by ISO as the 2013 edition standard (November 2013), URL: http://www.omg.org/spec/BPMN/ISO/19510/PDF/
 Semantics of Business Vocabulary and Business Rules (SBVR), v1.2. Object Management Group (Nov. 2013). Available at www.omg.org/spec/SBVR/1.2/
 Whitestein Technologies, Living Systems® Process Suite, http://www.whitestein.com/products/process-suite
# # #