Posted on

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.  Continue reading “Harvesting business rules from the IRS”

Posted on

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 Continue reading “RuleBurst re-brands as Haley Limited”

Posted on

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, was the first time I heard a consensus that a standard ontology of events and processes was sorely needed.  I’ve had a number of discussions with others on this over the interim until today’s posts by Paul Vincent, summing up an OMG meeting in Washington, DC, and Sandy Kelmsley’s comments on a survey of 590 business process modeling notation users.   Continue reading “In the names of CEP and BPM”

Posted on

Behind the CEP curtain – it’s about time, not the cache

TIBCO is the CEP vendor most focused on the market for business rules, as reflected in Paul Vincent’s post here.  Although I agree with Paul that rule vendors are not currently offering enough in terms of support for long-running processes, the conclusions that he draws in favor of considering a CEP alternative to a BRMS are not compelling yet.

Paul said that rules don’t address the following that are addressed by CEP:

  1. BAM (business activity monitoring) and the other BPM (business performance management)
  2. Complex-rule processing
  3. Customer-centric (portfolio-based) decisions / policies

I am sure Paul was just being flippant, but you may notice that there is a bit of a war going on between CEP, BPM and rules right now.  Continue reading “Behind the CEP curtain – it’s about time, not the cache”

Posted on

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. Continue reading “CEP crossing the chasm into BPM by way of BRMS”

Posted on

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.

Continue reading “Understanding events and processes takes time”

Posted on

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

Continue reading “The $50 Business Rule”

Posted on

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

Continue reading “Elicitation and Management of Rules, Requirements and Decisions”

Posted on

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!

Continue reading “When Rules Meet Requirements”

Posted on

Business Rules Process Management

Some strategy folks in an enterprise architecture group recently asked for help making rules more relevant to their organization. Their concerns ranged from when to embed rules in their middle tier versus encapsulate them within services to identifying ideal use cases and reference implementations. They were specifically interested in coupling rules with BPM and BI.

Such questions occur every time a group or enterprise considers adopting rules technology for more than a specific application. They are looking for guidelines, blueprints, or patterns that will help them disseminate understanding about when and how to use rules. They have adopted a BPM vendor which will be integrated with their selected rule vendor, each as enterprise standards, so they are particularly interested in the integration requirements between the two.

Two high level understandings are critical for success in furthering adoption of rules technology.

  1. abstract activities for which rules technology well-suited and
  2. when and why rules technology is better than familiar alternatives

Continue reading “Business Rules Process Management”