1. Introduction

In the spring of 1999, Weir Pumps -- Scotland's largest engineering company and a major player in the pump manufacturing industry -- set out to improve its return on investment in its standard product range.  The objective was simple enough, to increase revenue from an existing product range, but the method was -- within the framework of the company -- revolutionary.  We set out to configure the standard range product line and the full scope of supply that embraced it.  A secondary objective (although not necessarily so in the eyes of I.T.) was to market the product using the power and flexibility of the internet.

This paper tells the story of how the development evolved and how, ultimately, it led us to Business Rules, a concept that is now taking root in the engineering infrastructure of the company.

The application is a web-based expert system, based upon the principles of Configuration.  From the start, the application derived much of its functionality from the database and we recognised from the outset that this project was a little different from traditional I.T. developments.  In early presentations about our work, we used to present the business model as in Figure 1.

Figure 1. Presentation of the Business Model

2. Ownership

When any business enters into the process of configuration, it does so on the understanding that the business itself accepts responsibility for the knowledge that is spread throughout the organisation.  In short, the business is waking up to the realisation that ownership of information is crucial to making the whole process work.  It is unfortunate that throughout the relatively short life of the I.T. industry, information (or data as many users prefer to call it) is the responsibility of the I.T. department, and when something is found to be wrong with the data then it is the I.T. department's problem.  The principles of configuration challenge this theory to the core and in our experience, this illusion --that the data belongs to I.T.-- has been the biggest single obstacle on the path towards progress.  We found that the configuration process was concerned as much with the ownership of the data as it was with identifying what was required to be configured in the first place.

It also became clear during the early days that business terminology itself was open to ambiguous interpretation.  A prime example was in the way we priced a pump.  The sales and marketing department understood the process in one way whilst the finance department understood it in another.  Only when we brought the 'experts' together to define a standard data model did we expose the flaws in both sides' thinking.

Hindsight is a wonderful thing.  When we set out on the road to configuration, we thought that configuration meant little more than the pump (and perhaps the motor).  Little did we realise at that time that we should also configure the commercial activities of the company, the finishing and delivery activities, the documentation that goes out with the product, quality control and testing, etc., etc.  In fact, everywhere we looked we found something important that could contribute to our configured model.  In time, we recognised that anything outward facing to the end user of that facility was a candidate for configuration.  Alternatively, looking at it from the user's perspective, anything of importance to the user requires it to be configured, and that is why so many different aspects of the full scope of supply fell under the spotlight of configuration.

Having decided on the requirement and having configured the full scope of supply, we then set about defining useful outputs.  Our objective throughout was to ensure that the power and flexibility of the business model remained with the users (who owned it), and it was chiefly because of this objective that we embarked on a process of creating soft coded rules (owned by the business) in place of traditional program code.  As we later discovered, a common business rule engine operating on a diverse set of business rules offers a very powerful way of capturing (and documenting) knowledge within the business.

3. Configuration

Configuration is the process of tree-mapping the business in order to identify Things of Significance that contain Features that have Options.

Each leaf on the tree map represents a configurable Thing Of Significance of the business.  For example, Figure 2 shows a tree map of the full scope of supply of a product sale:  Commercial, the Pump, the Motor, Finishing & Delivery, and Testing are all Things Of Significance.

Figure 2. Tree map of Product Sale's Scope of Supply

A feature is an aspect of a Thing Of Significance that is important to its user.  It is something against which the user selects an option.  Figure 3 gives an example of the features for the Thing Of Significance pump.

Figure 3. Features for Pump

Features contain options and an option is selected against each feature (normally by the user but occasionally [automatically] by the system).  Figure 4 gives examples of options for the Feature pump arrangement.

Figure 4. Example of options for a feature

4. System Components

The system employs a flexible design based on rules and hierarchies.  The structure of the entire system is based upon the following simple concepts:

• A central reference library
• Things Of Significance, Features, and Options
• Parent/Child Relationships
• Exclusion Rules
• Business Rules
• Standard Options

4.1 Central Reference Library

*/ ?>

As in any information system, we make extensive use of static reference information.  Instead of capturing each distinct data set in its own table, however, we use a central repository, subdivided into specific types.  Experience has taught us that this approach means less clutter and stronger typing of data, itself a strong feature of our system.

Figure 5. Separation of reference types from reference data sets

