Introduction to business rules

Taking advantage of Business Rules Management Systems

Arun Chhatpar (arunchhatpar@gmail.com), Senior Rules Architect, Freelance Software Architect and Consultant

Arun Chhatpar is a regular contributing author to IBM developerWorks, and he has more than 10 years of software design and development experience encompassing decision analytics, business rules management systems, core Java, UI frameworks and workflow orchestration. He is also a Sun Certified Enterprise Architect and business rules expert.
Summary: Business rules have existed since companies started automating business processes using software applications. Traditionally, they have been buried deep inside the application in some procedural programming language. As business rules matured, business users tried to control and manage these rules without directly having to deal with IT, which hasn't always been successful. Using an example from the insurance industry, this article provides an introduction to business rules and the importance of Business Rules Management Systems (BRMS) in bridging the gap between business and IT.

Introduction Business rules, described as the externalization of business logic and also as automation, are a means of implementing and enforcing business policies, and BRMS are a means of accelerating the change process. Helping to identify business rules has been one of the most challenging tasks in my experience as a business rules architect because business rules have been made difficult to understand. But it is not that difficult if you understand what constitutes a business rule. This article tries to solve that mystery of what differentiates a structured logic to be classified as a business rule by looking at a real-world example from the insurance industry. Business rules management is part of the overall business process management (BPM) framework. The IBM WebSphere Process Server is geared towards a complete BPM solution, and Business Rules is one of its major pieces. This article also gives you a brief introduction to the business rules component from WebSphere Process Server.

Back to top Examples of business conditions

So what is a business rule? In its simplest terms, it is a representation of decision logic that is pertinent to a particular business function in a specific industry. The insurance industry is a highly regulated one in terms of business and legal regulations and the cost of not following these regulations can be quite severe. These restrictions have created a need for this industry to adopt a better way to manage their decisioning logic and has also made them one of the early adopters of business rules technology. In order to introduce business rules and some of its advantages over procedural code, this article looks at some examples of business conditions from the insurance industry and discusses why they could be better off defined as business rules within a business rules management system. Example 1: Knockout condition Policy processing time is of great importance in the insurance industry, and a quicker response with system applications can provide a greater number of opportunities for agents to generate more business. The policy underwriters in the insurance industry use a potential client's driving history as one of the factors to determine risks. This first example shows a front-end underwriting filtering condition to accept or reject an application based upon a driver's history. Listing 1 shows how the condition would be stated in plain English. Listing 1. Knockout condition to filter policy applications
If a vehicle is registered in California and Driver had 3 accidents in past 2 years Then Decline to underwrite or issue an Auto policy.

Example 2: Tiering placement condition After the policy has been submitted, it usually is classified into different tiers based upon different application criteria. This helps identify unusual policy applications for underwriters. This next example shows one such classification. Listing 2 shows the business condition in plain English. Listing 2. Tier placement business condition for underwriting

If the age of the Driver of vehicle is between 25 and 35 And If no accidents in past 2 years Then Put this Driver in Preferred Tier. (higher discounts by default for this Tier).

Example 3: Validation/eligibility condition Claims processing is yet another important function in Insurance and the following example defines two business decisions or actions if the claim was not submitted within a certain timeframe. Listing 3 shows the Claims business condition in plain English. Listing 3. Business condition from Claims processing in Insurance
If Claim for an accident is not submitted within 15 days Then Do not settle the claim And Send to manual resolution queue.

The three previous examples show what business defines as conditions or constraints necessary to underwrite a policy and give a discount based upon driving history, and to settle a claim, respectively. The insurance industry is all about managing and minimizing risks. They do this by formulating business conditions and automating them using software applications, which is where the IT experts come in. Until the introduction of BRMS, IT

had all the control to manage the business rules, which made things difficult from the end user's perspective. It also left a lot of room for misinterpretation, which resulted in poorly managed code and ultimately affected the overall business. And IT implemented the rules by using a programming language. Listing 4 shows the code if the knockout condition (from Listing 1) were written as structured logic in an object-oriented programming language such as Java. Listing 4. Knockout condition implemented in Java

