Business Rules and Standards

(1)

1 800 999 2955 from the US 1 415 472 2211 from anywhere [email protected] email

Business Rules and Standards

A Fair Isaac White Paper

Stan Hendryx

Chairman, OMG Business Rules Special Interest Group

(2)

Introduction

The Business Rules Approach is a business governance technique based on explicit rules that are written down and expressed in plain language. These rules are motivated by identifiable and important business factors and are intended to guide or influence business behavior in desired ways. Business rules depend only on the business vocabulary, which consists of terms and facts of the business that are commonly understood by people inthe business when they talk about

the business. As such, business rules are closely related to business processes, procedures and workflows, and serve to govern these business activities. Any substantial organization will have many, many rules, so a practical issue arises about how the rules are managed, disseminated and consistently applied to business transactions to which they apply. A common approach is to incorporate business rules into the information systems of the business. In the Business Rules Approach, business rules are managed outside of the information systems they govern. This paper discusses challenges inherent in transforming rules from their expression in plain business language into executable computer code, in managing the volume of rules and frequent changes of rules, and how standards are evolving to facilitate these processes.

Why the Business Rules Approach?

The Business Rules Approach aims to give business people direct control over their business rules, including prescribing the rules and managing their deployment and enforcement in automated or manual systems.

Business rules have always been owned by the business, but over the past several decades of the information revolution, management and deployment of rule enforcement has usually been delegated to the Information Technology department, which has been expected to incorporate the rules into the designs of the computer systems it provides for the business. Given the state of the art of information technology over the years, incorporating rules into systems generally meant interpreting the plain language rules in terms of computer program logic that became part of the structure of the computer system. Often, rules were not written down by either the

business (which delegated control to IT), nor by IT (which was more interested in managing computer software than managing only business artifacts). Rules often ended up being “implied” by accepted business practices, and details were often missing. It was left to the programmer to divine the rule and program its enforcement into the system from any specified IT requirements. Sometimes, available technology was strained to handle the rule, and

compromises were made for economic or technical reasons, leaving rules only partially implemented, or left to be manually implemented.

(4)

The result of imprecise, incomplete and informal connections between business and IT people during system development is that information systems often fail to meet business needs. Worse, since the rules are embedded

in the structure of the information system and mixed with program control logic, they are often

exceedingly difficult, expensive and time-consuming to change, and can only be changed by IT personnel. These circumstances have resulted both in very high failure rates of IT projects to meet business needs, with associated exorbitant costs, and the need to “redevelop” applications on a periodic basis to meet changing business needs. Because of the limitations of technology, these shortcomings have often been accepted, grudgingly, as part of the cost of system implementations. With the Business Rules Approach, technology is advancing to the point where these costs no longer need to be tolerated, and the business rules returned to the control of the business.

Business Rules Technology

Over the last decade, a new class of enterprise system platform has emerged—the business rule engine, or inference engine, such as Fair Isaac Blaze Advisor. This class of platform provides two main benefits over previous platforms: 1) business rules are treated as data, not as part of the system structure; and 2) the logical relationships between rules are determined by the rule engine at run time. These benefits derive from efficient algorithms used by the rule engines, often derivatives of the Rete algorithm originally developed by Charles Forgy. The first benefit, treating rules as data, enables changes in rules to be made quickly, with no changes to computer programs required, with obvious implications for ease and speed of rule maintenance.

Determining rule relationships at run time means that programmers no longer need to

laboriously construct and program logic trees that give the exact order in which rules need to be evaluated in each situation. “Let the rule engine do it!” Dynamically constructing the rule tree also means that individual rules can be defined declaratively and decoupled from one another for purposes of rule maintenance and deployment. This is an important practical consideration for maintaining large rule bases.

Rule engines provide us with a platform capable of supporting implementation of individual rules that can be dynamically changed. However, there is more that is required for rule engines to meet their full potential. The Rete algorithm can only process rules that are formally defined, with strict syntax, and manipulating software data entities. The production rule format required by rule engines is not plain-text business language, and not all business rule statements are

