driving profitable decisions with business rules …...white paper driving profitable decisions with...

white paper

Driving profitable decisions with business rules management

The business case for advanced business rules management

Business rules management systems are designed to help organizations efficiently develop,

execute and maintain their business rules in a centralized environment. With sophisticated rules

management technology, a business can greatly improve the effectiveness, agility and consistency

of the decisions it makes across its enterprise.

The nature of decision making in business is most often complex, and never static. Usually for any

one decision, multiple data elements must be evaluated. In addition, decision making must respond

to constantly changing conditions—external factors such as economic changes, competition or

regulations, as well as internally driven changes such as new product launches or new strategies.

Without a sophisticated system for managing rules, it’s highly improbable for an organization to

make decisions that avoid losses or drive profit.

That’s why leading organizations today are implementing advanced business rules management

systems (BRMS). These businesses are relying on rules management technology to make the best

decisions under a wide variety and complexity of conditions.

This white paper explains how a BRMS helps businesses make profitable decisions. It describes how a

BRMS can support a variety of operations within an enterprise, and details what functionality to look

for in an advanced BRMS. It covers:

• Why rules management is essential to a business’s success and how it drives profit.

• Why rules management must be separate from process management applications.

• How to develop and execute business rules; and how to interface a BRMS with process applications, and make it easy for non-technical business experts to use and manage the system.

• How to calculate a rules system’s return-on-investment.

• How to introduce a BRMS into operations.

September 2010 »» Summary

» www.fico.com Make every decision countTM

© 2010 Fair Isaac Corporation. All rights reserved. page 2


table of contents

»» Automated»Decision»Making»in»Business»Processes» » » » » » » » » » » » » » » »3

Business Rules Management Systems Versus Workflow and BPM Technologies . . . . . 4

Overcoming Common Obstacles to Profitable Decision Making . . . . . . . . . . . . . . . 5

Business Rules Overcome Limitations of “Legacy Code” . . . . . . . . . . . . . . . . . . . . 6

»» Specifying»Business»Rules» » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » »7

Rule Language Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Using Existing Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Flexible Degrees of Authoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Decision Tables for Lookup Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

»» Managing»Business»Rules » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » 11

Controlled Rules Management for Business People . . . . . . . . . . . . . . . . . . . . . . .11

Rulesets for Control and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Managing Rule Service Reference Information and History . . . . . . . . . . . . . . . . . .12

Simulation to Analyze the Business Impact of Changes . . . . . . . . . . . . . . . . . . . .13

»» Executing»Business»Rules»» » » » » » » » » » » » » » » » » » » » » » » » » » » » » » 14

Multi-Step Decision Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Advanced User Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Heterogeneous Enterprise Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . .15

»» Technical»Considerations»for»a»BRMS» » » » » » » » » » » » » » » » » » » » » » » » 15

Scalability and Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Auditability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Analytics Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

»» Return»on»Investment »» » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » 17

Calculating the ROI of a System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Reduced Opportunity Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

Reduced Development Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

Reduced Maintenance Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

Reduced Migration Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

»» A»Strategy»for»Getting»Started»with»Rules» » » » » » » » » » » » » » » » » » » » » 19

»» Conclusion »» » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » 20

»» About»FICO»» » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » 21



Business»Process»Management (BPM)»and workflow are often confused with business decision making. Indeed, there is an overlap in the concepts, but the two carry out distinct, yet complementary functions.

BPM»is concerned with the overall tasks used to drive a complete process from start to finish. This may include assignment and movement of physical resources, information gathering and processing, online and offline communications, approval and referral sequences, determination of prerequisites for future steps and the integration of automated systems with human employees. Workflow tends to concentrate more on the steps used to drive information or products through a subset of an overall business process, perhaps concentrating on physical production of an item or on an approval process necessary to implement a design change. Both BPM and workflow include the integration of automated systems with physical tasks occurring over time, and often include waiting for one step to be completed before being able to continue later with the remainder of the process.

Real-time»business»decisions, based on business rules and rule development, differ from workflow and BPM in that they focus on making a particular decision based on the conditions present at a given time. Such decisions may be used as tools to drive the succeeding step in a larger business process. It may be helpful to think of business decisions as a subset or component of a workflow or business process.

A simple analogy (Figure 1) helps illustrate the difference between business rules and BPM, as well as how they are connected. Business rules provide a “brain” for an organization’s operations, while BPM and workflow act like a “nervous system.” The brain can accomplish little on its own, but is able to make complex decisions based on data that it receives. The nervous system meanwhile carries information from sensors, such as fingertips or eyes or ears, to the brain and then carries out the brain’s resulting decisions back to the muscles so that the body can act on those decisions. The nervous system, like most BPM solutions, can make simple decisions and handle routine routing and escalation. However, it needs the brain to make more complex, more critical decisions.

Figure 1: A Simple Analogy

BRMS Is the Brain• It makes decisions when exposed to events and supplied with relevant data.• It does not physically perform any actions itself.

It is getting colder, I just turned the AC on, it’s normal.It is getting colder, it is getting late too, I need a jacket.

BPM Is the Nervous System• It carries information (documents) from the organs (departments) to the brain.• It transmits decisions made by the brain to the involved organs for a coordinated response.

Go to the closet, pick a black jacket that matches my outfit and put it on.

»» »Automated»Decision»»Making»in»»Business»Processes



To use a concrete example, consider a retailer who sells liquor. The business process involved inmaking a sale includes greeting the customer, identifying the goods chosen for purchase, checking their prices, noting that liquor is included, asking the customer for proof of age, checking the age against state and federal guidelines for liquor sales, ringing up the order, accepting payment from the customer, issuing a receipt, bagging the goods and thanking the customer.

