CRUD in Business Rules: Accident-Prone Decision Logic

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Ronald G. Ross
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

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 (, 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!

# # #

Standard citation for this article:

citations icon
Ronald G. Ross, "CRUD in Business Rules: Accident-Prone Decision Logic" Business Rules Journal, Vol. 11, No. 2, (Feb. 2010)

About our Contributor:

Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the BRS Methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:

Ron serves as Executive Editor of and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997, now part of the Building Business Capability (BBC) conference where he serves as Co-Chair. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. Find Ron's blog on For more information about Ron visit Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross
Subscribe to the eBRJ Newsletter
In The Spotlight
 John A. Zachman
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1
 Ronald G. Ross

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.