The high cost of IT project failure.

Nearly one quarter of IT projects fail, and nearly half are challenged in meeting their business goals.† The cost is staggering, estimated to run to $350 billion per year. Of this,

on the order of $200 billion is attributed to inadequate specification of business rules in the system design.

(5)

readily expressed as production rules, so some transformation is required. In order for business people to be able to specify and maintain the rules in their “domain” language, yet for rule engines to be able to process the same rule (meaning) in a production rule format, rule management technology is required.

Blaze Advisor’s Structured Rules Language (SRL) provides a business-readable syntax that is considered one of the more powerful and high-level rule syntaxes available for rule engines. For example, a rule may be written in SRL as:

if customer’s account’s limit is greater than $3000 then set status of application to “preferred”. This syntax does refer to specific, named objects such as customer and account.. A higher level of abstraction may be required for true business users, such as Blaze Advisor Rule Maintenance Application users, who are presented with web pages that define the allowable objects and operations for any particular rule, in a custom rule representation designed to suit their particular business domain.

(6)

Need for Standards with Business

Rules

Although I spoke above about the production rule format, every rule engine vendor has their own proprietary rule language, e.g., Blaze Advisor’s Structured Rule Language (SRL). There is no industry standard production rule representation—yet. Since a large business may have rules in several formats, they will likely need to apply “Enterprise Decision Management” technology using a standardized rule representation that is interoperable across multiple vendors’ products. Also, it would be helpful if vendors of systems for “plain language” rule management (such as business modeling and requirements gathering tools) could have a common format for expressing their rules that could ultimately be transformed into the common production rule

representation. To support the maturation of the Business Rules Approach with products from different vendors that work together for related purposes, standards are needed at many levels.

Fair Isaac Blaze Advisor is committed to providing support for the rule representation standard support as and when it becomes available.

Production rules are rules of the form

if <proposition A is true> then <proposition B is true>.

This is a logical implication, an inference. A production rule may also imply an action:

if <proposition A is true> then <perform action C>.

Production rules can be “chained” together logically: r1: if isRaining then road.isWet; r2: if road.isWet then road.isSlippery; r3: if road.isOily then road.isSlippery; r4: if road.isSlippery then driver.reduceSpeed; Given isRaining, the action driver.reduceSpeed is called for. This is an example of forward chaining, going from premises to conclusions or actions.

Sometimes we need to go from conclusions to premises, backward chaining, e.g., when performing diagnosis:

if patient.hasFlu then patient.hasRunnyNose;

In diagnosis, the system determines the questions to ask: “Does patient have a runny nose?” then determines what conditions are consistent with the observed symptoms.

To assure the meaning of the rule is the same in the system as in the business, the business vocabulary and the business rule format must be transformed into the data elements used by the information system to express and process the rules. With these transformations, each datum and behavior of the information system will then have been consistently and reliably interpreted from, yet be traceable to, the business requirements.

(7)

Viewpoint Models, Transformations

and Model Interchange

To understand the different kinds and levels of standards that are needed and evolving, it is first helpful to understand the concepts of viewpoints, aspects, models, model transformation, and model interchange.

A viewpoint is a position from which a subject is evaluated. Viewpoints are best understood by considering the many stakeholders who are involved with a subject business: owners, managers, advisors, employees, partners, suppliers, customers. Consider also those involved with a subject system: owners, users, analysts, software architects, systems architects, programmers, installers, and operators. Each group has a specific attitude or way of considering the subject—a specific viewpoint. Each group has a set of concerns about the subject that are of paramount interest to that group. Each group also has a specific vocabulary for talking about the subject—business or system—to communicate their viewpoint, and often a unique style of representing their

viewpoint. Note that a business is a different subject from the information system that supports the business; this is an important distinction in modeling.

For example: viewpoints for business rules include the “business owner” viewpoint or perspective, and the “IT designer” viewpoint or perspective.

