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 12Some 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 12Shortly 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 12Here 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.