Thursday, December 03, 2009

Business Rule Concepts

by Ronald G Ross. Third Edition: Getting to the Point of Knowledge. Business Rule Solutions 2009.
ISBN 0-941049-07-8

A copy of this book arrived in the post this week. I don't know who sent it but I assume it's a review copy from the publishers. (In which case, the publishers have chosen not to implement the standard Cover-Note role. Perhaps they have implemented the If-Anyone-Reviews-It-We'll-Probably-See-Something-On-Twitter rule instead.)

As the title indicates, the book provides a detailed account of the concept of Business Rule, and appears to offer some elements of a methodology for doing something or other. My normal procedure for reviewing such books is to apply the Four Causes.

  • Final Cause - what's the purpose, for whom
  • Material Cause - what is the stuff that is being worked on
  • Efficient Cause - who does it, and how
  • Formal Cause - what's the conceptual framework
Most of the book is taken up with a conceptual framework for business rules. What does a business rule look like, and how can different kinds of business rule be classified. So that's the Formal Cause.

Ross argues that just as the human body is composed of bones (structure), muscles (power) and nervous system (control), so business is composed of factual knowledge (structure), processes (power) and business rules (control), expressed as nouns and verbs.

To me, this looks like a huge simplification. For a start, in order for the human body to do anything useful, the muscles need energy. The biological control system doesn't only control the muscles, it also controls the respiration system - delivering stored energy to the muscles. And for a business to be viable, we generally need to pay attention to the adverbs as well as the nouns and verbs. But in order to consider whether Ross's simplification is useful for some purpose, we need to look at the other three causes.

A business rule is supposed to describe the business. This suggests that there is some stuff (let's call it the implicit logic of the business) from which properly constituted rules can be elicited - the Material Cause. Rules are correct and complete if they accurately and fully capture the AS-IS or TO-BE logic of the business. (Ross tells us little about verification and validation, except to say that it's easier if the rules are held in some kind of repository.)

But which logic? Ross doesn't want to get sucked into expert systems or artificial intelligence (p 23). He argues that the point of establishing business rules is to give you more time for strategic and tactical thinking, problem solving and other stuff (pp 4-5). I infer from this that he is not trying to elicit the logic of these higher-level activities (where my interest in Organizational Intelligence is focused): his methodology concentrates on what he calls Operational Decisions.

The book also contains a number of rules about rules. For example
  • A rule saying there shall be no rule restricting the age at which a customer can open an account (p 92). This kind of rule is important in any organization where different units can define some of their own rules.
  • A rule saying that the cheapest rule should be executed first (p 128). This kind of rule is important for balancing the internal efficiency of a system with the external customer experience, and assumes we have some way of associating different kinds of cost with a rule. (The cheapest rule from the programmer's point of view may be very expensive in terms of customer satisfaction and lost business.)
These rules-about-rules are not formalized, and so I'm presuming they are not within the scope of the business rules methodology. However, some important rules-about-rules are stated in the Business Rules Manifesto (p 143-144). For example
    6.3 - A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action. 
    6.4 - Rules are based on truth values. How a rule's truth value is determined or maintained is hidden from users.
I suspect that these two rules conflict with each another. Unfortunately, I can't verify this suspicion, because the vocabulary used to express these business rules is not coordinated (see p 108). Perhaps Mr Ross should eat his own fish-fingers.

Now let's look at the Efficient Cause. The book seems to be aimed at a business analyst trying to specify the requirements for a system - either a completely automated system or what Ross calls a Really Smart System, which may include people making smart operational decisions with the support of rules that are rendered as guidance messages. However, I didn't get a very clear picture of how Business Rules might fit into a normal systems development methodology. Indeed, the back cover blurb advertises "a common-sense approach to solving today's operational business problems", but I could find nothing in the book that looked like a real business problem (as opposed to fairly routine business requirements.)

(To be fair, I should say that Ross's separation between facts, processes and rules seems consistent with some of the business modelling ideas I have published through the CBDI Forum, so I'm not saying it's wrong, merely that it may not be the whole story.)

Last but not least, the Final Cause. What is the value of this methodology, to whom? Ross asserts that the explicit separation of factual knowledge, processes and business rules produces more effective solutions, and therefore more successful (effective, adaptive) business behaviour (p 5). His approach has the "potential for closing the requirements gap between business people and IT" (p 28). And he asserts that for some class of crucial everyday decisions "you can capture all the business rules and make precise or optimal decisions" (p 31).

Ross doesn't provide any evidence for these assertions, but he doesn't have to, because they are "proven". Humph.

So where does that four-cause analysis leave us? What Ross gives us is a lot of detailed discussion about business rules and how they can be analysed. If you are already sold on the concept of business rules, and possibly interested in using business rules to design a layer of capability services that are decoupled from the entity layer and the process layer, then you may find the book very helpful.

Why have I devoted a long blogpost to discussing this book? Because I think it's important for design methodologies to be presented in a balanced way - covering all four causes.. Ross's book is typical of many such books - fairly sound on the Formal Cause, not so strong on the other three causes - and I think this imbalance helps to explain the patchy adoption of such methodologies.

Related Posts: Business Rules are Forking (March 2010)

1 comment:

Patrick Van Renterghem said...


I have also received a review copy of Ronald Ross's book on Business Rule Solutions, but I know where and why I got it: at the Three Amigo's event along with John Zachman and Roger Burton, Ron was offering to send out copies of his books when they became available. But indeed, an explanation was missing from my book as well. On the contrary, there were some marketing leaflets for Ron's consulting business...

I had the impression that Roger and Ron were not completely on the same frequency, and I get the feeling again when reading Ron's book that he tries to force business rules onto us as the solution to everything, where a) he can not convince me that this will work, b) perhaps it will work for simple cases as given in the book, but I don't see general business rule systems applicability. Perhaps
we need some of Ron's consulting to explain and implement...

Patrick Van Renterghem
twitter: @itworks