Each viewpoint has several aspects, particular facets that need to be considered to completely describe the viewpoint. It is common for an aspect to be devoted to addressing one or more of the questions1_{What? How? Where? Who? When? or Why? about the viewpoint.}

For example: an aspect of business rules in an “IT developer” viewpoint is the “motivation” for a business, why a particular system behavior is needed—the business rules.

A description of a subject—a business or an automated information system—from a particular viewpoint is called a model, or viewpoint model. A model is an abstraction of its subject that includes information pertinent to its viewpoint and omits information pertinent to other viewpoints. A complete viewpoint model may be composed of individual models of one or more of the aspects, which together describe all of the aspects of a viewpoint. Since the

different viewpoints of a subject have the subject in common, the viewpoint models of a subject are interdependent. There may be elements in one viewpoint model that correspond to elements in another, but each viewpoint model usually has unique elements as well.

A diagram is a concrete visual representation of part of a model, usually composed of graphical and textual elements. Many diagrams are typically needed to represent a whole model.

Typically, a given model element may appear in more than one diagram, a practice that lends continuity to the set of diagrams of a viewpoint model.

For example: Fair Isaac Blaze Advisor provides editors and browsers that represent models in the physical viewpoint for the data (e.g. Cross Reference Browser), function (e.g,. Function Editor), time (e.g., Ruleflow Editor) and motivation (e.g., Ruleset editor) aspects. In addition, Rule Maintenance Applications generated from Fair Isaac Blaze Advisor cover the logical viewpoint of the motivation aspect with business-specific views of rules.

1_{The questions What, How, Where, Who, When, Why are often quoted with respect to the Zachman Enterprise} Framework for Enterprise Architecture. See www.zifa.com/framework.html

(8)

Separating the concerns of different interest groups by using viewpoint models is a very important technique for managing the complexity of a business or a system throughout its lifecycle. It is very easy for a model to be overcome by complexity. It can be very difficult to create, maintain, understand, validate, communicate, or use a model when concerns of different viewpoints are mingled in a single model. The unique aspects of a viewpoint may change independently of those of the other viewpoints. Maintaining the separation of concerns in different models enables stakeholders to maintain their own viewpoint models, and allows viewpoint models to be reused in different combinations with other viewpoint models. Thus, separating business and technical concerns allows the business model to be maintained independently of the technical models. Separating design concerns from implementation concerns leads to reusable designs. Of course, making changes to one viewpoint model may require corresponding elements in other viewpoint models to be updated, to maintain consistency throughout all the viewpoint models of a subject.

Maintaining consistency among the viewpoint models is where model transformation comes in. For example, a business model will contain certain business entities, references to concrete or abstract things of interest to the business. A business entity may be represented as a certain data structure in a software architecture model of a system for the business. This data structure may in turn be represented as a relational database table and a set of Enterprise Java Beans in an implementation model of the system, as described in the example above. Clearly, if the

description of the business entity changes in the business model, or if required or permitted relationships to other entities (rules) change in the business model, these changes may likely need to be cascaded to the software architecture model and then to the implementation model. Because many such relationships need to be maintained in this way between different viewpoint models of a subject, it is desirable to build the models so that these updates can be accomplished by computer programs (tools) based on transformation rules, avoiding ad hoc entity-by-entity mappings from one viewpoint model to another. A mechanic has a set of tools based on English dimensions. When given a car to repair that is built to metric dimensions, the tools won’t work.

Business Model System Component Model Software Architecture Model Model Transformation Process Transformation Rules Model Transformation

(9)

The same concept applies to models and model transformations. In order for model

transformation tools to be reused on different models, the “dimensions” of the models need to be standardized in certain ways.

Example: the Object Management Group “Model Driven Architecture” provides a three-layer model with idealized transformations between them, which could map onto a use of Blaze Advisor as follows:

