Introduction

You have hundreds or thousands of policies, procedures and regulations you must follow and that your business users understand. Unfortunately, it is often difficult to  communicate these guidelines effectively to programmers for implementation in corporate systems. Your business needs to change as circumstances demand and this means your systems must change too, something that is hard to do with traditional development approaches. There are clear and demonstrated benefits to using business rules to develop applications. Business rules are clearer, easier to write and verify, easier to change and easier to map to the business purpose of a system.
 

Business rules can be used to express policies, procedures, regulations much more clearly than procedural languages typically allow. This means that they are better understood by business users, resulting in fewer errors and more rapid development cycles. They can also be changed more easily and more rapidly than code, partly because they are easy to read and partly because they are declarative.
 

However, system developers still mostly write business rules as programming code in an “interview and interpret” cycle with the business people. This imposes delay and costs when rules must be changed, even if these delays and costs are lower than an equivalent change to a non-business rules system.
 

How can business users be given the power to change their own rules in the production systems developed for them -- and should they be given this power?
 
 

Rules Change Over Time
 

Before we can answer this we should consider why rules need to change. For every use of business rules there are different reasons why those rules might change over time. Here are a few examples:
 

• Because your business policies do
• Because your competitors do
• Because the law does
• Because stock levels do
• Because your customers do
• Because your customers’ needs do

One of more of these is likely to be true for any rules-based system. That said, not all rules need to change and those that do may have very different requirements and frequencies of updating.
 

Firstly, some business rules are more-or-less fixed. If the check’s status is “Bounced” then the invoice’s status is “unpaid” or If the delivery’s date is after the delivery’s schedule_date then the delivery’s status is “Late”. These rules express basic truisms of a company’s business.
 

Secondly, some don’t need to change very often. A change in these rules has widespread implications that make changing the rule the easy part. For instance, if we were to change a rule like If ordered_product is not in inventory_list then status of order is “Rejected” it would impact how orders are processed in a very broad way. Ease of changing this rule is therefore not going to make the business more responsive.
 

Thirdly, many rules do change a little - part of the rule varies or can be varied. These rules are very common – they are sometimes called parameterized rules. For example, If the driver’s age is greater than 70 and years_licensed is less than 5 then driver’s risk is “High”. In this case the values used to test age and driving experience may change as the company’s policies or actuarial data change but the basic structure of the rule is fixed.
 

Lastly there are some rules that need to change completely or often. These rules are dynamic, driven by rapidly changing circumstances and highly variable policies. For example, rules about cross-selling or up-selling such as If any item in shopping_cart is of type “foodstuff” then add “Yogurt” to promotion_items.
 
 

Business Users Should Maintain Rules
 

So, just because the rules are going to change doesn't necessarily explain why business user should be able to maintain their own rules. Surely IT staff could maintain the rules just the same way they maintain code - they would still get an improvement in time to change a system thanks to the increased editability of rules. But there are much greater benefits if business users maintain their own rules.
 

Firstly they understand why, how and when the rules should change. Unlike your programmers who would need to be told and then have the change explained to them and who are probably too busy to do anything about it until next quarter anyway.
 

Secondly business users are going to be the first to see that a business rule is hurting the business. Companies can be losing money, market share and customers every second a rule remains unchanged if a competitor implements a “nicer” one or if a change in the marketplace makes a rule out of date.
 

Thirdly the people who run the business typically have the specialized knowledge required to truly understand your business rules, enabling them to change the rule right the first time, reducing the introduction of new bugs and reducing testing and quality assurance costs.
 

In summary, business users should be able to change the rules for themselves because do this is cheaper, faster and less prone to error.

 

So what can we say about rule maintenance, what rules can we apply? In order for a business user to be a rule maintainer, they must have access to an application that allows them to edit rules, they must own at least one of these rules and they must understand the rules to which they have access. Unless all of these things are true then they will not be able to serve themselves – maintain their own rules.
 

If no-one who runs the business can change any of the rules then it is a safe bet that there is at least one change in the IT department’s change request log and that means that our rule base is out of date. Unless someone is a rule maintainer we will not be able to keep our rule base truly up to date. Equally we just give everyone access then we will get a tower of Babel – consistency will be lost, changes will conflict and it will be too easy to change the wrong rule in the wrong way.
 
 

To let the people who can and want to maintain their rules do so effectively we must provide those with the knowledge with access to the rules, an application to maintain them and the rights to edit them.
 
 
 

How do you develop self-service rule maintenance applications?
 

There are four basic choices for letting people edit rules for themselves - let’s examine each of these in turn.
 
 

Complete Rules Development Environment
 

The first option is to provide a complete rules development environment, like Blaze Advisor from FairIsaac. Such an environment has a number of characteristics. It is typically considered suitable for programmers or power-analysts and includes integrated supporting tools such as cross-reference checks between objects, conflict detection, debugging aids, etc. It is usually workstation-based, supporting local or LAN-connected development teams and provides a limited audience with high flexibility and extensive functionality.

Syntactic Editor
 

