Join the Premier Community for RegisterLogin Business Analysts & Systems Saturday, February Analysts!

In association with the

20, 2010

Quick Links: Articles MA Blog Community Blog Jobs Interview Questions RSS Feeds Resources Articles

Templates

Books

BA Humor

Events

Business Analyst Articles: Business Analysis & Systems Analysis

Resources Articles News Books Directory of Websites Training Courses Organizat ions Articles and White Papers Current Articles | Search | Subscribe (RSS)

The 11 Secrets of Business Rules Success

Statistics: (346 Views) (0 Comments) Posted: Wednesday, February 17, 2010 Categories: Business Rules
Print

Do you twitter?: If
you want short updates on what's going on in the BA world and at ModernAnalyst.c om, simply follow us on Twitter:

A business es rules manage ment system (BRMS) can help a business in almost any industry realize two goals: make faster decisions with an automated process; and make better decisions for more profitable results.

http://twitter.co m/ModernAnaly st

BA ARTICLE ARCHIVE February

Webinar:
Enhancing Business Process Management with Business Rules

2010 (4)
January

Webinar: 5
steps to better quality requirements with Ian Alexander

2010 (7)
December

2009 (7)
November

Unfortunately, many businesses assume that the road to decision management success ends simply with selection of the right BRMS. But thats just one step one that should be accompanied by 11 others. My firm, over decades of experience in developing decision management applications, has identified 11 steps to ensure your success with a BRMS. These steps can help you make the most of the system you select; they can also help you select the system with features that best support sensible business rules practices. Following is a summary of the 11 steps. It addresses: picking the right decision application and development approach; writing rules effectively; monitoring and storing rules for best and long-term impact; and improving rules by operationalizing analytics.

Webinar:
Leveraging Visualization at Genentech An Agile Case Study

2009 (7)
October

2009 (6)
September

ARTICLE/PAPER CATEGORIES Activity

2009 (8)
August

Diagram
Agile Methods Analytical and

2009 (10)
July 2009

(9)
June 2009

Problem Solving Skills

Business

(5)
May 2009

Analysis Planning (BABOK KA)

Business

(10)
April 2009

(5)
March

2009 (12)
February

The right application and development approach

Obviously, a BRMS is to be applied as a decision management application. But not every decision is appropriate for a BRMS. For example, decisions that are always made differently or only made occasionally are not likely to be good candidates. So how do you Select the Right Decisions to Apply Your BRMS (Step 1)? Here are some characteristics of a decision to look for. The decisions might:

Intelligence
Business

Process Management (BPM)

Business

2009 (8)
January

2009 (6)
December

Process Modeling Notation (BPMN)

Business Rules Career as a

2008 (9)
November

2008 (8)
October

2008 (9)

Business

 September

Involve numerous rules. Have rules that change frequently. Require quick changes to meet short time-tomarket windows. Have rules that embody business domain knowledge best maintained by business people.

Systems Analyst
CBAP Class Diagram CoE/CoP for

2008 (4)
August

2008 (6)
July 2008

Business Analysts
Data Analysis

(8)
June 2008

Involve symbolic reasoning, be complex or involve rules that interact in complex ways. Require multiple levels of reasoning.

(17)
May 2008

& Modeling
Decision

(12)
April 2008

Good candidates have at least one of these characteristics and the best candidates have several. Even after youve determined its application, a BRMS is not a solution that simply starts workingit needs to Follow a Sound Methodology (Step2), in particular a delivery methodology. One popular delivery methodology that business rules work well withamong othersis the Rational Unified Process. It includes an iterative process that identifies risks early and often through the project. Regardless of your preferred systems development methodology, integrating activities for discovering, documenting, developing and maintaining rules maximizes your likelihood for BRMS success. You also need to recognize the importance of Documenting Requirements (Step 3). The first step is to document your business processes, then drill down into the details of your use cases. Use cases contain decisionsnot business rulesand you need to identify all the decision points within your use

Management
Elicitation

(7)
March

(BABOK KA)
Enterprise

2008 (21)
February

Analysis (BABOK KA)

Estimation Functional

2008 (16)
January

2008 (13)
December

Specifications
General

2007 (9)
November

Business Analysis
Getting Started

2007 (26)
October

as a Business Systems Analyst

IIBA & BABOK Interviewing &

2007 (2)
September

2007 (23)
August

Hiring Business Systems Analysts

2007 (12)
July 2007

(11)
June 2007

cases. When drilling into the decisions, you need to document the business rules that make those decisions, the terms used in those rules and other rule metadata, such as the rules source. Managing traceability (Step 4) necessitates another documentation practice. Business rule updates are driven by real-world changes. Traceability to the original source helps you find the right rules and artifacts to update as you address changing business needs. Therefore youll need to document and maintain records of any source information you needthe law it came from, the business unit that defined it, owners and approvers, and more.

Leadership &

Management
Process

(7)
May 2007

Improvement (CMMI, Six Sigma, SPICE, etc.)

Project

(6)
April 2007

(9)
March

2007 (5)
February

Management
Requirements

2007 (3)
January

Analysis (BABOK KA)

Requirements

2007 (2)

