In May and July of 2000, Java Developer's Journal (Vol. 5, issues 5 and 7) ran a two-part article on how business rules can be implemented in Java. To recap, business rules are a formalized representation of the policies, practices, and procedures of an organization, describing how business should be conducted under any particular set of conditions. Business rules aren't a programming concept but rather a business concept. The business rules of an organization may be contained in policy manuals, memos to employees, unwritten "tips and tricks" passed from employee to employee, or lines of program code spread among various applications serving different business needs.

The use of specialized business rule authoring/execution environments with independent rule repositories was introduced as a way to gain more control, consistency, and reuse of business rules throughout the automated systems of an enterprise. Business rules can be applied to Web-based interactive systems, and this is often the easiest way to grasp representative application examples. For instance, Web-based merchandising rules may decide the best products to display and promote to an individual shopper and the proper pricing and discounts to offer on an order. However, many other uses of business rules affect back-office processing or interactive system behavior via communications channels such as automated phone systems, electronic kiosks, wireless devices, and live customer agent support. (these channels are often referred to as "touchpoints" since they describe various means by which an end user can "touch" the enterprise.) It's also valuable to remember that rules may affect interactions not only with customers of an organization, but with its employees, suppliers, business partners, and the general public.

The previous JDJ articles mentioned products such as Blaze Advisor from Blaze Software (now a part of Brokat Technologies), JRules from ILOG, and Jess from Sandia National Laboratories as tools companies can use to implement business rules in Java applications. This article explores the representation of business rules and data objects, and focuses on how rule objects interface with external systems. We also examine issues in usability for nontechnical employees charged with updating business policies and operational logic in their organizations.

Using Objects in Rules
As shown in previous articles, business rules can easily be thought of in terms of if-THEN declarative statements, pairing a specific condition set with a desired action:

IF Amount of Order > $100
THEN Discount = 5%.

For instance, to the layman, a yellow tennis ball and a white tennis ball are two distinct objects, each having a physical manifestation independent of the other. Making the conceptual leap to each being an instance of a single object type with varying property values is a training exercise. It gets even worse when dealing with intangible process concepts, such as "the ExecutionPriority of a CollectionEvent."

Thus dealing with object and property definitions in business rule systems is a two-sided problem. Any company using formalized systems will already have created object definitions to represent the data being manipulated. Installing a new piece of software, such as a business rule engine, requires the programming staff to define the company's existing object representations in the proprietary framework of the new software. And because business rules are intended to be exposed to the business users, those users must have a familiar way to understand, use, and manipulate these objects. Most corporate IT departments are responsible for a variety of systems written in different languages, incorporating various third-party software packages produced at different times, and making use of object definitions originating in Java, databases, CORBA, COM, XML, and other formats. An attempt to rely exclusively on any one of these object representations by a new vendor is likely to cause implementation difficulties and delays. The approach favored by many successful business rule software vendors is to create a proprietary internal object representation and use utilities to map to external business object models.

As a demonstration of this approach, Figure 1 shows an object model import wizard from Brokat Technologies' Blaze Advisor. The utility has been given the name of an external Java class and has generated a table showing all the object and property definitions the class contains. The implementation specialist may include or omit individual properties (and Java methods, if desired) to be made referable from within the business rules. Individual properties may be renamed for use within business rules in order to make them more convenient to write or more understandable for business use.

Importing external object model definitions and mapping to internal representations enhances efficiency and speed in implementing the new business rule system. Object models need not be manually printed out, checked for type definitions, and recoded by hand in a proprietary language. Organizations looking to integrate business rules into their operations should look for smooth mapping and integration facilities for whatever object model representations they use.

A similar object model mapping can be used for external database definitions. In the Java world, JDBC connections interface with database tables (see Figure 2). Columns may be identified from a single table or from multiple tables, and SQL-formatted WHERE statements can be used to identify specific instance inclusions, joins between tables, and other data restrictions (see Figure 3).

Once object/property definitions have been imported, business rule authors may wish to create subclassed objects for use within their business rules. For instance, a finance company may have a Loan object defined in their general business systems. But for writing business rules dealing with automobile purchases, they want to define a special CarLoan object, inheriting the properties of Loan (see Figure 4).

This may be accomplished through graphical editors, filling in new property names and types in a form template, or through simplified code constructs such as:

A CarLoan is a Loan with
{ an odometerReading : an integer,
a dealerName : a string }
initially { odometerReading = 0 }

Remember that a business rule service is one component of an overall application. Depending on the application, the rule service may be explicitly called in order to make a logic-based decision, monitor events, and wait for a trigger to stimulate rule firing, or to create an external event to obtain additional information needed for processing. With mapped data objects, the business rule engine can interact in any of these sample use case scenarios:

1. Application: Instantiates data in a customer object and a loan application object. Should I approve, decline, or refer the application?
2. Rule Engine: Return an answer of approve/decline/refer.

1. Application: Starts the rule service to monitor external competitor's price object.
2. Rule Engine: Whenever competitor's price changes, fire rules to potentially update our price and discount business objects for use by all systems.

1. Application: Updates customer age object value and continues rule processing.
2. Rule Engine: To continue processing, a value for customer age is required. Retrieve the value from an external database table or have the application prompt the user.

Business Person Interaction with Rule Objects
The preceding sections dealt with the mechanical linkage of objects in a business rule package with external data systems. These are concerns for the technical implementation personnel at a company. Once the IT department has created definitions and linkages for their business objects, the question becomes: How can the objects be manipulated to drive business processes? It's then an issue for the business-level personnel at the company.