A syntactic editor, one that exposes the rules syntax for editing but provides some context-sensitive behavior, is our second choice and has a slightly different profile. It is intended to be accessible to more potential users, although this is still limited by the need to learn the syntax. It is somewhat easier to make available over the web to a dispersed team and can help users learn the syntax as they go by exposing the syntax to them. It needs strong context if lists of options are not to become unmanageable – simply making every rule, every condition and every action available will not work.

Rule Maintenance Application
 

A point-and-click interface – a rule maintenance application – is the third option. This has distinctly different characteristics. It can be a “zero-training" environment by taking advantage of the fact that users already know how to use web browsers, drop-down lists etc. It can use application logic to place conditional restrictions on different users, exposing different rules or rule components and making drop-down lists and other editing aids strongly context-sensitive to increase efficiency and decrease confusion. It can maximize utility to a broad audience by exposing as much or as little syntax as is desired in each case and it can be translated for multi-lingual support and customized to a familiar look and feel or integrated with other end-user applications.
 
 

Implicit Maintenance
 

Lastly rules can be maintained implicitly using embedded interfaces. These have a unique set of characteristics and are particularly useful in packaged products. They can allow for nonstandard interfaces to change rules (e.g. CAD systems) and for large volumes of rules to be changed from another system (e.g. parts database). They are expensive and time consuming to build, however.
 
 

Principles for Rule Maintenance Applications?
 

Regardless of the technology used to enable rule maintenance, several principles can be applied. We can ensure that the rules are presented in context and with maximum familiarity for a particular user. We can aim for simplicity in maintaining the rules and for reliability to ensure that changing rules is safe. Let's look at each of these.
 

Context
 

Business people do not want to “change rules” – they want to change their campaign, promote slow moving products, reduce their risk, increase the number of loans issued, and so on. This means that good rule maintenance applications are context-sensitive, in-process, and integrated with other application functions. They are also selective of which rules are exposed to which people. They are "Just part of doing business".
 

Familiarity
 

If business people are to take on rule maintenance, it is important that they don’t have to jump through too many hoops. A good rule maintenance application will use their terms, meet their expectations for a user interface, let them write rules against their “objects” and will not make them learn new syntax, editing styles, specialized terminology, etc.
 

Simplicity
 

Like any application, good rule maintenance applications must be as simple as possible and no simpler. They should be point-and-click, not scratch-and-think and use buttons, lists etc. They should present just what is needed and have many simple pages.
 

Reliability
 

The application must be reliable and must feel reliable. The application should not make your business user nervous and should prevent errors with controlled fields. It should use live data feeds from other systems to ensure timeliness and allow both instant and scheduled updates. Most important it must not impact a running system, not even on transactions that are underway.
 
 

Some Examples
 

Are companies actually building self-service rule maintenance applications today? Here are three examples.
 
 

Salesmation
 

Salesmation provides an ASP service for e-marketing. Business users control the logic that drives online marketing campaigns. It provides great context – rules editing is just part of setting up a campaign. It is very familiar to its users as it looks like the rest of the application and it has a very simple to use point-and-click interface. Lastly it is reliable as changes are applied to the correct company’s campaigns even though the server supports many companies. Changes may be applied instantly.
 

Business users select a campaign to edit and simple pages guide them through configuring the campaign. They use a simple point-and-click interface to change rules.
 
 

Compaq Zero-Latency Enterprise
 

Rules manage complex data-mining queries and automatically control the resulting actions depending on the query's findings while also giving the business manager hands-on control of the decision-making process. Compaq ZLE provides good context, giving users easy access to certain kinds of information about visitors. It is a fairly technical environment, but this is familiar to its fairly technical audience. It provides some simplicity by giving an easier way to create complex query setups than programming in system code and it is very reliable - changes are applied instantly and safely to all CORBA-based “agents” running on the Compaq Himalaya system.
 

Compaq ZLE uses a complete rules development environment and allows easy access to each visitor’s recent history as well as to demographics.
 
 

BEA Personalization Server
 

Uses rules to control personalization – delivery of information to a particular visitor is based on their predefined population segment and other characteristics. It is intended for a moderately technical audience: developers configuring the portal itself. The context here is excellent as it is all about personalization. The environment is very familiar as all configuration screens look similar. Pop up lists, drop down comparator selection etc. are used to make the interface very simple to use and the product is very reliable, being designed for widespread use in disparate environments.
 

Defining a segment using characteristics exposes the rule syntax while still providing some context-sensitive lists and menus.
 
 
 

Conclusion
 

So what can we learn about delivering self-service rule maintenance applications in the real world? Clearly there are many ways to give business owners access to their rules. However, true self-service rule maintenance requires four key features that should be designed into any corporate system:
 

• Context so that business users can change the rules as part of their normal work
• Familiarity so that they can learn to do this quickly
• Simplicity so that this maintenance work does not require an investment in education or training
• Reliability so that changes can be made whenever they need to without risk and without error

Rule maintenance must be thought of and designed as a complete application in its own right. To build a rules-based application without also building a complementary application to allow those who understand the business rules to maintain them is to fail to exploit business rules to their maximum potential.

# # #