A workflow included as a subset of this process is how to ring up the sale: Scan each item over the laser scanner; make sure the price registers on the terminal display; if liquor is included, ask for proof of age; check the customer’s birth date against the current date; accept cash and make change, or accept credit card and process for authorization; print a transaction receipt.

Included in this workflow process is a fairly simple business decision as one component. If the birth date of the customer is more than (21) years earlier than today’s date, allow the sale. Otherwise, prevent it. Notice that in the business rule we put parentheses around (21) years. This was meant to show that while the basic rule logic was constant for all retailers, specifics of the rule are variable based on location or specific retailer policies or legislative changes over time.

Business»Rules»Management»Systems»Versus»Workflow»»and»BPM»TechnologiesSoftware packages on the market today are built specifically to help organizations model and manage workflow and BPM processes. These contain special mechanisms to assist in defining sequences of tasks involving physical shipments, information retrieval and transfer, human intervention and wait/continue conditions that might be encountered during the process.

Workflow technologies usually include special queue management capabilities to route information or physical items to specific workers at specific times, and then reintroduce their modifications back into the main flow. Some of these “workers” will be IT systems doing some form of processing. However, many of the branching tasks that require decisions assume that the decisions are made by people, or are simple to describe and make. By and large these software packages provide a great deal of support for managing manual approval processes and queuing, with support for branching decisions based on relatively simple mechanisms. More complex decisions typically require external programming to accomplish. That’s where business rules management systems are important.

Business rules are a part of every business process in every organizational function. When these rules are complex, numerous, interdependent or subject to change, it makes sense to manage them with systems intended specifically for that purpose.

Business rules management systems address the unique needs of condition-based»decision»making. BRMS separates the logic behind business policies and practices from the mechanics involved in carrying out the actions recommended in the decisions. With that separation and centralization in a BRMS, business decisions may be shared between different business processes and workflows without requiring specification and maintenance in duplicate systems. Decision logic can also be more easily defined, located and maintained when the context of the surrounding business process does not affect its construction. An advanced BRMS houses the technology to support decision logic development and maintenance isolated from the business process.

At the center of leading BRMS today is a rule»engine—an execution component that rapidly and reliably executes the logic of the business rules. A rule repository stores, manages, versions and controls the rules, allowing different groups access to the rules as appropriate. Design tools for both



technical and non-technical users allow the rules to be edited by business users as well as integrated and deployed by IT professionals. Finally, deployment infrastructure components ensure that the rules can be deployed as services—Decision»Services—and integrated with business processes and enterprise software components.

Overcoming»Common»Obstacles»to»Profitable»Decision»Making»A business rules management system can help an organization overcome many challenges to making profitable decisions; therefore, these systems have been adopted by a broad variety of industries to solve numerous business problems (Figure 2).

Solving three problems in particular lays the foundation for its decision-making strength. One, it centralizes and organizes otherwise disparate, unorganized business rules throughout an organization. Two, it can empirically and automatically manage the otherwise highly complex nature of decision making. Three, it provides the attribute of agility, making it possible for businesses to respond quickly—and quickly modify their decisions—to constantly changing external and internal business conditions. Following is a brief, closer look at each of these areas of support.

Centralizing»rulesThe guidelines for what to do in different circumstances—what decision to make—are referred to as “business»rules ” Business rules may typically be found in policy manuals, regulatory mandates, programming code running corporate or departmental systems, or may simply be in the minds of employees who have learned a “best practices” approach to solving problems through practical experience. Business rules management technology centralizes the definition, storage, management and application of the many rules used in business operations. It provides organizations with greater automation, more responsiveness to change, less expensive distribution and maintenance of their business guidelines, and more profitable business decisions.

Managing»decision-making»complexityMaking business decisions, ones that result in desirable outcomes, can be a complex process. It can involve evaluation of numerous factors, or data points. For example, consider what a business must take into account to decide what action to take on a warranty claim. First, the business must determine if the product is or is not covered by a warranty; when and where the product was purchased; what was defective in the product and why; can the problem be repaired; how much would it cost to repair—or is the repair cost greater than a replacement cost. Getting any of these decisions wrong has a tremendous impact on immediate bottom-line profitability, and on longer-term profitability based on customer satisfaction. This warranty example is just one of hundreds or

Banking

Authorizations

Self-Service Web Inquiries

Account Management

Insurance

Claims Processing

Underwriting

Fraud Management

Retail

Behavior Scoring

Marketing / Campaign Management

Order Configuration

Telecom Government Manufacturing

Problem Resolution

Call Center / CRM

Personalization

Collections

Compliance

Self-Service Web Inquiries

Sales Commission Calculation

Product / Service Recommendation

Manufacturing ProcessImprovements

Figure 2: Common Applications of Business Rules Across Industries



even thousands of different types of decisions a business will face every day. A BRMS automates these steps in a decision process, in the right sequence, to come to a profitable decision in real time.

Adding»agility»to»decision»makingHowever, decision making gets even more complicated. Not only can any one decision involve many variables and steps, but these variables and steps can also change frequently. Why? Because making a profitable business decision never happens in a static environment. Instead, it is always the result of determining an appropriate action to take given a particular circumstance, or set of circumstances. And these circumstances are always changing.

Business decisions are constantly affected by multiple internal and external conditions and are therefore subject to constant change. Examples of external factors include competitive pressures, government or industry regulations, economic changes, evolving fraud schemes or even the development of new marketing channels, such as social networking sites. Examples of internal factors include the launch of new products or services, budget modifications, levels of risk tolerance or new strategies. Regardless of the factors, a business must immediately modify its rules to respond to conditions. A BRMS enables IT and business experts to quickly modify rules to adapt to conditions. It helps them determine changes to make by analyzing various rules scenarios, implementing changes and monitoring results for ongoing modification and improvement—all done easily within time to keep pace with changes.

