• 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 Approach (3)


Past, Present and Future of Business Rules (Redux)

It has been over 3 years since we released the white paper, the Past Present and Future of Business Rules. The paper has been widely distributed and we managed to generate many discussions, some of them were heated. My colleague, Christina Gruen suggested I update this and subsequently I have updated the paper and prepared a webinar. You can register for the webinar here:

To recap: the business rules approach (or operational decision management) BRA/ODM has principally evolved from three sources: Artificial Intelligence, Data Modeling, and Business Process Management. In the white paper, I explained 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. However, inferancing and functional programing is critical for developing decision analytics. Strict formalism in business requirements may sound desirable; yet it creates a lot of work of questionable value for the business analysts and the technician. Organizations are frequently ‘stuck’ in heavy; difficult to maintain environments in many large-scale business rules systems in finance and health care.

Having been involved with many of the standards and practices, I am hearing surprising rumblings that There are development on the horizon that I will be game changers. OMG’s decision model notation is becoming more prevalent, plus other efforts are poised to shift the industry.


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 Rules Requirements in the Real World

In a recent blog post on the requirement network group, Chris Kosba posed a question concerning the role of 'business rules' in requirements gathering activities. Again, this raises a common misconception about requirements and business rules.

I agree that it is necessary to know when your requirement is supporting a business decision through rules. To approach this issue, we need to meet the eternal question: what problem are we trying to solve? As messy as the requirements page in Wikipedia is, the meaning is pretty concise -a requirement is a singular documented need of what a particular product or service should be or perform.

If our requirement is that we should support the business rules, as defined by the business operations, (i.e. credit risk rating) then it is usually useless to document these business rules in requirements elicitation. The business rules are the data that drive the system. Documenting these rules would be equivalent to defining an employee database then defining the instances of employees in the tables. We know our employee table needs columns of first name, last name and middle initial. This is a requirement. Is it a requirement that the table organize the records "John A. Smith, Bob H. Jones, and Sally L. Quill"?

If your system requires that business rules be supported by BRMS then, business rules should be visually expressed as truth tables or logic trees. The truth table is a two-dimensional indication of conditions and conclusions. In Visual Rules, we call the logic tree a rule flow. In the real world, we often run into application requirements that are stored in spread sheets with logic that flows from worksheet to worksheet. Often, there are many tabs with dozens, if not hundreds, of lines of logic. We especially see this in score cards for probability of default (PD) models. These spread sheets can be converted into a visual model with the Visual Rules approach.

If the requirements documents show too many business rules, or business rules that should be in a BRMS, then they will become unnecessarily complicated.