May 1998                   Issue: 2

Journal of Conceptual Modeling
www.inconcept.com/jcm

Business Rules Require Real-World Identifiers
by Dr. John K. Sharp

In our quest to structure the world so that data is efficiently managed within computer databases we commonly depend on the creation of meaningless unique keys. This serves us well in the capturing, analyzing and displaying information. So well, in fact we sometimes don't pay attention to the use of the knowledge in the ongoing work of the business. The databases work fine, but we require people to enforce business rules outside of the application.

These business rules can be in the form of corporate policy or regulations. Often these policies are updated and changed periodically and individual policies can be in direct conflict with one another. This conflict may not be permanent, but during the differences between updating cycles two policies with some conflicting rules will officially exist. In some cases the policy, although official, is not followed because it is not liked, it is not known (conveniently not known sometimes), or it is just out of step with current activities. As an alternative, the business rules contained in the policies and procedures can be identified and then enforced in the application that captures the associated data.

Direct enforcement of business rules within applications stimulates action like you have never seen before. Even the threat of automatic enforcement is enough to trigger recycling of reams of policy documents. A purchasing application that I modeled was going to automatically route purchase orders for approval. Initially there were about 200 separate types of approvals that were required for the purchase of "special" types, quantities, or values of products. The initial analysis identified only 90 approvals that would be needed in the future application and the last count was 60 and going lower. [The application model turned the approval rules into data, so we were not required to implement them independently as tables or code. Thus, the design could be completed while the rule count headed down. This also provided for ongoing rule maintenance by the subject matter experts that did not involve table or code changes. The result was a real win-win situation for the project.]

Let's analyze a simple example of a petty cash reimbursement to an employee to see how a meaningless unique key is not sufficient for business rule enforcement.

Situation: An employee purchased a wrench at a local hardware store.

The completed petty cash form includes the following data:

The previous table can be written as the following sentence:

Employee E7654 submitted petty cash form 23416 on April 16, 1998 for a purchase made at Ace Hardware on April 15, 1998 in the amount of $8.43 that is described and justified as "replaced wrench broken this morning."

The Natural Language Modeling analysis procedure requires a matrix to be formed from the variable elements in the sentence. The result for this sentence is:

Employee <Emp_No> submitted petty cash form <Form_Id> for a purchase made on <Pur_Date> at <Vendor> on <Sub_Date> in the amount of <Amount> that is described and justified as "<Desc/Just>."

A petty cash expert determines the Yes and No answers when she/he responds to questions of the type:

Given that ‘Employee E7654 submitted petty cash form 23416 on April 16, 1998 for a purchase made at Ace Hardware on April 15, 1998 in the amount of $8.43 that is described and justified as "replaced wrench broken this morning."’ is true, is it allowed for another employee [such as E3443] such that ‘Employee E3443 submitted petty cash form 23416 on April 16, 1998 for a purchase made at Ace Hardware on April 15, 1998 in the amount of $8.43 that is described and justified as "replaced wrench broken this morning."’ may also be true?

For this sentence the expert's answer is No. The other answers are obtained by creating a similar sentence for each changing diagonal element in the matrix. Why is there one "Yes" answer? We would want to reimburse the employee if he/she went to the hardware store twice to get a wrench because two wrenches were broken in the morning. An important business rule now comes into play that requires us to not reimburse an employee twice for the same purchase.

The existing sentence requires a table with seven columns and a key over the Form_No column. If an auditor checked to see if reimbursements were duplicated she/he would look at only the non-key columns because the key column is by definition unique. If duplicates are found, the auditor would not know

• if they were two legitimate purchases,

• if the same purchase was entered twice by mistake, or

• if the employee tried to commit fraud.

The non-key columns of the original sentence must now be analyzed to help in the enforcement of the identified business rule.

Employee <Emp_No> submitted a petty cash reimbursement request for a purchase made on <Pur_Date> at <Vendor> on <Sub_Date> in the amount of <Amount> that is described and justified as "<Desc/Just>."

When the answers are all "Yes" the NLM procedure requires asking if the sentence instance,

