The secret of business user rule maintenance

I saw this post on rule templates over on The Road Hits The Rubber and it made me think about business users and the promise that business rules makes of allowing business users to maintain business rules. But here's the dirty little secret:

Business users don't want to "maintain rules" any more than they want to "write code"

What they want to do is run their business better. They want to:

• Relax their underwriting policies
• Reduce their risk exposure
• Retain more customers even if it costs more
• Promote slow-moving products
• Catch a new kind of fraud
• Enforce new regulations
• and so on...

Now you and I may realize that these are all ways of saying they want to control how certain rules are implemented in their systems or at least in the decision services within those systems, but that's not how they think. So if you are going to get business users to maintain the rules in their systems without them feeling like you are trying to make them into programmers, what are you going to have to do?

There are going to be four key characteristics if this is going to work:

• Rule maintenance must be presented as a business function
  • It cannot look like they are being made to maintain code
  • It cannot look like it was designed for IT people
  • It must look like they are doing what they want to do - changing the way their business runs
• The environment for rule maintenance must be familiar
  • Browser-based
  • As intuitive as possible
  • Uses the same layout and style as other systems they use routinely
  • Uses their terminology and expectations, not the rule engine's
• The process of rule maintenance must be integrated with other systems used by the business people
  • It should seem like a seamless process to go from a task to changing the rules
  • It should let them do rule editing when it makes sense for the user
• The whole thing must be secure & controlled
  • Audit trails
  • Release management
  • Security to prevent unauthorized changes
  • An environment that prevents them from making errors in the editing of rules

All of this means you need templates. Only well designed templates can provide the control and security you want before non-programmers start changing a system while also allowing enough control over how the user interface looks to convince users they are just doing their job, not their IT department's.In the end it comes down to this.

No business user is going to maintain this:

public class Application { private Customer customers[]; private Customer goldCustomers[]; ... public void checkOrder() { for (int i = 0; i < numCustomers; i++) { Customer aCustomer = customers[i]; if (aCustomer.checkIfGold()) { numGoldCustomers++; goldCustomers[numGoldCustomers] = aCustomer; if (aCustomer.getCurrentOrder().getAmount() > 100000) aCustomer.setSpecialDiscount (0.05); } } }

They might maintain this:

If customer is GoldCustomer and Home_ Equity_Loan_Value is more than $100,000 then college_loan_discount = 0.5%

But what they really want to do is see something like this:

College Loan Discounts Current Discount = [0.5]% Eligibility: <Gold Customer> and Home Equity Loan <more than> [$100,000]

Where the [numbers] are editable and the <lists> can be selected easily.