The model “dimensions” that need standardizing are the modeling languages. A modeling language is a set of terms, facts, and rules about constructing models of a specific viewpoint for a category of subjects, such as a business person’s view of business processes or business rules, or a system architect’s view of system objects or network communications. Each aspect of each viewpoint needs to be adequately modeled to the satisfaction of its stakeholder group, and this requires different modeling languages for many different aspects and viewpoints. Some language may be able to model some different aspects of different viewpoints, but no universal modeling language has been invented, nor is one likely to be invented, because of inherent differences in representation between different viewpoints, considering differences in the natural languages of the different stakeholder groups. A modeling language can be thought of as a model of a model, or metamodel.

Because a number of modeling languages are required—and these languages are still evolving and being developed—there is a need for modeling languages to work together. This is most evident at the tool level, where software tools that edit or transform models need to be able to read and/or write models that were created by other model editing or transformation tools. Ad hoc tool-by-tool model exchange protocols are not feasible. To enable processing that involves multiple languages, as in model transformation, it is very desirable that the modeling languages involved be defined in a common way. For this purpose, a model of modeling languages,

or meta-metamodel is used. In sum, there are four distinct categories of models involved in

COMPUTATION INDEPENDENT MODEL

Equivalent to “business model” Contains source business rules, or rules defined using

Blaze Advisor rule templates

PLATFORM INDEPENDENT MODEL

Equivalent to object model + rules model

Contains rules model, for example in Structured Rules

Language

PLATFORM DEPENDENT MODEL

Equivalent to Blaze Advisor Rule Server and Engine Choice of execution mode for SRL rules: declarative, sequential or compiled sequential Use of a Rule Maintenance Application Selection of Rule Execution Mode in the IDE

M3 – Meta-metamodel M2 – Metamodel M1 – Model M0 – Model Instance

Meta Levels in the OMG’s MOF schema

(10)

modeling technology (see inset). In the case of a database, for example, we would have 0) the data, 1) a model of the data, also known as the database schema, 2) a metamodel, or language for modeling database schemas, and 3) a meta-metamodel, or model of the schema modeling language.

The Object Management Group (OMG) has provided a standard meta-metamodel, called the

MOF (Meta Object Facility). Models written in different modeling languages that are defined in terms of the MOF can reside in a common repository and their MOF structure can be exploited through a process known as reflection to make possible efficient transformations between models. Reflection is the ability to determine, for any model element, the kind of metamodel element of which the model element is an instance. The UML, for example, is defined as a MOF metamodel, to facilitate interchange and transformations of UML models.

Model interchange standards are needed. Model interchange is needed on several levels. There is a need to interchange both models and metamodels. A complete modeling language has two main parts: 1) semantics (meaning); and 2) syntax (diagrams).

A semantic metamodel may accommodate multiple syntaxes, or outward forms. Different natural or man-made grammar may be used. Rules can be stated in the form of decision tables, decision trees, or scorecards. Different graphical conventions can be used.

For example: it would be advantageous to be able to specify business rules in a modeling language such as UML. Such rules could be more easily transformed into platform-specific 3GL code (when rule management is not required) or Blaze Advisor rules (when rule management is required).

Pragmatics is a third part to a modeling language. Pragmatics has to do with methodology and the way the language is used. Standards bodies are not generally fordealing with

methodology, at least not for modeling and business rules.

Example business rule methodologies include Proteus from Business Rule Solutions, including its semi-formal RuleSpeak language, and the STEP Methodology from Knowledge Partners, Inc. Fair Isaac and KPI have also jointly created a Business Rules plug-in for the Rational Unified Process (RUP) from IBM/Rational Software.

There is often a need to interchange the semantics of a model. Sometimes diagrams need to be interchanged, too. Sometimes we only need to know the structure of models, in order to store them in a repository and to retrieve all or part of a model, without interpreting the model. The MOF meta-metamodel facilitates these different needs, and makes MOF-based tools as

