Actions are Not Rules (and Vice Versa)

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

In this one-per-month special 'notepad' series, I am taking a quick look at important issues facing practitioners who are seeking to understand and apply the business rule approach for capturing business requirements and developing business systems.


A rule is a bit of declarative logic that is required to be true.  Here is an example:  A salesperson may sell a product only if that salesperson represents some manufacturer that produces that product.  Some action may be implied by the rule to maintain its truth (the point can be debated), but in any case such actions are under the covers (so to speak).  They are not of any direct concern to designers, nor any direct concern to implementors when the class of platform used for implementation is a rule engine.

Actions, on the other, are of direct concern to both designers and implementors (even when the class-of-platform is a rule engine).  In part, the reason is that the sequence of action-taking is always of direct concern because the outcome (of executing the process) depends on it.  The sequence of rule evaluation, in contrast, should make no difference whatsoever to the outcome (of the evaluation).

These distinctions can be difficult to grasp for those who have never been exposed to a rule engine.  Traditionally, rules have often been implemented as actions -- that is, as executable statements in some kind of programming language that executes statements.

The important thing to remember is that execution style depends on the class of platform.  In a rule engine environment, rule statements in declarative form are evaluated (not executed) by the system (rule engine) so the system can take responsibility for ensuring correctness of state, infer new facts, etc.  The system (rule engine) takes whatever actions are required.  That's nothing whatsoever like writing transforms (actions) in some procedural 3GL or 4GL and then deliberately executing them.

A counter-argument might be the observation that rules are often executed as actions in everyday human activity.  Police patrol.  Inspectors inspect.  Courts sentence.  Employee asks, "What are you doing?"  Supervisor replies, "Just checking to see if you are wearing your safety glasses."  Rule enforcement seems like 'actions.'

But to understand rules, you must separate the rule statement from the enforcement regimen chosen for the rule.  The enforcement of non-automatable rule statements (e.g., A hardhat must be worn by any worker working in a construction site) can be implemented only through procedures (scripts) and job responsibilities of those participating (e.g., the supervisor) in the activity.  But that doesn't in any way affect the rule statement.

For automatable rules (e.g., A group must not include both union and non-union members), you have at least two fundamental choices about how to enforce the rule.

  1. You can emulate people in the real world, creating some sort of enforcer object (or something) whose 'responsibility' is to enforce the rule.

  2. You can take advantage of the logic processing potential of computers and hand over the 'enforcement' of the rule to a rule engine (just like you hand over the management of data to a DBMS).

The latter choice is clearly better for many reasons.  Let me single out just one.  Analyze the 'group' rule given above, and you will discover there are several specific events where the rule needs to be evaluated, roughly including the following:

  1. when a new group (with two or more employees) is formed

  2. when a person (who is a member of a group with at least one other member) joins a union or drops out of a union

  3. when a new member is added to an existing group that already has another member

The problem with procedural approaches to rule enforcement is that you have no guarantee of consistent or comprehensive enforcement across all the procedures and actions that might produce those events.  Multiply that by the hundreds or thousands of rules associated with a typical business process.  At that scale, the quantitative difference produces qualitative differences in the rule-enforcement issue.  Time to move to a better paradigm!

A current goal in the IT industry is to make system models transformable into executable components.  Obviously you want such transforms to be trustworthy and consistent and manageable.  As far as I can see, as complexity in business logic scales up by orders of magnitude, the only conceivable way to achieve these goals is to address the business logic directly -- that is, a as a primitive.  'Directly' here means (a) based on shared semantics (terms and facts), (b) expressed directly as rules, and (c) supported by the right class of platform -- rules engine.

# # #

Standard citation for this article:


citations icon
Ronald G. Ross, "Actions are Not Rules (and Vice Versa)" Business Rules Journal, Vol. 4, No. 5, (May 2003)
URL: http://www.brcommunity.com/a2003/b141.html

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 BRCommunity.com 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 http://www.brsolutions.com/category/blog/. For more information about Ron visit www.RonRoss.info. Tweets: @Ronald_G_Ross

Read All Articles by 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.