Reference data sets are of reference types.  The types are defined as reference_types whilst the data sets themselves are stored in a single reference_table.

4.2 Things Of Significance, Features, and Options

*/ ?>

The physical instances of Things Of Significance (TOS), Features, and Feature Options are dynamic representations of the Configuration principles outlined in section 2.  There is no need for further explanation at this point, other than to say that each TOS, Feature, and Option is assigned a unique identifier within the overall system.

4.3 Parent/Child Relationships

*/ ?>

A parent/child relationship offers huge flexibility in designing complex information structures  In our development, both the parent and the child have an associated type that can either be the same or different, and the child can itself be a parent of further children of the same or different types.  Relationships can be of infinite length.

By offering both child typing and child sequencing, we are able to promote generic processing using a common Business Rule Engine.  In situations where it would normally be necessary to code loops via traditional program code, we offer the system designer the opportunity to build recursive solutions merely by pointing the relevant data to its next target.  In our model, the data drives the code rather than the (more traditional) other way around.

Figure 6 gives an example for deriving a product-specific pump component code:

Figure 6. Deriving a product-specific pump component code

4.4 Exclusion Rules

*/ ?>

Exclusion rules are a special case of business rules and are used as a means of restricting the options offered for a feature, based upon one or more options previously chosen (or automatically selected) for other options.

We make extensive use of exclusion rules in order to offer bespoke feature option lists to individual users and to ensure the consistency of the data.  For example, by nominating users as options of a feature user role, the system can filter out specific options from selected users.

Figure 7 depicts that option 1101 from feature 1003 cannot be selected with options 1211-1216 from feature 1008.  Therefore, whenever the user selects option 1101, the system selects option 1243 automatically on the grounds that there are no alternatives.

Figure 7. Example of exclusion rules

4.5 Translation Tables

*/ ?>

From the outset we had a need to derive data from a wide range of sources and to use that data in a structured way.  For example, in order to derive a unique support arrangement on a pump, we needed to use information about the pump, the motor, and the coupling arrangement in the lookup.  Having obtained the support arrangement, we then used that along with the size of both the pump and the motor, plus the rotation of the shaft, to derive a sketch from the library of sketches.  Then, having obtained a sketch, we used that -- along with codes, operands, and operators -- to derive the exact dimensions for presentation on the sketch.

At the time, each lookup referenced its own table with its own primary key using its own bespoke program logic to perform the lookup.  It was traditional application programming using relational technology.  By the time we had around 30 such tables, maintenance was becoming a problem.  Each time the business required a change to the way a piece of business logic operated -- for example, if a new selection criterion was introduced to a lookup -- we had to change the structure of the data and the form that went with it.

The light came on (if that is the right phrase to use) when we attempted to generate bespoke Parts List codes according to a set of feature options that the user had selected during the configuration process.  Suddenly, our lookup architecture was found wanting as the number of input parameters driving each output character was dynamically variable and none of the data structures that we had was suitable for the job.

Given that we operate on an Oracle relational database, we took the opportunity to construct the parts list table as a vertical structure (as opposed to the flat, horizontal structures of our existing lookup tables).  Each (variable) set of input parameters could now exist as rows of data, free from the constraints of fixed table design.  The next step was to find a way of processing variable numbers of input parameters against the table.  Easy … Dynamic SQL.  Our first rule engine accepted any number of input parameters and then constructed the SQL with which to lookup the rule table at run time.  Not only did it work but it performed admirably.  We were suddenly able to generate Parts Lists at the touch of a button from upstream tendering, all in a matter of seconds.

For students who experienced the delights of COBOL during their formative years, you will recognise our implementation of fixed and optional elements within a single parts list code.  In very much the same way as COBOL variable length records demanded a fixed portion at the head of each record structure, the optional elements of our code are dependent upon the fixed portion and hence upon the rules that generated it.

"So if it works for Parts Lists, it'll work for all of the other lookups," we thought to ourselves.  So we set about defining rule groups for each of the 30 or so static translation tables and turned each into a vertical, open-ended rule stack.  We evolved the rule engine to cope with partially-specified rules (rules where, say, six parameters are defined in the rule but less than that number are actually supplied at run time, allowing the application to perform filtering on the output side of the rule).

In effect, we had performed the following transformation shown in Figure 8.

Figure 8. Example of translation tables

