Decision Tables and Issues with the Decision Model

At  Bosch Software Innovations I have posted several posts on decision tables: here and here:

I ask the questions the proposition: can (or should) Decision Tables be used as in a pseudo-relational manner?

In the second part of the series I post that there is a theoretical breakdown of decision models purely based on Decision Tables.  Decision Tables are a useful and powerful metaphor for some aspects of decision modeling. But overuse can create serious issues when it is time to digitize the model.

The suggested existence of the relations or (inferancing relations) between tables asserts that there is a well formed function that can connect these. This is evident when the predicates are pure data types; however, decision tables can contain functions, such as the functions common to decision tables the relations break down.

My regular readers will know that I am taking aim at the Decision Model Approach. We are now working with a number of clients to 'Fix' there radically flawed and unstable models that have been built this way.  

My central issue with the decision model approach is that, events and process become buried in the approach. Our recent experiences prove this.

- 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.

Criticisms	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.