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

Mark Norton  25 March 2013 05:13:47 PM

On multiple occasions we have used the Idiom Decision Manager to successfully address decisioning problems that have already been attempted using alternative rules products and strategies. Given the relative cost and complexity of the products being used, we have at times found this surprising. In this post we provide one explanation as to why we believe that Idiom is able to address complex ‘rules problems’ that have been shown to be beyond the capabilities of pure 'rules engines'.

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 (by some definitions, the lack of Rete in Idiom makes this definitive). Since our founding in 2001, we have claimed to be a 'decision engine', and to address the decision automation space. This post focuses on the difference between what we mean by rules and decisions in the preceding statements.

Idiom seeks to fully address the ‘big’ decisions that are required to manage the "state" of the core enterprise assets that are the life blood of any organisation. Decisioning is particularly applicable to organisations where these 'assets' are described by high volumes of complex data entities - entities like superannuation fund member accounts, insurance policies, patient episodes, passenger itineraries, and utility meters, to give some examples that we have worked with recently. (For a background discussion on this topic please see our article on Modern Analyst, Requirements and the Beast of Complexity. )  

Idiom's view is that the ‘big’ decisions that define state changes in entities like those listed above are an (perhaps the) essential specification of how the organisation creates value. It is likely that these ‘big’ decisions will require hundreds, perhaps thousands, of intermediate decisions to be calculated and re-consumed in the overall decision making process before the ‘big’ decisions are finally made. What would constitute a 'big' decision in this context? The following are some real examples that we have addressed with 'decisioning':

• For the Superannuation Fund Account: Is all of its data valid (an audit decision); are there any age or contribution based member adjustments to make; what fees/insurances should be charged, and how much to charge; has the correct tax been applied and calculated.
• For the Insurance Policy: Do we have enough information about the risk and is it valid and consistent; will we underwrite the risk, at what cost, and under what terms and conditions.
• For the Patient Episode: What recoveries need to be made against what funding contracts given the range of patient conditions found and treated, and the services consumed.
• For the Passenger Itinerary: How many loyalty credits will be earned on this trip.
• For the Utility Meter: Does the billing pattern indicate a faulty meter.

Most of these 'decisions' have a heavy 'business rules' component. But are they decisions that can be made using a business rules engine acting alone?

In our experience, the bigger the decision, the more likely we are to need to manipulate the context data within the decision making process (by manipulate we mean validate/transform/revalidate the data). That is, the ultimate decision cannot be fully determined until the context data has been transformed and re-evaluated, often more than once. The rules that are actually implementing business strategy or intent are applied between these validation/transformation cycles.

This ability to dynamically transform context data between successive bouts of 'business rules' is as important to being able to address the ‘big’ decisions as are any of the more traditional business rules capabilities like condition/action tables, decision tables, or forward/backward chaining. The combination of data transformation and business rules (and if appropriate, recalculation of propensity scores via analytics) constitutes a single 'unit of work' that we call decisioning or decision automation.

It is critical that the entire decisioning 'unit of work' can be delegated to the business subject matter expert if we are to fully align business strategy and its implementing systems - the strategy becomes content under the 'hands-on' control of its business owners within an IT framework.  

In fact, if you can’t make these transformations ‘on-the-fly’ within the decision making process, then the process is limited to addressing partial 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 SME user 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’.

• Comments [0]