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.
• 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.
• 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.
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.