Business Rules Solutions: Flash Points

Flash points are the specific events when a rule needs to be evaluated based only on the semantics of the rule itself – that is, using no external model or specification such as a procedural model or decision model. For a behavioral business rule, flash points are the events where the rule could be violated. Flash points for the same rule can occur in multiple processes, procedures, use cases, etc., or at various points in ad hoc (unmodeled) business activity. Comprehensive support for flash points is essential for maintaining the integrity of business solutions. Invoking flash points automatically requires 'stateful' platforms. Read all about flash points in this month's Column.

Flash Points: Business Rules, Events and Integrity

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

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

Business Rule: A customer must have an address.

Figure 2. Multiple Events for a Simple Business Rule

Flash Points:

  • Event #1: When an attempt occurs to assert the existence of a new customer.
  • Event #2: When an attempt occurs to eliminate the address of a customer.

Business Rule: A territory must not include more than one of the following:

  • Non-candidate traditional gas station,
  • Ultra-service,
  • Food outlet.
Figure 3. Multiple Events for a More Complex Business Rule

Flash Points:

  • Event #1: When an attempt occurs to assert the existence of a new territory.
  • Event #2: When an attempt occurs to include a direct outlet in a territory.
  • Event #3: When an attempt occurs to change the kind of a direct outlet already included in a territory.
  • Event #4: When an attempt occurs to assert that a traditional gas station already included in a territory is not being considered for modification.

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.

Notes

1 Merriam-Webster Unabridged Dictionary – event 1a

2 Refer to www.RuleSpeak.com.

3 Business Rule Concepts: Getting to the Point of Knowledge 4th ed. by Ronald G. Ross, 2013, Chapter 8, pp. 99-102. PDF Version

Ron Ross

Ron Ross

Ronald G. Ross is Co-Founder and Principal of Business Rule Solutions, LLC (www.BRSolutions.com). BRS provides workshops, consulting services, publications, and methodology supporting business analysis, business rules, business vocabulary, and rule management. His popular public seminars on business rules and business analysis, the first on business rules (starting in 1996) and the longest-running in the industry, are given through AttainingEdge (www.AttainingEdge.com). At BRS, Mr. Ross co-develops Proteus®, its landmark business analysis and business rules methodology, which features numerous innovative techniques including the popular RuleSpeak® (available free through www.BRCommunity.com). These are the latest offerings in a 30-year career that has consistently featured creative, business-driven solutions. Mr. Ross also serves as Executive Editor of www.BRCommunity.com and its flagship on-line publication, Business Rules Journal. He is a regular columnist for the Journal's Commentary section which also features John Zachman, Chris Date, Terry Halpin, and Roger Burlton. BRCommunity.com, hosted and sponsored by BRS, is a vertical community for professionals working with business rules and related areas. Mr. Ross was formerly Editor of the Data Base Newsletter from 1977 to 1998. Mr. Ross is recognized internationally as the "father of business rules." He has served as Co-Chair of the annual Business Rules Forum Conference since 1997. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of the two landmark BRG papers,"The Business Motivation Model: Business Governance in a Volatile World" (2000, revised 2005) and the "Business Rules Manifesto" (2003). He is also active in OMG standards development for business rules and business models. Mr. Ross is the author of eight professional books. His newest are: Business Rule Concepts (2005), a second edition of his popular, easy-to-read 1998 handbook, and Principles of the Business Rule Approach, Addison-Wesley (2003), featuring the business rationale and opportunity for business rules. An earlier work, The Business Rule Book (1994, 1997), was the seminal work in the field. Mr. Ross received his M.S. in information science from Illinois Institute of Technology, and his B.A. from Rice University.
Share
Share
Share