Rules vs. Processes (Again) — Part 2: Now for Events

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles 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.

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

RuleA 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 return to article

[2] www.BusinessRulesGroup.orgreturn to article

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

[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. return to article

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

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

[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.return to article

# # #

Standard citation for this article:


citations icon
Ronald G. Ross, "Rules vs. Processes (Again) — Part 2: Now for Events" Business Rules Journal, Vol. 9, No. 7, (Jul. 2008)
URL: http://www.brcommunity.com/a2008/b427.html

About our Contributor:


Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the BRS Methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:


Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997, now part of the Building Business Capability (BBC) conference where he serves as Co-Chair. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. Find Ron's blog on http://www.brsolutions.com/category/blog/. For more information about Ron visit www.RonRoss.info. Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross
Subscribe to the eBRJ Newsletter
In The Spotlight
 Ronald G. Ross
 Silvie  Spreeuwenberg
The BRSolutions Professional Training Suite

BRSolutions Professional Training Suite

All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.