FICO Blaze Advisor Best Practices

Best Practices

For Java FICO® Blaze Advisor®

decision rules management system

Version 7.4

www.fico.com Make every decision count™

This document is the confidential, unpublished property of Fair Isaac Corporation. Receipt or
possession of it does not convey rights to divulge, reproduce, use, or allow others to use it
without the specific written authorization of Fair Isaac Corporation and use must conform
strictly to the license agreement.
The information in this document is subject to change without notice. If you find any problems
in this documentation, please report them to us in writing. Fair Isaac Corporation does not
warrant that this documentation is error-free, nor are there any other warranties with respect
to the documentation except as may be provided in the license agreement.
© 2009–2017 Fair Isaac Corporation. All rights reserved.
Permission to use this software and its documentation is governed by the software license
agreement between the licensee and Fair Isaac Corporation. Portions of the program may
contain copyright of various authors and may be licensed under certain third-party licenses
identified in the software itself in the <ADVISOR_HOME>/doc/thirdPartyLicenses/Readme.pdf
file.
In no event shall Fair Isaac be liable to any person or direct, indirect, special, incidental, or
consequential damages, including lost profits, arising out of the use of this software and its
documentation, even if Fair Isaac has been advised of the possibility of such damage. The
rights and allocation of risk between the licensee and Fair Isaac are governed by the respective
identified licenses in the <ADVISOR_HOME>/doc/thirdPartyLicenses/Readme.pdf file.
Fair Isaac specifically disclaims any warranties, including, but not limited to, the implied
warranties of merchantability and fitness for a particular purpose. The software and
accompanying documentation, if any, provided hereunder is provided solely to users licensed
under the Fair Isaac Software License Agreement. Fair Isaac has no obligation to provide
maintenance, support, updates, enhancements, or modifications except to users licensed
under the Fair Isaac Software License Agreement.
FICO™, Fair Isaac and Blaze Advisor® are trademarks of Fair Isaac Corporation in the United
States and may be trademarks or registered trademarks of Fair Isaac Corporation in other
countries. Other product and company names herein may be trademarks of their respective
owners.
FICO™ Blaze Advisor® decision rules management system is covered by U.S. Patents Nos.
RE43,474; 6,865,566; 6,965,889; 6,968,328; 6,933,514; 7,000,199; 7,152,053; 7,277,875;
7,428,519; 7,613,671; 7,831,526; 7,835,932; 7,930,196; 7,937,355; 8,099,376; 8,200,609;
8,237,716; 8,280,836; 8,730,241 and Indian Patent No. 240176 and others listed on
www.fico.com.

FICO® Blaze Advisor® 7.4

Last Revised January 31, 2017
Version 7.4
Template LG 7.1
Contents

Contents

CHAPTER 1:
Blaze Advisor Best Practices and Usage Patterns . . . . . . . . . . . . . . . . .5
Development Process Practices and Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Roles and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Business Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Application Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Object Model Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Rules Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Rules Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Repository Management Practices and Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Security Management Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Blaze Advisor Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Blaze Advisor Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Blaze Advisor Content At Rest Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Logging and Auditing Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Repository Content Organization Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
General Folder Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Business Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....... ......... 13
Technical Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Business Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Utility Templates and Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
SRL Entities and Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Rules Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Technical Library Authoring Practices and Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
SRL Entity Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Rule Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Variable Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Constant Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Functional Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Template Entity Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
SRL Entity Formatting Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
SRL Entity Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Writing Rules for Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Minimizing the use of Nested if-then-else Statements in Rules . . . . . . . . . . . . . . . . . 22
Comparing the use of Patterns Versus Quantified Expressions . . . . . . . . . . . . . . . . . . 23
Minimizing the use of Multiple Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Avoiding Repeated SRL Code in Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Fair Isaac Corporation Confidential and Proprietary Information 3

Contents

Avoiding the Excessive Use of Or Statements in Rule Conditions . . . . . . . . . . . . . . . 24

