Intuitively, we know that certain business rules apply when certain events occur. But how exactly?

At the risk of stating the obvious, let me begin by clarifying that a business rule and an event are not the same thing. There should be no confusion about that. A business rule gives guidance; an event is something that happens.[1]

How do business rules and events relate? Consider the business rule: A customer must be assigned to an agent if the customer has placed an order. Figure 1 presents a concept model diagram outlining the relevant terms and wordings for this business rule statement.

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

The business rule itself has been expressed in declarative manner using RuleSpeak^®.[2] 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.

Declarative also means that 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. Actually, there is another event when this business rule could be violated: "When an agent leaves our company…." This other event could pose a violation of the business rule 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 events.

• When a customer places an order …
• When an agent leaves our company …

The first is rather obvious. The second is 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 (expressed in declarative form) produces two or more kinds of events where it could potentially be violated or needs to be evaluated. (I mean produces in the sense of can be analyzed to discover.)

We call these events flash points.[3] Business rules do exist that are specific to an individual event, but they represent the exception not the general case.

Let's summarize what I've said so far:

• Business rules and events, while related, are not the same.


• Specifying business rules declaratively helps ensure no flash point is missed.


• Any given business rule, especially a behavioral business rule, needs to be evaluated for potentially multiple flash points.

Figures 2 and 3 provide additional examples to reinforce this last point.

Figure 2. Multiple Events for a Simple Business Rule

Figure 3. Multiple Events for a More Complex Business Rule

Why is that last point so important? The two or more events where a business rule needs to be evaluated are likely to occur within at least two, and possibly many, different processes, procedures, or use cases. They might also occur anywhere in ad hoc (unmodeled) business activity.

Yet for all these different processes, procedures, use cases, and other activity, there is only a single business rule. By specifying the business rule only once, and faithfully supporting all its flash points wherever they occur, you ensure consistency and integrity everywhere.

Discovering and analyzing flash points for business rules often also proves a very useful activity in validating business rules. Important and sometimes surprising guidance issues (a.k.a. business policy questions) often crop up. This capability is one of many for validation and verification of business rules that business-rule-friendly tools can and should support.

This type of business-rule-centric event analysis is not a feature of any traditional requirements or IT methodology — and perhaps even most importantly, of any widely-used automated rule platform. Once you fully appreciate that crucial insight, you can begin to see why legacy systems so often produce such inconsistent results.

References

[1] Merriam-Webster Unabridged Dictionary — event 1a.

[2] Refer to www.RuleSpeak.com

[3] Ronald G. Ross, Business Rule Concepts: Getting to the Point of Knowledge (4th ed), (2013), Chapter 8, pp. 99-102.

# # #