One reader sent me an e-mail asking about how to move from program code based rating to rules-based rating. Another reader asked me to contrast the benefits of table-driven rating versus rules based rating.

She asked:

Rules-based Rating. Seems to be the hot buzzword on the street, but not a lot of meat around it. Would like to understand: what providers really need it for what markets are affected and evaluate benefit of table-driven rating vs. rules-based rating.

The following answers some of their questions.

First Some Definitions.

Program code based rating n. the process of rating transactions where the information on how to rate a transaction is represented in program code and any tables of data are defined in the program code. Also know as process-based rating.

Table-driven Rating n. the process of rating transactions where there are one or more tables of data that encode different rating cases and the amounts to use in calculating the charge. These tables are stored outside of the program code so that the rating behavior can be changed without the program being modified.

Rule-based Rating n. the process of rating transactions where the information on how to calculate the charge is stored as rules which are processed by the rating code. The rules are usually stored as a table, but this table encodes the rating process steps (the algorithm) in addition to the definition of the rating cases and the amounts to use in calculating.

Rating Case n. the condition or conditions when a specific set of rate values apply.

Program Code Based Rating

Program code based rating is the method used for the earliest rating software that was implemented. There are companies still running this kind of software from more than 20 years ago. This kind of rating is normally the fastest in production because it involves little disk I-O and is compiled code rather than interpreted code.

IF RATE-PLAN EQUALS "MEGABYTE CHARGING"

THEN MULTIPLY MEGABYTES-TRANSFERRED BY 0.023 GIVING CHARGE-AMOUNT.

Figure 1. COBOL code to calculate the charge for a data transfer

Program code based rating must be created and maintained by programmers. Its problem is a side effect of the behavior of programmers. Most programs start out with a coherent style and structure. So long as the same programmer works on the software, the style and structure remains consistent and the costs of changing it remain low. The reality of software development is that new programmers often take over development and maintenance from the original programmers.

When your rating process is encoded in programming code, it is difficult for each new programmer to understand the meaning of the algorithm. This difficulty increases the amount of hours that you must spend before you can confidently change your rating process. When a change is requested, each programmer must first understand the code and then change it.

Most programmers are under pressure to do their work quickly. The amount of work involved in confidently understanding the existing rating program code causes programmers to insert code that is not coherent with the existing code. The programmer puts in code that is certain to get the desired results, but increases the complexity of the code. Each time that additional non-coherent code is added, the program complexity multiplies. Over time, programmers throw up their hands in disgust at the difficulty of modifying the program and urge management to rewrite the program.

This problem is true for all parts of your data processing, but the cost of misunderstanding the rating code is huge by comparison to other portions of any program. This code handles millions of money transactions. Even tiny errors turn into significant amounts of money when multiplied by a million.

Table-driven Rating

Over the last twenty years, many companies have sought to make it easier to control this difficulty by encoding their rate algorithm in tables. This permits you to encode the parameters of how to rate transactions in the table. Process code still exists, but its functional meaning is more clearly defined and it is easier to program and maintain. If you need to add a new rate plan, most of the time you can encode it in the table. This means you still change the program code, but less frequently. Less changes mean the code remains coherent longer and lengthens the lifetime of the rating code. You also are more likely to be able to define the functionality of the new program code clearly Table-driven rating is a big step forward.

Figure 2. An example table of rate information for a table-driven rating process

Each column in the table represents a data element that needed for the rating process. Each row represents a rating case that can apply. The problem that arises with table-driven rating algorithms is the static size and form of the tables. They become a problem when dealing with the continuing changes in rating plans. As marketing organizations struggle to find new algorithms that connect with customer value, they make up new methods of rating and then discard them when they fail to capture the market's attention. With each new way of rating, new kinds of information are needed in the table and new columns are created in the table. Since all of the rating code use the table, you end up with changes needed in all the code when you add new columns. Further, you will often add a column and then months later stop using it. It often means that you add columns, use them for awhile, and then will not be able to remove them for fear of dislocating other rate plans or program code.

The Gilded Cage Solution

The problems above can be handled with well-trained and disciplined programmers. A big part of the problem is the programmers. The best path for the company is to train their programmers for the rating code and then keep them on the job working with the rating code FOREVER. That solution isn't attractive for the programmer himself. Programmers rarely want this kind of a gilded cage where they are invaluable, but never allowed to stray from their assignment.

Since most companies can't afford to pay what it takes to keep their programmers in a gilded cage and many programmers can't be kept, a solution of rule-based rating is attractive.

Rule-Based Rating

Rule-based rating is program code based rating reborn. In this case you have a structure, the rating engine, where a rating oriented programming language is hosted. This is a simple language focused on the business problem. Usually a business/tariff analyst can learn the language in five days. Each rating plan can be programmed in a higher-level language oriented to the rating process. You can take advantage of well-tested underlying code (like a table-driven rating process) while defining the rate plan in language more easily understood by the marketing organization.

Figure 3. An example of rule-based rating plan using our Ratchet Rating System

Rule-based rating uses more computer power than code based rating. Program code based rating is compiled. Rule-based rating is interpreted. This performance difference has become unimportant, despite increasing transactions loads, because the power of today's computer have increased so dramatically from earlier machines.

This makes it possible for the rate plan development to be done by business/rating analysts rather than programmers. By changing the people involved from programmers (who seek skill development and opportunities to develop sexy programs) to business or rating analysts (who value order and control and who are more interested in business goals), you solve the problem of the gilded cage. You also reduce the amount of training needed to manage the rate plans and rating processes.

So you can see that with this investment in technology (rule-based rating), you gain the ability to solve organizational problems.

Summary

All three kinds of rating can be successful, but each version has its costs and limitations. I believe that the best route today is rule-based rating for its flexibility and its ability to widen the number of people in your organization that can understand and modify the rate plan information. It requires more computer power to process transactions, but this has become a cheap resource to consume.

	Positive features	Negative features
Program Code based rating	Fastest execution time Requires only enough programming effort to implement your specific rate plans. It can use any information in your transactions to calculate the charge.	Requires programmers to study the code thoroughly before any changes can be made. Can become messy after several programmers change it; even bad enough to require a complete rewrite. Can only use the inputs programmed into your rating processes.
Table-based rating	If the algorithm and type of inputs to the algorithm remain the same, business analysts can change rate plans without a programmer.	The structure of the table limits your flexibility. If you need to process the data differently or include new kinds of information, then you have all the problems of program code based rating. Can only use the inputs programmed into your rating processes.
Rule-based rating	Supports the creation and maintenance of rating algorithms and rate plans by business/tariff analysts (no programmer needed) It can use any information in your transactions to calculate the charge. Can use all the input fields in the rating rules.	Slowest execution time Involves a major investment in programming because you create a language for the description and implementation of rate plans.

 

Tell Me What You Want To Hear About

The subjects that I cover in Rating Matters are driven by my personal interests in rating and billing. These are limited by the breadth of my personal experience. Please let me know about items you want to hear about or you'd like explored further. Send me your requests at .

Subscription Management

To add a subscription, click here to fill out a form. To delete a subscription, click here to delete. Thanks.

©Copyright 2002 Service Level LLC
Rating Matters is a trademark of Service Level LLC