For these reasons, and many more, as businesses focus on automating large-scale business processes, they also need a method for automating their business decision processes. Seeing that need, leading businesses are complementing their automated process management with the automation of business decisions using advanced business rules management systems.

“A business rules approach to systems development promises to be the most practical and desirable way to build systems. And, given the pressures of e-commerce, the two most important advantages are that a business rules system can be built faster and is designed to easily accommodate changes in the business with minimal disruption.”

—Barbara»von»Halle,»“Business»Rules»Applied”

Business»Rules»Overcome»Limitations»of»“Legacy»Code”As we have pointed out, decision making has been a core component in many different business applications. Traditionally, these decisions, or rules, have been programmed as part of the general application code that runs the rest of the system’s processing. When decisions are translated into abstruse computer programming languages and embedded within the framework of the application, it becomes difficult, costly and time-consuming to make changes to them. They’re buried throughout systems, making them hard to find, understand and manage, which leads to inconsistent decisions, and sometimes to compliance and governance issues. Even worse, eventually the application code becomes so entrenched and interdependent that changing it is no longer practical. The code and all the business logic contained in it becomes “legacy code” within the organization.

Definition:»Legacy code is any application code that, although often performing an essentialservice to an organization, is considered difficult or impossible to update to incorporate changes in an organization’s working practices or IT infrastructure.



Having legacy code within an organization is not necessarily a bad thing. It is stable, proven inpractice and is far preferable to writing and installing entirely new programs and systems time and again. But the business logic incorporated in these systems can be expected to change—sometimes over long periods of time, sometimes on a daily basis (consider the decisions that home mortgage lenders use in order to determine the rates they offer on different mortgages). Business rules, properly implemented in a BRMS, allow legacy systems to continue to support business processes while accounting for changes to business policies, practices and procedures.

The key concepts supporting separation of business rules from the remainder of applicationfunctionality are threefold:

• Specify the rules in a way that does not depend on the mechanisms used to obtain and update data, or on the mechanisms used to carry out recommended actions.

• Allow organizational control and management of the rules in a way that does not depend on or affect the rest of the application code.

• Create a way to choose and execute the right rules, at the right time, in the right order, without involving control by the application code.

Any complete business rules management technology should incorporate all three elements through language and interface constructs, a processing “engine” and independent rule management facilities. The following sections discuss each of these aspects of business rules management and other functionality to look for in a comprehensive business rules system.

Specification of business rules for effective use requires a number of technical capabilities. First and foremost is rigid adherence to the concept that business logic is independent from the mechanisms used to manipulate data or implement decisions. It may be easiest to illustrate the meaning and importance of this concept first by looking at an analogy from everyday life.

Consider a young driver learning the basics of safe vehicle operation. At any moment, the drivermust make many logical decisions: How fast is it safe to go? When should turn signals be given and ceased? How much distance should be maintained from the vehicle in front of you? These decisions follow a basic logic incorporating externally mandated regulations, best practices learned from others’ experiences and current operating conditions. Data used in the decision process comes from many inputs—visual recognition of objects and vehicles around the driver, road and weather conditions, posted speed limit signs, tactile sensations of the vehicle’s traction and stability, and much more. Once a logical decision is reached (“It is safe to drive at 45mph right here and right now”), the implementation of that decision involves manual and automated procedures that might vary greatly from vehicle to vehicle. For instance, a motorcyclist turns a hand throttle that pulls a cable increasing engine speed by turning a chain more rapidly to make the rear wheel spin faster. But a car driver uses the right foot to depress a pedal linked to the engine which turns a drive shaft connected to front wheels or back wheels or even all four wheels depending on the car. The driver is able to use the same basic logic to make decisions about safe speeds no matter what “systems” he or she is “integrated with” to carry out the results of the decisions.

In the same way, a business process should be able to make use of rules to reach operational decisions that can be carried out by a variety of systems. For instance, when responding to a customer asking for product support, the company needs to make a number of decisions regarding the customer’s status, support level, location, problem area and so on. These considerations follow a single defined decision process, even though they may be used by completely separate applications managing

»» »Specifying»»Business»Rules



website interaction, phone center response by live agents or automated phone response systems. The physical interaction with the customer is irrelevant as far as the underlying logic is concerned.

This is one of the great limitations of business rules that are included with software applications designed for a single interaction method, such as web-based commerce. The rules may work within the application, but they typically are intricately bound to specific interaction methods. Once the company wishes to expand the decision logic to encompass other types of systems, it has to rewrite the rules to meet the implementation requirements of the new systems. Only an independent business rules system offers the flexibility and neutrality to work identically within multiple implementations.

“The adoption of rules has provided Air Products the ability to control the input of data at the point of entry. Our ability to respond to customers is accelerated because we have the right data entered correctly the first time.”

—Craig»S »Reber,»Air»Products»and»Chemicals,»Inc

In other words, a business rules management system can be “pure” in its implementation of rules to make logical decisions and recommend actions. It does not include—or wish to include—facilities to physically control input and output on a web screen, update call center agent scripts or initiate email broadcasts, for instance. Instead, it contains clearly defined integration points for systems that are built to accomplish these mechanical tasks. As a result, a rule can recommend an actionable concept such as “Offer the purple widget at 5% discount” which can be used by various systems to make the promotion through the web, emails or other channels without needing to duplicate and alter the rules.

Two other aspects of this design benefit businesses. First, by technically separating rules from business processes (and having them linked via integration points), an organization can make changes to each independently. Therefore, a customer web interface, for example, can be modified without regard for or concern about modifying rules. Second, rules changes can be made and implemented much more rapidly, allowing a business to respond rapidly to market changes, competitive pressures or new regulations. In essence, neither party—the rules team or various process teams—slows the other’s business improvements.