, exactly identifies one object (petty cash reimbursement request).

For this example the answer is already "No," because the same instance can appear twice as two legitimate separate purchases.

The NLM procedure then requires asking if a placeholder can be added to the sentence that will create an identifier for the object.

For this example the answer is "Yes," because a counter could be added to the sentence that would allow the two exact sentence instances to be separately identifiable.

The new sentence would be:

Employee <Emp_No> submitted a petty cash reimbursement request <Counter> for a purchase made on <Pur_Date> at <Vendor> on <Sub_Date> in the amount of <Amount> that is described and justified as "<Desc/Just>."

The subject matter expert with the help of the analyst decided that only three of the columns belonged in the identifying fields with the added Counter placeholder ("Yes" answers). This is because the Sub_Date has no bearing on the audit requirement and the Vendor and Desc/Just were free text fields that should not be included in an identifier. We have now found a real-world key ("Yes" answers in the matrix in this example) that will allow us to enforce the business rule described earlier. We could establish a procedure that provides for a default counter of one. During commitment every instance that requires a counter higher than one for completion would be preceded by a pop up screen that asks if this is the number two (or three) petty cash reimbursement for this amount that was purchased by the submitting person on this date. If the answer is "Yes," then the instance is recorded. If the answer is "No" then the input screen is cleared and another request can be entered.

The real-world key allows us to stop requests from being entered twice by mistake. Enforcing this auditing rule at the time of submission eliminates a mistake that could be very embarrassing to an employee. [If an employee had several requests and was distracted during entering them, a request could be entered twice. Explaining this to the boss or a higher manager would not be a highlight of the employee’s day.] The proposed enforcement of the rule also ensures that an identical request for money would be declared and then could be more thoroughly investigated before approval. The possibility of fraud is not eliminated. When the rules are known and are always enforced, the likelihood that fraud would be attempted is lower. Automatic rule enforcement may allow resources to be diverted from auditing and potentially from fraud investigations and moved to value-added work on company products or services.

Other auditing rules may also be modeled and enforced. This one rule is only an example of enforcing business rules within an application. The objective of modeling should be to provide more value than the construction of a database that has the right tables and primary keys, although the right tables and primary keys are a necessary requirement. The objective should include an effort to ensure that the application also prevents the introduction of bad data and highlights special items for information, action or comment. Natural Language Modeling contains an analysis procedure that guides the analyst through the analysis of all business rules. The documentation of the analysis results can be done on any CASE tool, although a NIAM or ORM tool will document more of the results.

Rules for the allowed exemptions from a rule can also be enforced through software. I do enjoy explaining the extra cost of doing this to management, because management seems to "need" a large majority of the exceptions.

A company-wide goal should be to replace the descriptive and voluminous text that now serves as policy and procedures with computable rules that are always enforced. Can we ever have a computable IRS code? I think a flat tax is needed before I could give an estimate on extracting the rules!

Happy Modeling!

Dr. John Sharp is the founder and principal consultant for Sharp Informatics.Before starting Sharp Informatics in 1997 he was employed by Sandia National Laboratories in Albuquerque, NM for 18 years. While at Sandia he held staff and management positions in all areas of information technology, including analysis, design, implementation, maintenance, information architecture, data administration, and information technology research. He has worked closely with Prof. Shir Nijssen of The Netherlands to improve the NIAM analysis methodology. Dr. Sharp is the creator of the first information analysis procedure known to be mathematically precise.This procedure reformulates the usual (imprecise and inaccurate) statements and examples from a subject area into verified fact types. The output of this productivity enhancing process (a set of information requirements) is compatible with all the latest and most productive database application creation tools. John is the editor of the international standard for conceptual schemas. He has co-chaired two international conferences on natural language modeling and he has presented numerous papers and seminars at professional conferences.

Contact information:

Dr. John Sharp
Sharp Informatics
1604 Vassar SE
Albuquerque, NM 87106
sharp@sharp-informatics.com
505-243-1498
fax 505-248-0345
http://www.sharp-informatics.com

© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement.
ISSN: 1533-3825