Business Rules Management Systems

Introduction

Repeated biennial surveys by the Standish Group since 1994 have shown that nearly three-quarters (73.3%) of US software development projects fail, either through cancellation at some point during the development cycle (25.9%), overrunning their budgets or time estimated and offer fewer features and functions than originally specified (47.4%).

One of the major causes given for cost and time overrun is restarts, where for every 100 projects that start, there are 94 restarts (This does not mean that 94 of 100 will have one restart, some projects can have several restarts.)

The reasons given for project failures were (in order of factor):

• Incomplete Requirements
• Lack of User Involvement
• Lack of Resources
• Unrealistic Expectations
• Lack of Executive Support
• ....

Several items of the list point to developing centric culture of many IT development organizations. Often developers expect a user to learn their language in the form of flow chart or UML diagrams. This is an error. Project teams must develop languages based on simple conceptual models of the domain, written in easy terms that can be understood by users and developers. BRMS has a role to play in this challenge for IT in today's fast-moving competitive environment.

Also, the cost of maintenance: 85% of all software development costs occur after the product has been released, where 80% of maintenance is due to unmet or unforeseen user requirements and only 20% is due to bugs or reliability problems. The cost of change is 1 unit in the definition phase, 1.5 to 6 units during the development phase, and 60 to 100 units after release (Pressman).

From the perspective of the developer, one of the reasons that object-oriented based development is so attractive is: If the maintenance is localized to the change objects, these changes do not propagate to other objects. However this benefit does not extend to changes to the business rules if they are scattered around the application or tightly bound to interface definitions. A typical change involves numerous groups of people and a multitude of processes to ensure that a business change was translated and effected into the business application.

The change in business policy is driven in large part by the change in the marketplace, in that businesses have to react to several different competitors and have to cater to an increasing number of diverse customers. It is important to react to change faster than competitors, and the reaction time is decreasing every single day. The combination of change and reaction time is placing even more pressure on information technology teams as time goes by.

Business Rules Management Systems (BRMS) to the Rescue

Many products in the industry today profess features that can solve the issues of complex processing. There are also a few technologies that permit the development of a rules-based processing system. Rule programming languages such as 'lisp' and 'prolog' have existed for a couple of decades. Java is being used to replicate the functionalities and features that were available with earlier expert systems languages and rule programming languages.

The other solution is to remove the definition of policies from implementation and code details and place them in a central location (the rule space). BRMS does it. BRSMS are systems to externalize business rules and to provide a facility for centralized business rule management. This addresses an urgent need businesses do have nowadays: to change their business rules in order to adapt to a rapidly business environment, and to overcome the restricting nature of slow IT change cycles.

Rule-based Applications

Rule-based applications are computer applications that use rules to provide recommendations or diagnoses, or to determine a course of action in a particular situation or to solve a particular problem.

The BRMS allow rule-based applications to:

• Capture policy and rules that are subject to frequent changes
• Implement those changes quickly and easily within a business application
• Manage and write rules in a familiar business language
• Business users can update software according to their schedule, rather than IT's

The success of a rules-based application is achieved when the business logic – the policies and knowledge of the business – is abstracted from the application logic; expose them across the enterprise via enterprise-class technical architecture. This makes the process of creating and changing business logic much easier. The same change requested by business users can be implemented without changes to program code by isolating the change and testing only the rules that were modified. Rules-based applications tend to be easier to maintain and at a lower cost because code does not have to be redesigned, retested, recompiled and redeployed for every minor change in business processes.

Common Features of BRMS

A key component of any BRMS is the business rule, there is no standard definition of business rules, it can be said "to be a statement that governs or constrains some aspect of the business". It is 'atomic' in the sense that it cannot be broken down or decomposed further into more detailed business rules. If reduced any further, there would be loss of important information about the business. Thus business rules are essentially policies by which an organization does business.

Rules

Rules in BRMSs are characterized by being declarative non-procedural; they state what is true, not how to compute it. Rules are usually expressed in the form of IF ...THEN ..statements, such as:

IF A THEN B

Where A is called the antecedent and B is the consequent. In expressing rules, the consequent usually takes the form of an action or a conclusion. In general, a rule can have more than one antecedent, usually combined either by AND or by OR. Similarly, a rule may have more than one consequent, which usually suggests that there are multiple actions to be taken.

An example of a rule might be:

• If the driver's age is less than 17, then deny all car rental requests.
• If a claim involves the loss of an item worth at least $1000, then the claim has at least a low probability of fraud.

Rules can also be specified in other formats, often tend to use the domestics (must or must not) form to expression constraints or inferences for example:

• An applicant for credit must be at least 21 years of age.
• A purchase order must not be invoiced before signed.

For many businesses, hundreds or thousands of such statements may be used to express their business policies, procedures and regulations that govern their business operations.

Rule Engine

Groups of different rules are specified and processed by Rules Engine, focused in separate business logic from control logic. It uses the rules and facts, and combines them together to draw conclusions. Facts represent inputs to the system that are used to derive conclusions, or to cause actions such as customer information, invoices.

After the analysis the engine can return results and/or call actions. These conclusions are often derived using deduction, although there are other possible approaches. Results may be simple data values or complex data structures. Actions can be almost anything including sending email.

Rule Repository

A rules-based processing model must offer a Rule Repository, a centralized location where all business logic is stored, creating a platform for easy migration and transfer during the various phases of system development.

The rule repository creates the possibility of storing different versions of a rule definition and recording the history of changes and supports the versioning of rules.

This also allows:

• The ability to audit the rules
• Definitions of multiples version of rules

Rule Templates

Rule templates are design patterns for rules. In many circumstances, a rule might be applicable to several data. In such cases, rule templates allow for the creation of rules with empty slots to be filled in later. A business rule template represents a partially defined business rule that contains placeholder slots for missing information. Templates can be used to create multiple rules with a similar structure, where only the value filled in the slots varies.

Rule Syntax Checking

A good BRMS will offer facilities for checking the rule syntax in real time, as the rules are entered, with structured rule languages.

Managing Objects in Natural Language

In the context of business rules, formal representation is an open problem; a BRMS must provide a formal language combining sufficient expressive power, efficient reasoning support, and naturalness of expression, to give common users the ability of understanding and personalizing their systems' policies.

It is necessary to provide user-friendly front-ends that illustrate the policy in a language familiar to the user, such as a graphical language, or may be natural language.

BRMS Products

Several rules engines are available, including commercial and open source choices. Commercial rules engines usually let you express rules in a proprietary English-like language. Others let you write rules using scripting languages such as Groovy or Python.

From the long list of candidate systems, we had to make a shortlist. The criteria we applied were that the shortlisted products should:

• Allow business analysts to create and modify the rules
• Use a fully-featured repository
• Allow applications to be deployed in a service oriented architecture
• Allow the rule engine to be a component or service within larger applications

Products

• Smart Rules, Kontac
• CLIPS, NASA
• JRules, ILog
• Jess, Sandia National Laboratories
• JBoss Rules, JBoss
• Blaze Advisor,Fair Isaac

Conclusion

Using a rules engine can significantly reduce the complexity of components that implement the business rules logic in your applications. An application that uses a rules engine to express rules uses a declarative and extensible than one that doesn't. As you've seen, the approach has a higher chance of being more maintainable.