What Are Business Rules?
Dr. Paul Dorsey
This is a harder question to answer than you might think. The main problem is that since “business rules” is a relatively new term, there isn’t a consistently accepted definition throughout the industry. There are many different groups all using the term “business rules” - all having different meanings in mind.
The origins of the term and the reasons for its popularity in the industry began with the “logical business rules” community founded by Ron Ross and Terry Moriarty using the name “The Business Rules Group.” Their perspective on business rules is quite similar to what a traditional systems person might call a “system requirement.” Of course, the term business rule is not focused on what the system needs to do but rather what it needs to support. However, this is what good analysts have always thought that a system requirement meant.
For decades, the best systems analysts approached a project by first trying to understand what the system they were designing needed to accomplish. Only after this solid foundation of the “business rules” of the organization was collected and codified, did the analyst, working with users, come up with the actual system level requirements. From the perspective of this first group, “a business rules approach” is simply a renaming of the process that good analysts have been using for years.
Early Thinking About Rules: The Business Rules Group
This is not to say that The Business Rules Group didn’t bring anything new to the table with all of the work that they did. Quite the contrary, more than just popularizing the term “business rules” and spurring thought about these rules for which we owe them a debt of gratitude, we also owe them for trying to create the first formal taxonomies of business rules. The first substantive contribution in this area was Ron Ross’ Business Rule Grammar which was published in The Business Rule Book: Classifying, Defining and Modeling Rules, Second Edition, 1997. Ross’ grammar, which attempted to formalize the English-language representation of a business rule such as “Every purchase order over $50,000 must go through three levels of approval.” This represents one of the rules by which an organization operates which needs to be precisely represented in a machine readable fashion.
Why didn’t this grammar catch on? First, even the basics of the grammar are very complex. Many people could not figure out how to use this grammar effectively. Even those very familiar and supportive of the grammar were sometimes unable to represent many business rules using the Ron Ross system. Even if the grammar had evolved and had eventually been in widespread use, the entire idea of a grammar for the representation of system rules eventually fails whether it is language or diagram-based. There are just too many rules in most systems.
As the BRIM™ environment evolves towards supporting virtually 100% of a system’s business rules within an integrated repository, it has been observed that the real number of rules in an ERP-type system is in the hundreds of thousands. Large systems may have a half million or more. To use a business rules approach and store these rules in some type of repository means that the repository must be manageable. It is not possible to reduce the number of rules in a system. All that can be done is to improve the efficiency of gathering the rules and make some intelligent assumptions about what the rules are so that we don’t have to independently ask a half million questions before building a system.
The other contribution of The Business Rules Group is represented by the papers that the group has recently published, which have attempted to create a structural taxonomy of business rules where rules are typed and, at some level, parsed. Again, in a full development environment, the existing taxonomy is not directly usable but does represent some excellent thinking and it allowed us to focus on the issue of structuring and parsing business rules.
In summary, the contributions of the Business Rules Group were that they popularized the term and concept of business rules, proved that it was possible to build a precise rule grammar and provided the intellectual foundation for structuring and parsing the business rules of an organization.
Business Rules in the Oracle Database Community
How did the information from The Business Rules Group find its way into the Oracle database community? Early on, David Hay and Bonnie O’Neil were members of The Business Rules Group and through papers and conference presentations made those of us in the Oracle community aware of the exciting work going on in the business rule community.
The database community has been working towards what has currently evolved into the “business rules approach.” Oracle database professionals use the term “business rules” assuming that the database already exists and the business rules (subset of first group’s definition) that should be enforced are the data rules that cannot be easily represented within an Oracle database or, in Designer shops, those that could not be handled within the Designer repository.
Database professionals created many trigger-based rules environments supporting several rule pattern types such as “Start Date is less than End Date” and similar rules. This group wanted to take some of the business rules, particularly those that are temporally volatile, and decrease the cost of gathering and implementing them. If the only way in which a rule is enforced is somewhere in some application code, if the rule ever changes, finding and changing that code is very expensive. Most database professionals do not think in these terms but some quantity of the rules have always been placed in data in tables to allow users to maintain the rules without the intervention of an IT professional.
Even the “lowly” reference table represents a business rules approach. The values in a reference table articulate the rule “What are the allowable values for attributes in other tables?” Usually there is an application that allows super-users to manipulate the values in these reference tables. Even when the values are not maintainable by users, they can be quickly and easily changed by those with the requisite privileges to do so.
Generic modeling which became popular five years ago is also another business rules approach. In a generic model, some portion of the structural business rules are stored as data and can therefore be easily changed.
The perspective of the database community and many of the business rule tool vendors is that they must satisfy the business rules that lie outside of the purview of the traditional tools used to create and manage databases.
Limitations of the Current Vision
This vision of business rules described above is limited and logically flawed. The fact that there exist employees working within departments in an organization is a business rule. These types of rules just happen to be enforced through the database. It is not logical to artificially declare that anything that cannot be placed into the database is a “business rule.” This limited vision of what business rules are has several permutations:
1. “Structural” (not process-related) rules used by Designer shops/Oracle home-grown business solutions mainly working to support rules such as “Start date must be less than End date.”
2. “Process rules” as characterized by many “business rule” products by companies like Blaze (now Fair, Isaac), Savvion and ILOG that provide a so-called process flow environment where it is assumed that the database exists and allow users to specify the processes governing the objects in the database. A type of process-flow charting, state transition engine or UML-based drawing tool is typically used for these types of rules.
The problem with both of these types of tools is that the end result is quite fragmented. Some business rules are enforced through the structure of the database; others enforced through data in generic portions in the database and still others through the add-on rule repository. Since no system enforces all rules, the ones left over must be enforced through code. Even though the efficiency of system development may have been improved by using the mechanisms described above, this is still an inherently flawed approach.
Dulcian’s Approach
The term “business rules” has a slightly different interpretation at Dulcian. There are two reasons for gathering business rules:
· As a communication vehicle for users to understand what their system will support
· To generate the system
In order to satisfy the communication reason, users must be fed back rules in a format that is close to the way in which they think and talk. This means that text and diagrams must be created using the language of the users to gather and represent the requirements. Unfortunately, the way in which users think and talk about their system requirements is limited by the imprecision of language and the inherent incompleteness of the requirements gathering process. These problems are insoluble. Ultimately, we must represent back to users what they have communicated to us and accept the limitation that what has been gathered is not complete or precise enough to allow us to build a system.
At Dulcian, this type of requirement is termed an “analysis requirement.” Some examples include:
· Problem customers should be contacted on a weekly basis
· Preferred customers receive 3% discounts except on low-margin items.
These types of requirements are obviously imprecise and cannot be directly implemented. What exactly is a “preferred customer?” What is meant by a “low-margin item?” Even if we could make language more precise and complete, we would still fail because of the sheer number of rules that need to be gathered. A text repository would be so large that it would quickly become unmanageable.
“Implementation rules” meaning a formalized mapping of the analysis rules to a specification allowing for direct implementation in a system is how Dulcian has solved the problem described above. Implementation rules must be readable by a user as well as understandable enough to be audited by users as a faithful formal representation of their analysis rules. These implementation rules must also be machine-readable in order to generate the system.
Summary
The term “business rule” means different things depending upon who is using it.
To someone from The Business Rules Group, it may mean a business level requirement of the system that may or may not be represented in a more formalized mechanism in a grammar or taxonomy. To a database professional, it may mean a business requirement not easily enforced in the database (structural requirement) or process flow.
Analysis and implementation rules as described above together form what are called “business rules” at Dulcian. For more information, see other whitepapers on the Dulcian website under Products/BRIM™ or Conferences, Papers and Presentations/Papers organized by Topic/Business Rules.