Blaze Advisor is a decision engine and rules-management repository that comes with an integrated development environment (IDE) for creating rules-based applications. Target applications include insurance adjudication, loan approval, credit scoring, product recommendations, regulatory compliance, customer rating, fraud detection and other problems that can be solved by means of condition-action ("if ... then ...") statements, decision tables and workflow logic. The tool is powerful but complex. Fair Isaac did a good job hiding the complexity with its IDE, which has a well-designed WYSIWYG interface. But beware: The ease of creating applications has led some to implement too hastily, which has hurt the cost-effectiveness and long-term maintainability of their applications.

Blaze Advisor has three distinct use modes: a design-time environment, an operational (deployment) environment and a user-oriented rules-maintenance environment. Blaze Advisor is a 100% Java app, so you can deploy its rules services to a number of different platforms. A deployment wizard simplifies this process.

The Blaze Builder design-time environment runs only on Windows, but the runtime system can be on almost any operating system with a current Java virtual machine.

The repository stores rules in an XML format. Other options for storing rules include file source control software such as PVCS or a database, or in an LDAP-friendly format, to control access using corporate security authorization. However, in any case, the underlying format of the rules is always XML.

Blaze Advisor code looks a lot like English statements, but it's a true programming language. It includes conditions, actions, branches, loops and access to data stores and classes. The IDE has a sophisticated debugging environment that analyzes the effects of changes and detects circular rules cycles, rules with no actions, rules with the same condition and different actions, and a host of other potential anomalies. The debugger also displays rule execution flow (see the screen capture on the top-right) and lets you set break points and conduct traces. These IDE tools will be familiar to most developers, who will find the visual debugging environment attractive and usable.

Blaze code looks like English because it uses intuitive phrases such as "satisfy," "does not start with," "of every" and "is any." Rules have English-like syntax, as in, "If at least two children satisfy (age < 10), then set discount to .5" or "SeniorCustomer is any customer such that (age > 65)." However, these aspects of the code aren't what make the language suitable for businesspeople. IT departments generally won't allow businesspeople into the full development environment unless they're familiar with the design-code-test life cycle (which is rare). Blaze's innovation is to provide what is called a rules-maintenance application (RMA) for users to perform rules management. Rules and their subparts, such as connectives and variables, are exposed to businesspeople as parameters and conditions in predefined templates (see the screen capture on the bottom-right) that restrict what nontechnical users can directly manipulate. Decision tables and decision trees help users visualize rules and their workflow sequencing.

Blaze's strengths and limitations came up in conversations with Fair Isaac reference clients. First American Field Services (FAFS), a property management and maintenance firm that targets repossessed properties, has implemented an application with about 2,000 rules driven by large decision tables. "Our business is in the rules engine, and basically we built it with one developer," says Mark Davis, the company's manager of MIS applications. A small team of developers at FAFS had rapidly implemented a prototype application for making property-management decisions. As is often the case, the prototype became the production application. By the end of June, FAFS had converted a third of its business off of its legacy AS/400 applications, remapping historical data into a new schema and continuing to mine the legacy system for hard-coded rules to implement in Blaze. Now, instead of rules hard-coded into procedural language (RPG) programs, FAFS has a central repository in Blaze that acts as the single source of rules-based truth.

FAFS acknowledges a few lessons learned along the way. Its implementation was quick and dirty — which is easy to do with Blaze because the development environment is so accessible to nonprofessional developers. Like so many prototypes, the application was implemented without a design, Davis admits. The FAFS application performs significant amounts of database access from the rules engine, yet it doesn't bring back the data all at once. It executes 21 stored procedures and doesn't cache any of the data. It also executes an old version of the Microsoft virtual machine. In short, performance lags. I/O-intensive processes go to the rules engine and are slow to return. This sort of hasty deployment will increase maintenance efforts and costs. On the other hand, the client's application is intentionally designed as a stateless one. This isn't a Blaze requirement, but it's needed to deploy identical code across separate, multiple servers (otherwise dependencies would be created between servers that ought to be independent). Thus, when the client is willing to invest beyond its two-way HP ProLiant class machine, the application will scale linearly.

AAA Michigan is another Blaze client. The organization is expanding its insurance writing activities to other states, which is an ideal application for Blaze: Basic insurance rules can be written that allow variation and customization on a state-by-state basis. AAA Michigan makes tens of thousands of microdecisions a day in an underwriting application that executes some 3,000 rules, estimates director of underwriting Mike Koscielny. Blaze is integrated into a complex architecture with a back-end mainframe that performs pricing and billing for the insurance agents and a custom Web front end developed with help from Accenture. Rules-maintenance application templates enable end users to update policy-based rules by themselves. AAA Michigan devoted time and effort to a coherent design and hasn't experienced any performance problems in its busy and complex environment.

The point of a decision engine is to change and redeploy the business rules that are the heart of enterprise operations without performing the equivalent of open heart surgery on the application every time a modification is needed. This is Blaze's strong suit; and Blaze accomplishes this in spades. However, at the risk of sounding Zen, it remains the case that our strengths are often our weaknesses. Thus, ease of prototyping can result in applications that are hard to maintain. Complex rule flows require careful testing or run the risk of unintended application behavior (bugs). Letting business users have access without carefully crafted templates means they can shoot themselves in the feet quicker and more often. This is not so much an issue with Blaze — which is a powerful engine and IDE that functions as designed — as with the unintended consequences of powerful technology. No one expected Blaze to make obsolete the need for a system development life cycle or design and testing rigor, nor has it done so. Blaze's signature claim is that it hands over rules maintenance to end users. The claim remains true but needs to be qualified by the fact that business rules are best contained in an entire development process.

• Blaze Advisor 6.0.3 pricing starts at $50,000. Fair Isaac, www.fairisaac.com.

Lou Agosta is a technology analyst specializing in data warehousing, data mining and data quality. He is the author of The Essential Guide to Data Warehousing (Prentice Hall PTR, 2000). Write to him at [email protected].