Business Rules FAQ

1

First we need to recognize the the BRF folks see rules as pretty big things.  Ron Ross talks about maybe 1000 rules in an ERP.  I think of those as analysis rules.  The more detailed implementation rules are also rules but don't seem to hit the BRF radar.

So I can be clear:  I think a real rule is:

"If a Jr. HR employee opens an employee record for maintenance, they are allowed to change the address but nor the salary field."  Many folks from the rules community think that the above is an implementation thing and not a rule at all.  I disagree.

But if that sort of thing is a rule then a lot of the following do not make sense.  And are not even true. 

Also, if you agree that the above is a "rule" then we will have perhaps 500,000 rules in a system and we need a very different way of thinking about them.

However, if you buy into my idea of analysis rules and implementation rules, then the manifesto is fine if you consider that it is referring to analysis rules.

Definitions:

Analysis Rule: The rules that users "tell" you.  Represented in a way that users think and talk. "Purchase orders over $50,000 need to go through 3 levels of approval."  Analysis rules are vague and imprecise and are not directly implementable without further analysis.

Implementation Rules: Rules that are complete enough to actually generate or drive a part of the system.  They should be readable and enterable by people but are not in natural language.  Natural language is not precise enough to be used.  If it is precise enough it is too wordy to be usable.  500,000 sentences is not manageable. An ERD is a rule representation for a subset of structural business rules.  It is precise enough to generate a data structure.  A process flow is also a suitable rule representation.  It can read and manipulated by a user and can be made to be precise.

There is a lot more of this discussion in the BRIM white papers on the Dulcian web site.

Paul

--- I do have a few comments on the specific points below

3. Rules are not process and not procedure.  They should not be embedded in either of these.

Not sure I agree with this, but I am not sure I understand what they mean by this.  Can anyone enlighten me?

4. Rules build on facts, and facts build on concepts as expressed by terms.

--- Well this is an articulation of the BRF rule grammar.  I am not sure I would agree that there is no other way to think abbout rules.

5. Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.

---  see comment on 4 above

10. Rules are best implemented declaratively.  Rules are based on truth values.  How a ruleís truth value is determined or maintained is hidden from users.

--- I have never seen any real discussion of how to implement "rules" as they describe them.  I think they need to actually pput an implementation algorithm on the table for us to be able to talk about how to best implement them.

13. The relationship between events and rules is generally many-to-many.

--- probably but how about a definition of an "event" first.

14. A rule statement is distinct from the enforcement level defined for it.  These are separate concerns.

--- I have no idea what this means

Full list at

http://www.businessrulesgroup.org/brmanifesto.htm