Rule Design – How Far Do You Go?

Rule Design – How Far Do You Go?

The topic of genericization in rule design came up the other day. I should explain first what was meant, and the easiest way to do that is with an example.

Suppose an OPA Customer conceives a rule that looks a little bit like this

Rule Design OPA 12

Some time later, the same customer finds that there are several similar rules, such as the next one below.

An attempt is made to streamline the rules into a more appropriate structure first of all. So a rule might be rewritten to take into account not just a boolean conclusion but something more interesting, such as return codes.

Rule Design OPA 12

Shortly after that, as the realization dawns that there are thousands of rules like this, a further effort occurs to streamline the concept even further as shown in the example below.

Rule Design OPA 12

Here we can see the rules are broken down in the manner of with input arguments that may be numbers, Booleans and so on. The exact components of each validation are detailed. This is further extended and generalized, broken across Excel and Word (to cope with grouping operators like either) and what have you.

And so the usage of the validations becomes something a little like this (I am exaggerating for effect). Further tables are created to schematize which rules are used in which business context. We shorten the attribute names, create legends, standardize the text used.

Rule Design OPA 12

We are so far away from anything resembling natural language that we might as well be using the Microsoft Win32 API. We have delivered our Rule Design but have we best served the customer? Of course the context is key (the audience for the rule design documents, the purpose of the rules – Web Service or Interview, to mention only a couple of criteria) but the presence of different teams and different competing teams – internal or external – seems to lead to black box designs that only serve to frustrate the customer.

If you are interested in learning about approaches to writing rules in Intelligent Advisor, check out part one of our series on refactoring and object-oriented concepts in Oracle Intelligent Advisor, or read part two.

Richard Napier

Author: Richard Napier

After 8 years in case management and ERP software roles, Richard Napier joined Siebel Systems in 1999 and took up the role of managing the nascent Siebel University in Southern Europe. He subsequently was Director of Business Development and Education for InFact Group (now part of Business & Decisions) for 8 years. He now runs Intelligent Advisor IT Consulting OÜ. Owner of intelligent-advisor.com, he also is Co-Founder of the Siebel Hub.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Serving Customers Worldwide
Hide picture