System development and maintenance has traditionally taken the form of IT personnel creating system requirements definitions through a process of interviews and cooperative work sessions with the business users of the proposed system. As development progresses and the system becomes more tangible and well understood, the business people often think of new exception cases, additional uses in new scenarios, or refinements to their original logic. Integrating logic changes into system programming can be laborious and time-consuming. Once the system is completed and in place, external and internal business factors may require periodic updates to the business logic in the form of new decision conditions and results.

Examples are endless. Merchandisers may vary product discounts based on supply and inventory considerations. Financial institutions may change interest rates or information requirements based on new regulatory mandates. Human Resources policies may affect employee benefits based on organizational changes or management discretion.

In all such cases a delay between making the business decision and having it reflected consistently throughout all corporate information systems is costly, frustrating, and sometimes even legally actionable. IT departments may be called upon repeatedly to make small changes to systems, taking their concentration and resources away from other system development tasks. Conflicts arise with IT managers trying to create structured work processes and release schedules while business management attempts to react swiftly to new business conditions.

Business rule systems were created to centralize the business logic aspects of automated systems and separate them from the underlying infrastructure of the systems' operation. In this way, rules can be changed to control conditional actions without affecting the overall programming code. If the rules are then exposed to the business decision makers themselves for maintenance and management within a constrained range of control, the IT department can be freed for major structural changes while the policy makers manage day-to-day business logic.

The structure for facilitating such logic separation has been implemented by most business rule software vendors. A centralized repository of rules, visible and alterable by the business owners, is common in such systems. The differentiator becomes the ease, speed, and security with which rules can be changed by nontechnical professionals.

Business rules are usually expressed in some structured language unique to the software vendor. As an example, in Jess from Sandia National Laboratories, a rule might be expressed in the following form:

Jess> (defrule CanPersonVote
(person (age ?x))
(test (< ?x 18))
=>
(printout t ?x " is a minor and may not vote"))

A business rule language should offer flexibility in authoring to suit various users' skills and comfort levels and should provide a natural link between a business concept and its formalization in the system. As an alternative example, here's the same rule code expressed in Blaze Advisor's structured rule language:

Rule CanPersonVote is
If person's age is less than 18
then print(the name of the person " is a minor and may not vote").

If customer.age > 16 then...
If the age of the customer is more than 16 then...
If customer's age exceeds 16 then...

Rule Maintenance Without Code
Even with more natural representations of business concepts in a business rule language, maintenance of the rules requires training in the specifics of that language, the use of some form of text editing environment, and exposure of the full rule syntax to the business policy maker. Maintenance personnel must also know the correct names of any objects and properties they wish to use in a rule. No matter how natural the names are, they can be overwhelming when dozens or even hundreds of names are sprinkled throughout a complex system. Business maintenance personnel have access to the entire rule, which could lead to undesired changes in the structure of the rule code, unauthorized changes to values they should not be altering, or simple mistakes due to unfamiliarity with the specific object and property names, or even from typographical errors.

The challenge for systems personnel is to build a stable system and then allow a specific subset of ongoing maintenance changes by the business units. Change should be controlled with authorizations, and the change process should insulate the maintenance personnel from process complexity and memorization. One approach is to allow rule developers to explicitly identify pieces of rules that should be exposed to business users for maintenance. These objects, conditions, or values may be constrained to a predefined set of allowed values, or may be left open for unrestricted input. Web pages are constructed using terminology and graphics that are familiar to the business policy makers, with replacement values presented as input fields. These may use fill-in-the-blank boxes or HTML features such as pull-down lists or radio buttons for entry. The use of password-enabled, Web page access security determines maintenance access, and rule changes can be tracked and authorized against an LDAP rule repository for check-in and checkout of rules.

As an example, let's use a generic merchandising rule:

Rule ProductDiscount is
If customer's age is more than 55
then discount = 0.05.

In the simplest form of maintenance, we might want to let the business unit change the amount of the discount given to our senior customers. We highlight the discount value and place it on a Web page, along with text that describes the use of the value. Note that we don't have to use any of the syntax of the rule itself. A JSP tag links the value entered on the Web page to the replacement point in the rule code (see Figure 5).

In a more complex example, we might make a generic template for defining discounts based on any one of a number of conditions:

Rule ProductDiscount is
If customer's age is more than 55
then discount = 0.05.

We can let the policy maker base the offered discount on one or more predefined properties for the customer object. (let's hope no merchandiser would actually base discounts on the criteria shown here!) He or she can also define the type of comparison operator, the comparison value and, of course, the discount amount. The rule-maintenance Web page might look like the one in Figure 6.

With a system such as this in place, maintenance personnel no longer have to remember proprietary syntax or object/property names. They can think purely in terms of the business decisions they're making. System developers can rest assured that the maintenance person can't make unauthorized changes, such as basing discounts on the customer's height or weight, or setting the action to apply a surcharge instead of a discount.

Summary
Business objects are a standard means for representing data in automated systems. Any company installing a business rule system should make sure that importation of existing object models is simplified and accelerated so they can quickly move to the core business task of writing the operational business rules. For business people to take advantage of the centralization and user maintenance of rules, they must be able to understand the objects and properties used in the business rules. Representation of rules should allow for flexibility in expression of these objects and companies should make sure that rule maintenance is practical on an ad hoc basis. This requires protecting the integrity of the rule structure while allowing business policy makers to make authorized changes in a comfortable and familiar manner without programming or training in specialized tools.