Business rules are forking

Another good post from @tetradian on business rules in response to James Taylor’s recent piece reporting Gartner's view that Business rules are king.

Tom agrees with James Taylor about the importance of discipline around business rules, but objects to an interpretation of business rules that goes back to Taylor's namesake Frederick Winslow Taylor.

Tom distinguishes between decision-support (where the decision is made by a collaboration between an automated system and human judgement) and automated decision-making (where there is no space for human judgement). This distinction is not always clear-cut - if the human actants within a complex business process lack the information, intelligence, attention or confidence to overrule the computer's suggested answer, then a decision-support system becomes defacto a decision-making system.

We should also distinguish between simple rules (binary logic) and more complex rules (modal logic, probabilistic logic). As Tom points out, much of the rule industry appears to assume simple composition of simple binary rules, which are inadequate for most interesting business problems (three quarters of his context space mapping framework).

Tom makes three important points

• We should not assume that the business rules are sufficient, invariant, accurate and complete, especially if they are derived from the people who run the existing processes. Therefore the identification and codification of business-rules generally leaves something to be desired. (One way of putting this is that the Real resists symbolization.)

• There needs to be a very strong emphasis on rule-maintenance, otherwise placing all the business-rules into an automated system will lead to a fit and forget attitude. (One way of putting this is a demand for double-loop or deutero-learning.)

• The viability of using automation for decision-making is dependent on the context.

---

In his new book Obliquity, John Kay discusses the example of waiting for a bus. According to the timetable, a bus should come every ten minutes. There are two rules that should help you decide whether to wait for the bus or walk - except that these two rules contradict each other.

Rule One says the longer you wait for the bus, the more likely it is to arrive soon. So if you have waited for nine minutes, it is practically certain to arrive in the next minute.

Rule Two says that the longer you wait for the bus, the more likely it is that Rule One is incorrect. So if you have waited more than nine minutes for the bus, it is starting to look as if the bus will never come at all.

If you have waited more than half-an-hour for the bus, then common sense suggests that Rule Two is in force. But as Kay points out, many people (including those who drove banks into bankruptcy) appear incapable of shifting from Rule One to Rule Two.

In real business situations, there is always a balance between following a rule and questioning the rule. It is not just automated systems that may fail to strike this balance; many people with significant business responsibility lack common sense. This is an important aspect of the context for decision-making.

---

Update September 2020

Prompted by the current interest in RPA, I've been looking over my old blogposts on Business Rules.

I'm not sure I agree with Tom's point that humans are good at modal logic - there are whole schools of psychotherapy devoted to unpacking common misuses of modal operators, for example reframing "always" and "never" into "sometimes". But individuals may be better than machines (whether computer machines or bureaucratic machines). 

James Taylor's post quotes Jim Sinur recommending a focus on high volatility rules - which would seem to tell against the "fit and forget" attitude Tom warns us about. But jumping forward ten years, we find RPA vendors recommending a focus on using bots for the low volatility rules. Meanwhile "mutant algorithms" try to tackle probabilistic decision-making. The issues raised in his post are clearly relevant to this new technology landscape.

Situation Awareness - Airline Example

Looking at an example of Operational Awareness at Southwest Airlines, presented at a TIBCO user conference in 2008 or 2009

Southwest Airlines is venturing into the rules development space with the Early Alert System. EAS enables SWA to have a real-time model of its entire aircraft fleet, tracking such activities as taxi in, taxi out, and in gate turn. It does this by maintaining a data structure representing physical assets and the activities they perform. Incoming data from those assets update the data structure, and rules react to the changes. We hope to use this paradigm going forward to use rules to monitor other aspects of the enterprise, enabling a more agile and efficient response to the airline's daily operating challenges. Our main points will be the Overview, Feature Review, Design, Other Uses of Rules at present by SWA and the future of rules at SWA. Greg Barton: Southwest Airlines, Senior Software Engineer

FlightExplorer was offering situational and operational awareness to airlines and airports back in 2002.

• real-time flight tracking information
• keeping the operations staff abreast of pending arrivals and departures
• delivering improved airfield safety and efficiency, as well as supporting billing
  

 

Kansas City, Dayton and Grand Rapids - Ford International Airports Take Off With Flight Explorer® to Track Aircraft and Provide Higher Level of Customer Service (Flight Explorer, 16 May 2002)

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)