Business Rule ADE

Terry Moriarty                

The great promise of applications built with the business-rule approach is that almost immediately after you establish a new rule, all the business’s organizations instantly respond…. The business systems automatically adapt to accommodate the new business rule. Policy manuals and help facilities change accordingly. The appropriate memos and emails go out to people who need notifying. And the application portfolio’s code and databases are updated, as necessary, to incorporate the new business rule. All at the push of a button. Yeah, right!

The true test of a business-rule product is the degree to which it can alter the operational environment so that the business behavior actually changes. It’s not enough to capture and classify business rules. To achieve the promise of the business-rule approach, the system must change when management releases new or enhanced business rules. Therefore, someone must consider the facilities provided to integrate the product into the organization’s application development environment.

Business Language Usage

The language of subject matter experts (SMEs) is the raw material. Business analysts must subject these initial business statements (in the form of ramblings) to analysis, restructuring into atomic business-rule statements, and classification. They then describe all the business concepts exposed during this discovery process in terms that are meaningful to the business.

Therefore, for a product to be considered a business-rule tool, it must let you express the business-rule statements in natural language and prevent IT-oriented names from creeping in. For example, suppose the SMEs identify Customer Portfolio’s Average 12-Month Rolling Ledger Balance as a business concept essential in determining which customers are Preferred. The fully defined concepts go to IT for implementation in the application’s portfolio. When column-naming standards are applied, the supporting database column is Portf_Ave_12MR_Ledg_ Bal_Amt. A classword (Amt) was added, standard abbreviations replaced full words, and blanks were replaced with an underscore to conform with the database’s column-naming restrictions. Similarly, the object-class method that derives the data becomes Set amtAverage12MonthRollingBalanceLedgerPortfolioCustomer because the OO naming standard uses “Of Language.” (The method name reads, “the amount of the average 12-month rolling balance of the Ledger of the Portfolio of the Customer.)

Valid reasons exist for establishing different names for the technology components that support the business concept, but these names should not be visible to the SMEs or the business analysts who populate the concept catalog and business-rule repository.

Likewise, any application using the business-rule engine must communicate with the end user — in error messages, help text, and so on — in business language. For example, if the user tries to assign an unqualified employee to a task, the error message should say something like, “Mary Smith must be a data modeler to be assigned to this task,”rather than, “Employee 12365 must have skill 4435 to be assigned to this task.”

Procedure Independence

Business rules should be specified independently from the processes they are intended to control; one business rule can control the behavior of different processes. Take the rule, “Every task must have a qualified employee assigned to it,” for example. Obviously, the Assign Employee to Task process can execute only if the assigned person has the skills the task requires. But this business rule also controls any other process involving a relationship between a task and its assigned employee, such as removing a skill from an employee assigned to a task that requires the skill, or if the assigned employee leaves the company. In such a situation, you want to specify the business rule once and have all the related processes properly controlled.

Rule-Firing Explanations

Many business-rule tools grew from expert systems technology, which often is able to ask why the rules engine came to its recommendation. If the rules engine says, “Mary Smith cannot be assigned to this task,” you can get further details by asking why.

The tool rationalizes its conclusions by presenting the business rules engaged, such as, “This task must have an employee assigned to it. This task requires data modeling skill. Mary Smith does not have data modeling skills. Therefore, Mary Smith cannot be assigned to this task.”

Access to Persistent Data

To determine which business rules should fire in response to a specific business event, a business-rules engine must have access to the current state of the involved business objects. This current state is derived from the enterprise’s persistent data stores.

Several techniques are available to gain access to the required data, such as direct calls to the database through standard interfaces (such as ODBC) or by accessing an instantiated object-class model. Regardless of which data management technique is used, the tool must provide access to data from within its environment. It should also minimize the need for external programs that access persistent data to instantiate business objects.

Application Portfolio Integration

A business-rules engine is a component of the enterprise’s application architecture. As such, any product that supports the development and management of business rules must be incorporated into the organization’s application development environment.

Ideally, the business-rule product can generate a working application, including GUIs and manipulation of persistent data, as well as the enforcement of business rules. Business analysts and developers must be able to modify the generated application when necessary. Therefore, the business-rule tool must provide an open architecture that lets it use standard protocols such as CORBA and COM. The tool’s design facility should be able to include any GUI widget available to the organization — through a standard component, such as one written in ActiveX — in addition to the tool’s native widgets.

Furthermore, techniques must be available so that any application developed without the business-rule product can access the knowledge held within the business-rules engine.

Validation Facilities

The product needs a rule-validation environment. Ideally, you would test the business rules as you discover them during the analysis sessions. Using the tool-generated base application, you can test the business rules by simulating variations of an event, based on the specified business rules and the state of the underlying business objects.

The validation facility needs to include a debugger so you can pinpoint the reasons the system behaves unexpectedly. The debugger must allow traditional techniques, such as trace, breakpoints, and object state reporting. The business-rule-firing explanation facility I discussed earlier becomes an important validation tool, because it reports the exact conditions under which each business rule fired.

You usually run simulations during the project’s business-rule discovery and analysis stage. Therefore, the validation facility must be available during those sessions. The tool must allow business analysts to easily locate and change the errant business rules and simulate the modified business-rule base in as close to real time as possible.

Business Systems Integration

Business rules are intended to control the behavior of the entire business system, not just the automated parts. Therefore, the business-rule knowledge base must be formatted for people’s use, as well as computer systems’. Therefore, the tool must let you incorporate the business-rule statements into policy and procedures manuals, whether held in soft or hard copy formats. When business rules are modified, it needs to generate change notices and revise manuals accordingly.

Not all business rules will be supported through a business-rules engine. Some may be enforced through data structures or program logic that is hard-coded into the database, or through object methods that can be modified only through IT’s formal change-management process. Under these circumstances, you need a facility to generate any necessary IT change requests and forward them to the appropriate parties.

Now you should have a complete set of business-rule evaluation criteria for judging management facilities (“Business-Rule Management Facility,” Database Programming & Design, Sept. 1998), classifying tools (“Business-Rule Stuff or Marketing Fluff?”Intelligent Enterprise, Feb. 9, 2000), and developing applications that enforce business rules. The next step before evaluation is to obtain a consistent case study of business rules, events, and scenarios for testing each product…which will be the subject of my next installment.

Terry Moriarty (terry@inastrol.com), president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management.