[This post describes an approach to integrating the Decsion model of von Halle and Goldberg with process modeling in BPMN.  For Part 1, click here.]

Before describing the integration of decision modeling with BPMN, I need to summarize the Decision Model approach described by Barb von Halle and Larry Goldberg in their excellent book.  I can?t do it justice in a simple post; if you want to find out more, just get the book.

The Decision Model

Although the book does not use the term, I would call it a metamodel for business decisions, i.e., a description of the relationships between specific decision components and the principles governing how they can be combined.  It does not specify a rule language, and is in fact language-independent.  Business-oriented decision models, which are the focus of the book, use a structured form of natural language to define business rules.  Those are easily mapped to IT-maintained data models and engine-specific rule languages for execution.

Just as the relational model imposes constraints on the organization of datasets, the Decision Model imposes constraints on the organization of rulesets.  A business decision is defined as “a conclusion that a business arrives at through business logic and which the business is interested in managing.”  The Decision Model provides the framework for structuring that business logic.  It makes most sense to use the Decision Model and its associated methodology when the decision has high busness value or the decision logic is subject to change, or is complex, or is reused in multiple business processes.  In those situations, the Decision Model?s advantages in management and governance justify the small additional burden its structure imposes.  It is most useful for organizations like financial services or insurance, where the number of decisions that must be simultaneously maintained and tweaked can run into the hundreds or thousands.

Here is an ultra-brief summary of the Decision Model:

A business rule, or business logic statement, relates a set of condition facts to a single conclusion fact.  A fact is a value of an attribute of some business concept, for example, Order.amount or Loan.Risk.  The fact type defines a domain of enumerated fact values used in the decision logic.  For example, the domain of the fact type Loan.Risk could be High, Medium, or Low.  (Technically, the domain could be a continuous numeric or date/time range, but for all intents and purposes it?s easiest to think of it as a set of enumerated values or ranges.)

Within a business rule, the conditions are all ANDed together, i.e., if Condition 1 AND Condition 2 AND Condition 3, then Conclusion.  You may not have OR?ed conditions in a business rule.  The OR?ed condition defines a separate business rule.

The set of rules concerning a single conclusion fact type is called a rule family.  It looks very much like a decision table, with a column for each fact type (conditions plus a single conclusion) and a row for each rule in the rule family.  The book is insistent that a decision table and a rule family are not the same thing, but my view is that people would better understand it if a rule family were described as a decision table subject to certain constraints.

The business logic of a rule family is declarative.  The order of the columns and rows in a rule family is immaterial, as is the algorithm by which it is evaluated on an engine.

A condition fact in a rule family may be the conclusion fact of another rule family, setting up a dependency relationship between the rule families.  Within a single decision model, those relationships must be strictly hierarchical; circular relationships are not allowed.  The top-level rule family represents the decision itself.

For example, the rule family for Loan.Risk could depend on the condition facts Borrower.AbilityToPay and Loan.LoanToValue, each of which would be defined in dependent rule families.  The Borrower.AbilityToPay in turn is based on facts such as Borrower.Income, Borrower.OtherLoans, Borrower.NetWorth, etc.  A condition fact type in a rule family is always either a dependent rule family or simple persistent data.  There is no limit to the nesting of dependent rule families.  Factoring the business logic in this way is the key to business agility, logic reuse, and effective governance.

The Decision Model also specifies a graphical notation for describing the rule family dependencies and a decision table-like structure for specifying a rule family.  That?s it in a nutshell.

Relating the Decision Model to BPMN

Now the question is how does a decision relate to BPMN.  In an appendix chapter in The Decision Model book, I suggested that it should be modeled as a Business Rule task, a new task type in BPMN 2.0.  My thinking when I wrote that last Spring was that beginning modelers mistakenly use gateways in BPMN to model decisions, which are rightly modeled as activities.  But now that I actually understand the decision model (read the book, took the training), I see that suggestion is correct only in certain cases.  The general case is more complicated.

The reason is that a Business Rule task is a single unit of execution.  It models the way a rule engine works, i.e., the condition facts are assumed to be simultaneously available to (or provided to) the task prior to execution, which returns the conclusion fact.  Nothing of consequence happens “in the middle.”

So integrating decisions and process comes down to this:  In a decision model, what is the unit of execution?  How much of it happens ?all at once??  It’s not necessarily the whole business decision.  In the Decision Model, the scope of a single decision is really determined by its business impact, not its implementation.  A decision is a logical abstraction, not a model of how that decision would be implemented in a business process. 

There is still great value in managing business logic across the enterprise at the decision level, i.e., as declarative statements independent of implementation, which could vary or change over time.  But to properly integrate decisions and process, we need to tweak the model in order to accommodate the procedural aspects of decision implementation.  I am thinking of a form of a decision model composed of nodes that map directly to BPMN nodes.  Let?s call it the Decision Implementation Model (DIM).  Nodes in DIM represent decision fragments corresponding to specific  BPMN activity types in the process model.  Thus DIM effectively separates the procedural and declarative aspects of a decision as it is actually implemented.

