Thursday, March 07, 2002

 
Posted by Mike Tarrani 3:56 PM
Zachman Framework - Part 3. This entry is going to introduce business rules, which is a continuation of my last two entries.

What are Business Rules? A business rule, according to Barbara von Halle in Business Rules Applied: Building Better Systems Using the Business Rules Approach is defined as:

[t]he set of conditions that govern a business event so that it occurs in a way that is acceptable to the business (or customer). The business people (or customer) state rules that define all possible and permissible conditions for the business event along with those that are not permissible or are undesirable.

She goes on to state:

A useful way to divide the world of business rules involves three major categories:

1. Terms
2. Facts
3. Rules

The terms and facts will be the foundation for a logical data model and physical database. The third classification ­ rules ­ is where the excitement lies in a business rules approach.

Rules are classified as five different types:

1. Mandatory constraints
2. Guidelines
3. Action-enablers
4. Computations
5. Inferences

If you're familiar with Information Mapping, you'll see parallels between that documentation technique and business rules. You'll also notice familiar concepts if you've worked with the IDEF family of models that provide a structured approach to enterprise modeling and analysis.

Why are they Important? I became a proponent of business rules when I saw how unambiguously they express requirements, and how they easily translate into specifications and test cases. However, the most important aspect of business rules is the fact that they are from the business and reflect a genuine view of what the business needs. By expressing requirements as business rules we in IT are forced to examine enterprise policies, processes and procedures, discover the constraints imposed by policy (corporate and external, such as regulatory and legal requirements with which the business must comply), and the other elements that are provided from Ms. von Halle's definition.

Example. An example of business rules in action is the best way to illustrate their value.

• Situation: A 1996 Congressional act mandated a statutory obligation be put into effect for the FCC and state telecommunications commissions to provide affordable telephone service to rural areas. The act allowed 15 months to establish a method for providing this service.

  To comply with this act, the FCC has begun assessing Universal Service Fund charges on all telecommunications companies. The companies in turn will pass this charge on to their customer base with two percentage based taxes, a low income USF tax on usage charges and a school, library and rural health care USF tax on usage charges.

  The federal government will send assessments to the enterprise periodically based on the prior periods' revenue.

  The percentage charges assessed to the customer base will then be determined by taking into account such factors as the size of the customer base, projected growth etc.

• Rules: The situation obviously imposes mandatory constraints in the form of a law. Since this is an example I am going to bypass the impact analysis and legal research that the situation requires and provide business rules that are based on the findings of those skipped activities:
  1. Incorporate into the system USF percentages for
     • low income
     • school
     • library
     • rural health care
  2. The existing tax calculation routine needs to be modified to use the percentage rates required by USF when applying the USF taxes.
  3. These rates from the previous rule needs to override the statutory rates supplied by the existing taxing interface.
  4. USF taxes applied need to be written to the existing Tax Detail table.
  5. USF taxes applied need to be shown on the Tax Summary report.

To underscore the value of using the business rules approach, consider a typical requirements specification using the same situation:

The business needs the ability to establish a system parameter to be used for storing the Universal Service Fund (USF) percentage rates and the ability to assess USF taxes based on these percentages.

Look familiar? This is, unfortunately, typical of requirements that are passed to the specification developers and designers. If you carefully read the requirement you'll notice that it not only is vague, but it breaks a basic rule in expressing requirements by stating a design approach (... establish a system parameter to be used for storing ...).

Contrasting the business rules approach with the typical example yields the following assessment:

• Efficiency - the requirements stated in the business rules are from governing source documents and business subject matter experts. The design team will not need to meet with the business subject matter experts separately to clarify details about the USF, percentages or other facts. This information was captured in the business rules.
• Testability - the requirements specification containing business rules can be used as the basis for a test strategy because there is sufficient information from which to develop test cases (the business rules show where the USF percentages are to be applied, and they point to other subsystems such as the existing tax tables that need to be regression tested).
• Non-ambiguity - the business logic is captured in the business rules and are expressed in a manner that can be interpreted only one way.
• Focus - requirements are separated from specifications and design because business rules capture the what is important to the business, not how to implement a solution (revisit the statement about establishing a system parameter above to see how easy it is to mix requirements and solutions if requirements are not precisely expressed as business rules).

Resources. I'll be writing more about business rules over the next few days because this topic has a rich body of knowledge. Until my next entry you may want to explore the basics, and the best starting points are: Knowledge Partners, Inc. whitepapers, which contains some of the best business rules material available on the web. One of the principals is Barbara von Halle, who has authored many of the whitepapers on the site, and is the author of Business Rules Applied: Building Better Systems Using the Business Rules Approach.

Business Rules Community is the website for the business rules community. This site is filled with articles, news, case studies and discussions. If you adopt business rules you'll find yourself visiting this site often. Business Rules Community is sponsored by Business Rules Solutions, LLC. Although this is a commercial site the principals, Ronald G. Ross and Gladys S.W. Lam, are internationally acclaimed as the foremost experts and practitioners of business rule techniques and methodology.

End Note. In my last entry I stated that I wanted to discuss the knowledge management aspects of the Zachman Framework with Muthukumar U and Kate Hartshorn. The opportunity to engage either of these two experts has eluded me, so I am going finish the business rules topic before addressing knowledge management. However, I did find an interesting paper titled A Methodology for Knowledge Discovery and Classification. You may also want to visit Technical Communications Resources and Business and Strategic Planning Resources, which are two web pages that Linda and I maintain. Both pages contain material related to business rules, policies and procedures, and knowledge management.