Rule»Language»FlexibilityWriting business rules in a formalized, executable fashion requires a clear, unambiguous syntax or language for expressing the business logic. The intent and logic of a rule should be clear to a business user, even if s/he is not trained as a programmer. Advanced business rules management systems use proprietary rule languages that combine intuitive readability with tremendous flexibility. For instance, the following examples show equivalent ways to express the same business rule in a BRMS:

• If the customer’s debt exceeds the customer’s assets, then set the status of the customer’s application to Declined.

• If customer.debt > customer.assets, then customer.application.status = Declined.

• If the debt of the customer is greater than the assets of the customer, then the status of the customer’s application is Declined.

All the formats above execute with equivalent efficiency, and their styles may be mixed and matched to provide the most convenience and familiarity for the users of the system. When business rules use a familiar format and language, business policymakers can have direct participation in the develop-



ment, testing and modification process. System implementation times are reduced, and the potential for interpretation errors between business intent and programming implementation are lessened.

Of course, there are times when more complex functionality is required in order to make complicated calculations, or to call upon external systems in the course of evaluating a business rule. Some software packages with simplistic rule languages require “escapes” to traditional programming code in order to handle such tasks. Other advanced systems include full capabilities for calls to other applications, as well as a rich procedural syntax that handles looping, mathematical operations, operations on text strings, and other complicated functionality. All of this can be executed within the framework of the rules processing environment and maintains the separation of rules from the remainder of the system application code.

Using»Existing»DefinitionsThe preceding section showed examples of a rule making comparisons of a customer’s financialstatistics to accept or decline an application. In order for the rule to make sense, we must know what is meant by “debt,” “assets” and “application status.”

In every company, data systems already exist that contain these types of definitions. They may be expressed as columns in database tables, as Java class definitions, as XML document specifications, or in other forms. Today’s leading rules management systems contain automated tools to read existing definitions and immediately make the item names available for rule writing. At the same time, links to the external data sources for those items are established so that when rules refer to them, the values can be read from or updated in the external storage locations. Vast time savings can be realized by eliminating the need for a “dictionary definition” step before writing rules. Items can even be given more understandable names for use within rules without needing to change existing data definitions. This extends the usefulness of pre-existing data sources and legacy system code while allowing more natural business logic definition within the rules system.

Flexible»Degrees»of»AuthoringIdeally, rule developers should have tools at hand to create templates for fast and controlled creation of rules. This speeds development of similar rules and provides security and consistency in their definition.

Equally important, the templates should provide rule developers with the option to create various levels of rule complexity and sophistication. One of the first considerations is how the rule will, or can be, edited—what elements can be changed and in what ways.

As you can see in Figure 2 (following page), a rule can start with perhaps just a couple of data elements or basic text rules as in box 1. That can be expanded by adding options for edit styles, such as state selection, or selection of other values, as shown in box 2. Or, as the business’s need or desire to refine decision making grows, more data elements can be added. As shown in box 3, you can provide exception rules or data elements that show comparisons. You may decide to allow the rule to be applied only to a particular customer segment (box 4). Or, ultimately, you may want to give business users complete flexibility to create and edit rules as shown in box 5.

The point is that providing flexible degrees of authoring can support the full range of expertise and experience in rules development. That’s particularly beneficial for businesses that are new to rules development and want to gradually gain experience and confidence in their practices.



Decision»Tables»for»Lookup»ConditionsWhen a rule set follows a certain pattern, but has several different test values and different action recommendations, a “lookup” table can be the best way to see and follow the actions. Consider the following set of rules:

• If the customer’s status = Gold and the customer’s sex = Female Then set the customer’s agent to “Julie”.

• If the customer’s status = Gold and the customer’s sex = Male Then set the customer’s agent to “Mike”.

• If the customer’s status = Standard and the customer’s sex = Female Then set the customer’s agent to “Lisa”.

• If the customer’s status = Standard and the customer’s sex = Male Then set the customer’s agent to “Doug”.

A BRMS can give you the ability to create a table expressing all these conditions and results without any code or syntax:

GOLDSex:

Status:STANDARD

FEMALE Agent = Julie

Agent = Mike

Agent = Lisa

Agent = DougMALE

Figure 2: Degrees of Authoring

1.

2.

3.

4.

5.

This chart shows how a rules system can provide flexibility in the level of sophistication or complexity of a rule’s development. As shown, the decision to accept or reject an applicant, for example, can be based on a lower number (one or two) of very general or dichotomous data inputs, as in box 1, or several data elements, each with a high number of variables, as in box 4 and 5.



Values for the table can be imported from Excel spreadsheets. Values can be changed within the table, and tables can be formatted in a variety of ways to allow multiple rows or columns, or single-axis lists. Results in the lookup cells can be complex rule actions as well as simple return values. This is a natural way to think about many types of rules (consider shipping rate charts at the post office). Decision tables are another way that a BRMS can provide increased clarity and decreased development time and effort in specifying business logic.

Business rules constitute the part of an application most prone to change over time. Many of today’s business decisions must be made amid change and uncertainty. For example, a business needs to comply with new or modified regulations; keep up with competitive pressure; react accordingly to economic trends and risk levels; or simply introduce new products and services with supportive strategies.

The people best qualified to gauge the need for new operational behaviors, envision the new decision criteria and responses, and authorize implementation of new business policies are seldom technically trained in programming techniques. Traditionally, business policymakers gather a set of business changes that need to be made, submit them as a formal request to a programming department, sign off the programming interpretation of the changes, and wait for a scheduling opportunity to have the changes implemented in a new software release. The delays, costs and lost business opportunities in this type of cycle are apparent, but traditionally implemented software systems offer no alternative.

