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.

References

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

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

# # #