4.6 Business Rules

*/ ?>

Whilst our use of rules was not new, the introduction of business rules represented a major step forward in the development of a generic business model.  Our implementation is based around a number of related database tables, some of which were introduced earlier:

• Reference Types
• Reference Tables
• Parent/Child
• Business Rules
• Standard Options (default values applied automatically by the system)

A 'business rule' is defined as a unique type in reference_types then the individual rule groups (of that type) are defined in reference_tables.  The system can contain an infinite number of business rule groups.

Each rule is based upon the principle that some combination of events (in this case, feature options) can combine together to cause another event, or series of events, to happen.  If the output event is a parent, then each of its children is invoked in turn, some of which may make further calls to additional business rules.  In what is effectively an object-oriented approach, business rules are accessed via a generic rule engine that is intended to provide the sole interface between the rules and the calling application modules (i.e., no application program calls the rules table directly).  The power of business rules is unlimited, and they are used within our application to provide the following diverse functionality:

• Bespoke navigation from one screen to another based on the user's security role and data already entered
• Bespoke features (and options) presented on a screen based on the user's security role and data entered
• Automatic population of default values on each screen based on previously entered data
• Generation of the components on a pump
• Generation of the Parts List configuration code for a pump
• Generation of the support arrangement for a pump
• Generation of the GA sketch for a pump
• Generation of the dimensions for the selected sketch
• Generation of the designated motor manufacturers for a pump
• Generation of the relevant motor for a pump
• Generation of the relevant coupling manufacturer for a pump/motor
• Generation of the relevant coupling for a pump/motor
• Generation of the relevant guard for a coupling
• Generation of the efficiency adjustments for a pump
• Generation of the relevant test area for a pump
• Generation of the relevant test quantities for a set of pumps
• Generation of the testing for a pump
• Generation of the overhead rates for a pump
• Generation of the production variants for a pump
• Generation of the price of a pump
• Generation of the product description sentences for a pump
• Generation of the relevant quality plans for a tender
• Generation of the relevant insurance premium ratings for a tender

In total, we have almost 5,000 distinct classes of rule (each class performs a specific function within the application), and we have 130,000 distinct business rules (each class of rules may contain many individual rules).

Each business rule set may contain several individual rows of data that are joined by 'AND' or 'OR' conditions to form a single composite rule.  Do not be fooled into believing that the following pseudo-code is actually code from a program.  These rules are stored as data in the database and processed by the business rule engine.  For example:

rule 1
if feature option 1102 has been selected for feature 501 and
feature option 1112-1140 has been selected for feature 503
  then
    perform action 15046 (which sets the appropriate overhead rate)

alternatively…

rule 2
if feature option 2228 has been selected for feature 506 or
feature option 2236 has been selected for feature 508
  then
    perform standard option 251097 (which sets a default value)

AND and OR rules may also be combined in a single rule:

rule 3
if feature option 8105 has been selected for feature 8005 or
feature option 8107-8109 has been selected for feature 8005 or
feature option 8110-8112 has been selected for feature 8005 or
[feature option 10727 has been selected for feature 10614 and
feature option 37025 has been selected for feature 36038 and
feature option 200005 has been selected for feature 200002]
  then
    perform parent action 282029 (which performs some Java functionality and screen navigation using parent/child technology)

However we also have rules of the form:

rule 4
if feature option 1259 has been selected for feature 501 and
feature option 1112-1140 has been selected for feature 503
  then
    perform action 15046 (which sets the appropriate overhead rate)

Do not be misled into thinking that rule 1 and rule 4 can be combined into a rule of the following form:

if feature option 1102 has been selected for feature 501 or
feature option 1259 has been selected for feature 501 and
feature option 1112-1140 has been selected for feature 503
  then
    perform action 15046 (which sets the appropriate overhead rate)

Firstly, the two separate rules may invoke different results, which would certainly preclude them from being merged into a single rule.  The main reason they cannot be joined, however, comes from the condition associated with feature option 1259.  What is this rule actually saying?  As 'AND' binds more tightly than 'OR,' this rule would be satisfied if feature option 1102 has been selected for feature 501, irrespective of what has been selected for feature 503. This clearly contravenes rule 1.  If we were to change the 'AND' to an 'OR' condition, then the outcome would be even worse since the rule would be satisfied if either 1102 or 1259 was selected for feature 501, or 1112-1140 was selected for feature 503. That clearly violates both rules.

