- On Business Rules Categorization – Part I – Defining “business rule”
- On Business Rules Categorization – Part II – Use of business rules
- On Business Rules Categorization – Part III – Other rule classifications
- On Business Rules Categorization – Part IV – Rule Classification
- On Business Rules Categorization – Part V – Rule Classification part 2
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 | |
|
1 |
Rules for data transformation |
Rules that transform data from one format to another. |
ETL tools, Database, XSLT, Integration tools |
|
2 |
Rules for referential integrity |
Rules that represent and control the relationships between entities. These are database associations, multiplicity, constraints, triggers, etc. |
Database |
|
3 |
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 |
|
4 |
Rules for security |
Rules that control access to functionality or data based on roles |
Single Sign On, Authentication services |
|
5 |
Rules for presentation |
Rules that allow for dynamic content to be presented to users. |
Dynamic web pages, Content management |
|
6 |
Rules for workflow or business process |
Rules that are business process and workflow related. |
BPM or Workflow Engine |
|
7 |
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 |
|
8 |
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.
Conclusion
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.
I disagree with the separation of “rules for workflow or business process” since I think that they are just the application of the other rule types (e.g., rules for security, rules for rating engine, rules for decisions), not a class on their own. I would have added this as a comment on Eric’s blog, but typically don’t comment on sites that require me to create a login.
I have taken this as advice and taken off the requirement of being a registered user on the blog’s site.
And to come back to Sandy’s inital comment, the classification is meant to be a way of identifying where rules could end up during the implementation phase of a project, hence the “Execution component” column in the classification.
Since there are BPEL execution engines and similar products and that during implementation these tools might end up being used, I created the category.
Hopefully this helps to clarify the classification.