Welcome to the IDIOM Decision Products Knowledgebase.

alt
 



Recent Comments

      More than just business rules - when business rules are not enough

      Mark Norton  25 March 2013 05:13:47 PM
      Idiom has regularly addressed ‘rules problems’ that have been beyond the capabilities of some of our better known peers, regardless of their size and pedigree.

      This post explains why we think this is occurring. Those of you who have worked with Idiom know that we do not claim to be a rules engine per se, notwithstanding our credentials in this space. We do claim to address the decision automation space. The key is the difference between rules and decisions in the preceding statements.

      Idiom seeks to fully address the ‘big’ decisions that are required to manage the state of core enterprise assets – assets like pension fund accounts, insurance policies, patient episodes, passenger itineraries, and utility meters. For a background discussion on this topic please see our article on Modern Analyst, Requirements and the Beast of Complexity.  

      It is likely that the single ‘big’ decision will require hundreds, perhaps thousands, of intermediate decisions to be calculated and re-consumed in the overall decision making process before the ‘big’ decision can be made.

      What is less obvious is that in our experience, the bigger the decision, the more likely we are to need to manipulate the context data. That is, the ultimate decision cannot be fully determined until the context data has been transformed and re-evaluated, often more than once.

      This ability to dynamically transform context data between bouts of decisioning is as important to being able to address the ‘big’ decision as are any of the more traditional business rules capabilities like condition/action tables, decision tables, or forwards and backwards chaining!

      In fact, if you can’t make these transformations ‘on-the-fly’ within the decision making process, then you are limited to addressing ‘little’ decisions within a staged, traditionally coded application. Complexity, cost, and risk, have just gone up by an order of magnitude, but more importantly, this is now outside of the ability of our target user, the SME and/or analyst, to address the ‘big’ decision as a delegated task. This fundamental goal becomes unreachable.

      A recent example can be used to make this point:

      A utility company runs power meters. The ‘big’ decision is: 'Is the meter working correctly?'

      Before any assessment can be made, the traditional irregular billing and power consumption patterns need to be normalised into standardised, artificial billing periods, and then aligned with locally standardised consumption. Only after this can we apply rules to detect likely meter errors, which is a precondition to any meaningful decision making about meter status and rectification.

      If the utility SME and/or analyst is to be able to meaningfully assess the raw context data (that is, the prior billing) and resolve this into useful decisions (like ‘the meter is not working correctly, go and fix it!’), then transformation into standardised data that is aligned on like date-time boundaries, and which is smoothed according to local variations in consumption, is a necessary part of the decisioning process. This would not fit into a traditional business rules paradigm (and certainly not rete). Ergo, business rules cannot achieve decision automation, and decision automation is ‘more than just business rules’.