• The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling
    The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling

Entries in Business Rules (20)


Business Rules Usage Patterns

Dr.  Ketabchi, from Savvion, believes there are seven process usage patterns. These are 

  1. Human Centric
  2. Document Centric
  3. System Centric
  4. Decision Centric
  5. Case Management
  6. Project Centric
  7. Event Centric     

There is an eighth one, the 'shadowing' process. This is a process for monitoring 'legacy' processes. Dr. Ketabchi A description of each of these processes can be found in this BPM Institute recorded webinar.

As the BPM Industry matures, these patterns will emerge. We know from design patterns, that best practices can emerge from the wisdom of experience. 

I believe there are some distinct business rules usage patterns. I list these here:

Usage Pattern Center

Typical Legacy Sources



Computations and Score Carding

Spread Sheets, Desktop Databases and Scripting

Credit Risk, Security Targeting

Generally Computes one or more metrics. Often one or more decision tables serve as the final arbitrator

Hierarchical or Hierarchical Graphs 

Database and Scripting Languages, Cobol

Insurance, Social Benefits or Entitlements 

Seeking a number of nodes in a large graph of options and factors. Logic can be deeply nested and the graph can be imperfect

Pattern Matching

The Gamut of Source Code (C++, Fortran, Basic, C#)

Fraud Detection, Market Abuse, Security

Often applies multi-variant or fuzzy logic 

Algorithmic Decisions


Source Code


Derivatives,  Hedging, Environmental Modeling

Focusing on Applied Numerical Methods, Regression Techniques and Statistics

Event Directors


Sensor-Based Controls

Uses within event processing applications


 - Tom Debevoise


Unpacking Decision Management: A Changing Landscape

There is an excellent recent review of knowledge management as written by Fahmi Ibrahim (here). I was struck by the parallels between KM and business rules, so I 'borrowed' his conclusions and mapped them to my understanding of the business rules industry.


Key Points 

Poor Conceptual Understanding

The vast majority of the business rules literature (1)(2)(3)(4) and products are built on the assumption that business rules should be expressed as a linguistic, symbolic or interpreted evaluation of facts. However, the characteristics of this approach make it difficult to create, control and manage changes (5)(6).


The alternate approach views business rules as a set of sequential sequence of logic that categorize, compares, computes and controls a business decision or direction.


Many organizations have successfully implemented both approaches.

Lack of Common Framework

In reviewing the literature and standards, business rules and the business rules approach lacks a common framework and there is no consensus of a working definition of either. Commercial software focuses on IT infrastructure. In the OMG standard there is the semantic business rules vocabulary (SBRV). SVBR has very little to do with the needs of IT operations. Consequently, the business rules are misunderstood and underutilized, especially in rules intensive-areas such as health care, logistics, risk management and finance,

“Rebottled Old Wine‟

Many products employed expert systems that were developed over 3-decades ago to solve unrelated AI problems. Other approaches evolved from the limitations of the relational data bases (7)(8). The result is that the definition of business rules and business decisions is too narrow and will not encompass the evolving event driven infrastructures of tomorrow.

Bandwagon Effect

In the last 10 years, many companies jumped onto the rules bandwagon without understanding the meaning and implications of expert systems, fact-based modeling, or vocabulary approaches. In fact, many companies became bogged down in analysis paralysis and endless ‘death by meeting’.

Success or Failure

The business rules approach has delivered significant results but the success rate is mixed. There are many examples of organizations which have successfully implemented BRA. Yet anecdotally, we encounter initiatives will fail to have significant results. Like knowledge management, some have declared that BRA is a fad without real business benefits.

Value and Measurement

While business rules are widely recognized as a valuable metaphor for controlling business results there is little understanding of how to manage these.

I think business rules should support an expanded view of business rules in the enterprise-one that encompasses and moves beyond supporting a process decision (or endless meetings that might make that someday). New metaphors, especially events, are on the horizon. As with every method, the complexity of the situation will significantly expand. To survive, the business rules approaches should reduce complexity and increase transparency with today's model-driven approaches.


Business Process Management, Remember the Basics

As Sandy Kimsley pointed out in her links, Ken Swensen responded to the question, is BPM Dead? In all of our discussions of technology, business processes, business rules, business events, it is easy to lose focus on the basic worth of business process management.

Therefore, it is useful to review the differences between function- and process-orientation within organizations. Most organizations, that use BPM, intend to become process-centric. Organizations with a robust process focus are distinguished by having a extensive, cultural process orientation. Big, complex organizations consider the process focus as extremely important, and this system is particularly common in insurance, healthcare, and financial services. A functional organization orientation, on the other hand, is more prevalent in small enterprises and is well-suited to the way they handle business.

A functional organization is an organization that delivers a strong capability in a limited number of functions. These might include highly specialized product and skills where knowledge or availability is limited. Obviously, a functional focus works for them.

Each focus,functional versus process-centric has advantages and disadvantages. In his admirable work on business process management, James Chang created the table below that summarizes the differences between organizations adopting each focus. A functional organization allows an easier balance of work among workers with functional excellence because they all have similar skills. This organizational style outlines natural, comprehensible ways that each task should be performed and assigns this to the appropriate proponent.


Functional Organization

Process Organization

Work Unit:



Key Figure: 

Functional Executive 

Process Owner 





Functional excellence,

Easier work balancing because workers have similar skills,

Clear management direction on how work should be performed

Responsive to market requirements,

Improved communication and collaboration between different  functional tasks,

Performance measurements aligned with process goals


Barrier to communication between different functions,

Poor handover between functions that affects customer service,

Lack of end-to-end focus to optimize organizational performance

Duplication of functional expertise,

Inconsistency of functional performance between processes,

Increased operational complexity

Strategic Value:

Supports cost leadership strategy

Supports differentiation strategy


Work Management:

 Functional Quality Focus

Cross Functional Coordination

Table 1 Benefits and Drawbacks of the Functional Versus Process orientation in organizations (Business Process Management Systems, Chang).

Conversely, a process organization enjoys improved communication and collaboration and may therefore be highly responsive to market requirements. Further, performance is easily measured across the process organization, as it is stated in terms of process goals. However, process organizations suffer from lack of or poorer quality communication between the different functions relative to their functional counterparts. There is reduced end-to-end focus, as opposed to the functional structure. Moreover, there may be considerable duplication of functional expertise, inconsistent functional performance between processes, and increased operational complexity. This may make the structure of the process-based organization redundant and bulky.

- Tom Debevoise


Business Rules and Business Process Modeling Simplified

In BPMN 2.0 there is a shape for business rules:


 This shape denotes the place within the process model which calls business rules and obtains decision output.  The question is, how do you use it?

The difference between process and rules is simple; processes are stateful and rules are stateless. In BPMN a process has an explicit or implicit single start and one or more stops. In business rules there is no start or stop. It is an expression of a sequence of logical conditions.

Consider the figure below:


Simple Process with exclusive gateway, the process corresponds to the process: Start: When A Condition: Start Activity A When B Condition: start activity B, When either complete: Stop

This simple process uses the exclusive gateway to choose which activity to run. The activity, A or B, will run for an indeterminate time. When it is done the end is reached. A simple flow rule from Visual Rules is shown in Figure 2.  A flow rule is a graphical representation of a path of logic. There is no time element to the evaluation; either condition A or Condition B will be the outcome of the evaluation of the conditions in the two gateways-there is no time element to consider.


Figure 2: Simple decision graph with two exclusive outcomes, the diagram corresponds to the logic IF A condition Then A Outcome else If B Condition then B Outcome.

The two figures compare and contrast the similarities of BPMN and business rules. Both evaluate the logic conditions to decide which process activity or outcome to choose. The contrast is in the time element. This is what we mean when we stay the process is stateful and the decision graph is stateless.

If we connect the flow rule with the process then the process model looks like this:


This is simple, but most process decision are more complicated than that. I discuss process decisions in a white paper located here:


The Past Present and Future of Business Rules

Innovations Software Technology has released my most recent white here.  In this document, I review the early beginning of the Business Rules Approach (BRA), discuss the current practices, and conclude with some predictions.

The BRA has principally evolved from three sources: Artificial Intelligence (Expert Systems and others), Data Modeling, and Business Process Reengineering. Circuitously, expert systems became one of the originating technologies for business rules. In the white paper I explain the differences between the sequential logic approach and the inferencing approach adapted from expert systems.  I have experience with both and clearly my bias is towards sequential, graphical approaches. 

Before I worked for Visual Rules, I led the development of an open source business rules engine, OpenLexicon. OpenLexicon used a sequential approach; however, rules were developed with a language template. My understanding of the sequential approach also includes the lessons learned here.

Certainly, business rules and decisions are critical aspects of enterprise architecture. Yet they are aspect of a larger approach. Business rules have already expanded beyond the outdated paradigm of a process-decider. To remain viable the business rules approach will need to support an expanded vision within the enterprise-one that encompasses and moves beyond supporting a process decision.

Again, the paper is available here.