On the other hand, an advanced rules management system offers a way for organizations to implement business changes more efficiently and more quickly, with reduced chance of errors, costs and operational impact. Because business rules are separated from, and independent of, the underlying system code that keeps a business application operating, they can be changed without impacting basic system functionality. A BRMS can provide tools to expose specific parts of business rules to nontechnical users, who can then change rules in a controlled, secure and limited manner without programming or specialized training. New functionality can be added in the same manner, allowing both technical and business users to create structured rules following a particular format. Creation, alteration and deletion of rules can be accomplished over secure web pages. Of course, facilities to track and record all changes to system logic are required for auditing purposes, so a system should include this functionality as well.

Controlled»Rules»Management»for»Business»PeopleAs we’ve stated, the rules used to control business operations change over time. However, the business policymakers who are responsible for making new decisions and changing existing ones don’t think in terms of “rules programming.” They want business applications designed to easily let them accomplish business tasks—such as introducing new promotions, changing discount levels, altering rating criteria or incorporating new regulations. But creating such modification and management applications is a task often equivalent to building the underlying business systems themselves!

Because of that, it’s best if the rules management system contains facilities for easily creating and running integrated rule maintenance applications over the web. Rule developers start by defining specific formats in which rules may be created, reviewed and modified. The rules system then creates default web pages displaying fixed text and modifiable selection or fill-in areas. All links between the web pages and underlying rules code are maintained by the rules system. The generated web pages may be cosmetically altered using any HTML web-editing tool to suit the graphics, terminology and control interface standards of the organization. The end result is

»» »Managing»»Business»Rules



a collection of web screens that have controlled functionality to accomplish specific business modification tasks without specialized syntax or code fragments. Access to different pages can be controlled through corporate security systems, including LDAP authorization protocols. Giving business decision makers direct control over the logic used in key business processes reduces delays and costs in implementing needed changes to the business.

Rulesets»for»Control»and»MaintenanceA system’s rulesets give developers the ability to group related rules for segmented control over rule definition and maintenance, conditional execution, reuse and ease of management and documentation. Because ruleflows can call upon rulesets as part of an ordered chain of execution tasks within an overall decision process, proper grouping of rules limits the scope of potential inter-action between rules, and reduces the number of rules that need to be tested for potential conflicts.

Rulesets are also a natural way to separate maintenance and management of different functional aspects of business operations. For instance, a company might have a special VIP department responsible for customer relations with their best customers. This department could specify and update groups of rules that deal only with their VIP customers, secure in the knowledge that other groups are not being impacted by their rule changes.

Companies with large numbers of rules use rulesets to physically segment rules so that they can be found later. Imagine the difficulty of finding a particular line of code that controls the mortgage rate offered to first-time single-family buyers in the state of Ohio in a ten thousand line program. But if there is a group of rules specifically associated with Ohio mortgage rates, or single-family first mortgages, updates can be made more quickly and confidently. This segmentation of functionality also offers benefits in hosted applications for application service providers (ASPs). The ASP can create common sets of rules that apply to all their client companies, while allowing individual control of clients’ differentiated policies through rulesets.

Managing»Rule»Service»Reference»Information»and»HistoryIn business rules management it’s important not to overlook recording what has been done with rules. Since business rules control key decision processes, it is crucial to have clear access to what rules were in play when decisions were made, who made changes to rules and why changes were made. Part of this process is dependent on a commitment to good change management procedures within the organization. But the software being used to manage the rules should also contribute functionality to support enterprise control and auditing.

As you’ll read in the following Executing Business Rules section, a BRMS can assist with auditing and tracing rule execution at runtime. A number of built-in features in some solutions can also support historical record keeping. Core to these capabilities is a central»rules»repository»for managing physical storage of defined rules. The system should provide representations of rules and ruleflows for maximum flexibility and compatibility with a wide variety of current and future systems. However, organizations may choose to physically store and access the repository through flat files, databases or LDAP systems. The centralized storage of rules allows single-point editing and reuse of core logic components that are accessed by different business applications throughout the enterprise. To record the state of an entire rule service at any point in time, a “snapshot” may be taken of the files containing the rules and ruleflow structure. This can be recovered, reused or examined later for auditing and results testing/comparison against later versions.



“The creation, maintenance and administration of rules knowledge presented a voluminous challenge to manage, and we needed to fashion a powerful and unyielding solution to the problem.”

—Rex»Martin,»Ph.D.,»Principal»Engineer»and»Architect,Sun»Services’»Knowledge»Management»and»Innovation»Team

Advanced rules systems will maintain interfaces to several of the major source control software packages, including CVS and PVCS, giving companies the option to use check-in/check-out facilities for rule files. Other packages may be used through command-line interfaces a system may access through menu commands and options.

Rules management and maintenance applications that take advantage of web interface systems can automatically add documentary information to rule creation and changes, showing the author, time and date of the rule change, optional comments about the change, and any other information the organization might want to track (such as version number or cross-reference information).

Documentation»facilities may include both interactive HTML hyperlinked files and text-only print format files with automatically generated tables of content. Both versions show: the basic flow structure and components of a rule service; individual rules and other entities used in the decision process; cross-reference information showing interactions between various components; documentary text that rule developers and business users have added to their work; and potential conflict information between rules. The complete “code” of all rules in the system may be reported, or you can choose to record only the names and documentation information for rules.

Simulation»to»Analyze»the»Business»Impact»of»ChangesBefore new rules are implemented, it’s desirable—and highly advisable—to know how effective they’ll be in realizing objectives, and how they’ll affect operations as a whole. For instance, businesses need to react quickly to changing conditions. But taking fast actions can’t be at the expense of accurate decision making. So, what’s the best way to strike a balance—to develop new decision strategies on the fly that successfully build a competitive advantage?

