We’ve moved to http://www.haleyAI.com

April 3, 2008

Cyc is more than encyclopedic

I had the pleasure of visiting with some fine folks at Cycorp in Austin, Texas recently.  Cycorp is interesting for many reasons, but chiefly because they have expended more effort developing a deeper model of common world knowledge than any other group on the planet.  They are different from current semantic web startups.  Unlike Metaweb‘s Freebase, for example, Cycorp is defining the common sense logic of the world, not just populating databases (which is an unjust simplification of what Freebase is doing, but is proportionally fair when comparing their ontological schemata to Cyc’s knowledge).  Not only does Cyc have the largest and most practical ontology on earth, they have almost incomprehensible numbers of formulas[1]  describing the world.   (more…)

Advertisements

March 28, 2008

Harvesting business rules from the IRS

Does your business have logic that is more or less complicated than filing your taxes?

Most business logic is at least as complicated.  But most business rule metaphors are not up to expressing tax regulations in a simple manner.  Nonetheless, the tax regulations are full of great training material for learning how to analyze and capture business rules.

For example, consider the earned income credit (EIC) for federal income tax purposes in the United States.  This tutorial uses the guide for 2003, which is available here. There is also a cheat sheet that attempts to simplify the matter, available here. (Or click on the pictures.)

eitc-publication-596-fy-2003.jpgeitc-eligibility-checklist-for-tax-year-2003.jpg

What you will see here is typical of what business analysts do to clarify business requirements, policies, and logic.  Nothing here is specific to rule-based programming.  (more…)

March 26, 2008

Agile decision services without XML details

Externalizing enterprise decision management using service-oriented architecture orchestrated by business process management makes increases agility and allows continuous performance improvement, but…

How do you implement the rules of EDM in an SOA decision service?  (more…)

March 21, 2008

Ontology of time in progress – amounts needed

Recent posts on money and time have produced some excellent comments and correspondence.  There is even recent OMG effort that is right on the money, at least concerning time.  For details, see the Date-Time Foundational Vocabulary RFP.  I am particularly impressed with SBVR “Foundation” Vocabularies, which I understand Mark Linehan of IBM presented last week at an OMG meeting in DC[1].

Mark’s suggestions include establishing standard upper ontologies for:

  1. Time & dates
  2. Monetary amount
  3. Location
  4. Unit of measure
  5. Quantities, cardinalities, and ratios
  6. Arithmetic operations

I will skip operations for now since they are not taxonomic concepts but functional relationships involving such concepts.  I believe the post on CEP and BPM covered time in adequate detail and the post on Siebel’s handling of foreign exchange covered the currency exchange aspects of money.  It only touched on the more general concept of amounts that I will focus on here.

The remaining concepts are common to almost every application conceivable.  They are some of the most primitive, domain-independent concepts of a critical and practical upper ontology.  They include: (more…)

March 20, 2008

RuleBurst Re-brands as Haley Limited

For those who are interested in my former company, they are still committed to natural language business rules management technology, as shown in their most recent press release.  They have also picked up on the public sector activity, especially eligibility, as discussed here

From the release, CEO, Dominic OHanlon, said:

  • “With our natural language rule authoring capabilities and BRMS solutions, we are uniquely positioned to make our customers more competitive and agile in a fast-paced, highly-regulated world.”
  • “For the government market, Haley is a worldwide leader in using natural language technology to rapidly transform regulations, policies and rules into automated decision-making systems, to determine eligibility for government services, and in the taxation and immigration arenas.”

As discussed here, this focuses comes from (more…)

March 11, 2008

Goals and backward chaining using the Rete Algorithm

I was prompted to post this by request from Mark Proctor and Peter Lin and in response to recent comments on CEP and backward chaining on Paul Vincent’s blog (with an interesting perspective here).

I hope those interested in artificial intelligence enjoy the following paper .  I wrote it while Chief Scientist of Inference Corporation.  It was published in the International Joint Conference on Artificial Intelligence over twenty years ago. 

The bottom line remains:

  1. intelligence requires logical inference and, more specifically, deduction
  2. deduction is not practical without a means of subgoaling and backward chaining
  3. subgoaling using additional rules to assert goals or other explicit approaches is impractical
  4. backward chaining using a data-driven rules engine requires automatic generation of declarative goals

We implemented this in Inference Corporation’s Automated Reasoning Tool (ART) in 1984.  And we implemented it again at Haley a long time ago in a rules langauge we called “Eclipse” years before Java.

