Rules and Processes: Examples Showing How They Relate

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

I am often asked about how rules relate to processes.  I should really say, how business rules relate to business processes.  The simple answer is that business rules off-load various kinds of work from business processes.  There is, of course, more to the story than that.  Since examples sometimes work best, I am devoting this entire column to a sample set of rules, all in RuleSpeak, to illustrate six different kinds of significant off-loading.  See if you agree with these six categories or if you can add more.

1. Branching.  Suppose a process includes the task 'Verify Basic Claim Information', which has the three conditional branches coming out of it:  Valid, Invalid, and Incomplete.  What are the criteria for going one way as opposed to another?  A relevant structural business rule might be:

A claim can be considered valid only if it has all the following:

* An active policy.

* A claimant.

* An incident.

2. Derivation.  Suppose a process involves determining whether an insurance claim is large.  This determination might be off-loaded to some structural business rule(s) such as the following:

A claim is always considered large if the claimed amount exceeds $50,000.

3. Timing.  Timings can make or break effective business operation.  Since timings can cover a highly generalized set of criteria, they should be off-loaded from business processes in the form of operative business rules, as the following example illustrates.

A claimant must be notified within 5 days once their claim has been denied.

4. Iteration.  What limits need to be placed on performing a repetitive task or cycle of tasks within a business process?  Limits on iteration can be expressed as operative business rules, such as the following:

The total number of requests made for additional information for a claim must not exceed 10.

5. Service Level Agreement.  Suppose an unresolved problem or circumstance needs to be escalated to a higher level of authority as it becomes more urgent.  The specifications for such escalation can be expressed as some operative business rule(s), as follows.

A customer service request must be brought to the attention of a supervisor if the request is not resolved within 4 hours.

6. Business Consistency.  One of the most difficult goals for effective business operations is achieving simple consistency in business practice across different situations or scenarios.  Treating rules as a first-class citizen in business architectures (as prescribed in the Business Rules Manifesto) off-loads a significant share of this concern from business processes.  The following operative business rule (which depends on the rule given for "large" in item #2 earlier) illustrates.

A client must be monitored by a specialist if the client has filed a large claim.

This full import of this rule might not immediately meet the eye.  The rule obviously must be enforced when a large claim is filed.  However, there are two other events where a potential violation could also occur, as follows.  The business rule innately covers all these scenarios.

  1. A specialist assigned to a large claim leaves the company or retires.  This could leave a large claim without a specialist to monitor it.
  2. A claim originally not large when first filed becomes large later (say, because of adjustments, new charges, etc.).  This could also result in a large claim without a specialist to monitor it.

By the way, this rule is not unusual or peculiar at all.  The large majority of business rules are of this type -- that is, multi-event.  A solid architecture supporting both business rules and business processes takes that into account -- indeed, I believe this is nothing less than a defining characteristic of true business rule architectures.

# # #

Standard citation for this article:

citations icon
Ronald G. Ross, "Rules and Processes: Examples Showing How They Relate" Business Rules Journal, Vol. 7, No. 10, (Oct. 2006)

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 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 For more information about Ron visit Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross
Subscribe to the eBRJ Newsletter
In The Spotlight
 Jim  Sinur
 Ronald G. Ross

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.