compatible as possible, regardless of the tool’s vendor or specific kind of model the tool works on. The OMG’s MOF-based standard for model interchange is called XMI (XML Metadata Interchange). There is also a Java interface to an MOF repository, called JMI (Java Metadata Interface) that provides access to MOF models and metamodels by Java programs.

In summary, we have seen that there are many complementary and cooperating standards required on which to build out a modern software development toolkit based on the Business Rules Approach and modeling technology.

■ Standards for modeling languages, or metamodels, for different viewpoint models

■ Especially needed are standards for business modeling, for business vocabularies, rules, and processes, in business language, to help close the gap between business and IT

(11)

■ These standards must take into account differences in natural languages and the need to make equivalent models in different natural languages

■ Standards for model semantics and standards for model syntax ■ Standards for representing business rules in different viewpoint models

■ Standards for model transformation, to allow computer programs to “read” models and to accurately convey into technical models the intent of business people as contained in business models

■ Standards for representing models in forms that allow them to be interchanged between tools

■ Standards for runtime interchange formats for use by advanced applications ■ Standards for meta-metamodeling and for interchanging modeling languages ■ Standards for interchanging model diagrams

Many of these standards exist today. Some are in process. Some are planned. Several standards organizations are involved in building the standards infrastructure for the Business Rules Approach.

Business Rule Standards Organizations

Business rules have become a hot topic in standards organizations over the last several years. At first glance, it might appear that there are many competing standards evolving, a disconcerting thought that suggests we might have many “standards” and thus no standard. Fortunately, while there is some competition, the main standards bodies are working together to coordinate their work and prevent this unhappy situation. For the most part, different bodies are addressing different parts of the problem, supported by vendor and user groups that have different needs. These are the principal bodies involved with business rules standards:

■ Object Management Group (OMG) www.omg.org

■ International Organization for Standardization (ISO) www.iso.org

■ Organization for the Advancement of Structured Information Standards (OASIS)

www.oasis-open.org

■ World Wide Web Consortium (W3C) www.w3c.org ■ Java Community Process www.jcp.org

■ RuleML www.ruleml.org

There are also specialist bodies that have been convened to address a particular specification area. Examples include Rule Markup Language Initiative, RuleML www.ruleml.org; Business Process Modeling Initiative, www.bpmi.org; DARPA Agent Markup Language, DAML and DAML+OIL, www.daml.org; and others.

Object Management Group

The OMG Architecture Board has defined the Model Driven Architecture™, MDA, the OMG’s architecture framework, to integrate all work of the OMG and provide the vision for achieving interchange, interoperability and model transformation at all levels. The MDA framework has three viewpoints: Business Model (recently renamed from Computation Independent Model),

(12)

Platform Independent Model (PIM), and Platform Specific Model (PSM). The Business Model corresponds roughly to rows 1 and 2 (contextual and conceptual models) of the Zachman Framework applied to the business or enterprise. The PIM corresponds roughly to row 3 (logical) applied to the information system, and deals with the class of platform. The PSM corresponds roughly to rows 4 and 5 (design and components) applied to the information system, and deals with specific implementation technology. MDA stresses transformation of Business Models to PIMs, and PIMs to PSMs, as a means of gaining control over complexity and reuse of models.

The Analysis and Design Task Force has just completed, or is nearing completion of OMG’s core modeling standards, UML and MOF:

■ UML 2.0, the latest release of the Unified Modeling Language™, now in finalization, which will continue to be the main language modeling for PIM and PSM modeling. This release addressed ease-of-use through a more modular language design, and brought UML and MOF into closer alignment through a shared core model.

■ MOF 2.0, the Meta Object Facility™, is the industry standard meta-metamodeling standard. The MOF 2.0 core is now also the UML 2.0 core. It is also in finalization. All metamodels coming from the OMG, including UML and the business rules metamodels mentioned below, are based on MOF.

■ MOF 2.0 Diagram Interchange Metamodel, which provides standards for modeling tools to interchange model diagrams, in now in finalization.