In DIM, the unit of execution is a rule family.  Here execution does not mean automation, just implementation in the context of a business process.  For purposes of process model integration, we?ll define three rule family types:

  1. Executable rule family (ERF).  Business logic is explicit, and all condition facts are available for immediate execution, i.e., either persistent data or the conclusion of another rule family.  In BPMN, ERF is modeled as a Business Rule task, such as implemented by a business rule engine.
  2. Human decision (HD).  Business logic is opaque (it?s a human decision), and execution could take time.  In BPMN, HD is modeled as a User task.
  3. External decision (ED).  Again business logic is opaque (not necessarily a human decision) and execution is long-running.  In BPMN, it is modeled as a Send/Receive task pair (or equivalent message event pair).  An example might be a credit score provided by an external service. [Note: In BPMN Method and Style, a Service task is interpreted as a synchronous request and short-running, while a Send/Receive pair is interpreted as an asynchronous request and long-running.  But this is really a matter of modeling style.]

Thus to describe decision implementation within a business process, we may need to decompose the decision model into finer-grained DIM rule families.  As in the original decision model, a condition fact in a DIM rule family can be populated by a conclusion fact from a child DIM rule family.  However, in DIM the link from child to parent rule family implies procedural behavior, i.e. sequence flow in BPMN.  [Note: If a rule family is ERF and all its direct dependent families are also ERF, then they could be combined as a single unit of execution (Business Rule task) in BPMN.]

In this segmentation, the difference between HD and ED comes more from BPMN than from the decision model.  In HD the decision is made by a performer within the process, and in ED it is made by an external participant.  In decision model terms, there is little difference between them, as both represent opaque decision logic and long-running execution.  By “opaque,” I mean that the business logic is not a predefined expression of a set of facts.  However, it is possible that an opaque decision (HD or ED) requires certain facts as input, so it could be dependent on other rule families in DIM.

Besides separating the procedural from the declarative portions of the implementation, we need to consider another important element missing from the decision model: actions.  The only process action represented by a DIM rule family is making the decision, i.e. executing the business logic.  It does not include actions such as:

  • Retrieving data from its source into the DIM fact domain
  • Pre-validating fact data and correcting it if necessary
  • Sending notifications to participants and stakeholders
  • Updating systems with conclusion fact data
  • Handling timeouts and exceptions within the decision implementation
  • Executing other conclusion-triggered actions, such as starting another process

All of these actions are represented in the process model as BPMN activities or event handlers.  Except for executing conclusion-triggered actions, they are best represented as nodes within a Decision Subprocess. Each DIM rule family maps to a Decision Subprocess containing one activity representing the DIM rule family type and other activities representing these other actions.  [Note: the BPMN 2.0 specification does not include a Decision Subprocess type.  Its semantics are the same as a regular BPMN subprocess, embedded or reusable.]

Conclusion-triggered actions are typically represented by a gateway following the Decision Subprocess with a gate for each tested conclusion leading to the triggered sequence of actions.  Since rule family conclusion values are exclusive alternatives, the paths can be merged downstream without a gateway.

Decision Model Example

To illustrate how all this works, consider the decision to approve a loan.  The Decision Model, in the Goldberg/von Halle notation, looks like this:

The top-level rule family Loan.ApprovalStatus represents the decision itself.  Rule families are named after their conclusion fact.  The “ticket” shape enclosing the rule family lists its condition facts.  Those above the dotted line are dependent rule families, shown by other tickets in the diagram.  Those below the dotted line are expressions of perstitent data.  Here Borrower.CreditRisk is a dependent rule family and Loan.SpecialConsideration is an expression of persistent data, in this case a human decision.  Borrower.CreditRisk itself dependent on two other rule families.  Factoring the business logic in this hierarchical way enables business agility and logic reuse.

The business logic is apparent from the Decision Model’s tabular rule family notation:

A blank Condition cell means this condition is not used for this particular rule (row).  The Decision Model does not require it, but it is convenient to model conclusion fact types as “abstract” enumerated values like High, Medium, and Low.  Specific numerical ranges are used in expressions of persistent data.  Note in this business decision, all of the logic ultimately depends on just four persistent data facts: Monthly Income, Monthly Payment, Reported  Credit Score, and the Special Consideration human decision.  The rule family structure, however, makes the decision logic easy to parameterize, change easily, and manage.

Mapping the Example to DIM

In the previous example, the Decision Model acts as if all of the source facts are available before executing the decision all at once.  In real business processes, this may not be the case.  Here, for example, we’ll say that the borrower’s monthly income and loan monthly payment facts are data available internally within the process making the decision.  Reported Credit Score is an external decision, made by a credit reporting service.  Special Consideration is a human decision made within the process.  And here we’ll say that this human decision requires IncomeToPmtRatio as an input fact, setting up a dependency on another rule family.

Now ReportedScore and SpecialConsideration are no longer considered persistent data, but decisions, broken out into their own special rule families.  HD and ED rule families here are shown with a dashed border.  The other rule families, shown with the standard solid border, are ERF.  Note IncomeToPmtRatio is a child of both CreditRisk and SpecialConsideration rule families.  This does not violate the no-circularity principle.

Now each of the DIM rule families maps to an activity in the BPMN process model for the decision, as shown below:

We’ll look at adding exception handling and other actions in Part 3.