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 rule. 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
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.)
- 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.
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)