In this article I list a number of observations on the coexistence and the relationship between business rules, decisions, and processes.  They represent my contribution to the panel on business decisions at the 2013 Building Business Capability conference.  (See [1] and [2] for other contributors.)

Business processes should be flexible and at the same time compliant with business policies, rules, regulations, and protocols.  Processes use decisions and support decisions.  Decisions and processes are related to business rules, and all are important to the business.  Some separation of concerns seems necessary here to tackle this business modeling issue.

Observation 1:  Decision trees are not process paths

A first simple observation relates to the separation between processes and decisions.  A process model should not be the direct mapping of a decision tree (as in Figure 1) because subsequent decision diamonds could be merged into one decision point (when age > 18 and medical record is clean, accept the client, otherwise decline).  The business logic is not the same as the process.  Of course the example is trivial, but it illustrates how some process representations overemphasize decision paths.

Figure 1.  Process model with cascaded decision diamonds.

Observation 2:  Separating (decision) rules from the process simplifies the process

This one is obvious and well-known.  Separating these decision rules, such as calculations or classifications, allows us to model and maintain the rules outside the process and keeps the process more simple, stable, and flexible when only the rules change.

Figure 2 revisits part of the example from the first observation.  A change in the rules will no longer impose immediate changes to the flow logic, and therefore creates an agile and maintainable environment.  Separating rules and decisions from the process simplifies the process model (i.e., separation of concerns).

Figure 2.  Offloading the process

Although the advantages are obvious, the implications are more profound than commonly accepted.  Process modelers are often reluctant to give up the detailed overview and comfort of nicely-drawn process paths.

Observation 3:  Modeling Decisions/Rules is a separate modeling task

Note that the setup of this observation is the further extraction of business logic from the overall process.  Where the previous observation only modeled the individual decision points, this observation considers a level of separation that aims to model the business knowledge autonomously and be reusable across the process(es).  The decision (e.g., in complex legal documents) can be modeled independently, and this knowledge can be used at one or more appropriate places in one or more processes.

Over the years, numerous notations and frameworks have been proposed to formalize rules, goals, requirements, and decisions.  The approaches take the business modelers through various stages to efficiently model the decisions and their inputs (business knowledge and data).  Recently, extensions within the range of business knowledge representation frameworks have been provided.  These include the forthcoming OMG Decision Modeling & Notation (DMN) standard^[3] which will represent decision requirements and different decision logic representations, such as decision tables (see Figure 3).

DMN is not about methodology.  It is about indicating the importance of modeling decisions.  It is also about a standard notation to represent the dependencies between decisions and to represent the logic of a single decision.  It will allow harmonizing and clarifying the decision and decision table message.  It does not replace the good old (but modern) decision table methodology, but it does make business users and implementers aware of the need of clear decision specifications — both outside and (certainly) inside the context of business processes, whatever the underlying methodology (or lack thereof).

Figure 3.  DMN levels.

Observation 4:  Good decision table models are a proven technique to represent some types of rules

Most people know what a decision table looks like:  a number of rows or columns containing rules about combinations of condition expressions with their respective outcome.  The reason for its success is simply that every column (if rules in rows), or every row (if rules in columns), or every dimension (if rules as a crosstab) is about one specific condition.  This fixed order of conditions allows a compact overview of rules.

The format of decision tables, however, is only part of the story.  When the CODASYL Decision Table Task Group produced its report A Modern Appraisal of Decision Tables,^[4] it not only contained an overview, notation, theory, and algorithms but also a development methodology.  This development methodology (Chapter 5) covers such aspects as:

• Guidelines for composing effective decision tables (effects of size, completeness, inconsistency, …).
• Developing a hierarchical structure of decision tables that serves as a functional solution to the problem.
• Definition of a working subset of decision tables (completeness, no inconsistencies, no redundancies, no overlapping rules, no ELSE-rule, …).
• A simple 8-step method for constructing good decision tables.
• A transition from the specification to design, implementation, and maintenance.

After the CODASYL report, the development methodology has been further refined and explained, e.g., at the Business Rules Forum since 2004 (for example, see [5]).

Figure 4.  Structures of decision tables (on the cover of A Modern Appraisal of Decision Tables).

Observation 5:  Decision models are not lower-level details of one process

Decisions can span multiple processes, multiple activities.  That is why a decision model, or a set of decision rules, is not just attached to one activity in one process.  It can be reused throughout a process and across multiple processes.

