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

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

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

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

Blog at WordPress.com.