Wednesday, April 05, 2006

Decision Trees

This second and last article in this series discusses decision trees, what are they, when to use them and when not to use them.

Decision trees help systems reach a predictive decision that relies on navigating a path of historic knowledge to reach the end conclusion. An analyst or rules writer lays out the decision path with branching conditions leading to different outcomes. Decision tress during execution very closely resemble structured programming. The serially arranged branching statements can be compared to nesting if…then…else statements in traditional code.

In contrast to decision tables, decision trees have the advantage of being able to contain an inconsistent set of parameters without necessarily making the tree more complex. For example, each branching point does not need to concern the same parameters. Trees become more complex when each parameter potentially has a large number of different values. This is the inverse of decision tables. Each possible parameter value becomes a node at a branching point in the tree. Trees are generally complex and unruly to represent and even more so when the number of branches and levels grow.

We do NOT recommend using decision trees as an implementation for rules unless there are very good reasons to bypass inferencing and force the execution of one rule before another. We do not recommend decision trees for the following reasons:

  • Decision trees are very brittle when rules change and require significant maintenance.
  • Decision trees quickly become complex and difficult to manage.
  • Rule engines utilize inferencing to determine the execution order of rules. Decision trees hardcode the execution order of rules which circumvents the entire inferencing capability of rule engines and make rule maintenance equate to the maintenance of hard coded and nested if…then…else statements.
  • The entire decision making process is triggered by making a choice about one parameter (the root element). With inferencing, the rule engine can start anywhere and work its way towards the same answer from any angle as it executes rules.
  • Ordering the execution of a small number of rules within a ruleset is better done through rule execution prioritization using weights rather than trees. Even so, this should rarely be necessary.

Trees can be made more user friendly and manageable by writing a high level rule flow around the execution of rule sets and decision tables.

We DO however recommend using decision trees during the rule analysis process for the following reasons:

  • Decision trees will help analysts identify groupings of rules, which generally trigger together, which will assist with the identification of rule sets.
  • Identical smaller branching structures at different places within a larger tree expose ruleset reuse opportunities within a ruleflow.
  • Analysis using decision trees may expose business processes currently hidden within a larger chain of rules.

2 Comments:

At 4/24/2006 12:20 PM, Blogger KK said...

James,

I see you posted an article of your own discussing decision tables and trees just a few days after mine:

What are the characteristics of rulesets?

Despite your above criticisms, I think we are actually in a larger agreement on this topic than your response would suggest. I would expect that given your comments, your article would present decision tables and trees in a very different light than mine. I seem to see more parallels than differences however.

 
At 5/11/2007 1:47 AM, Blogger Ensing said...

If an image is worth a 1000 words ...
here is a video of a Decision Tree editor.

I agree with James Taylor that good business rules editor are essential for modeling business logic. This is only one rule representation format that an end-user might use.

Acumen Business

 

Post a Comment

<< Home