Excerpted from Chapter 3, Business Rule Concepts:  Getting to the Point of Knowledge (Third Edition), by Ronald G. Ross (August 2009). ISBN 0-941049-07-8   http://www.brsolutions.com/publications.php

CRUD stands for Create, Retrieve, Update, Delete — all system events.  You should never express business rules based on CRUD.  For one thing, CRUD isn't business terminology so the result will always be a data or system rule rather than a business rule.  Not good!

But there's more.  Using CRUD to express rules has hidden side effects.  Often the result is an unintended or unknowing limiting of coverage to a single event.  Let's work through an example:

CRUD Rule:  Update product cost if the cost of any of the product's components changes.

In RuleSpeak (www.RuleSpeak.com), the subject of any business rule statement providing a computation formula is always the name of what is being computed.  Product's cost is therefore indicated as the subject in the following revised version.

Business Rule:  A product's cost must be computed as the sum of the cost of all the product's components.

The original CRUD version for this business rule limits coverage to a single flash point (an event when a business rule needs to be evaluated).  That flash point is when the cost of a component included in a product changes.  The revised version covers not only that flash point, but the following two as well:

• When a component is newly added to the make-up of a product.
• When a component is newly removed from the make-up of a product.

This broadening of coverage should be analyzed carefully, of course — it might not represent true business intent.  (If not, the when condition should appear explicitly in the RuleSpeak version at the end of the sentence.)  My point is this:  CRUD is simply a when condition in technical garb.  No when condition, especially a disguised one, should ever appear in a business rule statement accidentally.

Let's consider another example:

CRUD Rule:  Don't delete a customer that has placed any open orders.

What is the true business intent of this rule?  It stands to reason that if deleting a customer that has placed an open order is disallowed, then opening an order without a customer is probably also disallowed.  From a business perspective, always knowing who the customer is for any open order is probably key.  Removing the CRUD produces:

Business Rule:  An open order must be placed by a customer.

This revised version omits any mention of the delete a customer flash point.  It inherently also covers the open an order flash point (i.e., asserting that an order is open).  Even this simplest possible business rule turns out to have more than one flash point!

In RuleSpeak, when is always taken to mean only at the point in time that some specified event occurs.  Suppose the business rule above had been written this way (not recommended):

Rule:  When an order is created, it must have a promised shipment date.

In this version, the rule applies only when an order is created (comes into existence).  But what about two seconds later?!  Should anybody (or any system) be allowed to delete (discard) the promised shipment date?  Probably not!

Including a when clause in the expression of a business rule chains the business rule to that specific flash point.  More often than not, that narrowing of coverage does not reflect true business intent.  Experience has shown that the large majority of business rules are inherently and naturally multi-flash-point.  Be very careful when you say when!

# # #