Put to the Test: HaleyAuthority 5.1: Follow the Rules (in Plain English)Put to the Test: HaleyAuthority 5.1: Follow the Rules (in Plain English)
This BRM system offers a natural-language alternative that puts business users in charge of rules management.
As businesses move deeper into the realms of mass customization, process optimization and risk management, success depends on managing and making decisions consistently, in real- or near-real-time and with greater automation. Enterprise decision management solutions are aimed at providing this capability, and these, in turn, are driven by the management of business rules.
Rules management systems generally fall in two categories: business-oriented and application-oriented. Products in the first category are relatively technology-agnostic and emphasize rules management from a business perspective: End users are responsible for defining and maintaining rules, which are then made available to software applications. Systems in the second category are typically more closely tied to application technologies (such as Java). HaleyAuthority, from Haley Systems, is a leading business rules management (BRM) system that firmly falls in the first category. The system is built around strong capabilities in natural language understanding and chained reasoning--or "Semantic Role Modeling" as Haley calls it--and it offers a business-user-friendly alternative for automated decision management.
PROS |
---|
• User friendly with strong natural-language capabilities. |
• Supports ontology and rules standards including OWL and JSR-94. |
• Business rules engine has a small footprint compatible with mobile devices. |
CONS |
• Lacks support for popular rule modeling paradigms. |
• Inadequate provisions for debugging rules. |
• Poor documentation offers little help to untrained users. |
Building The Knowledge Base
Modeling business rules in Haley begins with defining concepts and relations. For example, if we were to construct a rule base for an Employee/ HR system, employee and salary would be concepts, and EmployeeSalary would be a relation. Haley has a number of pre-defined concepts such as amount of money, so you can simply declare salary as a kind of amount of money, and the product automatically understands things it can do with salary, such as use it in computations. Creating a relation between employee and salary is as easy as dragging and dropping salary over employee.
A key aspect of creating relations is defining phrases that determine how the relation can be used. As you can see in the "Edit verb phrasing" window in the screen shot at left, it helps to know your grammar: verbs, adverbs, adjectives and possessive prepositions--not everybody's cup of tea, but not quite as daunting as coding. Once all the concepts defined, you can define statements, such as "a salaried employee is an employee that is paid a salary." Haley validates such statements as you type them in and indicates if the statement is understood or not. It does this in sequential fashion starting from the left, so unless you have defined the starting term "salaried employee," for instance, the system wouldn't understand subsequent components of the statement. You also can define conditional statements, such as "an employee is entitled to a vacation if the employee is a salaried employee," but this requires a bit of fancy footwork (routine, once you know how) in creating a relation between employee and vacation that includes the phrase "is entitled to."
The Haley knowledge base is multi-tiered. In the lowest tier is a dictionary, which is where you define the basic elements of the language: adjectives, adverbs, nouns, prepositions and verbs. Next, you define concepts and relate them, clarifying the relations with phrases that use the language elements. There are five types of concepts: entities (such as employee), quantities (such as salary, as a quantity of money), time, unit and value (e.g. EmployeeTitle, as a value of string). Haley comes with numerous pre-defined concepts in all categories except entities, which tend to be specific to the organization. Lastly, you define statements, qualified by conditions. You group these statements--which are, in essence, the business rules--into modules for convenience and effective management.
Rules can be defined for analysis, leading to the creation of a fact ("if an employee has title of CEO then the employee is eligible for super-fat bonus"), or for action, leading to an executable result ("if an employee is eligible for super-fat bonus then award the employee one million stock options"). To aid processing, lookup tables can be defined for values such as the number of stock options to be awarded by title and years of service. Forward and backward chaining directs the flow of decision logic, prioritization enforces rule dependency and versioning enables rules to evolve over time.
The Haley knowledge base can be stored in a file or (more typically) a relational database. It can be developed, managed and shared using a client tool (as shown in the main window in the screen shot on page TK), and it's deployed using the Haley business rules engine. The engine is small enough to run on PDAs and provides application programming interfaces (APIs) for Java and .Net, as well as support for Web services (these features were not tested).
Focusing on natural language, Haley has chosen not to support some of the more popular (and visual) rule modeling paradigms, such as decision tables, decision trees and state-chart diagrams--though some of these can be modeled, with some effort, in natural language terms. Haley's lookup tables are fairly robust, but I cannot see them as a substitute for the kind of complex, multiple condition/action logic that can be modeled in decision tables. Provisions for debugging rules also need to improved, and the documentation is poor, making it difficult for untrained users to make use of the software.
Putting The Owl In A 'BOX'
To deploy Haley (or any natural-language-based decision management solution), businesses must first take up the potentially painful and time-consuming activity of defining ontologies in domains of interest. An ontology is a vocabulary, consisting primarily of related concepts, relations between concepts and a grammar for building upon the concepts and relations. Fortunately, Haley's Express Paks (formerly "Knowledge-Paks") offer pre-defined sets of terms and concepts by industry, and its Business Ontology Exchanges (BOX) add an online forum for sharing industry-specific ontologies. Both of these offerings promise to shorten deployment cycles (though the only BOX available at this writing is for the insurance industry, so I hope more are on the way).
Haley's strength is its ontology-based approach and its commitment to standards, exemplified by its plan to support the OWL and JSR-94 standards. OWL, the Web Ontology Language from W3C, is intended as a common language for specifying ontologies that are interoperable and can be shared across the Web as a step to realizing the ambitious Semantic Web. JSR-94 is the emerging standard Java runtime API for business rules engines. The Haley Rule Markup Language (HRML), recently introduced, is a proposed XML-based standard for defining rules, which Haley will use to make all related product documentation, XML schemas, APIs and examples available to the public. Haley's strategy is to achieve leadership through the standards initiative.
Ensuring A Fast Response
HaleyAuthority is a well-designed solution that is rated highly by both Forrester Research and Gartner. The company is serious about its commitment to the natural language-based approach, business ontologies and the standards movement. This is good news for customers, as it offers a compelling alternative in the marketplace for enterprise decision management. The use of natural language helps companies quickly respond to changing demands and conditions because business analysts can change rules without the delays inherent in IT development.
* HaleyAuthority 5.1 enterprise deployments start at $50,000, including Haley's rules engine.
Rajan Chandras is with the New York offices of CSC Consulting, and can be reached at [email protected]. The opinions expressed here are his own.
Insuring Success With Business Rules
As enterprises continue to move away from silo applications and towards a service-oriented paradigm, they will find it valuable to collect and manage rules centrally. Haley Systems customer Farm Bureau Financial Services reports that automated rules management helped reduce insurance transaction times by 75 percent--from days to a matter of hours--with 60 percent of 450,000 transactions in 2005 processed without manual review, up from 10 to 12 percent before the system was deployed in November 2004. Brett Clausen, vice president of underwriting and operations, says rules management has:
• Eliminated process paperwork and reduced workloads and expenses
• Cut policy issuance times
• Improved consistency in underwriting risks
• Increased adaptability and responsiveness to market and regulatory changes
• Freed underwriters to focus on exposure/ liability challenges
• Improved monitoring and management of results
The company's main deployment challenge was defining the insurance business ontology, but Haley's natural-language approach paid off: The task could be assigned to a business analyst rather than an application programmer. Haley's documentation was found lacking, but Clausen says training and patience were the keys to success.
The insurance industry is a natural for business rules management (BRM), but many businesses stand to benefit from the technology. Business rules can be integrated into custom applications and are an integrated part of business process management/automation (BPM/ BPA) solutions. The caveat, however, is that BRM is far easier to use in new systems--built from the ground up to work with rules engines--than it is to integrate with existing systems.
About the Author
You May Also Like