Premise and Conclusion

Rules vs. Processes (Again) — Part 2
Now for Events^[1]

by Ronald G. Ross

Processes connect to rules via events.  Processes produce events, which can fire one or more rules (i.e., cause the rule(s) to be evaluated).  The rules might determine whether the event is undertaken correctly or will produce a desired outcome.  The rules also might make some decision.  The rules are externalized from the processes and established as a separate resource.  This permits direct management of the rules, which in turn permits much closer tie-in to the business side and far greater agility in decision logic.

This notion of Rule Independence is the centerpiece of the business rule approach.  The various principles underlying this fundamental principle are enumerated in the Business Rules Manifesto.^[2]

Understanding Rule Independence requires careful examination of the relationship between rules and events.  Intuitively, we know that certain rules apply when certain events occur.  But what exactly is the connection between rules and events?

To understand, we must probe into events more deeply.  What is an event?  There are at least two ways of looking at events, both correct from their own perspective.

1. The business perspective:  For the business, an event is something that happens requiring the business to respond, even if only in a trivial way.  (Usually, the response is not trivial.)  For example, a customer places an order.  This is an event that requires a well-organized response.  Often we try to organize our response to such business events in advance — for example, within business process models, workflow models, procedures, and so on.
   
   
2. The IT perspective:  For an information/knowledge system that supports the business, anevent is something that happens and needs to be noted or recorded^[3] because knowing about the event is potentially important to other activities, either those occurring during the same time frame or those that might happen later.  In the business rule approach, of course, such recording is always based on predefined terms and facts — that is, primarily on the basis of the fact model.  An information/knowledge system can support the fact model in several ways:  either directly, or indirectly through a database design, a class diagram, and so on.  To simplify matters, let's just say there is some data somewhere in the system that must be updated (created, modified, or deleted) to record the event.  Otherwise, the business cannot know about the event.  For convenience, I will call these update events.

Now, how do events connect with rules?  Consider the following sample business rule (expressed in RuleSpeak).  Figure 1 shows the relevant terms and facts for this rule.

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

Figure 1.  Terms and Facts for the Customer Rule.

The rule itself 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 rule — nothing more, and nothing less.

Declarative also means that the rule makes no reference to any business event or update event where it potentially could be violated and/or needs to be tested — that is, where it needs to fire.  The 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 rule could potentially be violated.  Actually, there is another event when this rule could be violated.  In business terms this other event might be "When an agent leaves our company...."  The corresponding update event might be "When an agent is deleted...."^[4]  This other event could pose a violation of the 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 rule could potentially be violated during two quite distinct kinds of events.  The first — "When a customer places an order ..." — is rather obvious.  The second — "When an agent leaves the company ..." — might be much less so.  Both events are nonetheless important because either could produce a violation of the rule.

This example is not atypical or unusual in any way.^[5]  In fact, it is quite commonplace.  In general, every business rule (in proper declarative form) produces^[6] two or more kinds of events where it could potentially be violated and/or needs to be evaluated (i.e., needs to fire), both at the business perspective and the system perspective.^[7]

In summary, what does this analysis reveal about the relationship between rules, events, and processes?  First, it illustrates the basic point that rules and events, while related, are not the same.  Second, it illustrates that there are always potentially multiple events where any given rule needs to fire (be evaluated).  Figures 2 and 3 provide additional examples to reinforce this crucial point.  Finally, it illustrates that the relationship between processes and rules is an indirect one — processes produce events, and events in turn should fire rules.

Figure 2.  Multiple Events for a Simple Rule.

Rule:  A customer must have an address.

This rule produces…

Update event #1:  When an instance of customer is created.

Update event #2:  When an attempt occurs to delete (nullify) the value of address.

Figure 3.  Multiple Events for a More Complex Rule.

Rule:  A territory must not include more than one of the following:
    * Non-candidate traditional gas station.
    * Ultra-service.
    * Food outlet.

This rule produces…

Update event #1:  When an instance of territory is created.

Update event #2:  When an instance of direct outlet is added to (included in) an existing territory.

Update event #3:  When an instance of direct outlet already included in a territory changes kind.

Update event #4:  When an instance of traditional gas station already included in a territory gets or changes evaluation.

References

[1]  Excerpted from Chapter 2, Business Rule Concepts:  Getting to the Point of Knowledge (Second Edition), by Ronald G.  Ross, September 2005.  ISBN 0-941049-06-X - www.BRSolutions.com

[2] www.BusinessRulesGroup.org

[3]  More precisely, an event from this perspective can be defined as any change in state.

[4]  The specific update event that poses a potential violation of the rule is actually the deletion of an instance for the 'is assigned to' fact type.

[5]  Rules do exist that are specific to individual update events, but these rules represent the exception, rather than the general case.

[6]  I mean "produces" in the sense of can be analyzed to discover.

[7]  An obvious exception is if the rule is qualified in such manner that it applies only when a given event occurs, for example:  A customer must be assigned to an agent who lives in the same city at the time of assignment.