Advances in decision»simulation»technology allow companies to assess potential strategies faster. New capabilities empower business users to simulate the results of proposed business rule changes, then put the best results into production—in minutes, not months. With decision simulation, you can apply new business rules to historical data to project the results and decide whether they’re worth pursuing.

In the past, achieving this level of confidence was both expensive and cumbersome. A company that didn’t want to risk putting untested decisions into action had to custom-code a wide array of simulations. IT departments had to run the simulations or build a user-friendly interface for business users to generate their own results. Months could go by with no return on investment as opportunities to increase revenue slipped past.

Advances in decision simulation enable companies to be more nimble, putting control of simulation squarely in the hands of the business user. Built to work “out of the box,” these new capabilities empower business users who have minimal technical expertise to conduct complex simulations in minutes. They can:



• Test new business rules using historical data and analyze the results.

• Compare potential changes to verify and validate the logic behind them.

• Conduct what-if»analysis»on competing strategies to choose the best one.

• Generate easily understandable reports that demonstrate how proposed changes will affect profits, costs, regulatory requirements and/or other business metrics.

Using advanced decision simulation technology is always advantageous. But it is particularly beneficial, or even imperative, in highly volatile environments or uncertain economic periods.

A key benefit of installing a BRMS is the reduction in complex programming needed to support business logic execution. This reduces rule implementation time, costs and employee resources needed to create a business application. But in order to achieve these benefits, the business rules technology must incorporate sophisticated software components. These components are designed to accomplish all the tasks that would otherwise need to be written in the application code.

Many advanced rules systems contain ready-to-use components to manage simultaneous requests for decisions from different applications or for different users; condition-based selection of the right rules to fire, in the right order; auditing software to record what rules were used in the course of making a decision; and support for complex decision chains without needing explicit control from the calling application.

Multi-Step»Decision»ProcessesJust as the warranty claims example presented earlier in this paper pointed out, in practice, business decisions are typically composed of many subtasks and intermediate decisions that contribute to a complete decision process. Here’s another example. A credit card issuer wishing to make a decision about what credit limit to offer a new customer would first make a decision about whether the applicant should be accepted as a customer; then make a decision as to what type of card to approve; and finally, make a decision as to the credit limit to offer. Each step must be completed in the correct order for the final decision process to be complete and correct.

Some decision processes are even more complex, with different processing branches that can be followed based on criteria evaluated along the way. The above credit card issuer might need completely different decision processes and associated rules based on the applicant’s country of residence.

A rules application could call for each subtask or intermediate decision in sequence, choosing which branch of the process flow to pursue. However, this introduces coding complexity and processing overhead from repeatedly invoking the rule system. More importantly, it violates our primary goal of separating decision logic from the rest of the application code.

One way to get around this is with multi-step»decision»processes (often referred to as ruleflows). Defined by the rule project developer, ruleflows lay out the entire decision process in a graphical, ordered chart of tasks and branching conditions. An application calling upon the rules management system to make a complex decision merely specifies the highest level of the ruleflow and turns over all execution control to the rule processing engine, which is optimized to perform the right tasks in the right order. Business benefits include a reduction in processing overhead (with associated computer resource usage and delays in response time); separation of application infrastructure code from the business logic operation; and faster development through the use of tools specifically built to support ruleflows.

»» Executing»Business»Rules



“It’s very important for us that any decision has to be communicated at the point of decision. The UK cards market is very competitive—you can’t say, ‘We’ll let you know in a couple of days.’”

—Phil»Jobson,»Sr.»Analyst»Change»and»Execution,»Egg

Advanced»User»InteractionDecisions are not always made based on known and available information. Businesses often need to interact with the user of the business application to get data that is used in the decision process. It’s advantageous to have the ability in rules systems to distinguish between data values that have not yet been asked for, data values that the system attempted to retrieve and found no value for, and data values explicitly set to null (no value).

Another advantageous feature in a rules system is the ability to specify a group of questions that should be asked as a set at the same time. Each question can have an internal property (data item) associated with it so that the provided answer is placed directly into the proper storage location. A rule can then call for a single action to retrieve the full set of data values. This reduces coding time and complexity during development, as well as simplifying the maintenance in adding more questions to the application later.

Finally, advanced systems also contain features to simplify the dynamic updating of information on web pages for interactive applications. Rules can specify what information should be presented on a web page, including additional questions that should be asked based on the answers to previous questions. Again, the mechanics of physically displaying the web pages are left to external systems to keep decision logic separate from infrastructure code. But easily defined and maintained links to the external systems provide speed and efficiency during development and execution.

Heterogeneous»Enterprise»Platform»SupportSome business rules systems allow a single product release to run on hardware and software platforms ranging from individual users’ laptops, to office servers, to the largest multi-processor mainframes. As a result, companies don’t have to worry about purchasing different versions of the software for different operating systems or compiler release levels.

This capability allows the decisions at the heart of legacy systems to be renovated for clarity,processing efficiency and ease of maintenance without having to replace the entire system. Once rule services are defined, they can be reused by additional applications and physical systems throughout the enterprise.

“From a management standpoint, we can more easily influence how things are done with onestreamlined system in place. The Decision Support System models apply all applicant characteristics objectively in the same way, every time. So we’re treating customers consistently across multiple distribution channels.”

—Patrick»J.»Madigan,»Asst.»Vice»President,»Underwriting,»Unitrin»Kemper»Auto»and»Home

When a BRMS is built to be a callable component of a business application, it can provide decisions based on data about the case in question. That data may be read from database tables, XML documents, MQ Series data streams, Java or COM objects, or from past parameters from the calling application. By the same token, the system can make calls to external applications, functions and

»» Technical»Considerations»»» for»a»BRMS»



business systems from within rules to initiate external processes, make complex calculations or update values in external data stores.

