A well-known problem with decision tables is that they frequently become too big and too difficult to manage. It is also well-known that OpenRules utilizes Excel-based decision tables as its major representation mechanism for business rules. So, I decided to share some methods used by our customers to make large decision tables more compact. Traditional decision tables contain many condition columns and one (or more) action/conclusion columns. For example, the following figure shows a fragment of a typical decision table provided by one of our customers:
Figure 1. A fragment of a Decision Table (Rule Family)
Usually, a decision table requires one column per decision variable. Frequently such condition or action column contains two sub-columns: one for an operator (such as “>=” or “Is”) and one for a value (such as “398” or “High”). In particular, the above table corresponds to the decision table format, also known as “Rule Family”, recommended by the Decision Model, even if it uses more than one conclusions. While the total number of columns in the decision table remains small, such decision tables are very convenient to create, understand, and maintain. Problems start when decision tables have more than 5-6 columns. To avoid such situations, decision modeling methodologists recommend to split a large table into several small ones. Unfortunately, this advice is not always applicable in real-world applications with a large number of decision variables (200, 300, and more). As different rules (rows) inside the same decision table may use different variables, the total number of related columns may grow quickly. This frequently occurs in large enterprise systems, especially when decision tables are being generated from a database or by a rule discovery software such as Rule Learner. For example, the decision table on the Fig. 1 is only a fragment of the following decision table generated by the Rule Learner:
Figure 2. An actual “large” Decision Table
We had to present this table in a zoomed out format to show all columns. Hopefully, you may see that it contains 17 (yellow) conditions and two (green) actions. The total number of columns is (17+2) * 2 = 38. As a result, this table is too wide to be observed as the whole on one page, and even Excel’s scrolling or zooming do not really help. How to make a table like this one smaller and more compact? OpenRules allows you to merge two sub-columns in one by replacing a column of the type “Condition” with a column of the type “If”. The Figure 3 shows the proper example:
Figure 3. Merging Operator with Value in one column
Unfortunately, this method, while minimizing the number of sub-columns twice, will not make a serious difference for very large decision tables: you still need one column for every decision variable.
Now, let’s look closer at the Figure 2. In spite of its small size, you may notice that the majority of cells are empty. Actually, while every rule (a table row) reserves 17 cells for every condition, the maximal number of the used cells is only 5. It is interesting that real-world experience shows that the same fact remains true for the most “large” decision tables. Even decision tables with hundreds of columns usually have no more than 10 (maximum 15) not-empty columns per rule! It leads us to a natural way to compact such decision tables:
for every condition column move a decision variable name from a column title to a third sub-column!
Instead of the traditional column’s structure:
Figure 4. Condition column with two sub-columns: variable name is in the title
we may use another OpenRules condition representation:
Figure 5. Condition column with three sub-columns: variable name is in the first one
This way, a table on the Fig. 1 will be transformed to the following one:
Figure 6. Replacing “Condition” to “ConditionVarOperValue”
The entire table on the Fig. 2 now may be compacted to the following decision table:
Figure 7. Compacted Decision Table from the Fig.1
While the initial decision table had 17 condition columns, the compacted one has only 5! Not only empty cells have been dramatically eliminated, but the table itself became observable (while a little zooming-in still would not hurt). More importantly, it is easy to understand and to manage each rule on the Fig. 7 to compare with its multi-columns counter-part on the Fig.1.
I expect that many decision management practitioners who were frustrated with their large decision tables will appreciate such a simple solution that comes as a part of the new OpenRules Release 6.2.3.
The above method describes how a rule designer can manually compact a large decision table without changing the actual rules. However, sometimes you may completely change the rules themselves to make your decision table more compact. If you have enough examples of applying this decision table to different test cases, you even can do it automatically with Rule Compressor – read more at http://openrules.com/rulecompressor.htm
The drawback of this compacting technique is that it gets hard to tell that the decision table is complete. Completeness of a decision table is required if you take them seriously.
There are several other ways to cope with lager desision tables, In most of the times, you could split the decision in multiple tables (see The Decision Model (http://kpiusa.com/index.php/The-Decision-Model/the-decision-model.html) .
I’ve already addressed this concern at LinkedIn http://goo.gl/2qVvz: “There is no silver bullet in designing decision tables. I described one approach that obviously has its own pros and cons. One may apply it when splitting DTs is not possible anymore. It is especially important when DTs are generated automatically from a database or by a rule learning system such as http://openrules.com/rulelearner.htm. That’s why we, decisioning software vendors, have to provide decision designers with various choices for decision table organization and not to limit them to only one particular method.”
Obviously, it is more difficult to visually analyze completeness of a compacted decision table – compactness comes with its own price. However, if you use an automated decision model analysis tools such as Rule Solver, they still may help you to find conflicting or missing rules even inside compacted DTs.