Best Practices for Business Rules Integration

Best Practices for Business Rules Integration for Business Rules Analysts, Architects and Developers tasked with designing and developing business rules applications.  To help you achieve success as a business rules Architect/Analyst, this pocket book presents the following material:

• Architect level best practices
• Best practices for making business rules integration more maintainable
• Business Rules open standards
• Business Rules for J2EE and .Net technologies
• Out-of-the-box and open source business rule engines

Introduction - Business Rules
A Business Rule 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. 

Why Use a Business Rules Approach?
Traditionally, most systems are designed using the communication process. Users tell IT professionals what their system requirements are during the analysis phase. Some type of analysis document is generated. The IT professionals then build the system and deliver it to the Users. Even with the best RAD approaches, the cycle time from rule/requirement specification to a working system is significant (days, weeks or even months). In order to validate that the system has met the specified requirements, Users must interact with the system to reverse engineer their requirements and compare these with their originally stated business rules
This approach can lead to breakdowns in the following areas:
1. Translating the business rules from the Users’ intentions to the analysis document
2. Interpreting the analysis document into system design specifications
3. Implementing the system design specifications
4. Users validating original business rules in delivered system
Poor communication is certainly not the only reason that many systems fail, but this traditional approach creates a communication environment in which it is very difficult to succeed.
There is an alternative communication process in the rules-based environment. In this environment, Users and IT professionals work together to specify the rules and place them into the rules repository.
This repository acts as a common point of communication for both Users and IT professionals. The advantages of developing systems in a rules environment are as follows:

• Rules are represented in a format that is understandable by Users. Users can help enter and manipulate the rules.
• Rules are represented in a format that can be used by IT professionals as a system design document.
• Generators can immediately generate a working version of the system.

 

A key difference between the traditional communication process and the business rules-based communication process is that the information in the repository can be understood and used by end Users, IT professionals and the system generators. The only potential communication breakdown in this environment is in the transition from the User’s intentions or requirements to finalizing the repository rules. Since it is possible to generate almost immediate feedback from the entered rules, Users can quickly interact with the system and evaluate whether or not the business rules they envisioned have been accurately represented. As soon as the rules are specified, they can be evaluated in a working system.
Finally, a real benefit of the business rules approach is that the rules repository forms the full system specification allowing for independent decisions about handling the rules. This is true even for substantial changes to the system architecture. For example, in the current uncertain web application environment, systems built today using Oracle Form Builder or Visual Basic may need to be deployed in JavaServer Pages or Java clients in JDeveloper or .Net. The best defense against this uncertainty is to hard code as little of the program logic into the applications as possible. This is not to say that application code cannot reside in applications when using a business rules approach. Instead, generators can be created to take the code from a repository and generate the applications. With this approach, all of the rules are kept in one place and the decision about how to implement them can be made independently.

Business Rules Integration                  Process
First, let us explain the business rules integration phases in the context of best practices and the role each one plays in your business rule application development.

Repository Management

                        Management of the business rules and its related objects in a repository.

Fact Based Modeling

A representation of the application world using natural language analysis method. The representation is basically in business terms and business facts.

Business Rules

A business rule defines or constrains one aspect of your business that is intended to assert business structure or influence the behavior of your business. 

Business Process Modeling

The purpose of Business Process Modeling (BPM) is the construction of a concise, unambiguous representation of a business.

Business Terms

                        The terminology used by the business in their day to day business operations. 

Business Facts

Business facts are essentially entities and cannot be split into smaller facts without losing information

Business Process

Business Process is a collection of activities in a specific sequence designed to produce a specific output.

Rules Priority

Priority is an attribute of a rule that governs the order in which rules are added to the Firing Queue. The first rule in the Firing Queue will have the highest priority. Priorities are assigned as integer values; the value can be in the range from 0 to 100,000 (both inclusive).

Rules Execution

The Run-Time Rule Engine is based on a forward-chaining inference algorithm that uses a three-stage policy execution methodology to resolve rule conflicts:

1.  Matching. In this stage, facts introduced to the engine are matched against rule conditions. If a fact matches a condition of a rule, then that rule becomes a candidate for execution and is added to the rule engine agenda. An agenda is completed when all facts that are simultaneously present in working memory are matched to all active policy rules.

2.  Conflict Resolution. The conflict resolution stage subsequently compares all candidate rules on an agenda to determine if any execution sequencing conflicts exist in the logic of the rules. If any are determined, the conflicts are resolved according to the execution sequence defined by the user. The engine then sorts the agenda based on priority (high to low). The rule with the highest priority will execute first.

3.  Action. In the action stage any required actions are executed. Actions can assert new facts or retract/update facts into the rule engine, which causes the cycle to continue. This is known as forward chaining—where the match/resolve/act cycle repeats for rules affected by a changing fact base. The user has explicit control over when forward chaining should and should not occur (using the Assert/Retract/Update functions).

Business Rules and Web services

The Web services architecture is an interoperability architecture: it identifies those global elements of the global Web services network that are required in order to ensure interoperability between Web services.

Business Rules and SOA

A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. A means of connecting services to each other is needed.

Business Rules Scalability

Scalability is the capability to increase resources to yield a linear increase in service capacity. The key characteristic of a scalable application is that additional load only requires additional resources rather than extensive modification of the application itself.
Although raw performance makes a difference in determining the number of Users that an application can support, scalability and performance are two separate entities. In fact, performance efforts can sometimes be opposed to scalability efforts.

Versioning and Rules Priority

This involves the ability to have different versions of the same rule and evaluate only certain versions. Multiple versions of rules are supported and such versions can be prioritized.

Backward & forward chaining

Most Rule Engines support both forward and backward chaining. Backward chaining is called goal driven reasoning. Reasoning proceeds backwards, beginning with the goal, chaining through the rules, creating sub-goals and finally matching the facts. Forward chaining is also known as data-driven reasoning. The facts (or data) are exposed to IF-THEN rules. A combination of facts may satisfy one or more rules. Firing of the rules may assert some more facts, which may satisfy more rules and so on. Forward chaining involves exposing initial facts (data) to the rule base and producing new interesting and useful facts.

Grouping of rules

User can put together logically related rules to form a Rule Set. The rules can be exhaustively evaluated in a sequence. Rules can be evaluated such that only a particular rule is fired, or an alert is raised if more than one rule fires. The sequence can also be started from any point.

Rule Templates

Allows the user to define templates for rules, based on which rules can be stored in a database.