There are many technical implementations used to manage large-scale business systems. Systems architects face decisions about issues such as application server integration, stateful versus stateless sessions, synchronous versus asynchronous operation, and EJB or MDB container specifications. It’s best to use a rules system that automatically generates the proper integration code that will work under any of these scenarios. That will significantly reduce implementation time and costs.

Scalability»and»ReliabilityScalability»is a prime consideration for organizations planning to integrate business rules management into their core business operations. As business volumes increase, the software must not place artificial constraints on the throughput of transactions or business processes. Some rules management systems use configurable»parallel»processing»threads so that enterprises can balance machine resource utilization against processing volume demands. These can interact with load monitoring and balancing services provided by application servers to dynamically adjust system performance for optimum performance/capacity tuning.

The bottom line is that organizations can rely on this functionality to handle increased processing needs in a well-defined manner, making use of additional computing resources as they are added.

“The most important thing that we would stress to other organizations is how important it is to have a strategic vision with an eye on the future. Developing how you are going to use your business rules architecture to meet your business needs today and, more importantly, your future business needs is paramount in designing an IT architecture.”

—Michael»Koscielny,»Director,»Regional»Underwriting»Operations,»AAA

A second aspect of rules technology scalability is the ability to efficiently manage a growing number of rules—having the capacity to define and manage tens or even hundreds of thousands of rules as they are added over time. The ruleset and ruleflow architecture of a system can enable the processing engine to examine a subset of the entire rule population to find the rules applying to a particular task in an overall rule service. Then the advanced rule filtering technology in the rule execution engine efficiently categorizes rules based on similar conditions to add the right rules to the processing queue, bypassing rules that do not affect the decision outcome.

AuditabilityAny business making use of formalized rules to drive underlying decision processes needs a way to track and record what rules were used in reaching a decision. A reliable rules management system should include audit»threads that can be activated to produce execution trails stored in files. These can be archived, queried and reported against using third-party software programs. Some solutions also include sophisticated real-time tracking and testing tools, so that: test values can be entered in a running system; intermediate properties can be checked during processing; rule execution can be viewed graphically with breakpoints and event traces specified; and developers can step through execution one rule at a time. All of these functions can be made available within the development environment using a test engine, and on production systems in a secure testing thread while production work continues without impact.



Analytics»IntegrationIn addition to integrating a rules system with other software programs and applications, a business can also integrate analytic modeling into some rules systems. Analytics can act as an extension to rules management. Analytic models can be embedded in the rules platform, with rules supported by analytics subsequently deployed throughout the enterprise to all applications. This presents another strong case for the separation of business rules and business processes. Decision-making tasks within a process are ideal for applying analytics to execute precise, relevant and targeted decisions.

Calculating»the»ROI»of»a»SystemTo justify a new information system purchase, one considers the value of the system to the business compared to its cost. In calculating the value of a system, a business should consider the benefits it delivers, such as streamlined operations, lower headcount requirements, and avoidance of business mistakes, fines and other undesirable outcomes. Value is also derived from minimizing lost opportunities, for example losing customers to competitors or missing sales opportunities because of a procedural oversight.

Figuring the total cost of a system can be equally complex. “Total Cost of Ownership” (TCO) is a term used to refer to the cumulative costs associated with the purchase, implementation and ongoing use of a product or system.

The Total Cost of Ownership of a system =

• The cost to develop/implement

• Maintenance costs over time

• Potential migration costs for integration with new systems/platforms

• Business penalty costs (incorrect results, inconsistencies, schedule delays)

The cost to develop and implement a system includes purchase prices of necessary hardware and software, and costs for programmers, consultants, third-party integrators and any training requirements. Maintenance costs must incorporate the frequency and difficulty of making changes to the system, programming costs including specialized personnel, and the costs of lost development opportunities that are postponed in favor of maintenance.

A business also needs to account for maintenance costs and lost opportunity costs incurred over the life of a system. Most core business systems outlast their initial implementation environment. Data sources change over time, new hardware and operating systems are installed, and new applications are installed that must interface with the legacy systems, which all require project costs.

However, costs also build up in other ways, outside of tangible project costs—for example, when systems are not installed or updated promptly to meet new business requirements and are therefore not producing proper business decisions. In some applications, these type of costs include “inconvenience factors,” such as personnel costs incurred by having to manually adjust or work on transactions not covered by the automated systems. In other cases, costs may accrue from performing superfluous, unnecessary tasks, such as always ordering medical or credit reports instead of choosing the cases where they’re really needed. In the worst situations, costs of bad or out-of-date business decisions can include fines and legal action.

Therefore, a BRMS should help increase business value while reducing total costs over the lifespan of one or more applications. It should offer a development, execution and maintenance environment

»» Return»on»Investment



that can offer value to many different business applications without driving incremental costs. This differs from the traditional calculation of ROI for a single niche application.

Reduced»Opportunity»CostsWhile a business is developing a new application, it’s critical that it be able to deploy the system quickly and maintain strong rules management in the interim, especially for complex decisions. A sophisticated rules management system can help a business more rapidly deploy new applications, and benefit through the re-use of rules. Businesses can reduce lost opportunity costs with faster deployment. Then, when subsequent systems need to be deployed, rules can be reused for even faster deployment.

Lost opportunity costs are perhaps even more crucial when considering changes over the life of an application. By definition, when a need for change is recognized, there is some benefit to the company in implementing the change and some lost opportunity in delaying the implementation. The time spent between recognizing the need for change, revising specifications, recoding and re-implementing all adds to the time during which opportunities are being lost.

