A businesses rules management 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. Unfortunately, many businesses assume that the road to decision management success ends simply with selection of the right BRMS. But that’s 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.
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:
- Have rules that change frequently.
- Require quick changes to meet short time-to-market windows.
- Have rules that embody business domain knowledge best maintained by business people.
- Involve symbolic reasoning, be complex or involve rules that interact in complex ways.
- Require multiple levels of reasoning.
Good candidates have at least one of these characteristics and the best candidates have several.
Even after you’ve determined its application, a BRMS is not a solution that simply “starts working”—it needs to Follow a Sound Methodology (Step2), in particular a delivery methodology. One popular delivery methodology that business rules work well with—among others—is 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 decisions—not business rules—and you need to identify all the decision points within your use cases. When drilling into the decisions, you need to document the business rules that make those de¬cisions, the terms used in those rules and other rule metadata, such as the rule’s 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 you’ll need to document and maintain records of any source in¬formation you need—the law it came from, the business unit that defined it, owners and approvers, and more.
Writing rules effectively
To write effective rules, you need to Manage Your Business Rule Quality (Step 5) in rule development using two important measures—rules 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:
If applicant’s gender is “Male” and applicant has a Criminal Record and applicant’s number of accidents is greater than or equal to 2 and applicant’s age is less than 25 then set applicant’s risk to HIGH
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:
If the Customer is Platinum then the customer’s order qualifies for a 10% discount and the customer’s order qualifies for free next-day shipping
Two different business changes would require us to change this rule—any 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:
If the Customer is Platinum then the customer’s order qualifies for a 10% discount
If the Customer is Platinum and the Customer’s order total is greater than 50 dollars then the customer’s 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. It’s critical to consider how rules will be authored and edited—what 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 in¬stance (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 Re¬ject, 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, it’s 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 can’t just start using them. Instead they need to Verify the Business Rules (Step 7) to make sure that the rules they’ve written don’t have structural problems. A BRMS should include a tool that analyzes all the rules and other artifacts to find potential prob¬lems. 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 testing—checking 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 long-term 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 them—in 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 organization’s 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 FICO’s whitepaper, The 11 Secrets of Business Rules Success or contact FICO at [email protected].