This page contains Chapter 1 of the paper "Defining Business Rules ~ What Are They Really?", produced by the Business Rules Group. Other formats in which this paper is available are described in Defining Business Rules -- What Are They Really? (Abstract & Table of Contents)
The subsections in this chapter are:
The GUIDE Business Rules Project was organized in November 1993 to formalize an approach for identifying and articulating the rules that define the structure and control the operation of an enterprise. Systems analysts have long been able to describe an enterprise in terms of the structure of the data that enterprise uses and the organization of the functions it performs, but they have tended to neglect the constraints under which the enterprise operates. Frequently these are not articulated until it is time to convert the constraints into program code. While rules that are represented by the structure and functions of an enterprise have been documented to a degree, others have not been articulated as well, if at all. The Business Rules Project proposes to do this and, in doing so, to fill in the gaps for the kinds of business rules that have not been adequately documented in the past.
It is hoped that, as the task of defining business rules is better understood, techniques and tools will be developed to support the missing elements of the task. Techniques would include formal methods for describing rules rigorously, with tools translating these formalisms directly into program code or other implementation constructs. While graphic techniques have existed for some time to describe data structure and functions, formal methods for describing rules are relatively new and still being refined.
The GUIDE Business Rules Project has been organized with four specific purposes:
The first two objectives have been met, and the results are presented in this document. The Project articulates what constitutes a business rule and what about the rule should be captured and described. The discussions that led to this point have provided the groundwork for the latter two objectives, but much work remains to be done in these areas.
The first part of this document (Chapters 1-3) describes business rules in general -- why we are concerned with them (this chapter), how they are created (Chapter 2), and what it means to formalize them (Chapter 3). The second part (Chapters 4, 5, and 6) describes in detail the conceptual model that the Business Rules Project developed to describe specifically what constitutes a business rule and what kinds of business rules exist. Portions of the model are shown with each explanation, and the entire model may be seen in Appendix A.
The model is drawn according to the conventions of IDEF1X, with a modification to the convention to make the relationship names easier to include in this text. The rule for reading the model are contained in Appendix B of this document. The concept definitions are summarized in a Glossary (Appendix E).
Throughout the paper, examples are drawn from a case study about a car rental company that was developed by Model Systems, Ltd. of the United Kingdom. The full case study is described in Appendix D.
The techniques of systems analysis have evolved over the years to provide methods for describing many aspects of a business or government agency. We can now draw pictures of the way information flows through an organization, the sequence of actions an organization will follow, the structure of its operating information, and so forth. In some sense all of these constitute 'rules of business,' but they have not covered a very important aspect -- the set of rules that determine how a business operates -- that is, rules that prevent, cause, or suggest things to happen.
For example, a conceptual model can represent the inherent operating structure of an organization. It can represent what is fundamentally possible in an organization. Depending on how it is constructed, it may also represent some of the constraints on an enterprise. As the model becomes more abstract, however, it describes fewer of these.
In Figure 1, for example, a division may be composed of one or more sections, and a section may be composed of one or more departments. This is a very particular way of modeling an organization and expresses some very specific business rules. For example, a department may not directly be part of a division, and a section may not be part of a department.
This model has the disadvantage, however, that if these business rules change, the structure of the model must also change, as would the structure of any database that is based on the model. If the business were to define a new organization type (such as 'group') between section and department, a new entity (and its corresponding table) would have to be added to the model and the relationships would have to be rewired.
An alternative model, shown in Figure 2, removes the explicit and arbitrary (that is, manmade) declarations of organization types, yielding a structure that can easily accommodate changes to the organization without itself having to be changed. In this version, an organization (any organization) may be part of any other organization. Furthermore, each organization may be identified as being of an organization type. Each organization type may also be part of another organization type. Now, if a new organization type is added, it is simply another occurrence of organization type without any change to the structure. Thus, the possibilities for the enterprise have been opened up so that any system built based on the model will not itself impose constraints.
However, the business still does need to impose constraints, and those that were implicit in Figure 1 are no longer present in Figure 2. While such constraints should not be implemented via an inflexible database structure, they must still be accounted for in some fashion.
A preferred method would be for us as analysts to describe such rules explicitly and individually. For example, we would like to document the rule that 'cycles are not permitted' <1> and the rule that 'the hierarchy of an organization must be consistent with the hierarchy of its types.' <2>
Moving the expression of the rules out of the model is not necessarily bad news. Previously, when these kinds of rules were implicit in our models, we tended not to be aware of them, making it harder to challenge them and ask if they were in fact appropriate. Now this becomes an explicit part of the analysis process.
In summary, constraints can be dynamic and changing, so it is not appropriate to build them routinely into implementation database structures. Even so, such rules are still important and must be accommodated. The Business Rules Project has set out to provide the means for making all business rules -- not just the structural ones -- explicit.
John Zachman has provided a useful context for discussing the architecture of an information system. His "Zachman Framework" <3> is a matrix that describes the various ways the stakeholders of an enterprise view the business and its systems. It characterizes 'architecture' in terms of the perspectives of the different stakeholders (represented by rows in the matrix) and focuses on the different aspects of architecture (represented by the columns). The rows represent, successively, the planner, owner, designer, builder, and subcontractor perspectives. The columns reflect the aspects of data, process, location, role, timing, and motivation.
The Business Rules Project has chosen initially to address the first and sixth aspects (i.e., the 'data' and 'motivation' columns) from the designer's perspective (i.e., 'row three'). In other words, the domain of the current effort is specifically the structure of a business' data, along with the constraints and other motivation-related aspects of the enterprise information system. While documenting 'data' is reasonably well understood, the Business Rules Project is adding the aspect of 'motivation.' There will be some reference to the aspect of 'process' in business rules, but this will be minimal.
The Project's position in 'row three' means that it is concerned with those business rules that affect the storage of persistent data values, described in a technology-neutral way. At this time, the Project is not concerned with the rules of a business that do not have an information system component. That perspective will be addressed in future work.
A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules that concern the project are atomic -- that is, they cannot be broken down further.
For our purposes, this may be viewed from two perspectives. From the business ('Zachman row-2') perspective, it pertains to any of the constraints that apply to the behavior of people in the enterprise, from restrictions on smoking to procedures for filling out a purchase order. From the information system ('Zachman row-3') perspective, it pertains to the facts that are recorded as data and constraints on changes to the values of those facts. That is, the concern is what data may, or may not, be recorded in the information system.
The GUIDE Business Rules Project decided to address the information system perspective first, and this paper reflects that orientation. Accordingly, a business rule expresses specific constraints on the creation, updating, and removal of persistent data in an information system. For example, the record of a purchase order may not be entered if the customer's credit rating is not adequate.
While this may appear closely related to the business ('row two') rule that says that "we will not sell anything to a customer with a bad credit rating," the perspectives are subtly different. Adopting this constrained scope provided three practical benefits to the project:
First, the focus on the information system perspective has made the problem tractable. It has been possible to understand and model business rules as constraints on data. It will be much more difficult to make equally clear assertions about business rules as they are practiced in the business.
Secondly, the project has intentionally not dealt with entire categories of issues pertaining to the behavior of people in an organization. These include:
It is the project team's intention that a follow-on project will address these issues, as well as delving deeper into the issues of inferences and action-influencing assertions.
Finally, by dealing solely with issues of information structure, the project has not had to deal explicitly with events. From the perspective of an information system, an event only manifests itself by virtue of the fact that persistent data have come into existence or been modified. The business rules described here control whether or not such data may be created or changed, and the implications when this occurs.
A statement of a business rule falls into one of four categories:
The most basic element of a business rule is the language used to express it. The very definition of a term is itself a business rule that describes how people think and talk about things. Thus, defining a term is establishing a category of business rule. Terms have traditionally been documented in glossaries or as entities in a conceptual model.
Terms are discussed together with facts in Chapter Four as "Structural Assertions."
The nature or operating structure of an organization can be described in terms of the facts that relate terms to each other. To say that a customer can place an order is a business rule. Facts can be documented as natural language sentences or as relationships, attributes, and generalization structures in a graphical model.
Facts are discussed together with terms in Chapter Four as "Structural Assertions."
Every enterprise constrains behavior in some way, and this is closely related to constraints on what data may or may not be updated. To prevent a record from being made is, in many cases, to prevent an action from taking place.
Constraints are discussed in Chapter Five as "Action Assertions."
Business rules (including laws of nature) define how knowledge in one form may be transformed into other knowledge, possibly in a different form.
Derivations are discussed in Chapter Six as "Derivations."
Go to... Top of page | Next chapter | Table of Contents | BRG Home Page
Copyright ©2001, the Business Rules Group. All rights reserved.