Business Rules Concepts

Business Rules Concepts by Ronald G. Ross (Third Edition)

This is a handy introduction to business rules where it really matters, in the business side of the enterprise.
I read this from two perspectives - as an old-stager in the IT domain and viewing it as a text to recommend from enterprise architect to business decision-makers.

The first pass left me spluttering "well how would this work in practice" at a number of stages. On the second read I was nodding in agreement throughout at the exposition of why expressing Business Rules formally, is a good thing.

What I would like to see is a companion volume "Business Rules Practice Manual" but as Ron Ross says this is probably best provided by some hands-on consultancy.

I did feel that the concept of separation between Business Rules and Business Process could have been pursued more. Certainly you need to avoid coding your business rules within the business process as you would wish to keep them out of the mainline IF-THEN coding of CODOL, JAVA or whatever but some hints about how to integrate the use of BR with BPM would have been useful.

I was glad to see the re-introduction of Decision Tables, familiar from my youth in COBOL and PL/1 programming. However, the examples of decision tables miss explanation of both the basic principles and reasoning. My use of these, from software development, is a bit dated but wikipedia provides a clearer grounding with this example:

A technical support company writes a decision table to diagnose printer problems based upon symptoms described to them over the phone from their clients. The following is a balanced decision table.

Printer troubleshooter

		Rules
Conditions	Printer does not print	Y	Y	Y	Y	N	N	N	N
	A red light is flashing	Y	Y	N	N	Y	Y	N	N
	Printer is unrecognised	Y	N	Y	N	Y	N	Y	N
Actions	Check the power cable			X
	Check the printer-computer cable	X		X
	Ensure printer software is installed	X		X		X		X
	Check/replace ink	X	X			X	X
	Check for paper jam		X		X

With a business rules focus you may object to the expression 'Action' . Replacing 'Action' with 'Assertion' probably meets the intent within Business Rules.
The example on page 111 is particularly difficult to understand.
The use of N-values conditions makes it difficult to rationalise the large number of rules that you get when using many conditions independently to determine what to do. I would replace the N-values with a set of binary values Customer IS 'Silver' etc.
Introducing the 'ELSE' rule feature of classic decision tables at this stage might avoid frightening people with the thought that they are going to have to explicitly deal each of the 192 rules. Yes, 'ELSE' does sound a bit like programming so how about 'Otherwise' or 'Default'

One further niggle - the Table 12.2 is missing in the copy I received -even in the digital age human error can still get you! Ron kindly provided a pdf of this.

That said, if you want to explore the sound basis for Business Rules in your enterprise, start with this entry point.