Regretably, to the best of my knowledge, ART is no longer available from Inference spin-off Brightware or its further spin-off, Mindbox.  To the best of my knowledge, no other business rules engine or Rete Algorithm automatically subgoals,  including CLIPS, JESS, TIBCO Business Events (see above), Fair Isaac’s Blaze Advisor, and Ilog Rules/JRules.  After reading the paper, you may understand that the resulting lack of robust logical reasoning capabilities is one of the reasons that business rules has not matured to a robust knowledge management capability, as discussed elsewhere in this blog.  (more…)

February 25, 2008

Agile Business Rules Management Requires Methodology

Don’t miss the great post about his and Ilog’s take on rule and decision management methodologies by James Taylor today (available here). 

Here’s the bottom line:

  1. Focus on what the system does or decides.
    • Focus on the actions taken during a business process and the decisions that govern them and the deductions that they rely on.
    • In priority order, focus on actions, then decisions, then deductions.
  2. Don’t expect to automate every nuance of an evolving business process on day one – iterate.
    • Iteratively elaborate and refine the conditions and exceptions under which
      • actions show be taken,
      • decisions are appropriate, and
      • deductions hold true

Another way of summing this up is:

Try not to use the word “then” in your rules!

Do check out the Ilog methodology as well as the one I developed for Haley that is available here.  The key thing (more…)

February 20, 2008

Haley / ART syntax lives on in open-source Java rules

Filed under: Business Rules, Rules Engines — Tags: , , , , , , , , , — paul@haleyAI.com @ 2:24 pm

The ART syntax lives on in yet another product! 

JBOSS Rules (formerly Drools) just described its imminent support for rules expressed in the CLIPS syntax here.

NASA derived CLIPS from the syntax of Inference Corporation’s Automated Reasoning Tool (ART) in the mid-80s.  I designed and implemented the ART syntax with Chuck Williams on a team with Brad Allen and Mark Wright. 

CLIPS didn’t have many of the features of ART (including an ATMS or backward chaining, for example), but it (more…)

February 19, 2008

Understanding events and processes takes time

We have been teaching a computer to answer questions like, “How much did IBM’s earnings change last quarter?”  It takes a fair bit of knowledge, including how to understand English, to answer this question.  But teaching it what a “quarter” is brought back memories of debates with some former CMU colleagues about what units are and how to model time.  Since quite a few people ask me for help with knowledge engineering and ontological matters, I thought some might be interested in parts of those debates.As you will see, a strong upper ontology of common knowledge is required to understand common business knowledge.  Leveraging such an ontology is the only way to deliver business rules for under $50.

Sentences like “do something if more than a number of possibly related things have happened within a timeframe of something else happening” or “do something if nothing happens within a timeframe following something happening” are extremely common in business process management (BPM), complex event processing (CEP), and workflow.  With a sense of time, a business rules management system (BRMS) can support BPM, CEP, and workflow applications almost trivially.  Without a sense of time, most BRMS force users to perform computations.  

For example, without a sense of time and an infrastructure that supports it, the sentence “call a customer if no response is received within 30 days of notifying the customer of a delinquency” has to be transformed into something like “if a notice is mailed on a date and the notice is a delinquency and the date of notification has a day number then compute the date for checking by adding 30 to the day number and check for a response to the delinquency notice on the date for checking”.  The checking on a date for a response to a notice must also be implemented as a database (or persistent queue) of events to be polled or triggered by application code.  Then a second rule is required to implement the check, as in “if checking whether a response has been received to a notice and the notice was given on a date of notice and the notice was given to a customer and there exists no record of communication with the customer since the date of notice then call the customer”.  (Note that this is actually how most BRMS products would implement this.  The natural language approach I prefer handles the original sentence.)

The discussion here reflects the general structure and content that a usable ontology for business process management requires.  Most users of business rules management tools will find the need to understand and engineer this discussion in their tool of choice.  As my Haley Systems customers know, much of this is reflected in Authority’s built-in ontology and English vocabulary, but quite a few of the points discussed here reflect improvements, especially concerning the confusion between units and amounts.

As you will see the discussion takes careful thinking.  Some readers may find it onerous.  If at any time you have had enough (or if you simply cannot take anymore!), please skip to the end and decide whether to fill in the conclusions by revisiting the body.

(more…)

January 31, 2008

The $50 Business Rule

