In my previous column,[1] I outlined the basic elements of RuleSpeak® from a formal point of view, as part of the Journal's coordinated coverage of Semantics of Business Vocabulary and Business Rules (SBVR).  In December 2007, the Object Management Group (OMG) approved the "Semantics of Business Vocabulary and Business Rules" (SBVR) to become an official specification of the OMG.  Version 1 (SBVR 1.0) was published January 2008; Versions 2 (SBVR 1.1) & 3 (SBVR 1.2) were published in 2013).[2]  SBVR is the first OMG standard for concept models and business rules. SBVR is a highly structured set of fundamental concepts, not a syntax for rule representation — it can support a variety of representational schemes and best practices.  In this month's column, extracted from the RuleSpeak Annex for SBVR, I examine RuleSpeak's support for definitions under SBVR, and how it relates to rules.  The companion SBVR Speaks column introduces SBVR's treatment of 'definitions' in general and, specifically, covers their representation in the language of SBVR Structured English.[3]

RuleSpeak^® is an existing, well-documented^[4] business rule notation developed by Business Rule Solutions, LLC (BRS) that has been used with business people in actual practice in large-scale projects since the second half of the 1990s.  The Semantics of Business Vocabulary and Business Rules (SBVR) is very flexible in supporting alternative practices with respect to rules and definitions, including those of RuleSpeak.  This flexibility is enabled by the underlying logical formulations and their underpinnings in formal logic.

Two core RuleSpeak practices with respect to definitions are the following.^[5]

1. 'Essence' by Definitions.  A definition should always focus on the core essence of a concept — that is, on fundamental meaning that is unlikely to change.  Such meaning is expressed as naturally as possible.  The form of language used in common dictionaries is strongly preferred.


2. 'Boundaries' by Rules.  All constraints should be expressed as rules separate from definitions.  Such rules generally define the 'boundary conditions' of a concept; that is, when something is or is not an instance of the concept.  Since specific boundaries for a concept (e.g., 'gold customer') can change over time, they should not be embedded in definitions.  An additional advantage — crucial for communication with and among business people — is that the underlying vocabulary can be kept as compact and as focused as possible.

Experience in large-scale projects indicates that these core practices

• ensure good business communication.
• produce friendly and highly stable definitions.
• scale extremely well for complex business problems featuring hundreds or thousands of rules.

RuleSpeak might therefore be characterized as more 'rule-ish' than the approach described in SBVR Structured English.^[3]  RuleSpeak is well suited for practitioners who want to

• move faster to rule capture.
• use more natural (less formal) wordings for definitions.

These issues are pragmatic concerns for business rule projects.  It is important to remember, of course, that under SBVR either approach (and others) can produce identical semantics 'under the covers' (i.e., in logical formulations).

Example in RuleSpeak

A EU-Rent definition and set of related specifications taken from the SBVR EU-Rent Annex^[6] concerning 'agency' (a category of 'branch') serve to illustrate.  The RuleSpeak approach is outlined subsequently.

Sample Definition and Related Specifications for 'Agency'

Consider what 'agency' means to EU-Rent:  these are service desks in hotels, travel agents, etc.  They have storage space for few cars, and are operated on demand by part-time staff who will typically do the entire workflows for rental and return.  Here is EU-Rent's formal definition.

RuleSpeak Approach for the 'Agency' Example

Definitional Rules vs. Behavioral Rules

In RuleSpeak, the distinction between definitional rules and behavioral rules is viewed as follows.^[7]

• Definitional rules prescribe criteria for how the business chooses to organize ('define') its business semantics.  Such rules express criteria for correct decisions, derivations, or business computations.  Definitional rules supplement definitions.
  
  
• Behavioral business rules focus directly on the propriety of conduct in circumstances (business activity) where willful or uninformed actions can fall outside the boundaries of behavior deemed acceptable.  Unlike definitional rules, behavioral rules can be violated directly.

The distinction is clear-cut in most cases; in some, it is more difficult.  For example, consider 'booking' in the EU-Rent case study.  'Booking' (like 'order', 'reservation', 'registration', etc.) is essentially a 'made-up' device of the business.  It is an artifact of knowledge that exists 'simply' to help manage complex, expensive resources.

Therefore, rules about creating bookings (e.g., that the requested pick-up date-time is to be after the booking date-time) are to be viewed as definitional.  If not followed (applied) in creating a booking, the booking is simply invalid.  In other words, since bookings are a knowledge 'thing', the business can establish definitive rules for them.  These are the boundary rules discussed earlier.

Now consider 'actual pick-up date-time', the date-time when possession of a rental car is actually handed over to a rental customer (or is said to have been, anyway).  EU-Rent might want to avoid post-dating handovers — i.e., have a rule that the actual pick-up date-time is to be after the booking date-time.

This case is quite different.  'Actual pick-up date-time' reflects activity (or the communication thereof) outside the realm of knowledge artifacts — i.e., conduct that takes place in the 'real world'.  Because such rules can be broken (by people), they are behavioral.

In borderline cases, RuleSpeak best practice is the following:^[8]

RuleSpeak Best Practice:  Carefully distinguish what should be (according to the definitional rules) vs. what really is, based on actual business decisions / actions.  One or more behavioral rules are then specified to constrain 'what really is' against 'what should be'.  These latter rules, being behavioral, are the ones that can be violated.

References

[1]  Ronald G. Ross, "The RuleSpeak^® Business Rule Notation," Business Rules Journal, Vol. 7, No. 4 (Apr. 2006), revised (Oct. 2013), URL:  http://www.BRCommunity.com/a2006/b286b.html   

[2]  Semantics of Business Vocabulary and Business Rules (SBVR), v1.2.  Object Management Group (Oct. 2013).  Available at http://www.omg.org/spec/SBVR/    SBVR 1.2 and all related files are available at http://www.omg.org/spec/SBVR/1.2/ 

[3]  SBVR Insider, "SBVR Speaks:  Concepts and Definitions in SBVR," Business Rules Journal, Vol. 7, No. 5 (May 2006), revised (Oct. 2013), URL:  http://www.BRCommunity.com/a2006/b288.html

[4]  Ronald G. Ross, Principles of the Business Rule Approach, Boston, MA:  Addison-Wesley, 2003, Chapters 8-12.  Versions of RuleSpeak have been available from Business Rule Solutions, LLC since the late 1990s, available for download at RuleSpeak.com.  Public seminars have taught the syntax to thousands of professionals starting in 1996 (www.AttainingEdge.com).  The original research commenced in 1985, and was published in The Business Rule Book, 1994 (www.BRSolutions.com).

[5]  Ronald G. Ross.  Business Rule Concepts:  Getting to the Point of Knowledge.  4th ed.:  Business Rule Solutions, LLC, 2013, Chapter 5, pp. 61-62. (www.BRSolutions.com/b_concepts.php).

[6]  The car rental examples come from EU-Rent, a (fictitious) car rental company.  This popular case study was contributed to the SBVR effort by Model Systems and appears in detail as Annex G of the SBVR document.

[7]  Ronald G. Ross.  Business Rule Concepts:  Getting to the Point of Knowledge.  4th ed.:  Business Rule Solutions, LLC, 2013, Chapter 7. (www.BRSolutions.com/b_concepts.php).

[8]  Ronald G. Ross.  Business Rule Concepts:  Getting to the Point of Knowledge.  4th ed.:  Business Rule Solutions, LLC, 2013, Chapter 7. (www.BRSolutions.com/b_concepts.php).

# # #