On Business Rules Categorization – Part IV – Rule Classification

This entry is part 4 of 5 in the series Business Rules Categorization

This is the fourth of a multiple part on the topic of business rules categorization.

In Part I, we saw a definition for business rule which is very broad and needed to be broken down a bit more. In Part II, I performed a search on the use of the terms “business rules” which showed me that a lot of people refer to those words. In Part III I searched for a classification of business rules that would help put some clarity into it all and found some starting points.

What this classification is about

As I performed my search for a classification, I eventually was able to identify what it was and was not:

  • It is a work in progress and will probably change based on discussions and further research
  • It is a classification of business rules, that is, rules that are under business jurisdiction
  • It does not mean that the implementation of these rules is done by the business people, but they should be the ones in control of the contents of the rules
  • It is not a replacement for other classifications or categorizations that have been documented
  • It is a categorization of business rules based on where the business rules will most probably be implemented in a SOA architecture. 

The basic classification

  Rule Category Description Execution component


Rules for data transformation

Rules that transform data from one format to another.

ETL tools, Database, XSLT, Integration tools


Rules for referential integrity

Rules that represent and control the relationships between entities. These are database associations, multiplicity, constraints, triggers, etc.



Rules for data validation

Rules that keep the information (data) in the system consistent. For example, mandatory attributes, type, min, max, etc.

Dynamic web pages, Database


Rules for security

Rules that control access to functionality or data based on roles

Single Sign On, Authentication services


Rules for presentation

Rules that allow for dynamic content to be presented to users.

Dynamic web pages, Content management


Rules for workflow or business process

Rules that are business process and workflow related.

BPM or Workflow Engine


Rules for decisions

Rules used to define the dynamic, business-level building blocks of the policies, directives and initiatives of an enterprise.

Business Rule Engine


Rules for rating engine*

Rules that represent a pricing model to be applied to a given transaction.

Rating Engine

My comments on the classification

The first three categories are all Data related and can be grouped under a parent category as such.

As indicated, my motivation for creating this classification was to identify which execution component would actually implement the rules in a SOA architecture.

As for the documentation and management of the rules, that is a totally different exercise since some of these tools are built with documentation and management in mind, whereas others are not.

But these are not all for the business…

Some will argue that some of these rules categories are not business rules but I think that all of these have a “under business jurisdiction” component as shown below although it does not mean that the business will be implementing them in the system.  

Rule Category
Why under business jurisdiction?


Rules for data transformation

Business decides which fields map to which other fields.


Rules for referential integrity

Business decides what is the relationship between items as well as the multiplicity


Rules for data validation

Business decides what the type of the field will be, the length, the allowed values, etc.


Rules for security

Business decides on the roles, the accesses to which functionality


Rules for presentation

Business decides which pages should appear, in what order, etc.


Rules for workflow or business process

Business decides on the processes used in the enterprise


Rules for decisions

Business controls all decision rules


Rules for rating engine

Business decides on the pricing models to use



I would like to hear from readers about their thoughts on this classification. I actually have some more posts planned on the subject if there is some interest. Primarily (for now)

  • How it relates to System/IT rules and Business rules as discussed by Ronald G. Ross
  • How the BRS Rule classification relates to this one

I’m looking forward to hearing from readers.

* I want to thank The Hartford for their inspiration on adding the rating engine to the classification after their presentation at the Business Rules Forum 2008.

On Business Rules Categorization – Part III – Other rule classifications

This entry is part 3 of 5 in the series Business Rules Categorization

This is the third of a multiple part on the topic of business rules categorization.

So far, we have seen a definition for business rule which is very broad and needed to be broken down a bit more. I then performed a search on the use of the terms “business rules” which showed me that a lot of people refer to those words. I then was hoping to find a classification of business rules that would include all of that and put some clarity into it.

As part of my search for a categorization, I obviously performed a search on existing classifications. This post will be about the main classifications I have found and my thoughts on each of them.

Note that my own classification will not appear in this post since this is just an overview of other classifications I have found. This might not be of general interest to everyone and readers can actually wait for (or go to) the next post in this series to see what I proposed.

Ronald G. Ross’ BRS Rule Classification Scheme

The obvious place to start is to look at Ronald G. Ross’ work on the subject. He summarizes it in an article available on brcommunity.com[1].

His classification contains the following three main categories (for more details see his article):

  1. Rejector (Constraint)
  2. Producer
    1. Computation Rules
    2. Derivation Rules (Inference rules)
  3. Projector (Stimulus / Response Rules)
    1. Enabler
    2. Copier
    3. Executive (Trigger) 

This is a good classification but as I was looking at this classification I realized that I was looking for a classification that would allow me to identify in which type of system the rules would be implemented, not just what type of rule it was. I will explain that a bit further in the article, for now let us continue a quick review of other classifications.

Barbara von Halle’ classification from Business Rules Applied[2]

In her book, she lists a few classifications from other sources and proposes her own classification which goes as follows:

  • Term
  • Fact
  • Mandatory Constraint
  • Guideline
  • Action Enabler
  • Computation
  • Inference

In this case, some of the classification is very similar to the BRS Rule classification. The main difference here is Guideline which is different. As for Term and Fact, as far as I am concerned they are not types of rules but then again this isn’t my classification now is it?

One thing I liked when I read through the classification is some of Versata’s classification which I will detail later in this post.

Inastrol’s Business Rule classification scheme