Work on acquiring knowledge about science has estimated the cost of encoding knowledge in question answering or problem solving systems at $10,000 per page of relevant textbooks.  Regrettably, such estimates are also consistent with the commercial experience of many business rules adopters.  The cost of capturing and automating hundreds or thousands of business rules is typically several hundred dollars per rule.  The labor costs alone for a implementing several hundred rules too often exceed $100,000.

The fact that most rule adopters face costs exceeding $200 per rule is even more discouraging when this cost does not include the cost of eliciting or harvesting functional requirements or policies but is just the cost of translating such content into the more technical expressions understood by business rules management systems (BRMS) or business rule engines (BRE).

I recommend against adopting any business rule approach that cannot limit the cost of automating elicited or harvested content to less than $100 per rule given a few hundred rules.  In fact, Automata provides fixed price services consistent with the following graph using an approach similar to the one I developed at Haley Systems.

Cost per Harvested or Elicited Rule

(more…)

January 8, 2008

Elicitation and Management of Rules, Requirements and Decisions

A manager of an enterprise architecture group recently asked me how to train business analysts to elicit or harvest rules effectively. We talked for a bit about the similarities in skills between rules and requirements and agreed that analysts will fail to understand rules as they fail to understand requirements.

For example, just substitute rules in the historical distribution of requirements failures:[1]

  • 34% Incorrect requirements
  • 24% Inadequate requirements
  • 22% Ambiguous requirements
  • 9% Inconsistent requirements
  • 4% Poor scoping of requirements
  • 4% Transcription errors in requirements
  • 3% New or changing requirements

(more…)

January 3, 2008

When Rules Meet Requirements

I am working on some tutorial material for business analysts tasked with eliciting and harvesting rules using some commercial business rules management systems (BRMS). The knowledgeable consumers of this material intuitively agree that capturing business rules should be performed by business analysts who also capture requirements. They understand that the clarity of rules is just as critical to successful application of BRMS as the clarity of requirements is to “whirlpool” development.[1]  But they are frustrated by the distinct training for requirements versus rules. They believe, and I agree, that unification of requirements and rules management is needed.

Consider these words from Forrester:

One might argue that Word documents, email, phone calls, and stakeholder meetings alone are adequate for managing rules. In fact, that is the methodology currently used for most projects in a large number of IT shops. However, this informal, ad hoc approach doesn’t ensure rigorous rules definition that is communicated and understood by all parties. More importantly, it doesn’t lend itself to managing the inevitable rules changes that will occur throughout the life of the project. The goal must be to embrace and manage change, not to prevent it. [2]

But note that Forrester used the word “requirements” everywhere I used “rules” above!

(more…)

December 13, 2007

Business Rules Market Maturity

Filed under: Business Process Management, Business Rules, Standards — Tags: , , , , , , , , , , , , , , — paul@haleyAI.com @ 8:49 pm

Some recent correspondence with clients and prospective adopters of business rules technology indicates interested mainstream has become increasing concerned and confused by consolidation in the business rules market.

On the analyst front, they read advice such as the following from Gartner:[1]

As Gartner has stated, the BRE market is a volatile technology sector, and market trends point to increased consolidation. In recent research, we stated that some consolidation will come from rules-to-rules acquisitions. Recent examples of this include Trilogy/Versata buying Gensym and now, RuleBurst purchasing Haley Systems.

Another form this consolidation will take is application vendors or business process management suite vendors buying much-needed rule technology, as seen in SAP’s recently announced intention to purchase Yasu Technologies. In either case, rule technology will persist, but the vendors selling the technology will often be different.

I agree with Gartner, enterprise app and BPM vendors desperately need rules technology. I also agree with the following analysis from Forrester:[2]

SAP’s decision to purchase Hyderabad, India-based Yasu Technologies greatly improves its business rules management capabilities. Other large vendors would be wise to follow SAP’s lead in the business rules market. If you look at the big vendors, they’re all going to need this technology. SAP’s competitors are going to have to step up to these requirements also.

It’s encouraging that SAP bought Business Objects and is now buying Yasu. We’re seeing requirements to link business rules and business intelligence or analytics. SAP has told us they have seen these requests, and we’re encouraged that SAP is now acting.”

Unfortunately, Gartner’s concluding advice could have been more constructive:

Prospective BRE customers: Buyer beware – the rule engine market is a volatile sector. Choose your vendors carefully and be prepared to see more BRE acquisitions.

(more…)

Blog at WordPress.com.