Business rules can be as powerful and as clever as the application designer wants them to be.  Consider the following example:

if feature option 1207 has been selected for feature 505 and
feature option 1217 has been selected for feature 507 and
feature option 1262 has been selected for feature 509 then
  generate pump component 2587

if feature option 1207 has been selected for feature 505 and
feature option 1218-1221 has been selected for feature 507 and
feature option 1231-1232 has been selected for feature 509 then
  generate pump component 2634

if feature option 1207 has been selected for feature 505 and
feature option 1218-1221 has been selected for feature 507 and
feature option 1233 has been selected for feature 509 then
  generate pump component 2641

if feature option 1207 has been selected for feature 505 and
feature option 1218-1221 has been selected for feature 507 and
feature option 1234 has been selected for feature 509 then
  generate pump component 2648

If we interrogate the business rules by offering 1207, 1217, and 1262 as input parameters to the rule engine, we will receive back an output result of 2587.  Similarly, if we offer inputs of 1207, 1219, and 1231, we will receive back 2634. 

But what if we offer only 1207 and 1218?  The result will depend on the type of call, and this introduces a new dimension to the use of the rules.  If we offer 1207 and 1218 as input parameters with ANY type of rule match, then we will receive back 2634, 2641, and 2648, since all three rules satisfy the input conditions.  However, if we make the same call with an ALL type of rule match, then no rule is satisfied since three parameters are required to satisfy a rule, but only two have been supplied.

By supporting ANY and ALL types of calls, the business rule method effectively allows the calling application modules to be as specific or general as they desire in order to achieve their business objective.

4.7 Stacking the Rules

*/ ?>

By 'stacking' calls to the rule engine on top of each other, we have been able to implement some very complex engineering solutions through data modelling.  For example, the following steps are required in order to derive a specific motor for use with a pump that has been previously selected and configured:

1. Find the impeller material

2. Find the motor speed

3. Find the bearing bracket size

4. Find the shaft pointer

5. Find the motor power range

6. Find the absorbed power

7. Select the motor

In a traditional programming language, this would have achieved by a number of calculations built into the program, thereby making the logic difficult for engineering users to access and hence difficult to maintain.

We implemented a solution using stacked rule calls to the business rule engine, as shown in Figure 9.

Figure 9. Stacked rule calls in the business rule engine

In this example, each call supplies input parameters to the business rule engine and receives back one or more responses.  Each output response is of a known type.  Each successive call merges those outputs with further inputs until the final desired output (the motor) is known.  In every case, the rule engine acts as a 'black box,' taking inputs, processing them against the rule base, then handing back the result.  The rules themselves act as documentation of the company's engineering operation and, as such, are available as data for maintenance by engineers.

4.8 Standard Options

*/ ?>

Standard Options offer a method of implementing default values for features and options.  Here are some classic examples of their use:

• Static default selection of an item from a picklist
• Dynamic default selection of an item from a picklist based on selections already made
• Automatic selection of options for multiple (ranged) features
• Automatic selection of different options based on business rules
• Automatic selection of predefined 'free text' values against a one or more features

5. Memory Resident Business Rules

Whilst dynamic SQL served our purpose in the early days of writing business rules, two things quickly became apparent:

• As we added more rules, performance was bound to suffer due to the overhead of parsing and executing the SQL for each request.

• The same common lookups were appearing over and over again in different rule groups.  This was a necessity whilst we were using translation tables but in the business rules environment, redundancy proliferated.

We therefore set out to find a method of eradicating the redundancy whilst retaining the existing functionality, and it was this methodology that led us to employ memory-resident tables in order to maintain run-time performance at its former level.

The trick was to specify each business rule through a parent/child relationship and to have the children point to unique lookups within each rule.

For example:

In Figure 10, we have the original definition of a set of business rules that were processed by dynamic SQL.

Figure 10. A set of business rules processed by dynamic SQL

In order to process these rules as memory resident tables, we must first separate the rules using the parent/child and business rule methodology.  In doing so we have moved the join condition from the business rule to the parent/child and introduced the concept of a rule family.  All of the elements in the original business rule are redefined as a single family in parent/child and the family has a single output row (of lookup type parent) in the new business rule table.  Each unique element of the business rule is defined with its own business rule id (previously, all elements in a rule shared a common business rule id).