An advanced rules management system reduces the upgrade cycle time by allowing business “owners” to respond instantly when they recognize an existing problem or need for change. They can make secure and controlled business logic alterations without putting application infrastructure code in jeopardy. Even in cases where programming departments need to make more complex changes, the clear separation of rules from application code and the ease of alteration, test and change impact analysis makes the process faster and more assured. This dramatically reduces lost opportunity costs in systems where change is a constant.

Reduced»Development»CostsSophisticated rules management systems should reduce the time and cost of developing new applications. With an advanced rules system, business users are able to do more of the work themselves or in conjunction with programming teams—diminishing the amount of effort and costs associated with specifications, retesting and iterative code development. This cost reduction is more significant with more complex problems. Also, some solutions have prebuilt subsystems to: handle case-dependent rule execution; multi-user interaction with rules; on-the-fly rule replacement without downtime; and documentation and integration with external data and systems. These are all functions that would otherwise need to be designed, built and tested by the enterprise.

“There’s a lot of excitement in our business, especially around managing fraud much more efficiently, more specifically, than before. We’re also looking to bring the time it takes for introducing a new offer from six to nine months down to less than two weeks.”

—Brian»Burdick,»Dell»Financial»Services

Development costs can be further reduced by renovating and extending legacy systems—givingthem a new “brain” based on business rules rather than requiring development of completely new systems. When a rules system is not dependent on a proprietary data scheme, existing data sources and external systems can also be extended and used for new business functionality.

Reduced»Maintenance»CostsAdvanced rules systems are more likely to operate correctly from their initial implementation. The combination of clear business rule syntax, graphical ruleflow and other powerful tools ensure that



business people can participate in design and development. But it also ensures that the system architecture is more modular and intuitive to understand by both programmers and business owners.

Of course, changes are inevitable as business needs evolve over time. When changes are needed, businesses can make them fast and less expensively since business users can often make changes themselves. If a rules system includes tools for cross-reference, reporting, performance monitoring and graphical debugging, businesses save time and costs even when programming staff are required to make changes or perform maintenance.

Reduced»Migration»CostsIf a rules management system can be universally supported by Java implementation, organizations can make use of business rules on all major hardware/software platforms, from Windows to Solaris to OS/390 and Linux. With some solutions, no special hardware purchase costs are required to implement the rules system. If a company wishes to re-architect their operational environment later, they can do so secure in the knowledge that the logic underlying their business applications can move without modification to the new platforms.

Not every institution can jump straight into a full-fledged, enterprise-wide launch of rules. For many businesses, it makes more sense to roll rules out in stages, and gradually expand the system based on learning best practices. This approach can not only lead to greater long-term success, but also to permanent organizational support.

Pilot programs are a good way to start. A BRMS team can select one area of business, or a channel such as a customer web interface, to design and implement a set of rules. It’s also advisable to start with a discrete set of rules, and rules that are less subject to change. This gives business users a feel for how well rules can help them, without incurring risk of rule failure due to volatility. In time, the BRMS team can begin to roll out a percentage of more volatile rules and gain experience in quickly modifying rules to meet changing conditions.

It’s also a good idea to choose rules to develop by looking over backlogs of development projects, and to find programs that require a high level of involvement from business experts. These areas will most likely have the most impact in reducing IT dependencies and costs.

This type of staged approach will give the BRMS team experience in working across the rules architecture (rule development tools, rule repository set-up and deployment infrastructure), and help them learn about interfacing rules management with business process applications and platforms.

»» A»Strategy»for»Getting»»» Started»with»Rules



A business rules management system is essential for any business that operates in an environment of changing conditions—competitive, strategic, regulatory and other conditions that affect how it makes decisions. Process management falls far short of how dynamically a rules management systems can make complex, profitable decisions in constantly changing environments. Rules management significantly improves processes.

But a BRMS shouldn’t be viewed just as a necessity. It’s also an opportunity to capitalize on data.

In an age when information is prevalent and readily available, organizations need to think beyond commonplace process management; they need to strive for not just efficient operations, but also for highly intelligent operations driven by sophisticated rules management. A BRMS makes that vision a reality.

However, not all rules management systems are the same. It’s important to look for technologies in a BRMS that help IT and business experts work together to develop intelligible, effective rules; to easily maintain, share and modify rules across the enterprise; and to quickly deploy new process applications with immediate support from the rules system. The selection of the right BRMS will present companies with a return on investment in bottom line operational costs, minimization of lost opportunities, and greater control and consistency of more profitable business decisions.

“Business rules technologies are ideal for building systems to automate critical business decisions or scenario-based processing. Automating the decisions at the heart of business processes using business rules makes it easier to manage and evolve these processes to respond to a changing business environment. Business rules technology shows a high time to market response for regulated or rapidly changing business decisions which generally translates into high ROI.”

—Jim»Sinur,»Vice»President»and»Research»Area»Director,»Gartner,»Inc.

»» Conclusion

about FICO

FICO, Blaze Advisor, Capstone, Falcon, TRIAD and “Make every decision count” are trademarks or registered trademarks of Fair Isaac Corporation in the United States and in other countries. Other product and company names herein may be trademarks of their respective owners. © 2009–2010 Fair Isaac Corporation. All rights reserved.

2701WP 08/10 PDF

» For»more»information US»toll-free» International» email» web +1 888 342 6336 +44 (0) 207 940 8718 [email protected] www.fico.com

FICO»(NYSE:FICO) transforms business by making every decision count. FICO’s Decision Management solutions combine trusted advice, world-class analytics and innovative applications to give organizations the power to automate, improve and connect decisions across their business. Clients in 80 countries work with FICO to increase customer loyalty and profitability, cut fraud losses, manage credit risk, meet regulatory and competitive demands, and rapidly build market share. FICO also helps millions of individuals manage their credit health through the www.myFICO.com website. Learn more about FICO at www.fico.com.


driving profitable decisions with business rules …...white paper driving profitable decisions with...

Documents