Flash Points: Where Business Rules Meet Business Events

There is a direct link between business rules and business events – one not fully understood by many Business Analysts. What is that link and why is it so important? This discussion raises a very big question about how your current requirements approach addresses business rules. Can you answer that question confidently? Here is what every Business Analyst should know about business rules and business events.

Business rules generally apply at various points in time. This point is especially important for behavioral rules – business rules that concern human and organizational behavior and that can be violated. Such violations should be detected in real time.

Each of the various points in time when a behavioral rule needs to be evaluated represents an operational business event. Such events can arise in either business processes or ad hoc business activity.

How do you find these operational business events? Consider the behavioral rule:

A customer must be assigned to an agent if the customer has placed an order.

Figure 1 shows the relevant terms and wordings for this business rule.

Figure 1. Terms and Wordings for the
Agent-Assignment Business Rule

The business rule has been expressed in declarative manner. This means, in part, that it does not indicate any particular process, procedure, or other means to enforce or apply it. It is simply a business rule – nothing more, nothing less.

The business rule makes no reference to any event where it potentially could be violated or needs to be evaluated. The business rule does not say, for example, “When a customer places an order, then ….”

This observation is extremely important for the following reason. “When a customer places an order” is not the only event when the business rule could potentially be violated and therefore needs to be evaluated.

Actually, there is another event when this business rule could be violated: “When an agent leaves our company….” The business rule needs to be evaluated when this event occurs too since the event could pose a violation under the following circumstances: (a) The agent is assigned to a customer, and (b) that customer has placed at least one order.

In other words, the business rule could potentially be violated during two quite distinct kinds of operational business event.

• The first – “When a customer places an order ...” – is rather obvious.

• The second – “When an agent leaves our company ...” – might be much less so.

Both events are nonetheless important because either could produce a violation of the business rule.

This example is not atypical or unusual in any way. In general, every business rule produces two or more kinds of operational business events where it could potentially be violated or needs to be evaluated. (I mean produces here in the sense of can be analyzed to discover.)

These operational business events can be called the business rule’s flash points. Business rules do exist that are specific to an individual event, but they represent a small minority. Two additional points:

• Expressing each business rule in declarative form helps ensure none of its flash points is exempted inadvertently.

• Discovering and analyzing flash points for business rules can also prove useful in validating business rules with business people. Important (and sometimes surprising) business policy questions often crop up.

Your Current Requirements Approach: A Very Big Question

Why is the insight that each business rule generally produces multiple flash points so important? The two or more events where any given business rule needs to be evaluated are almost certain to occur within at least two, and possibly many, different processes, procedures, or use cases. Yet for all these different processes, procedures, and use cases there is only a single business rule.

Now ask yourself this (the very big question):

What in your current IT requirements methodology ensures you will get consistent results for each business rule across all these processes, procedures, and use cases?

Unfortunately, the answer today is almost always nothing.

In the past, business rules have seldom been treated as a first-class citizen. No wonder legacy systems often act in such unexpected and inconsistent ways(!). Organizations today need business operation systems where business governance, not simply information, is the central concern.

Business rules should be seen as one of the starting points for creating system models – not something designers eventually work down to in use cases. That’s the tail wagging the dog.

By unifying each business rule (single-sourcing), and faithfully supporting all its flash points wherever they occur, Business Analysts can ensure consistent results across all processes, procedures, and use cases. Is there really any other way?!

Author: Ronald G. Ross is recognized internationally as the ‘father of business rules.’ He is Co-founder and Principal of Business Rule Solutions, LLC, where he is active in consulting services, publications, the Proteus® methodology, and RuleSpeak®. Mr. Ross serves as Executive Editor of BRCommunity.com and as Chair of the Business Rules Forum Conference. He is the author of nine professional books, including his latest, Building Business Solutions: Business Analysis with Business Rules with Gladys S.W. Lam (2011, http://www.brsolutions.com/bbs), and the authoritative Business Rule Concepts, now in its third edition (2009, http://www.brsolutions.com/b_concepts.php). Mr. Ross speaks and gives popular public seminars across the globe. His blog: http://www.ronross.info/blog/ . Twitter: Ronald_G_Ross