Observation 6:  There are many more business rules than decision rules

If all you have is a hammer, everything looks like a decision rule.  But business rules are not (only) about decisions; they are also about behavioral constraints, timing, task allocation, etc.  So reducing business rules to decisions is an oversimplification.

See [1] for a good overview of the business rules space (and the decision space).

Observation 7:  Sometimes the entire process is basically the execution of a complex decision; there may be multiple ways to 'process' a decision

Before we install or reengineer a process for a complex decision, it will be good practice to study the decision and data requirements.  Depending on the decision logic, we could (automatically?) design an optimal process where optimality is defined in terms of process criteria.

In a large number of cases, the process does not just contain decisions, but the entire process is about making a decision.  The major purpose of a loan process (for example) or an insurance claim process (etc.) is to prepare and make a final decision.  The process shows different steps, models the communication between parties, records the decision, and returns the result.  One specific process representation, however, is only one possible way to implement a specific decision.  There may be many possible process models for a given decision structure so it is worth examining the relationship between decisions and processes.

For a given decision (structure), the decision process could be organized in very different ways, according to various criteria:

• The process can try to optimize the company's resources, given a minimum service level.
• The process can focus on minimal average waiting time, from the customer's point of view.
• The process can try to minimize customer contacts (touch points), by having all information available up front.
• The process can try to minimize redundant information requests, only asking the customer information when and where it is needed.
• The process can focus on other criteria, such as collaboration, organizational structures, etc.

Each of these criteria can lead to very different process models, even if the decision structure remains the same.

Observation 8:  Rule-driven, declarative (or intelligent) BPM

When attention is put on capturing regulatory and internal directives in business rules of different forms, maximal allowable freedom is left for letting the process instances grow organically.  Moreover, business operations that are modeled according to these principles have the advantage that compliance with internal and external directives can be easily demonstrated.^[6]

Several business process research subdomains are comprised in this observation, including declarative business process management, ad-hoc business processes, and adaptive case management.  Business processes that are characterized by a dynamic, human-centric, and non-standardized setting will benefit from the flexibility that could potentially be provided by declarative process modeling (e.g., healthcare processes:  while general medical principles are the same for all patients, each case will be different due to complications, patient conditions, etc.).

Standard processes handle expected situations, but we need more intelligent processes for the unexpected.^[7]

Conclusion

Business rules, processes, and decisions are all important, as indicated in the Business Rules Manifesto,^[8] the Business Process Manifesto,^[9] and the Decision Management Manifesto.^[10]  For the coexistence of and the relationship between the three, we could use a Business Modeling Manifesto.

References

[1]  Ronald G. Ross, "Three Major Myths of the Business Decision Space — And Why They Matter to Business Analysts," Business Rules Journal, Vol. 15, No. 1 (Jan. 2014), URL:  BRCommunity.com/a2014/b737.html  

[2]  James Taylor, "Putting Decisions First — Why Building Decision Models Delivers Business Rules Success," Business Rules Journal, Vol. 15, No. 2 (Feb. 2014), URL:  BRCommunity.com/a2014/b746.html  

[3]  The Decision Model and Notation (DMN) Specification 1.0 Submission is available from the Object Management Group (OMG) at omg.org/spec/DMN/Current  

[4]  Codasyl, "A Modern Appraisal of Decision Tables," Report of The Decision Table Task Group, ACM:  New York (1982), 322 pp.  

[5]  Jan Vanthienen, "The History of Modeling Decisions using Tables (Part 3): Standardizing Decision Table Modeling (16 guidelines)," Business Rules Journal, Vol. 13, No. 5 (May 2012), URL: BRCommunity.com/a2012/b652.html  

[6]  Jan Vanthienen and Stijn Goedertier, "How Business Rules Define Business Processes," Business Rules Journal, Vol. 8, No. 3 (March 2007), URL:  BRCommunity.com/a2007/b336.html  

[7]  Jim Sinur, "Measuring Levels of Raw Intelligence in Your Processes," Business Rules Journal, Vol. 15, No. 2 (Feb. 2014), URL:  BRCommunity.com/a2014/b744.html  

[8]  Business Rules Manifesto, at businessrulesgroup.org/brmanifesto.htm  

[9]  Business Process Manifesto, at bptrends.com/resources/bp-manifesto/  

[10]  Decision Management Manifesto, at decisionmanagementsolutions.com/decision-management-manifesto  

# # #