■ MOF 2.0 Query, View, Transformation Metamodel is an important standard, due for adoption in the fall 2003, that will provide “SQL for models,” a language for

programmatically accessing models that are based on MOF metamodels (query), and for transforming model constructs into other constructs in the same language (view), or other languages (transformation).

■ XMI 2.0, the XML Metadata Interchange specification, has been updated to increase the robustness of tool interchange capabilities of MOF metamodels and of models based on MOF metamodels. OMG standards that are MOF-compliant are required to be defined with XMI representations.

■ RAS, the Reusable (software) Asset Specification will provide an XML schema for

managing software assets which will include collections of business rules. RAS is expected to complement the MDA software development process with asset management.

The OMG’s Business Rules Special Interest Group is chartered to develop a road map of specifications for business rules:

1. Business Semantics of Business Rules. This request for proposal (RFP) was issued in June 2003, with adoption about 18 months later. The RFP calls for a metamodel of business vocabulary and a semantic metamodel for business rules for business people. This will likely include interchange standards with the Ontology Web Language (OWL) and RuleML, as well as XMI.

2. Production Rule Representation. This PIM-level RFP was issued in Sept 2003, with adoption expected to be about 18 months later. The RFP asks for a metamodel for

representing production rules in UML models. This metamodel will be defined in terms of XMI and is expected to provide the first interoperable production rules standard.

(13)

3. Business Modeling. Work is planned on this RFP beginning in late 2003. The RFP will address the integration of the business semantics of business rules with business process models.

4. Business Rule Management. Work is planned to begin in late 2003. This RFP will ask for a standard model of business rule classification, versioning, responsibility, deployment and traceability.

5. Business Rules for Legacy Transformation. Work planned in 2004. This PIM RFP will address the matter of applying business rules to legacy systems.

Fair Isaac Blaze Advisor is a supporter and contributor of the OMG Business Rules Special Interest Group, as part of Fair Isaac’s active membership of the OMG. Blaze Advisor is expected to support the Production Rules standard when it becomes an OMG standard. Other subgroups of the OMG are involved in related work.

The Business Enterprise Integration Task Force has worked out the Business Process Definition Metamodel RFP, which is intended to unify different business process modeling languages, and the Business Process Runtime Interface, a PSM-level that is designed to provide a standard application programming interface for workflow engines.

The Ontology Special Interest Group has issued the Ontology Definition Metamodel RFP, a PIM-level specification that is aimed at a terminology interchange model to support the semantic Web, unifying different ontology (terminology and logic) representation schemes.

RuleML

RuleML is a combination of various XML rule representation standards from various academic and research bodies. It is strongly based on PROLOG-style logic programming and

representation, but is being adapted to support object-oriented features. The PROLOG-background to RuleML means that the RuleML XML documents incorporate both rules and

data, which might make early versions impractical as a commercial rule representation in high-performance component-based systems, but more practical for applications like electronic contracts and the Semantic Web.

RuleML itself relies on existing standards: it directly references the JSR-094 standard (see below) as a means of executing RuleML-compliant rule engines. It combines a number of research initiatives into rule mark-up languages.

In 2003, a derivative of RuleML was developed called “OORuleML,” incorporating explicitly the notions of object-oriented data models. Further developments of this RuleML branch may prove to be useful for communicating business rules in a commercial environment supported by rule engines.

JSR-094 Rule Engine standard

The Java “Rule Engine API” standard was created by the Java Community Process that consisted primarily of application server and rule engine vendors. It defines a J2SE-compliant API for invoking a rule engine, allowing applications to be developed that are architecturally vendor-neutral.

(14)

Fair Isaac Blaze Advisor is a significant contributor to the JSR-094 standard, the first

implementer of the standard in a commercial rules engine, and contributed the reference version of the standard.

International Organization for Standardization

ISO is a multinational organization with a broad range of standards. ISO sometimes gives its imprimatur to the works of other bodies that reach international status. ISO terminology and thesauri standards are important for business modeling. Related standards include the Reference Model of Open Distributed Processing, Enterprise Viewpoint Language, and Dublin Core Metadata.

