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.)

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. 

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? 

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 O’Hanlon, 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

In the names of CEP and BPM

Have you heard the one about how to drive BPM people crazy?

Ask them the question that drives CEP people crazy!

Last fall, at the RuleML conference in Orlando,

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. 

Externalization of rules and SOA is important – for now

James Taylor’s notes on his lunch with Sandy Carter of IBM and the CEO of Ilog prompted me to write this.  Part of the conversation concerned the appeal of SOA and rules to business users.  Speaking as a former vendor, we all want business people to appreciate our technology.  We earn more if they do.  They say to IT “we want SOA” or “we want rules” and our sale not only becomes easier, it becomes more valuable.  So we try to convince the business that they are service-oriented, so they should use SOA.  Or we tell the business that they have (and make) rules, so they should use (and manage their own) rules.   And rules advocates embrace and enhance the SOA value proposition saying that combined, you get the best of both worlds.  This is almost precisely the decision management appeal.  Externalize your decisions as services and externalize rules from those services for increased agility in decision making.   This is an accurate and appropriate perspective for point decision making.  But it doesn’t cover the bigger picture that strategic business people consider, which includes governance and compliance. 

Nonetheless,

Effective SOA and business rules have one requirement (or benefit) in common: externalization.  

The externalization of services from applications

CEP crossing the chasm into BPM by way of BRMS

Complex event processing (CEP) software handles many low-level events to recognize a high-level event that triggers a business process.  Since many business processes do not consider low-level data events, BPM may not seem to need event processing.  On the other hand, event processing would not be relevant at all if it did not occasionally trigger a business process or decision.  In other words, it appears that:

• CEP requires BPM but
• BPM does not require CEP

The first point is market limiting for CEP vendors.  Fortunately for CEP vendors, however, most BPM does require event-processing, however complex.  In fact, event processing is perhaps the greatest weakness of current BPM systems (BPMS) and business rules management systems (BRMS), as discussed further below.