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 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

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: Deconstructing the Grammar of Business (June 2009), Business Rules are Forking (March 2010)

Ambiguity

All About

I think I am going to start a collection of items that tell me what services or service-orientation is all about. The words "all about" generally make me uncomfortable, especially when I see how many different things (sometimes even from the same source) that SOA is supposed to be "all about".

In the past week, Martin Fowler and David Ing have both posted material about some widely differing uses of the service-oriented tag. (For what it's worth, I think it's the Meridian David Ing, not the Systemic Business one.)

They both use the word ambiguity. I think contradiction would be a more accurate word for what Martin describes in his bliki.

I've heard people say the nice thing about SOA is that it separates data from process, that it combines data and process, that it uses web standards, that it's independent of web standards, that it's asynchronous, that it's synchronous, that the synchronicity doesn't matter ...

Explanation

But the diversity of explanation is not always a sign of contradiction or ambiguity. One reason why there are many different accounts of SOA in circulation is that these accounts are performing at least four different tasks.

Explanation		Examples from David and Martin
Explaining purpose and value	What are services good for?	SOA as a BA execution vehicle
Explaining use	What can we do with services - by what process are the benefits achieved? What does SOA allow you to do?	Building integration points on to your application architecture to open up your data and processes Allowing systems to communicate over some form of standard structure
Explaining form	What does a service look like - what is its essential structure? What are the essential characteristics of a service architecture?	Services are like COM/CORBA components but with cross-vendor standards and/or run-time options around transports SOA is an architecture where applications disappear
Explaining source	Where do services come from - by what process are they made?	Exposing software through web services Using (mostly) asynchronous messaging to transfer documents

(These four types of explanation were described by Aristotle, and are known as the Four Causes.)

Black Box

The ambiguity doesn't come from the fact that there are these different ways of talking about services, nor that these ways of talking about services are imprecise or even contradictory. In some areas, a great deal of effort has gone into producing fairly detailed and reasonably consistent standards, for what that's worth.

The ambiguity comes from the fact that the relationships between these different ways of talking about services are not clear. How does this form relate to this use, and how does this use relate to this purpose? That's where the vagueness and hand-waving often appears.

At some point in the future, the relationships between purpose, use, form and source may cease to be uncertain and become stabilized. When this happens to a technology, it becomes what Bruno Latour calls a "black box" - it encapsulates a particular way of solving engineering problems. Until then, we are faced with creating these relationships afresh for each SOA opportunity.

That's where a good methodology scores - not just to provide guidance on what to do, but to provide guidance on how to reason about what to do.

Update July 2008

John Evdemon has posted a collection of "what is SOA all about" under the heading Moving the SOA Goalposts

Layering Principles

Martin Fowler reports on a workshop in which people (a good group of people, [but] it was hardly a definitive source of enterprise development expertise) vote on principles for software layering.

Some people take this exercise seriously. JohnLim describes the result of the vote as excellent guidelines, while Paul Gielens adds his own vote. Others are more critical, including David Anderson and Rob Diana.

To my mind, even if you could collect up the most experienced people in the software world, I distrust the idea that you could get a coherent and meaningful set of architectural principles from a vote.

Architectural principles must come from reflective practice and/or grounded theory. For example, I can derive layering from a differential theory of change, as follows.


Purpose - What is layering supposed to achieve?

A well-layered artefact or system is more adaptable, because some types of variation can be accommodated within one layer without significantly affecting adjacent layers.


Form - What is the underlying structure of layering?

Boundaries between layers represent step changes with respect to some form of variation, from some perspective:

• Differential change over time
• A split between relatively homogeneous and relatively heterogeneous 

Process - How do layers get established? Layers emerge from an evolutionary process, in which a series of small alterations affect the architectural properties of a system or (often unplanned and unremarked by the so-called architects).

• Redundant layers (where there is insufficient difference in variation between two adjacent layers) tend to gradually fuse together. 
• Flexibility that is not used or exercised will attenuate. 
• Engineers under time pressure will take shortcuts that compromise the official separation between layers. 
• Where there is excessive differentiation within a single layer, this will tend to split apart, initially in an incoherent way.

Material - What is the source of a particular layering?

Layering comes from the experience of variation.



Related post: What's wrong with layered service models? (May 2009), Data Strategy - More on Agility (March 2020)