Organization for the Advancement of Structured Information Standards

OASIS is responsible for the Web Services Business Process Execution Language, BPEL4WS. Oasis also has Electronic Business XML, ebXML, and many other standards.

World Wide Web Consortium

W3C is responsible for the Internet standards, including HTML, HTTP, and the Extensible Markup Language, XML, and many XML-related standards. The W3C is a prime mover toward the Semantic Web. It is responsible for the Ontology Web Language (OWL).

Business Process Management Initiative

BPMI was set up to provide a cross-industry standard for representing Business Process

Management, where such business processes may include business-rule driven processes. BPMI has defined 2 standards:

■ Business Process Markup Language—BPML is an alternative to BPEL4WS.

■ Business Process Markup Notation—BPMN is a graphical notation standard for both BPEL4WS and BPMN, and may be used to represent workflow, ruleflow and service orchestration.

Workflow Management Coalition

WfMC is responsible for defining workflow-specific standards for process definition, a workflow client API, interoperability, audit data, and naming conventions. More recently, WfMC has cooperated with BPMI around the use of BPMN in workflow. Many workflow processes are rule-driven.

(15)

Conclusion

The Business Rules Approach is being refined to bring information technology into closer alignment with business, to increase the responsiveness of technology to business needs. To achieve these objectives, a layered approach to modeling is being pursued, separating concerns of different stakeholder groups into different models. Standards are in place or being developed, in particular guided by OMG’s MDA, to enable interoperable tools to be developed that can work within model layers and up and down the model architecture stack. In the business layer, which drives the other layers, the emphasis is on modeling the business in the language of business people. Business vocabulary, business rules, and business processes are the three axes of a business model. Basing business models on standard MOF metamodels will enable

standards-based tools to store, merge, access, and transform business, PIM, and PSM models to achieve a new level of capability in enterprise application development. The combination of effective business modeling and model transformations, with the proven benefits of the Business Rules Approach, should go a long way in reducing the $200 billion cost of wayward IT projects.

1_{For an in-depth treatment of the business rules approach, see:}

Ronald G. Ross, “Principles of the Business Rule Approach,” Addison-Wesley, 2003

Barbara von Halle, “Business Rules Applied: Building Better Systems Using the Business Rules Approach”, John Wiley & Sons, 2002

David Frankel, “Model Driven Architecture,” John Wiley & Sons and OMG Press, 2002

Tony Morgan, “Business Rules and Information Systems: Aligning IT with Business Goals,” Addison-Wesley, 2002

(16)

Corporate Headquarters:

200 Smith Ranch Road San Rafael, CA 94903-5551 1 800 999 2955 from the US

1 415 472 2211 from anywhere

[email protected] email

Offices Worldwide:

Brazil, Canada, France, Germany, Japan, Singapore, Spain, United Kingdom, United States

www.fairisaac.com

Fair Isaac and FICO are trademarks or registered trademarks of Fair Isaac Corporation, in the United States and/or in other countries. Other product and company names herein may be trademarks or registered trademarks of their respective owners.

About Fair Isaac

Fair Isaac Corporation (NYSE:FIC) is the preeminent provider of creative analytics that unlock value for people, businesses and industries. The company’s predictive modeling, decision analysis, intelligence management, decision management systems and consulting services power billions of mission-critical customer decisions a year. Founded in 1956, Fair Isaac helps thousands of companies in over 60 countries acquire customers more efficiently, increase customer value, reduce fraud and credit losses, lower operating expenses and enter new markets more profitably. Most leading banks and credit card issuers rely on Fair Isaac solutions, as do insurers, retailers, telecommunications providers, healthcare organizations and government agencies. Through the www.myfico.com Web site, consumers use the company’s FICO®_scores,

the standard measure of credit risk, to manage their financial health. For more information, visit

Business Rules and Standards