Writing rules effectively

To write effective rules, you need to Manage Your Business Rule Quality (Step 5) in rule development using two important measuresrules must be concise and atomic. Concise business rules only mention concepts that are absolutely necessary to decide upon an action or otherwise draw a conclusion. Consider, for example, the following rule:

Management and Communication (BABOK KA)

SDLC, Process,

and Methodologies
Security

Analysis
Sequence

If applicants gender is Male and applicant has a Criminal Record and applicants number of accidents is greater than or equal to 2 and applicants age is less than 25 then set applicants risk to HIGH

Diagram
Service

Oriented Architecture (SOA)

Soft Skills

Are all four conditions needed for this rule? Would an applicant be high risk if they were a male under 25 years who had two or more accidents? If so, the criminal record check is redundant and should be removed. Atomic business rules keep the concepts addressed by the rule as simple as possible. An atomic rule should be focused on one concept or outcome. Consider this business rule with two outcomes:

Solution

Assessment and Validation (BABOK KA)

Structured

Systems Analysis (DFDs, ERDs, etc.)

Technical

If the Customer is Platinum then the customers order qualifies for a 10% discount and the customers order qualifies for free next-day shipping
Two different business changes would require us to change this ruleany change to the discount policy or to the free shipping policy. However, when written atomically it would be easy to modify if the criteria for free shipping changed, for example:

Topics
Testing &

Quality Assurance (QA)

Tools Unified

Modeling Language (UML)

Use Cases User Interface

If the Customer is Platinum then the customers order qualifies for a 10% discount If the Customer is Platinum and the Customers order total is greater than 50 dollars then the customers order qualifies for free next-day shipping
In addition to being concise and atomic, you need to Choose the Right Metaphor (Step 6) in your rule development. Its critical to consider how rules will be

& Usability
Vertical

Domain or Industry

authored and editedwhat elements can be changed and in what ways. Flexibility in authoring should be part of a BRMS. As shown in Figure 1 below, you might start with a simple text rule (1). To help a business user edit this rule safely and easily, you could establish edit styles let them select the state and enter a value, for instance (2). Over time you might decide to also specify exception rules, such as does and does not live in the specified state. You might also allow different comparisons (not just less than) and allow rules to specify Accept or Reject, not just Reject (3). Ultimately you might allow the rule to be applied only to one of your defined customer segments (4) or give users complete flexibility to create and edit rules (5).

While the if then style is the classic business rule style, its not the only style. Many situations call for writing sets of rules such as in a decision table, exemplified in Figure 2. Decision tables may not be appropriate for all sets of rules, however. If the rule set is very sparse or if the condition action pairs are not symmetrical, then a decision tree as shown in Figure 3 is more appropriate.

So now that business rules are written, and even edited, business users cant just start using them. Instead they need to Verify the Business Rules (Step 7) to make sure that the rules theyve written dont have structural problems. A BRMS should include a tool that analyzes all the rules and other artifacts to find potential problems. While this automated support for verification is important, it should not be a black box. In many cases automated verification can only identify potential problems. Effective verification must combine automation with manual consideration of potential problems. Once verified, you want your business users to Validate the Business Rules (Step 8) they author and edit to ensure that they work. Typically this

validation is divided into unit testingchecking that a change to a specific set of rules behaves correctly and regression testing to confirm that the system as a whole behaves as expected.

Monitoring and storing rules for best and longterm impact

Simulating the Business Impact (Step 9) of a verified and validated set of changes is a critical requirement. After all, everything may work, but the business result may be undesirable. To do this properly, BRMS users need to employ decision simulation technology. This allows a user to understand the impact of a set of rule changes before deploying themin business, not technical, terms avoiding costly strategy errors. Now, with verified, validated, impactful rules in hand, you can manage your decisions as a corporate asset. But this requires rules storage in a repository Structure for Reuse and Governance (Step 10). The repository design must support your decision service lifecycle as well as your organizations governance policies, access controls and more. A well-designed repository reduces development time and increases speed to market. Best practices in repository design should divide it into Technical, Business, Decision Services and Testing Libraries.

Improving rules by operationalizing analytics

Business rules underpin your operational decisions,

ensuring that decisions are made appropriately, legally and as intended. But you also want to improve your decisions, which is where predictive analytics come in. Business rules define decisions but Operationalizing Analytics (Step 11) makes them smarter. Today predictive analytic models can be brought into business rules-based decisions auto-matically using either a black box or a white box approach. The black box approach involves code generation that implements the analytic model and the automatic integration of this code in the BRMS. Rules can use the result of the predictive model exactly as they use other attributes or data elements. While this is a common approach, it is not generally as effective as a white box approach which imports models and enables rule developers and authorized users to see and even modify models. Author: Amede Hungerford, Senior Director, Decision Management Solutions, FICO

For more detailed information on this topic request a free copy of FICOs whitepaper, The 11 Secrets of Business Rules Success or contact FICO at info@fico.com.

Rating 1 2 3 4 5

Comments Only registered users may post comments.

Advertising Opportunities | Contact Us Privacy Statement | Terms Of Use Copyright 2006-2010 by Modern Analyst Media LLC