Business Library Authoring Practices and Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Effective Dating and Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Effective Dating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Setting the Processing Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Graphical Rule Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Decision Table Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Decision Tree Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Decision Graph Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Score Model Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Release Management Practices and Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Setting up the Environment(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Releasing a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Logical Release via Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Physical Release as a Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Release Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Quality Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Basic Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Manual Simulation and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Automated Regression Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Importing or Exporting a Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Deployment and Execution Practices and Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Execution Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Pre-compiling Rule Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Rule Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Performance Tuning Tips For Java HotSpot Virtual Machines . . . . . . . . . . . . . . . . . . . . . 38
Java HotSpot VM Dynamic Optimization Approach . . . . . . . . . . . . . . . . . . . . . . . . . 38
Impact on Blaze Advisor Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 Fair Isaac Corporation Confidential and Proprietary Information

CHAPTER 1

Blaze Advisor Best Practices and Usage

Patterns

This document provides an in-depth discussion about the conventions, best

practices, and patterns related to the construction, implementation, and usage
of the FICO® Blaze Advisor® decision rules management system. It provides
suggestions on how to develop rule services and their underlying development/
management infrastructure.
If you would like to comment on those best practices, to submit your own best
practices, or to suggest additional topics, please contact
[email protected].
Best practices and pattern information is provided in the following areas:
 General rules development process
 Rule repository management
 Technical library authoring
 Business library authoring
 Release management
 Rule service deployment management
The content for each practice/pattern will follow general industry pattern
documentation norms as follows:

Name Practice/pattern name

Intent A short statement about the rationale for the practice/
pattern in the context of the addressed design/
implementation topic
Motivation Presents the potential benefits of applying the practice/
pattern in terms of functionality, reliability, usability, and
maintainability.
Implementation/Solution/Example Describes at an abstract level the relevant structures,
sequences, or other implementation details, while
including discussion of relevant pros, cons, and trade-
offs.
Related patterns/References

In general, the information presented is independent of any specific

deployment platform and/or architecture. Exceptions to this rule will be noted
as appropriate.

Fair Isaac Corporation Confidential and Proprietary Information 5

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

This document is intended for a technical audience whose members are

responsible for the design, implementation, testing, configuration, and
deployment of rule-based services using Blaze Advisor. It is assumed that the
audience has at least completed the introductory Blaze Advisor training
classes, and has a basic understanding of object oriented design principles.

Development Process Practices and Patterns

Similar to other software development processes, the life cycle of business rule
development is an iterative process that includes specification, design,
development, and test phases.

Roles and Responsibilities

This section provides an overview of the necessary roles and responsibilities to
design, develop and maintain a Blaze Advisor business rules application.
The roles and responsibilities include:
 Business Analyst
 Business user (Subject Matter Expert)
 End user
 Quality Assurance Engineer
 Application Architect
 Object Model Architect
 Rules Architect
 Rules Writer
As the reader continues through this topic, it is important to understand that it
is frequently necessary for one employee to fulfill more than one of these roles.
Conversely, it is also equally common for more than one employee to fulfill the
responsibilities of a single role. The assignment of the roles and employees is
dependent upon the needs for each individual development project.

Business Analyst
The Business Analyst is responsible for defining the business processes which
will be supported and then gathering and organizing the business rules that
will provide the foundation for the application planning process. This list of
rules will typically be in the form of structured natural-language statements
that clearly, completely, and concisely express the rules, facts, policies, and
procedures that will be implemented. Once these statements are clearly listed,
the Business Analyst will work with the Object-Model Architect to identify the
objects (business data) which will be referenced by the rules. After the object
model and the control flow for the rule project have been set up, the Business
Analyst writes or modifies rules, either directly in the Blaze Advisor IDE or
through a rule maintenance application. However, for complex rule projects,
the implementation of the business rules could be the responsibility of the Rule
Writer.

6 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

The general skill set for a Business Analyst is:

 An in-depth knowledge of the business policies, sometimes called the
problem domain , that the rules-driven application is going to model.
 The communication skills to gather relevant policy information from a
variety of sources.
The analytical skills to:
 Determine when information is inconsistent, incomplete, incorrect, or
irrelevant.
 Compile the relevant policy information into clear, complete, and concise
descriptions of business policies.

Application Architect
The Application Architect is generally a senior developer on the project,
responsible for determining:
 Scalability
 Security
 Persistence mechanisms
 Where the rule service(s) will fit in the application architecture.
 The appropriate invocation mechanism the application architecture will use
to invoke the business rules.
The general skill set for an Application Architect is:
 Knowledge and experience designing application architectures.
 Java/ OO programming
 The customer’s network, middleware, server architectures and databases
used by the application.

Object Model Architect

The Object Model Architect identifies the business objects that the business
rules will execute on, and also determines how to derive the objects from
larger object models in the application.
The deliverables derived from this role serve as an important link between the
Business Analyst and the Application Architect. The Business Analyst requires a
set of business objects that completely and accurately describe the data
requirements for the business problem. The Application Architect has to know
what data the other application components are expected to provide to the rule
service, and what they can expect to get from the rule service.
Defining the data contract between the rule service and the client(s) of the rule
service is a prerequisite to any development effort. A data contract defines
what data will be passed to the rule service by the client and what data the
client can expect back from the rule service.
The general skill set for an Object Model Architect is:
 Familiarity with object-oriented programming concepts.

Fair Isaac Corporation Confidential and Proprietary Information 7

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

 Knowledge of the technology for the object model

For example Java, COBOLor XML, etc.
 Ability to map business/rule data element requirements to the appropriate
data sources.

Rules Architect
The Rules Architect is responsible for developing the rules project using
Blaze Advisor. This includes importing or creating the object model defined by
the Object Model Architect, designing the execution flow, and defining the
rulesets and functions. If the rule project includes a rule maintenance
application, the Rules Architect might also be responsible to develop the
templates and the user interfaces for the application.
The general skill set for a Rules Architect is:
 The analytical skills to comprehend logical relationships
 Familiarity with object-oriented terms and concepts.
 Strong knowledge about the Blaze Advisor Rule Engine and best practices
about building high-performance rule projects based on various
Blaze Advisor artifacts.

Rules Writer
The Rules Writer (Rules Developer) is responsible for writing detailed rulesets
and Blaze Advisor source code constructs specifications, implementing them in
SRL, and perform unit testing on them.
The general skill set for a Rules Writer is:
 Strong ability to understand business rule requirement documents and
capacity interact with business analysts to resolve issues regarding
business rule requirements.
 Above average rule development skills using Blaze Advisor SRL.
 Sufficient knowledge about the technology used to implement the
supporting object model such as Java, COBOL or XML to interact with the
object model architect and resolve potential issues between the object
model and the business rule implementation.

Repository Management Practices and

Patterns
The configuration of the business rules repository defines all the underlying
parameters for services such as persistence, change management, and
concurrency control.
The following sections contain FICO recommendations for repository best
practices:
 “Security Management Practices” on page 9

8 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

 “Repository Content Organization Practices” on page 12

Security Management Practices

Addressing security threats is a key element of software development. Security
requirements address confidentiality, integrity, and availability of information
and systems. Early integration of security in the development of an application
enables you to maximize your return on investment through early
identification, prevention, and remediation of security vulnerabilities.
With this in mind, Blaze Advisor recommends that you consider the following
security architecture principles when designing your rule project:
 Fail Safe
This means that if the application encounters a situation and it can no
longer proceed, then it must deny access to the resource. For example, if a
firewall cannot validate the action that is being requested, it should reject
the operation.
 Deny by Default
If rights and/or permissions are not explicitly granted, an application must
deny access to the resource.
 Compartmentalize user access
This type of access provides users with access to data and functions that
they require and restricts them from accessing data or functions they do
not need.
 Defense in Depth using multiple layers of security
Multiple layers of security ensures that if one security mechanism is
vulnerable to an attack, an additional layer will still enforce an adequate
security policy.
 Run with Least Privilege access
Applications need to run with the minimum amount of system privileges
that they need to function. Where elevated privileges are required, they
should be granted for the minimum period of time they are required. A
similar principle is the “need to know” principle where only the minimum
number of people have administrative access to production web, database,
and application servers.
 Trust but Verify objects or other applications.
Applications need to trust other applications or objects on the same host or
the network, however, they must always verify the source they are trusting.
The same applies to users and their actions. For instance, before
performing any administrative actions, it is important to check that the
requesting user is indeed an administrator authorized to request such an
action.
 When possible, Use and Reuse Trusted Components
Other system designers, either on your development team or on the
Internet, have faced the same problems as you. They may have invested
large amounts of time researching and developing robust solutions to the
problem. In many cases they will have improved their components through
an iterative process and learned from common mistakes along the way.

Fair Isaac Corporation Confidential and Proprietary Information 9

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

Using and reusing trusted components makes sense both from a resource
stance and from a security stance.
 Use a Multi-tier Security Architecture for web applications.
Infrastructure considerations for web applications should be addressed to
limit exposure to internal resources as well as limiting the likelihood for
direct access to application data.
The following sections contain information on best practices for security in
Blaze Advisor:
 “Blaze Advisor Authentication” on page 10
 “Blaze Advisor Authorization” on page 10
 “Blaze Advisor Content At Rest Management” on page 12
 “Logging and Auditing Activities” on page 12

Blaze Advisor Authentication

Authentication is the process of determining if a user or entity is who they
claim to be and serves as the foundation for enforcement of subsequent access
control policies. Blaze Advisor recommends that you implement authentication
for users who need to access your rule project, rule maintenance application,
or deployed rule service according to your existing corporate authentication
policies and procedures. Blaze Advisor repository authentication is usually
handled externally, for example through the use of a third-party LDAP-based
system.
The Single Sign-on and Embedding RMA Example included with your Blaze
Advisor installation demonstrates how you can implement a Single Sign-on
(SSO) environment for accessing RMAs. After authenticating a user upon sign-
on through an LDAP server, the user credentials are stored as session
attributes, so users are not required to enter their credentials through the sign-
on screen for each application, see the Single Sign-on and Embedding an RMA
Example” in the FICO Blaze Advisor Help.

Blaze Advisor Authorization

User authorization is the process of controlling what actions authenticated
users can perform on which repository entities. Blaze Advisor recommends that
you apply your organization’s best practices for authorizing users to areas of
the rule project, rule maintenance application, or deployed rule service as
appropriate.
For example you can use the following approach to identify the users, tasks,
resources, and constraints:
 Identify the resources that need to be protected. Examples of Blaze
Advisor resources include repository entities such as business objects, rules
and rulesets, decision metaphors, and template and instances.
 Identify the actions/operations that can and/or cannot be performed
over the Blaze Advisor resources. Typical operations include reading,
writing, and creating a new instance, and modifying or deleting an existing
instance.

10 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

 Identify the roles in the application. These typically can be obtained from
the use-case scenarios for the application where they are often represented
as the actors or subjects. It is important at this stage to identify hierarchies
as well. Applications must be coded to ensure users can be segmented by
role with appropriate authorization/privilege level assignments (Separation
of Duties). For a description of some typical Blaze Advisor roles, see “Roles
and Responsibilities” on page 6.
 Identify the authorization constraints. This steps aims to bring the
resources, the actions/operations that may be performed on those
resources, and the roles together to define which roles can perform what
operations. For instance, you may want to limit your users with the
Business Analyst role to only editing instances in the RMA whereas you may
want your Rule Writer to have access to both the repository entities in the
Blaze Advisor IDE as well as the instances in the RMA.
Blaze Advisor provides an Authorization Manager interface that can be used to
implement authorization services for a repository. This Authorization Manager
interface can be written to check the login credentials stored in different types
of files, systems, or services to authenticate and authorize users.
The Blaze Advisor Authorization Manager framework is the proper mechanism
for registering an external system or building your own authorization system.
The Authorization Manager can be activated for any type of operation (create,
modify, delete, check out/in, promote, list…) on any entity by any user.
The Authorization Manager is registered at the repository level and therefore
applies to all connections including the Blaze Advisor IDE for the technical
users, such as the Rule Writer, and rule maintenance application for the
“Authorization Manager Example” on page 5 users, such as the Business
Analyst. See “Authentication and Authorization Manager Example” in the FICO
Blaze Advisor Help.
For fine-grained authorization management, the ideal solution is to manage the
user/group authorization in an external system such as LDAP or database.
Administrators can grant access to the entities in the repository as appropriate.
A synchronization mechanism must take place in order to reflect the content of
the repository in the external system.
In order to reduce the administration tasks, authorization management can
also be implemented as a routine based on groups. For example users can edit
anything that is owned by their group but have read-only or no access to rules
owned by other groups. This mechanism can be delegated to an external
system and be tailored to operate on management properties. As of today,
authorization manager implementations typically grant and restrict access per
folder and/or groups of files as file-level authorization management is viewed
as incurring too much administrative overhead .
If you want to provide authorization management at the rule maintenance
application mainly for your business users without configuring an Authorization
Manager at the repository-level, see “Managing Instances Using Life Cycle
Management” in DevelopingRuleMaintenanceApplications.pdf .

Fair Isaac Corporation Confidential and Proprietary Information 11

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

Blaze Advisor Content At Rest Management

Protection of critical organizational assets is best done in a layered manner
ensuring that if one security layer/mechanism is compromised that the
trespasser immediately encounters another “wall.” For many organizations, the
business logic encapsulated in its business rules represent a company’s critical
competitive market advantage and, as such, need to be protected at all costs.
Under such circumstances the Blaze Advisor converter facility can be used to
encrypt repository content thereby preventing someone who has gained
unauthorized access to the server that physically hosts the repository from
understanding the content. See “Implementing Content Protection for
Repository Items” in ManagingRepositories.pdf .

Logging and Auditing Activities

Blaze Advisor recommends that you provide logging information for audit trails
to support authentication and authorization compliance. We recommend that
whenever possible, audit trails be created to maintain records of activity by
system and application processes, as well as by user activity of systems and
applications.
These trails should provide valuable information to facilitate security objectives
such as intrusion detection by unauthorized users and malicious insider
attacks. For example, application logs can identify where authorization failures
have taken place and provide necessary information for corrective actions to be
taken by system administrators; logs should hold information needed to trace
events to a specific user account; contain information related to the authorized
and unauthorized use or attempted misuse of resources.

Repository Content Organization Practices

The repository structure reflects the project breakdown and the units of reuse.
For example, a single template containing the entire set of sub-templates will
be difficult to reuse because of the complexity, while smaller units of reuse will
ensure more success in the long term assuming that they are well-organized.

General Folder Organization

A repository can be dedicated to a single domain or shared across projects,
departments, or the enterprise. When common management and
administration is a key, customers usually select an approach where the
repository is shared across the enterprise. For optimal reuse, repository
contents are organized in a folder-based hierarchical structure, breaking down
the entities in terms of geography, business units, or any other logical
organization that is relevant in terms of business rules management.
Frequently, those units correspond to business areas.
Customers who want to expose their rules to business users, require a more
structured folder organization that can ease reusability, maintainability, and
manageability.

12 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

The following breakdown is recommended:

 Business Library contains the business rules (in template instances) that
are maintained by the business users in the rule maintenance application.
 Technical Library contains the following:
 Technical rules maintained by the technical users in the
Blaze Advisor IDE .
 Any SRL entities needed to support the rules such as Business Object
Model definitions, functions, and ruleflows, etc.
 Any templates and providers
 Rules Services Library contains the following:
 The files that are deployed in the production application(s) that are
maintained by the rules architect and/or the developer in the
Blaze Advisor IDE .
 Projects assembling all or part of the Technical Library and some
Business Library folders.
 Testing Library contains the following:
 The rules services to be unit tested and maintained by the rules
architect and/or the developer in the IDE
 Test data and/or a mechanism to load test data from a data warehouse
 Test ruleflow that strings together one or more rules services
 Project assembling one or more rules services projects, test data, and
test ruleflow

Business Library
The Business Library content is typically exposed to the business users when
they have the ability to navigate within the repository and open a selection of
files or projects.
We recommend that the folder structure follows a natural navigation scheme
for the business users. Both intuitive and systematic, such an organizational
breakdown will also immediately facilitate the understanding of the repository
by its main users, and will also simplify the security access down the road.
Depending on the expected usage of the repository through the projects and
organizations, other organizational guidelines may apply. For example, some
customers have organized their repository along the lines of their
organizational structure. Business users can then access only the specific rules
that apply to their business unit or territory/geography.
The fundamental recommendation is thus to start by considering the
management constraints that apply to the repository usage both short and long
term, and structure the repository along those lines. That will simplify both the
repository navigation for the business users, and the set up of the security and
partition policies by the administrators.
When the same business users maintain several projects, we recommend that
you list the project as the last classification. They will then have an easier time
navigating back and forth.

Fair Isaac Corporation Confidential and Proprietary Information 13

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

Technical Library
The Technical Library content is typically managed by the rules architect and
rules developers. The authoring of this content is done exclusively in the
Blaze Advisor IDE .

Business Object Model

The business object model has a particular role in the rules projects. Typically
a single object model is common to the entire rule project. It is very often
reused across multiple projects.
The business object model is traditionally imported from an external source
(Java classes, COBOL copybooks, XML schemas or databases). Business object
models are top-level entities. One or more business object models can be
grouped in a designated “Object Model” project that includes all object model
entities. This project can be included in other projects.
Object model separation/isolation provides multiple advantages:
 The object model can be imported into multiple projects.
 The object model is not polluted with any project specific rules.
 The object model can evolve independently of the rules projects. This is
critical for standard industry-specific object models that are not maintained
in-house. Assuming that the structure mostly expands, the existing set of
rules is likely to be still applicable. Furthermore, some applications may
require the same rules to apply to two concurrent versions of the object
model.
 Multiple object model implementations may be used for the same set of
rules. This is still an infrequent situation as most companies rely on XML for
portability. In some cases, the same rules may apply to an object model
implemented both in Java and COBOL classes or any other external
structure. The rule instances must be assembled with the appropriate
object model at deployment time.
 With a properly structured set of generic templates, changes to the
implementation of the business object model will not propagate into all the
templates that generate code using them. The changes can remain isolated
to the generic templates. These type of generic templates are sometimes
called “business vocabulary” or “business terms”.
The object model is typically located in the Technical Library under its own
folder, as shown in this figure. This allows multiple projects to use the same
object model.

14 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

Utility Templates and Providers

Utility templates is a term used to refer to templates and providers that can be
used and reused throughout the repository.
Value List Providers are a typical example. To avoid updating multiple
templates when a Value List Provider changes, the provider should be defined
in one location and referred to by a Value Holder in the templates that need to
use it.
Utility templates – such as effective dates or audit trace – should also be
maintained in a one location and referred to by the Rule or Ruleset Templates.
We recommend that you locate the utility templates and providers in a folder in
the common area of the Technical Library for easy access.

Fair Isaac Corporation Confidential and Proprietary Information 15

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

SRL Entities and Templates

SRL entities and templates are maintained by the technical users. It is
important to keep security and migration issues in mind when organizing the
project file system.
We recommend storing them in the Technical Library. Decision steps should be
segmented in their own organizational structure. The segmentation should be
intuitive and as self-contained as possible to ensure ease of reuse across
multiple projects.

In this example, a ruleflow sequencing the various steps may be located in the
Underwriting directory. Each one of the steps could be further segmented with

16 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

the main function of ruleset at the top level, other functionals in one folder,
and templates in another folder.
Some SRL entities such as enumerations, global patterns, variables, and
generic templates should be located with the object model utility templates in
the Object Model folder.

Rules Services
In general terms, the deployment of rule services is the role of the technical
staff, and fairly independent of the work done by the Business Users. The
recommendation is to reflect that distinction in the organization of the
repository.
A rule service may require a specific signature or may receive a custom data
structure as a parameter. When writing this invocation stub, we recommend
that you externalize the template in its own deployment folder, called Rules
Services in the figure below.
Frequently, ruleflows are specific to rule services and can be organized
following the same principles. Ruleflows used in this way implement the
graphical weaving of various business rules entities into executable rule
services that can be deployed.
The primary benefit is to avoid repository pollution. When this information is
self-contained, the rules are independent of deployment artifacts and therefore
can easily be deployed in other projects. The deployment folder may contain
several folders with deployment templates for each target.
The deployment folders also contain the object model instance, the rule
instances, and the deployment instance. The files are referred to by the rule
server and/or deployment manager at runtime.

Fair Isaac Corporation Confidential and Proprietary Information 17

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

Testing
Prior to deploying a rule service, it is good practice to set up regression tests
for unit testing within the repository. Testing follows the same guidelines as
deployment:
 Testing templates should be created. The testing templates may trigger the
testing of a single “rule” instance or chain all rulesets of the rule instances
in a testing ruleflow. The testing template is typically responsible for the
creation of test data.
 Testing project files should include the object model instance, the rule
instances, and the testing instance. This project is used for testing in the
Blaze Advisor IDE .
 This testing framework allows technical users to unit test the rules
maintained by the business users. The same data sample can be reused for
multiple rule projects.

Technical Library Authoring Practices and

Patterns
Adopt, use, and enforce a single, organization-wide set of Structure Rule
Language (SRL) coding conventions.
Like many programming languages, SRL has a rich syntax that allows users to
capture an almost infinite breadth and depth of decisioning logic. And like any
such programming language, this rich grammar, if not used with some level of
discipline, can result in rules (i.e., code) that’s not as easy to understand, and
therefore maintain, test and reuse, as it might otherwise be.
The needed stylistic disciplines can be grouped into the following three broad
categories:
 SRL entity naming conventions

18 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

 SRL entity formatting conventions

 SRL entity documentation conventions
The subsections that follow contain FICO’s recommendations regarding each of
these conventions. It should be noted that more important than following these
specific conventions is for each organization to adopt a set of conventions
(which may or may not be derived from our conventions). Further, any
deviation from the conventions should be documented to limit the confusion
among the target user community.
The following references for further information:
 “Blaze Advisor Rules Syntax” in Reference.pdf
 Vermeulen, A. et al. The Elements of Java Style. New York: SIGS Books/
Cambridge University Press, 2000.ISBN 0-521-77768-2.

SRL Entity Naming Conventions

Blaze Advisor entities must be assigned unique identifiers. Syntactically, these
identifiers must respect certain restrictions. Blaze Advisor places the following
restrictions on entity names:
 Identifiers consist of one or more letters (A–Z, a–z), digits (0–9), and
underscores (_), beginning with a letter. There is no limit to the number of
characters; all characters are significant.
 Either ASCII or Unicode letters or digits are allowed
 Corresponding uppercase and lowercase letters are not considered
identical; i.e., Blaze Advisor is case-sensitive
 The underscore is a meaningful character and not just a null separator
 Spaces and special characters are not allowed
The rule engine reserves certain words. You cannot use them as ordinary
identifiers. A list of reserved words is provided, see “Blaze Advisor Rules
Syntax” in Reference.pdf .
Semantically, SRL entity names should be comprised one or more concatenated
meaningful, domain-familiar words that together provide a reader with insights
into the entity’s purpose.

Note These restrictions do not apply to ruleflow and task names. For those,
the user should select names that are the most meaningful from a business
point of view. Those names support blank spaces.

Rule Naming Conventions

Use the following rule naming convention recommendations:
 Avoid overly long names.
Rule names should be long enough to adequately describe the rule’s
purpose but no longer.
 Capitalize the first letter of each word included in the rule name.
This stylist convention improves readability/understandability.

Fair Isaac Corporation Confidential and Proprietary Information 19

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

 Capitalize only first letter in acronyms.

This helps to avoid confusion when uppercase letters are used for word
separators.
 Avoid non-standard abbreviations.
Use only abbreviations that are commonly used in the target application
domain.
 Do not use names that differ only in case, this helps to avoid confusion.
For example, a rule that is used to evaluate whether a loan application has
a credit report might be named, CreditBureauReportRequired .

Variable Naming Conventions

Use the following variable naming convention recommendations:
 Follow all previously listed rule naming conventions except as noted. See
“SRL Entity Naming Conventions” on page 19.
 Use nouns to name variables. Variables represent things as opposed to
actions thus the use of nouns.
 Capitalize the first letter of each word included in the variable name except
the first one. Use a lowercase letter for the first letter in a variable name
and capitalize the first letter of each subsequent word included in name so
you can visually differentiate between a rule and a variable name.
For example, a variable used for a credit card applicant’s data might be
named, theApplicant .

Constant Naming Conventions

Use the following constant naming convention recommendations:
 Follow all previously listed rule naming conventions except as noted. See
“SRL Entity Naming Conventions” on page 19.
 Use nouns to name constants. Constants represent things as opposed to
actions thus the use of nouns.
 Capitalize all letters in constant names so you can visually differentiate
between a rule and a constant name.
 Separate words in constant names by ‘_’ so others can understand the
constant’s purpose.
For example, a constant used for the minimal credit score allowed by a
company might be named, MIN_CREDIT_SCORE .

Functional Naming Conventions

Functionals are rulesets, decision tables, decision trees, decision graphs, score
models, and SRL functions. Use the following functional naming convention
recommendations:
 Follow all previously listed rule naming conventions except as noted. See
“SRL Entity Naming Conventions” on page 19.
 Use verbs to name functionals.

20 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

 Functionals represent actions thus the use of verbs.

For example, a decision table that ensures that all data provided with an
insurance claim is correct might be named ValidateClaimData .

Template Entity Naming Conventions

Template entities are templates, providers, value holders and template
instances. Use the following naming convention recommendations:
 Separate words in template entity names by ‘_ ’ so others can understand
the entity’s purpose.
 Use a suffix to name global templates and providers to differentiate from
equivalent SRL entities. For example, your project may include rulesets and
Ruleset Templates.
 Do not use a suffix for local templates, value holders, and templates
instances. Adding a suffix makes the path to these items longer in the
Placeholder wizards in the Blaze Advisor IDE .
For example, a template for evaluating television usage might be named,
TV Usage Condition Template .

SRL Entity Formatting Conventions

The following simple formatting conventions can greatly improve rule
readability and therefore, understandability and maintainability:
 if, then and else statements should begin on separate lines.
 Nested statements should be uniformly indented.
 Each condition/action statement or expression should be on its own line.
 and and or keywords should be placed consistently at the end or beginning
of statement lines.
 Use white space where appropriate to make the SRL easy to read.
 Select a notational convention for your SRL. Blaze Advisor supports three
alternate – but equivalent – notational conventions:
 objectName.propertyName (the dot notation)
 the propertyName of objectName
 objectName’s propertyName
 Use parenthesis to clarify statement sequencing instead of relying on
implicit SRL operator precedent rules (especially and/or primarily with
complex rule statements).

SRL Entity Documentation Conventions

Use the following SRL entity documentation convention recommendations:
 Add comments only if they will aid others in understanding your rule(s).
 Alternatively, use the management properties facility in order to attach
information relevant to your project, application, organization and/or
domain to these entities.

Fair Isaac Corporation Confidential and Proprietary Information 21

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

Writing Rules for Performance

The following sections provide information to help you to avoid performance
problems in your rule project.
 “Minimizing the use of Nested if-then-else Statements in Rules” on page 22
 “Comparing the use of Patterns Versus Quantified Expressions” on page 23
 “Minimizing the use of Multiple Patterns” on page 23
 “Avoiding Repeated SRL Code in Templates” on page 24
 “Avoiding the Excessive Use of Or Statements in Rule Conditions” on page
24

Minimizing the use of Nested if-then-else Statements in

Rules
Minimize the nesting of rules (i.e., nested if statements) to improve rule
performance, maintainability and extensibility. Like many programming
languages, SRL has a rich syntax that allows users to capture an almost infinite
breadth and depth of decisioning logic. This rich grammar, if not used with
some level of discipline, can result in rules that are difficult to maintain, test,
and reuse.
Syntactically, SRL supports an ability to infinitely nest if statements. Though it
can be appealing to express business logic through nested if statements, the
rule understandability, maintainability, and extensibility decreases in direct
proportion to the depth of the nested statements. As such, nested expressions
should be avoided and/or minimized whenever possible.
Nested if statements do not take full advantage of the rule inferencing and
therefore may have a negative impact on performance when executing using
the Rete engine. The Rete (default) execution mode combines all the condition
into a decision network where individual conditions can be reused. Only the
left-hand side (LHS) of the rule participates in this network. All nested
conditions are executed for each individual rule independent of their level of
redundancy.

Example
The following rule does not take advantage of the rule inferencing engine:
if theApplicant’s salary is greater than $200,000
then {
if theApplicant’s homeownersStatus is true
then {
if theApplicant’s address’s state is (“CA” or “NY”)
then {
theApplicant’s offer = “Big City Offer”.
}
}
}

This rule provides better performance characteristics in a large ruleset:

if theApplicant’s salary is greater than $200,000 and
theApplicant’s homeownersStatus is true and
theApplicant’s address’s state is (“CA” or “NY”)
then {

22 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

theApplicant’s offer = “Big City Offer”.

}

Comparing the use of Patterns Versus Quantified

Expressions
When you want to optimize the execution of rules when operating on a
collection of objects, you can use patterns, and quantified expressions.
Patterns and quantified expressions both execute rules when objects satisfy a
condition. However, they differ in the way that they execute rules by the rule
engine.
 Patterns execute the satisfied rule for each object, one at a time.
Use patterns when you need to keep track of each object that satisfies the
rule, such as in action processing.
 Quantified expressions execute the satisfied rule at once for the entire
collection.
Use quantified expressions when:
 You do not need to keep track of each object that satisfied the rule.
 You need to check that a given number of objects satisfy the rule
(exactly 3, at least 1, etc.).

Example
This rule uses a pattern:
if anyBorrower’s FICO is less than 650
then
theApplication.justifications.append(anyBorrowers’s name “FICO score is less than
650”).

This rule uses a quantified expression:

if at least one Borrower
satisfies FICO is less than 650
then
theApplication.justifications.append(“At least one borrower’s FICO score is less
than 650”).

This rule would be executed only once per application.

Minimizing the use of Multiple Patterns

Minimize the number of patterns to improve rule performance. Patterns are a
convenient mechanism for expressing rules that apply to any object of a given
kind. When rules refer to different classes, patterns can be expensive. In some
case, writing an equivalent rule that does not rely on multiple patterns can lead
to better performance.

Example
This rule uses multiple patterns:
if (anyApplications’s amount is greater than $350,000
and anyBorrowers’s FICO is less than 650
and anyApplication.borrowers contain anyBorrower)

Fair Isaac Corporation Confidential and Proprietary Information 23

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

then {
anyApplication’s status = REFERRED.
anyApplication.justifications.append(anyBorrowers’s name “FICO score is less than
650”).
}

There are two simple strategies for reducing the number of patterns.
//If the rules are executed one application at a time, the first pattern is
//unnecessary. The rule can be re-written as follows:
if (theApplication’s amount is greater than $350,000
and anyBorrower’s FICO is less than 650
and theApplication.borrowers contains anyBorrower)
then{
theApplication’s status = REFERRED.
theApplciation.justifications.append(anyBorrower’s name “FICO score is less than
650”).
}

If the rule requires only one borrower under the 650 FICO limit, the rule can be
re-written as follows:
if (anyApplication’s amount is greater than $350,000
and at least one Borrower in anyApplication.borrowers
satisfied FICO is less than 650)
then {
anyApplication’s status = REFERRED.
anyApplication.justifications.append(“At least one borrower’s FICO score is less
than 650”).
}

This rule would be executed only once per application.

Avoiding Repeated SRL Code in Templates

Because many instances can be generated from a single template, repeated
SRL code in a template can quickly multiply and effect project performance and
compilation time. A common strategy is to put the repeated SRL in a function
and then replace the occurrences of the SRL in the template with calls to that
function.

Avoiding the Excessive Use of Or Statements in Rule

Conditions
In general, it is a good practice to minimize the use of complicated conditional
statements in a rule. However, while using Rete or Optimized Inference
execution mode, rule conditions that contain multiple or statements are
particularly problematic as doing so can seriously degrade performance.

Business Library Authoring Practices and

Patterns
Business users demand ownership of the business rules but do not want to
learn syntax and coding principles. A successful rule maintenance application
exposes business rules and policies in an intuitive manner. These sections
describe some best practices for managing your Business Library.
 “Effective Dating and Versioning” on page 25

24 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

 “Graphical Rule Editors” on page 27

Effective Dating and Versioning

You can use the Effective Dates and Versioning features to manage your rules
over time, to track changes, and to execute the relevant rules.
 Effective dating is a better fit when the following conditions are present:
 The business user has full control over the activation/deactivation dates
of the “versions” of a rule.
 The business user can get rid of any “version” of a rule.
 The application must concurrently support several “versions” of a rule.
 Versioning is a better fit when the following conditions are present:
 “Versions” must automatically record the user name and timestamp.
 Only the most current “version” of a rule is active in the running
application.
Very often these two concepts work jointly. The business user creates one or
several “flavors” of the same rule, with different content based on effective
dates. Every time the rules are modified, the versioning service creates a
“version” of the entire set. This configuration allows the business user to
define how many rules should be kept alive in the deployed application. The
versioning history shows when rules were added and/or removed from the
active set.
Effective dates are used to reflect policy changes over time.
 Regulation changes, company strategy changes, etc.
 Several “flavors” of the same policy can coexist for different timeframes.
 All flavors of the same rules are active in the deployed rule service.
 Rules are applied according to their “effective dates”.
Rule versioning is used to keep track of rule changes over time.
 Audit trail and multi-user locking.
 Past versions can be viewed.
 Past versions can be resurrected, overriding the current version.
 Only the current version is executed.

Effective Dating
Effective dates are used for rules that are loaded at runtime and can be
activated/deactivated based on the execution time. This concept is very
important when transactions are not executed at the system clock time. The
execution date and time should sometimes be set by the application data.
Blaze Advisor provides built-in support for effective dates. Effective dates are
used to constrain the applicability of rules to only the those situations in which
the processing time matches the time period specified by the corresponding
clause. By default, the processing time taken into account by Blaze Advisor is
the system time on the machine it is executing on. However, the processing

Fair Isaac Corporation Confidential and Proprietary Information 25

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

time can be modified at any point in time in SRL and programmatically in Java
. Typically, the processing time will be set to a time that is logically derived
from the transaction data or objects, such as an application submission date.
This figure shows a rule that uses effective dates.

Effective dates can be exposed to the business user in the rule maintenance
application. In general, the business user has the capability to create one or
more copies of the same rule structure with different effective dates. The rule
structure can be a rule or a more complex entity such as a decision tree or a
decision table. In some cases, effective dates have been applied to process
flows.

Setting the Processing Date

By default Blaze Advisor uses the system date as processing date. This
behavior can be altered to set the processing date dynamically for all or part of
the rules service execution.
The processing date is obtained via the clock() built-in. The system date is
obtained via the calendar() built-in.

Built-in Description
clock().timestamp() Reads the current processing date
clock().resetClock(“Nov 1, 2011”) Sets the processing date

This figure shows a rule that uses the clock() built-in.

Versioning
During the template design phase, the Rules Architect has the flexibility to set
the versioning granularity. Each value holder is a candidate for “independent
storage”. By clicking the Instances Stored Separately check box, the
technical user specifies that the content of this value holder should be
versioned and locked, independently from its parent structure. This figure
shows a value holder where the check box has been selected.

26 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

The level of granularity can be the rule service, the ruleset, or the rule. Entities
managed by different groups are managed independently and therefore
versioned independently. Typically rules that follow the “exception override”
pattern are likely candidates for rule level versioning.

Graphical Rule Editors

The use of graphical rule editors in the Blaze Advisor IDE should be
encouraged to maximize a user’s ability to understand the decisioning logic.
SRL syntax is extensive and powerful. Although its English-like nature makes it
readable by business analysts, it requires developer skills to author it. We
recommend that rule maintenance applications abstract the technical
constructs into policies that do not expose the if-then-else rule structure. The
graphical rule editors ensure a better understanding of the policy by the
business users and a shorter learning-curve. Constraints built into those editors
also ensure a safe environment for the business community, minimizing the risk
for them to “get into trouble”.
Graphical rule editors promote decisioning logic understandability – and
therefore, maintainability – through the visual feedback that they provide to
users. Thus, metaphor editors (such as decision tables, decision trees, decision
graphs, and score models) should be used instead of their SRL-level
equivalents.

Fair Isaac Corporation Confidential and Proprietary Information 27

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

Decision Table Editor

A decision table is a Ruleset Template or model that can be used to capture a
collection of similarly structured rules. Rules similar to the one in this example
can be captured in a decision table:
if (theClaim.planType = “HMO”) and
(theClaim.serviceType = “Office Visit”) and
(theClaim.inOutNetwork = true) and
(theClaim.grossMedicalClaim > 0 USD and
theClaim.grossMedicalClaim < 100.00 USD)
then {
theClaim.approvedClaimPay = ”100% of actual costs”.
theClaim.payee = “Physician”.
}

Decision tables should be used when it is natural for the user community to
conceptualize their decisioning logic in a tabular (table-like) format. Also,
decision tables are the preferred editor when the decisioning logic is
symmetrical, which means that the rules share the same condition and action
terms. Decision tables provide a convenient way to visually validate that the
array of rules that are required have been covered.
The structure of decision tables is fixed. Business users can create any number
of rules but they must follow a given number of conditions and actions. Only
the format and the values in those conditions and action expressions can be
modified.

Decision Tree Editor

A decision tree is a Ruleset Template or model that is used to capture rules
where the rule conditions can refer to the premises of other rule condition
along the same path. Rules similar to the one in this example can be captured
in a decision tree as a series of conditions nodes ending with an action node:
if (theApplicant.cardType = “Gold”) and
(theApplicant.isAHomeowner = true) and
(theApplicant.numberOfCreditCards >= 4 and
theApplicant.numberOfCreditCards <= 5)
then {
theApplicant.creditLimit = 4900.00.
}

Decision trees should be used when it is natural for the user community to
conceptualize their decisioning logic in a hierarchical (tree-like) format. Also,
the rules share a subset of their predicate statements, but the decisioning logic
is (possibly) asymmetrical. Decision trees provides a convenient way to
visualize the different paths in a complex decision process.
The structure of decision trees is flexible. Business users can create rules that
follow a variable number of conditions and actions. The types of conditions and
actions is determined at design time but business users decide which
combination makes sense.

Decision Graph Editor

A decision graph is a Ruleset Template or model that is used to capture rules
where the rule conditions can refer to the premises of other rule condition

28 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

along the same path. Rules similar to the one in this example can be captured
in a decision graph as a series of conditions nodes ending with an action node:
if (theApplicant.totalIncome >= 40000 and
theApplicant.totalIncome < 50000) and
(theApplicant.isAHomeowner = “true”)
then {
theApplicant.recommendedCard = “Standard”.
}

Decision graphs differ from decision trees because they can be viewed and
edited in graph representations in addition to the Leveled Tree representation,
which is very similar to a decision tree. Decision graphs in Leveled Tree
representation and decision trees include only one branch leading into each
node. Decision graphs in a graph representation, however, can include multiple
branches leading into each node. As a result, decision graphs in a graph
representation usually have fewer nodes than trees have.
Like decision trees, decision graphs should be used when it is natural for the
user community to conceptualize their decisioning logic in a hierarchical
format. Also, the rules share a subset of their predicate statements, but the
decisioning logic is (possibly) asymmetrical. Decision graphs provide a
convenient way to visualize the different paths in a complex decision process.

Choosing Between a Decision Graph or a Decision Tree

Choose between a decision graph or a decision tree based on the following
factors:
 A decision graph works best with a large decision model because of the
ability to simplify the graph structure and the ability to filter the overall
graph to work with one part of the graph at a time using highlighting,
slicing, action graphs, and so forth. A decision graph also works well in
environments in which you want to compare two similar, logical methods to
one another structurally or even based on projected performance through
the use of associated data sets. A decision graph however, does include
some limitations regarding the data types that can be associated with
conditions, the data types that can be used for actions, and the amount of
custom processing that can be included. For more information, see
“Understanding the Object Model Considerations Before Creating a Decision
Graph” in DevelopingRuleProjects.pdf .
 A decision tree works best when you require a flexible, customizable
metaphor. A decision tree can use many different kinds of data types with
action nodes and condition nodes, and allows more customization in terms
of SRL code, display choices, and functions. For more information, see
“Decision Graphs” in DevelopingRuleProjects.pdf .

Score Model Editor

Certain groups of rules are used to assign scores to business entities based on
computations and tests on their attributes. Typically, this is done in order to
compute an overall risk level, for example, that summarizes in a single
aggregate value a sophisticated group of risk assessment rules.

Fair Isaac Corporation Confidential and Proprietary Information 29

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

These kinds of rules can be organized using the Score Model Editor. This editor
allows the user to create derived characteristics from the business object
model. It creates groups of tests that “bin” the objects in sections that have
well-defined score increments attached to them. The user can also manage the
audit information that allows the invocation to have a meaningful audit trail
that provides an explanation for the score reached.

Release Management Practices and Patterns

Release management activities are independent of the content of the rule
repository. The following sections are designed to help Blaze Advisor users
understand the specifics of rule component and/or service release
management.
 “Setting up the Environment(s)” on page 30
 “Releasing a Project” on page 30

Setting up the Environment(s)

Blaze Advisor repositories can be organized in several staging areas for
development, testing and production. The number of staging areas is unlimited
and can reflect the environments defined for the quality control needs of your
project. In our experience, we have seen as many as five different testing
environments for a single project.
We recommend separating the “technical” development environment and the
“business” development environment. The former refers to the development
environment for new and/or evolving templates. The latter refers to the
development environment for new instances. Since there is a strong
dependency between the instances and their templates, it is important that
business users’ instances are upgraded to use the final version of the
templates.
Although staging areas can reside in the same repository, repositories
containing production data are traditionally located on different machines.
Production data is typically protected to avoid any unintended overrides. Rules
fall under the same scrutiny. See “Implementing Content Protection for
Repository Items” in ManagingRepositories.pdf .

Releasing a Project
There are several ways of dealing with release management. For some
customers, release management is about releasing rules from one staging area
to the next. For others, release management is about persisting a snapshot of
a given release of the project. That snapshot should contain sufficient
information for resurrecting that release. Blaze Advisor proposes two strategies
for dealing with this type of release management.
Tagging and “release as a copy” are complementary strategies where tagging
should be used for rule service-level release management and copying should

30 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

be used for coarse-grained, component-level release management (similar to

how jar files are used).

Logical Release via Tagging

Release tagging consists of associating meta-information with the version
history. The versioning manager provides APIs for resurrecting the appropriate
version of each component.
That mechanism is the most space-effective way to keep a memory of the exact
recipe for a given release. The extraction mechanism can be used for migrating
the release into the next staging area. If you have opted for quality control
processes, you may want to include an initial systematic tagging step.

Physical Release as a Copy

Another approach to release management is to create a copy of the project.
The released project does not require keeping all the meta-information in
memory, such as versioning history.
Creating a physical copy of the project implies that files are duplicated and
therefore utilize more disk space. It is also important to define naming
conventions early so that releases can be found easily.
The benefit of this mechanism is two-fold. First the maintenance of the
released project is simpler since it does not require the underlying
configuration for branching. Second other projects can refer to the version of
the rules they wish. No complex configuration is needed to extract at
deployment time the appropriate version of the rules to be included in the new
project.
This mechanism is particularly convenient when all releases must be readily
available for:
 Patch maintenance
 Assembly in multiple deployments
We recommend that you enforce authorization to limit modifications on the
released projects. Similar to the concept of Jar files in Java. development, the
content of released projects should be frozen. Since rules are more likely to
change for fixing the business logic, we let the repository administrator make
that decision using the authorization manager.

Release Location
Releases can be located anywhere in the repository or in another repository.
For ease of access, we recommend that you locate your released projects in the
folder named Releases and identify each one with a unique release number.
There are two main approaches you can use to determine a location for your
releases:

Fair Isaac Corporation Confidential and Proprietary Information 31

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

Approach 1: Releases can be stored in a separate directory in the same

repository as the source project. In the example below you see the released
project in the Releases folder:

The advantage of this approach is that it is easy to locate.

Approach 2: Releases can be stored in a central location in another repository
located on the same machine or a machine on a network. The Published AAA
Project in this figure has been published to a Deployments repository.

The advantage of this approach is that the releases may be located far away
from the source project.

32 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

Quality Control
When rules are promoted to the testing environment, several strategies can be
applied for validating the component/service quality.

Basic Validation
When a group of rules is a candidate for promotion to the testing area, basic
validation typically includes a compilation test. Compilation errors and
warnings can be reported to the development teams.
Conflict detection reports can also be executed to analyze the resulting rules
project. The first level of testing would be to report on the compilation errors
and conflict detection reports to the appropriate recipient.

Manual Simulation and Testing

When rules are modified by the development team, developers can create test
cases on the fly and test the new functionality and/or the new logic.
Rules modified by the business users can also be tested by them in a
deployment attached to the rule maintenance application. A number of options
can be offered including:
 Users can select the test sample from a library of existing samples
 Test sample can be entered in a simple user interface. This solution is only
suitable when the object model is small and straight-forward.
 Test sample can be uploaded onto the server. Business users can then
create test cases in a familiar tool such as Microsoft Excel.
The interactions and results can be customized to fit the business users’
expectations.

Automated Regression Tests

Automated regression tests are typically performed on the rules prior to
promotion.
Test cases defined manually by the business users can be gathered throughout
the development phase. The regression suite can then be used to validate that
none of the rules are broken due to the rule changes.
Simulations can also be performed on a sample database extracted from
production. Business users can run a simulation to evaluate the impact of the
new business logic on the past six months of applications, or on the existing
customer population. These simulations are vital to verifying that rule changes
comply with an organization’s business goals and objectives.

Importing or Exporting a Repository

The quality control / quality assurance processes can be enforced when rules
are migrated ( promoted ) from one staging area to the next.

Fair Isaac Corporation Confidential and Proprietary Information 33

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

During a typical promotion process, the rules must be tested. This includes first
and foremost the basic compilation validation. After the compilation test goes
through, regression tests should be performed to validate that the logic is
coherent with the business.
The promotion process then consists of migrating the rules to the next
repository. This process can be monitored manually. Most customers have
automated the process.
Blaze Advisor includes an Import and Export wizards. The wizards can extract
the portion of the repository that is of interest and import those rules inside
the target repository. This mechanism is used when the repositories have been
implemented with different storage mechanisms.
When both repositories have the same structure, the rules can be imported and
exported using low-level tools provided by the infrastructure. File-based
repositories can use simple file copying implemented via FTP, SSH, etc.
Database-based repositories must use a database import/export approach.
The technical team in charge of implementing this process must make decisions
on the most appropriate mechanism for the promotion process, whether or not
the history must be kept and migrated, and which files should be migrated.
When only business users are in charge of the rule maintenance application,
does it make sense to migrate the instance files only.
Scripts can be written and scheduled for automatic execution based on selected
triggering events.
It is prudent to couple the rule promotion process with a low level backup
mechanism. The target environment can be backed up prior to the import.
Once imported, the target environment can be tested. The process can either
notify the administrator or restore the old rules if the tests fail.
This diagram describes an example of promotion process. This simplification
assumes only two separate environments, while most customers have at least
three (Development, Testing, Production).

34 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

Deployment and Execution Practices and

Patterns
In general terms, the overall application architecture into which rule services
get deployed is defined by technical teams, responding to considerations that
are independent of the concerns of business users, such as response times,
scalability, distribution through multiple servers or locations.
Moreover, organizations often define their own workflow to deploy changes to
running applications. Some organizations encourage the direct deployment of
changes made by business users to the applications (through the usage of
properly configured rule maintenance applications), others impose elaborate

Fair Isaac Corporation Confidential and Proprietary Information 35

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

workflows, involving staged deployment to test environments first, then

deployment environments, with full audit and checks by specific organizations
and processes.
For that reason, the recommendation is to define the rule service deployments
in such a way that the rule service:
 Appears to the rest of the software components as a legitimate component
satisfying the constraints imposed by the architecture adopted for the
application.
 Provides the best trade-off between performance and flexibility in said
architecture.
 Offers the best flexibility in terms of rules re-deployment that is compatible
with the deployment workflow chosen by the architecture adopted for the
application.
Note that Blaze Advisor offers significant support for deployment through its
wizard-driven Quick Deployer which guides the users through the sometimes
complex steps required to deploy any piece of software into application
servers. It is recommended that the Quick Deployer be used, and that, if
necessary, the output files be adjusted, as opposed to creating deployments
manually.

Execution Mode
Each ruleset, decision table, decision tree, decision graph, or score model can
be configured to be executed in one of three possible modes:
 Rete or Optimized Inference
 Sequential
 Compiled Sequential
The standard execution mode is a Rete-based execution. Rete is an algorithm
that exhibits excellent scalability features when the number of rules, and in
particular the number of repeated evaluation fragments in the rule premises,
grows while the number of objects they are executed against does not explode.
This is an interpreted mode.

Note When using Rete or Optimized Inference execution mode, avoid the
excessive use of or statements in rule conditions. Doing so can significantly
degrade performance.
The compiled sequential mode replaces the Rete-based execution by the
execution of Java code that is emitted at project compilation time by
Blaze Advisor. In this mode, the rules are executed in native Java code
sequentially, one after the other, for all objects. When the objects being
manipulated are natively Java objects, this approach allows the Java virtual
machine to optimize the rules code through its various hotspot technologies,
thus allowing this approach to have significantly better performance
characteristics as the number of rules does not explode and the number of
objects does.
The key semantic difference between the two modes is the unavailability of
rule re-evaluation in the sequential modes. In sequential mode (compiled or

36 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

not), if a rule has been evaluated, it will not be re-evaluated in the same
session or invocation unless explicitly required by the code. It should be noted
that there are a number of cases of rulebases in which re-evaluation of rules is
used as a side effect to write evaluation loops, which can be done explicitly in
Blaze Advisor in both modes.

Pre-compiling Rule Services

Blaze Advisor makes it possible for the deployment staff to prepare ‘pre-
compiled’ rule services that can avoid the compilation step by simply loading
pre-compiled serialized rule service execution contexts. In general, this speeds
up the initial loading of rule services.
It is possible to also pre-initialize those serialized rule service execution
contexts by invoking, at deployment time, a function within the rule project
that can be used to set up initial values.
Pre-compilation is also used for deploying rule projects into restricted
environments. The precompiled rules cannot be modified. For example,
precompiled rules can be injected into a production environment instead of an
entire repository.

Deployment Manager
Rule services can be configured with the deployment manager facilities. A
deployment manager is a software component that either monitors the
repository or is notified programmatically of changes to the projects for rule
services, and is responsible for assembling new deployed versions of them,
making them available to the running rule services for them to reload them.
This allows, only through configuration, to obtain rule service deployments that
can automatically update themselves when the corresponding deployment
manager either detects or is notified of changes in the rule services, without
needing to bring any server or server-side component down or interrupt
transactions already being processed.
The same deployment manager can be used to provide a mechanism to
assemble deployments on the fly, based on configurations stored in the
repository. This could be used to solve the generation of rule services for
different data segments, or to support the management of rule services for ASP
operations.
The Deployment Manager is used in most projects, since updating rules on the
fly without bringing down the system is a key feature of rule engines.
Batch applications typically have different priorities; the primary one being
performance. Many batch applications must run in a limited time window. The
rules are typically not updated during the processing. The overhead of using a
deployment manager is not necessary in that case.

Fair Isaac Corporation Confidential and Proprietary Information 37

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

Rule Server Configuration

The configuration of rule services is governed by deployment descriptors stored
in rule server configuration files. These files are generated by the Quick
Deployer and, are in general, not something that users should modify.
The few exceptions relate to when the user must control the behavior of the
rule service with respect to:
 Allocation of execution contexts to invocations
 Recycling of pre-created execution contexts
 Threading
The user should follow the guidance of the documentation on these issues.

Performance Tuning Tips For Java HotSpot

Virtual Machines
The following are some performance tuning tips for the Java HotSpot Virtual
Machines and links for further information.

Java HotSpot VM Dynamic Optimization Approach

The Java HotSpot VM technology is Java’s answer to the long-standing criticism
made of the performance of applications relying on interpretation of source
code or compiled byte-code when compared to the performance of equivalent
applications compiled and optimized for given hardware and system
architectures.
Java’s approach is interesting because it replaces static compilation time
optimization with a series of technologies that achieve dynamic execution time
optimization of the code the applications effectively run.
In static optimization approaches, the optimization code needs to take into
account all the possible execution paths through the code being executed, and
invariably will make assumptions on the runtime characteristics of the
corresponding application. These assumptions may or not correspond to what
actually happens at runtime. Anybody who has spent time tweaking
optimization flags on “C” compilers can relate to this issue.
Consider now what happens in Java’s approach. There is no optimization made
at compilation time. The compilation is fast, and the generated byte code does
not attempt to optimize anything, thus not making any assumption on the
runtime characteristics of the application. However, the HotSpot VM will spend
cycles analyzing the actual runtime characteristics of the application and
proceed to optimize the code actually being executed. Each optimization made
by the HotSpot VM will result in a performance enhancement for the application
since it is based on what it will have observed of the application’s runtime
characteristics.
The result is that the HotSpot VM will gradually optimize the code being
executed, focusing in on enhancing the performance of that code that is

38 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

executed often, applying deep optimization technologies that would be

impractical and probably impossible to apply statically.
The price to pay for this kind of dynamic optimization is that at given points in
time, CPU cycles are ‘stolen’ from the execution of the current transactions in
order to analyze and optimize future transactions. There are a number of other
technologies in modern architectures such as Java that use the same approach.
Garbage collection is a very common one, in which time is ‘taken’ at certain
points in time to ‘clean up’ (recover memory for unused objects, defragment
memory, etc…) and enhance the performance of the application in terms of
future memory manipulation. While initial implementations of these approaches
tend to be crude, significant efforts are made by the vendors in order to make
these approaches less and less obtrusive., such as the large body of work on
different types of garbage collection approaches. The same is true of dynamic
optimization.
Currently, Java supports at least two large types of dynamic optimization
technologies, embodied in two different Java HotSpot VMs. See http://
www.oracle.com/technetwork/java/hotspotfaq-138619.html.
The following is a short summary:
 Client side HotSpot
This HotSpot VM focuses on simple localized optimizations, yielding good
performance for simple and client-side Java applications after a short
amount of analysis and optimization.
A typical optimization executed by this VM is method in-lining for simple
methods.
 Server side HotSpot
This HotSpot VM focuses on global optimization of long running server-side
processes. After deep analysis and optimization, it can lead to significant
performance gains for server-side applications.
Typical optimizations executed by this VM include but are not limited to
dead code elimination, loop optimization, constant propagation, register
usage optimization, etc…
In general terms, the client HotSpot VM is obtrusive (i.e. its effects can be seen
in the timing of execution of initial transactions), but since it optimizes little, it
is only obtrusive relatively early in the application’s execution and non-
obtrusive later.
The Server HotSpot VM is obtrusive for longer, but is better implemented in the
sense that its effect on each one of the initial transactions is smaller and its
overall optimization effect once applied is more significant.
The choice between these two Java HotSpot VMs depends on the runtime
characteristics of the application being executed, and its tolerance to the
tradeoff between short term obtrusiveness for long term performance gains.
Fortunately, it is fairly simple to select which mode to use, and there is no
change required on the source code or the byte code of the application
(see http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-
140102.html):
 java –Xint … disables all dynamic optimization and executes the byte code
with no attempt to optimize anything
 java –client … (default) enables the Java Client HotSpot VM

Fair Isaac Corporation Confidential and Proprietary Information 39

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

 java –server … enables the Java Server HotSpot VM

Impact on Blaze Advisor Applications

Blaze Advisor applications can be deployed in a number of different modes that
have different behavior with respect to the optimizations that can be expected
from the Java HotSpot VMs and the initial obtrusiveness.
The key difference is between interpreted execution (Rete-based or Sequential)
and compiled sequential execution of rulesets. The following is a short
summary of these three modes:
 Rete-based rule set execution
Rulesets configured to be executed in this mode take advantage of the
standard Rete-based propagation and agenda based execution. This mode
is interesting when the ratio between rules to be considered and objects to
be considered is relatively large and the ratio of rules actually firing to
those considered is small. Typically, tens of thousands of rules versus
hundreds or low thousands objects.
In this execution mode, a significant amount of the Java code executed at
run time tends to reside within the Blaze Advisor rules engine itself.
 Sequential-based rule set execution
When configured in this mode, rulesets are executed exactly as they were
nothing else than a long series of ‘if-then-else’ statements. This mode is
interesting when the ratio of rules actually firing to those considered for
firing is significant.
In this execution mode, a significant amount of the Java code executed at
run time tends to reside within the Blaze Advisor rules engine itself.
 Compiled sequential rule set execution
When configured in this mode, the SRL code corresponding to the ‘if-then-
else’ statements of the ruleset in sequential mode is converted into native
Java code at compilation time. The Java code is then compiled on the fly
and made available to the virtual machine for execution as any Java code.
This mode is interesting in the cases in which the objects are implemented
in Java and the ratio of rules considered to objects considered is relatively
small (a few thousand rules versus tens of thousands to millions of
objects).
In this execution mode, a significant part of the code actually executed at
run time is in the generated code itself, and not in the Blaze Advisor
engine.
The benefits of the dynamic optimization of Java HotSpot VMs depend on the
code actually executed at runtime:
 In the two interpreted modes, the code being optimized is primarily the
code of the Blaze Advisor engine (the part being executed) and the code of
the objects being accessed.
Note that the following depends of course of the ratio between these two
execution path spaces, but in general terms, the code being executed
within the Blaze Advisor engine is limited in size and ends up being
optimized rather quickly.
 In the compiled mode, the code being optimized is primarily the code
generated by Blaze Advisor and the code of the objects being accessed.

40 Fair Isaac Corporation Confidential and Proprietary Information

 FICO Blaze Advisor Best Practices

Again, note that the following depends of course of the ratio between these
two execution path spaces, but in general terms, the code generated by
Blaze Advisor may be significant in size and lend itself to significant
dynamic optimizations. In other words, the effects both in terms of initial
obtrusiveness and long term optimization of the dynamic optimization of
the Java HotSpot VMs will be most remarkable in this mode.
While it is impossible to come up with a general trade-off matrix describing the
various choices, the following table presents a typical case in which the logic
being executed resides mostly in the rules.

Note Only relative values are relevant.

The following table is a typical trade-off matrix.

Interpreted Execution Compiled Sequential

Initial Obtrusiveness  Client HS: Low  Client HS: Low
 Server HS: Medium  Server HS: Large but
progressive
Long Term Performance Gain  Client HS: Low to Medium  Client HS: Medium
 Server HS: Low to Medium  Server HS: Medium to
Large

In terms of assessing the impact of the initial obtrusiveness, the following table
can be considered.

Hotspot Obtrusiveness Obtrusiveness Performance

No dynamic optimization None Over 100,000 transactions:
(java -Xint <app>  18 ms average transaction
time
Client HotSpot dynamic First 1,000 iterations Over 100,000 transactions
optimization  8 transactions between 10  7.8 ms average transaction
(java -client <app> and 100 times slower than time
average
Second 1,000 iterations
 1 transaction between 10
and 100 times slower than
average
No negative impact beyond
2,000 iterations
Server HotSpot dynamic First 1,000 iterations Over 100,000 transactions
optimization  34 transactions between 10  1 ms average transaction
(java -server<app> and 20 times slower than time
average
Second 2,000 to 15000
iterations
 Around 150 transactions
between 10 and 20 times
slower than average
No negative impact beyond
15,000 iterations

Fair Isaac Corporation Confidential and Proprietary Information 41

Chapter 1: Blaze Advisor Best Practices and Usage Patterns

Note
 The important information is in the comparison between the modes in
terms of orders of magnitude and not in the absolute numbers themselves.
 This is just an example. The results will depend on the rules and the
implementation of the objects themselves.
 The table uses an example of a compiled-out sequential mode
Blaze Advisor rules application with a few thousand rules and monitored
through 100,000 invocations.
The following links provide more details on the subject of dynamic optimization
in the various Java HotSpot VMs, as well as some details on the various
garbage collection technologies they use.
General Java HotSpot VM info:
http://www.oracle.com/technetwork/java/hotspotfaq-138619.html
Details on the options on the Java HotSpot VMs:
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-
140102.html

42 Fair Isaac Corporation Confidential and Proprietary Information

Index

A Decision Table Editor 28

decision tables
authentication management
naming conventions 20
best practices 10
Decision Tree Editor 28
authorization management
decision trees
best practices 10
naming conventions 20
B deployments
best practices 35
best practices
authentication management 10 E
authorization management 10
effective dating
deployments 35
best practices 25
effective dating and versioning
overview 25
F
effective dating in rules 25
for using Blaze Advisor 5 folders
privacy management 12 best practices 12
publishing projects 30 formatting conventions for SRL 21
releasing projects 30
repository content 12
J
repository management 8 Java HotSpot VM 38
rule authoring 18
security management 9
N
system date as processing date 26 naming conventions
versioning 26 constants 20
Blaze Advisor rules 19
best practices 5 SRL entities 19
template entities 21
C variables 20
comments naming conventions for functionals 20
convention 21 nested rules 22
constant naming conventions 20
O
D organizing repository folders 12
Decision Graph Editor 28
decision graphs
P
naming conventions 20 patterns
decision metaphors comparing usage with quantified
overview of editors 27 expressions 23
minimizing use 23

Fair Isaac Corporation Confidential and Proprietary Information 43

Index

performance Structured Rule Language (SRL)

rule writing 22 best practices for rules 22
performance guidelines conventions for comments 21
patterns 23 formatting conventions 21
performance tuning naming conventions for constants 20
Java HotSpot VM 38 naming conventions for functionals 20
privacy management 12 naming conventions for rules 19
processing date for rules 26 naming conventions for SRL entities 19
projects naming conventions for template
publishing (best practices) 30 entities 21
releasing (best practices) 30 naming conventions for variables 20
published projects system date for rules 26
best practices 30
V
Q variables
quality control for rules 33 naming conventions 20
quantified expressions versioning
comparing usage with patterns 23 best practices 25, 26

R
released projects
best practices 30
repositories
best practices 8
content organization practices 12
rule naming conventions 19
rules
best practices 18
best practices for performance 22
effective dating 25
formatting conventions 21
nested 22
processing and system dates 26
quality control 33
rulesets
naming conventions 20

S
Score Model Editor 29
score models
naming conventions 20
security management
best practices 9

44 Fair Isaac Corporation Confidential and Proprietary Information