Figure 11. Introducing a Business Rule Family

Having defined the rule families, we now need to establish the relationship between rules and families in order to maximise run-time performance.  Using the example in Figure 11, we develop the relationships shown in Figure 12.

Figure 12. Relating Rules to Rule Families

When the rule engine is called, it performs the following functions:

1. Build a list of business rules (it's actually a table held in memory, indexed by the business rule id) that satisfy each individual input parameter.

2. For each matching business rule (from step 1), get the rule pointer for each rule and follow the business rule pointer chain in order to build a list of families (indexed by the family id) that include those business rules.  Maintain a counter with each family that specifies the number of business rules that have selected this family during step 2.  Note than each chain is terminated by a zero in the 'next pointer' column.

3. Look through the list of matching families, searching for any family whose number of matching rules (i.e., the count from step 2) is the same as the number of business rules in that family (i.e., this is a fully satisfied rule family).  Such a family is deemed to have satisfied the business rule, and the output action defined against the family in business rules is to be performed.

Copies of the business rule pointer table and the business rule pointer chain are stored in the Oracle database and uploaded into memory when the database is loaded.  The business rule engine then operates against the memory resident tables.

6. User Interface

The user interface is defined by navigation and display.  Navigation determines the sequence in which screens are visited whilst display determines what is shown on each screen.  Both navigation and display are controlled by business rules.

6.1 Navigation

*/ ?>

Whilst the presentation layer of the application is built upon Java, navigation is controlled by business rules, thereby removing the need for application-specific menus.  The procedure starts off by defining feature options to represent entry and exit in each screen, as illustrated in Figure 13.

Figure 13. Defining feature options to represent screen entry and exit

Business rules are then used to control not only the navigation between screens but also any additional processing that is required to be performed (in the correct sequence) along the way:

if feature option 37001 has been selected for feature 36026 and
feature option 200003 has been selected for feature 200002 then
  perform parent action 282001….

which in turn invokes …

• standard option 290001 (which sets a default value)
• standard option 290100 (which sets another default value)
• a Java Server Page
• a user feature on the new page
• a named Java Servlet

Navigation is enabled by the use of passports.  Just as in real life, the users's passport is updated to reflect the current location (i.e., screen).  If the user leaves the system abnormally (by a system crash or other unexpected error), this will be detected at the next login and the user will be positioned back into the most recently visited screen.  All transaction data is committed on moving from one screen to the next so data loss in the event of an error is minimal .

6.2 Display

*/ ?>

Each screen in the system is defined as both a feature (of the Thing Of Significance Presentation) and a display group.  When the user arrives at a screen (i.e., the rule engine has selected that screen for display), each business rule defined within the display group is executed.  Only those features whose business rules evaluate to true are displayed to the user. 

Figure 14 gives an example for the pump configuration screen (36026).  Display Id 436 is a heading that appears on the first row if rule 16014 is satisfied.  On each subsequent row, one of two display ids is presented, depending on the relevant business rules.  In fact, the questions are very similar but relate to different ranges of pumps.

Figure 14. Example of screen display rules for a display group

In the same way that business rules are used to dictate the questions on each screen, additional business rules are used to filter the feature option against each question.  The output action against each display id's business rule is a parent/child action whose children include a feature option business rule.

7. Application Overview

Figure 15 gives an overview of the entire business model.

Figure 15. Overview of the entire business model

Figure 16 depicts tendering for standard products.

Figure 16. Tendering for standard products

Figure 17 depicts potential applications for the future.

Figure 17. Potential applications for the future

8. Security

System security in is also implemented via business rules and user features (Figure 18).  By introducing security feature options into navigation business rules, the application designer has the power to navigate users around the system in a controlled manner.

Figure 18. Implementation of system security

Business rules also persist within each screen.  Suppose we have a screen containing ten pieces of information, only six of which are relevant to a salesman.  Alongside the definition of each piece of information is a business rule that defines one or more security roles (defined as feature options).  Consequently, business rules have a fundamental role in deciding not only where users go within the system but what gets displayed once they get there.

It is important to remember that none of this functionality requires the application designer to write any additional program code.  The designer needs only to define the rules.  The Business Rule Engine and the Java front-end take care of the rest.

# # #