What Rule Independence Means to System Models ~ Less and More than You Think!

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

This issue's column is another installment of my periodic 'notepad' series, which focuses on specific issues facing practitioners seeking to understand business rules and make them part of their company's approach to requirements and system development.

A system designer recently sent an e-mail message about capturing and expressing business rules in the context of system design.  He described his approach (paraphrased) as follows:

'How we treat business rules depends on what kind of model we're developing.  If we're developing a dynamic model, then business rules map to expressions based upon action semantics; if we're developing a static model, business rules need to represented by something static, namely an invariant.'

Here is my reaction.  There are several fundamental questions here.

Question 1.  Why should business rules ever be rendered in other kinds of models?

A fundamental principle of the business rule approach is that business rules should be first-class citizens of the requirements world.  A related principle is that they should be a discrete part of business and technology models -- which is to say, defined independently of other aspects of these models.  These are in fact the very first two principles of the BRG's Business Rule Manifesto.[1]

Let me say as a plainly as possible that if you use a rule engine to implement your business rules, there should never be any point during the development of specifications at which the business rules should be rendered using other kinds of models.

The situation is different, of course, if you do not have a platform such as a rule engine under which business rules can be implemented directly.  In that case, it will be necessary to render the business rules in the form(s) best suited to the platform(s) you do intend to use -- in other words, in some form other than 'pure' rules.[2]  An example might be a processing model in which rules are rendered as pre-conditions and post-conditions.

Question 2.  If business rules must be rendered in other kinds of models, when should such rendering occur?

As discussed in previous columns, we share John Zachman's view that the form of deliverables should be based on the audience they address.  Following his Framework, this leads to the following four perspectives:

  • Business Perspective

  • System Perspective

  • Class-of-Platform Perspective

  • Specific-Platform Perspective

The first-class standing of business rules should never be surrendered for the business perspective -- even without a rule engine as the eventual implementation platform.  With no rule engine, however, rules must be rendered in other models as soon as the chosen class of platform(s) is/are considered.  There is simply no alternative.  So in that case, rules lose first-class citizenship at the class-of-platform perspective.

The only remaining question involves the system perspective.  Should rules be rendered in other models there?  This requires a closer look.

In the Zachman approach, the system perspective involves establishing a knowledge/record-keeping system in which surrogates for real-world things are to be managed and manipulated.  A key criterion is that these surrogates are to be viewed independently of any technology (class of platform).

Based on that prescription, the answer is obvious.  If rules are to be first-class citizens, there is no need whatsoever at the system perspective to render them in other models.  And indeed, there are many reasons for not doing so -- the precision and the flexibility of your design, to mention just two.

Let me restate this point differently.  In system models (the system perspective) there should be no divergence in rule constructs arising from a rule's relationship to (dependence on) other kinds of models.  Any criteria devised for that purpose will inevitably make premature assumptions about the characteristics of the platform(s) to be used for implementation.  The Manifesto expresses this important insight as follows.

(4.4):  Any statements of rules that require constructs other than terms and facts imply assumptions about a system implementation.

So, my response to the designer's e-mail is this:  If you are having to sort out which rules map to action semantics, and which ones to static models, then you are already assuming characteristics of platform(s) -- and almost certainly too soon.


[1]  Business Rules Group, Business Rules Manifesto -- the Principles of Rule Independence, Ver. 2.0 (Nov. 2003), URL:  http://www.BusinessRulesGroup.org/brmanifesto.htm  return to article

[2]  Such models are composite rather than primitive.  Composite models limit overall flexibility.  return to article

# # #

Standard citation for this article:

citations icon
Ronald G. Ross, "What Rule Independence Means to System Models ~ Less and More than You Think!" Business Rules Journal, Vol. 5, No. 6, (Jun. 2004)
URL: http://www.brcommunity.com/a2004/b192.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.