Terry Moriarty’s company Inastrol[3] uses the following classification:

  • Eligibility (Inference)
  • Validation (Constraint)
  • Computation (Calculation)
  • Process (Even-Condition-Action / Action Enabler)
  • Authority (Policies) 

I found interesting that this was the first use of the word “Process” since some rules are obviously associated to processes.

Versata’s classification [4]

As mentioned above, Versata had some interesting categories listed in von Halle’s book. I then went and searched Versata’s web site and also found some archives and I compiled the following list which they used at one time or another:

  • Referential Integrity
  • Derivations
  • Validation
  • Constraint
  • Action/Event
  • Presentation
  • Data
  • Transaction
  • Process
  • Decision


In this list which I compiled from different sources, I liked the distinction between process, data, transaction, presentation and decision rules since chances are these types will be implemented in a different product.

One thing that is interesting is that most if not all of the classifications can be mapped back to the BRS Rule classification.

Well there you have it. That was my inspiration for building my own classification. In my next post, I will detail this new classification.

[1] The BRS Rule Classification Scheme
[2] von Halle, Barabara, 2002, Business Rules Applied, Wiley
[3] http://www.inastrol.com
[4] http://www.versata.com

On Business Rules Categorization – Part II – Use of business rules

This entry is part 2 of 5 in the series Business Rules Categorization

This is the second of a multiple part on the topic of business rules categorization.

So my search for a definition was done (see part I of this series). But as I had done a lot of research and reading, I found that the words “business rules” was being used a lot by many people and in different contexts.

So I started compiling a few of the main places where the words “business rules” were being used. This was hopefully going to help me with my new search for a way to categorize the rules.

For example, I found references to business rules in:

  • Database world: Basically a business rule is a constraint on the database tables. Of course, when you think of it, the cardinality (or multiplicity) of records between tables should be driven by the business. But the best definition I found was in the book “Database design for mere mortals”[1]:

A Business Rule is statement that imposes some form of constraint on elements within a field specification for a particular field or on characteristics of a relationship between a specific pair of tables. A Business Rule is based on the way the organization perceives and uses its data; this perception is derived from the manner in which the organization functions or conducts its business.

  • Business Process Modeling world: As you may have read in one of my previous posts on the convergence of BPM and Business Rules, this is where I started discovering that those relationship was becoming stronger. In short, business rules support business processes. So there are a lot of BPM references that mention business rules. One of the basic ones I will mention here is from “Business Process Management with a Business Rule Approach”[2]:

Business rules should use data to support decisions, and the process should direct that data to the services that consumes it or provide other data.

  • Content management and portal world: The business rules here are concerned with information flow (which pages or fields to display), basic data validation (field length, type, value) that needs to be done earlier rather than later (i.e. Database).

Now the fact that there were many places referring to business rules in a different manner was somewhat complicating things a bit, but it also made sense when I was considering the scope of the definition. 

These findings would prove to be my stepping stone for starting my own categorization.

[1] Hernandez, Michael J. (1996), Database design for Mere Mortals, Addison Wesley Professional
[2] Debevoise, Tom (2007), Business Process Management with a Business Rules Approach, BookSurge Publishing

On levels of process modeling in BPMN

Bruce Silver just wrote an interesting piece on three levels of process modeling that is worth a read if you are interested in BPM.

The three levels he discusses are:

  • Level 1: Documentation of business process models using a standard notation
  • Level 2: Adding exception flows
  • Level 2b: (Previously level 3): Implementation of individual tasks, or even the process data and conditional logic needed in an automated process implementation
  • Level 3: In BPMN version 2.0, this will be to create fully executable process implementations based on a standardized design language

Since BPMN 1.1 was falling short of delivering the excutable component for a standard, it looks like the OMG will have that as a goal for BPMN 2.0.

Hopefully this evolution of BPMN will help resolve the problems when dealing with BPMN now and needing to execute it and not having a fully compatible executable standard with BPEL.

On Business Rules Categorization – Part I – Defining “business rule”

This entry is part 1 of 5 in the series Business Rules Categorization

This is the first of a five part series on the topic of business rules categorization.

My work and research on rules categorization is a side effect of my search for a definition for “business rule”.

To find a definition of “business rule” I looked in multiple places, looking for previous definitions of the terms and to try and find how other practitioners were defining it[1]. I was also looking for something that could be agreed to by a group of people and withstand some level of criticism by having good references.

Over the years many people created their variation of the definition, most of them being just fine, but I finally found what I was looking for when I looked through the Semantics of Business Vocabulary and Business Rules (SBVR), the Object Management Group (OMG) specification.

Business Rule: a rule that is under business jurisdiction.

It was that simple.

Well, actually, some clarifications need to be made. “under business jurisdiction” can be a bit tricky to understand. If a law is passed and the business has to comply with it, it is clearly not under their jurisdiction. But actually, the part that IS under the business jurisdiction is how business decides to comply with that law. So it is under their jurisdiction.

When I found that definition, I was happy and unhappy at the same time. I had found a definition that was backed by a recognized standards organization (OMG), so I was happy. I was unhappy because to me it seemed to be a very broad definition and it needed to be broken down in some way.

The rest of the posts in this series is about that research and what I have compiled so far to help me categorize those rules.

[1] if I ever turn this series into a white paper, you will find most of my references there, in the meantime if you really want references feel free to leave a comment or contact me.