public String driverKnockOutCheck(Driver driver) { // The first step is to call another method to calculate the total number // of accidents in past x number of years. int numOfAccidents = calculateNumOfAccidentsInPastNu mberOfYears(2); // Apply the business logic and based on this set the status of // policy to APPROVED/DECLINED. If (numOfAccidents >= 3) { currentPolicyStatus = DECLINED; } return currentPolicyStatus; }

There is nothing wrong with this implementation, though it is not very easy to change or manage. Business also has to seek help from IT for any modifications. Here are some of the disadvantages to this approach from a business user's point of view:

Hardcoded logic -- If you notice, all the parameters such as number of years, number of accidents allowed, and all that is constant is hard wired in the code. Once this gets compiled into executable code, it's hard to make changes to it. Language-specific coding -- As the example shows, when such a condition is implemented using any programming language, it needs experts/programmers who know that language for any kind of changes or updates to the business constraints. It takes a long time to implement changes -- Any change to even a single attribute has to go through most of the steps of the Software Development Life Cycle and sometimes it might take weeks or even months. Let's say, for example, that the business analysts decide to allow 5 accidents instead of 3. To make that simple change it has to go through most of the Software Development Life Cycle steps such as Development, QA, and release management. Business does not have direct control -- Most importantly, business does not have direct control of this logic; they have to depend on IT to make any changes.

There are various ways to automate the change process and give utmost control of these changes to business users. One of them is defining the logic as business rules in a BRMS. The next section explores what makes structured logic to be defined as a business rule.

Back to top What is a business rule? Searching on the Internet for "business rule" turns up a lot of different definitions. Here is one of the more common ones: "A business rule is a statement that defines or constrains some aspect of the business." Simple, isn't it? Business rules are usually comprised of sets of declarative statements and constraints that can then predicate certain actions or goals. Simply stated, they are the "what" rather than the "how" of business operations. The main purpose of a business rule is to assert business structure or to control or influence the behavior of the business. A rule thus embodies a formal, implementable expression of some "user requirement," usually stated in textual form using a natural language (for example, English). This textual form is called a business rule statement. Each business rule statement indicates a discrete, operational practice or policy in running the business, without reference to any particular implementation strategy or specific technology. (Users, of course, generally should not be concerned with how rules are actually enforced.) The knockout condition rule discussed at the start of this article is in fact a business rule, because it is forcing a business constraint -- to decline the policy to a high-risk driver.

Back to top One more knockout condition Let's take a look at another example that shows an underwriting filtering condition to accept or reject an application based upon a driver's history. The condition in plain English is shown in Listing 5. Listing 5. Knockout condition to filter policy applications
If a vehicle is registered in California and Driver had 3 accidents in past 2 years Then

Decline to underwrite or issue an Auto policy.

This example, as well as all of the others above, are examples of business rules. When implemented using a good BRMS, these rules can be written in simple English phrases, just as the example shown in the knockout condition example from Listing 1. This type of familiarity allows business policy makers to work in close conjunction with IT. It bears repeating: BRMS tools allow business user to define rules in simple English. This feature alone is the biggest selling point for businesses to move to using BRMS systems, because it gives end users the power to control the business logic without having to learn complex programming languages. The next section explores some more features and reasons for using BRMS tools.

Back to top What is BRMS and what does it provide? BRMS are software tools used to create, manage, and support business rules of an enterprise. They bridge the gap between business and IT by giving the control of business logic to business analysts. The basic idea is that the BRMS decouples an application's business logic from its data validation logic and from its flow control. The business logic runs in its own container, the "Rules Engine," and business analysts code the business rules in a simple English-like programming language, which is very simple to understand and learn. Even a business user who has never programmed in any programming language can easily create and manage these rules. Figure 1 shows the conceptually common architecture of a BRMS system.

Figure 1. BRMS system architecture

Any top-of-the-line BRMS system has three major pieces to it. First is the IDE, or the Integrated Development Environment, used by IT staff, mainly rules developers, to create the framework necessary for business to create and manage rules. Second is the Rule Management Application, which is the user interface that business users use for creating and making changes to the rules, and finally the Rules Engine itself. The Rules Engine is the one that your business applications/systems interface with, to get automated decisions based upon rules created in the Rules repository, which acts as a rules database. Here are some of the advantages that become apparent from the BRMS architecture, as shown in Figure 1.

Business users have direct control over rules that govern how enterprise applications must behave. Business logic can be altered with almost no interaction with the IT. Because rules are written in a plain English-like language, they are more understandable to business-level people, leading to a better business-IT relationship, reduced implementation times, and fewer opportunities for interpretation errors. BRMS's also provide different ways rules can be grouped together for easier understanding and better management. One such grouping of rules is called a RuleSet. It's a collection of logically common rules. BRMS tools promote loosely coupled architecture. Top of the line BRMS products such as Blaze Advisor and Pega Rules also support Service-Oriented Architectures (SOA).

BRMS provides rich development, testing, and document features such as: debugging, controlled execution flow, cross-reference tools, and reporting tools. Better rules management - When you have large number of rules to implement, BRMS is a better choice because of its ability to simplify the management and organization of all those rules. It is also easier to trace, log, and debug issues, even when the total number of rules is very high.

Back to top Added benefits of using BRMS Because rules in a BRMS are managed and executed as an independent process, which can be embedded or called upon by your application, they can be updated at any time without having to recompile. If implemented right, the changes can even be made without process interruptions to your production system. The updated rules can be tested off-line and then phased into the running application according to your deployment strategy (regular release cycles, quick release updates, etc.). For a list of some leading providers of BRMS products please check the Resources section of this article.

Back to top Initiatives from IBM in a BRMS world -- WebSphere Process Server The insurance industry has been trying hard to move away from its legacy systems, for many of the reasons that this article has been pointing out from the start: Procedural code is hard to maintain and code written in legacy systems using languages such as COBOL is even harder. IBM has been a pioneer in aiding and supporting the efforts to move away from the legacy systems to more mature systems that encompass objec- oriented languages such as Java and also more loosely coupled architectures such as SOA. WebSphere Process server is one such initiative from IBM to help all businesses with that effort, including the insurance industry. With the WebSphere Process Server, IBM is taking a unique approach towards Business Rules by taking care of the bigger technological component that encompasses BRMS -Business Process Management. WebSphere Process Server is geared towards a complete Business Process management (BPM) solution and Business Rules is one of its major pieces. From a technical point of view, it is a runtime engine for artifacts produced in a business-driven development process. It claims to be the next-generation business process server that supports different forms of integration based on SOA and open standards. The services-based model enables automation of business processes that span across people, workflows, applications, systems, platforms and architectures. Figure 2 gives an overview of the WebSphere Process Server platform.

Figure 2. WebSphere Process Server platform and the Business Rules component as one of its major Service components

Image is courtesy of the IBM developersWorks article entitled WebSphere Process Server: IBM's new foundation for SOA. Business rules authoring in WebSphere Process Server is supported by an Eclipse-based desktop tool. Business Analysts can use the Web-based runtime tool included with the server. It is also independent of other service components in the server allowing the rules to be changed dynamically without affecting other services. This is a powerful BRMS tool.

Back to top Summary Business rules are not a new idea. They have been around since the inception of Artificial Intelligence in software applications. But traditionally they have been implemented in procedural logic, buried deep in application programs. The biggest problem with such implementations has been that they produce a highly inconsistent enforcement of rules and makes rapid change to them virtually impossible. We need some sophisticated and mature tools to lessen such problems. BRMS is one such promising technology.

Resources Learn

Business Rules Community has a lot of articles and tutorials and is very good place to start learning more about Business rules.

"The Phased Approach to Mining Business Rules," Business Rules Journal, Vol. 8, No. 5 (May 2007), by Mukundan Agaram, has very good examples on how to mine for Business rules in your system. Very informative article by Ronald G Ross that makes a good case on if All Rules are Business rules? Creating and deploying business rules (Neil Kolban, developerWorks, October 2006) is a neat tutorial that shows you how to use WebSphere Integration Developer to create and deploy a solution that uses business rules, and then test that solution in WebSphere Process Server. WebSphere Process Server: IBM's new foundation for SOA (Wolfgang Kulhanek and Carol Serna, developerWorks, September 2005) is an introductory article explaining WebSphere Process Server and the Business Rules service component for that server. Read the article Business rules management systems for an explanation of what Business Rules Management systems are and what you should look for before selecting one for your enterprise. Business Rules blog, most informative and interesting discussions on Business Rules, design and architecture. The EDM (Enterprise decision management) blog is a good source of articles, discussions on EDM related stuff. The article IBM WebSphere Developer Technical Journal: Introducting the WebSphere Integration Reference Architecture (developerWorks WebSphere, August 2005) provides an overview of the WebSphere Information Integration architecture. Get the latest version of Business Process Execution Language for Web Services version 1.1 specification. Learn more about WebSphere Business Integration, visit the IBM Business Integration product site. You'll find technical documentation, how-to articles, education, downloads, product information, and more. Learn more about WebSphere Business Integration Server Foundation, visit the IBM Business Integration Server Foundation product site. You'll find technical documentation, how-to articles, education, downloads, product information, and more. Find resources for WebSphere Business Integration developers on the WebSphere Business Integration zone. Take advantage of WebSphere training and certification resources.

See the Rational EGL resources page for information about Enterprise Generation Language (EGL), the modern version of 4GL which is used for defining business rule logic. Rational Unified Process (RUP) includes the Business Modeling discipline, which focuses on how to understand the business domain -- including business rules -effectively. Find out more about RUP.

Get products and technologies

IBM's WebSphere Process Server has Business rules as one of the server components for its Business Process management suite. Try a beta version of the RUP for WebSphere Business Modeler Plug-in to see how easy it is to visually define your mission-critical business processes. Blaze Advisor from Fair Isaac is one of several BRMS tools. JRules from ILOG is another BRMS tool.

Discuss

Participate in the discussion forum. Get involved in the developerWorks community by participating in developerWorks blogs.