Published in TDAN.com April 2002
My interest in the business rule approach stems from three separate threads weaving together to form a cohesive direction:
- Write Once, Use Often
- Let the Documentation Generate the Code
- Let the Business Write the Documentation
Write Once, Use Often
My belief is that there is a fundamental information structure that underlies any enterprise that engages in commerce: the exchange of goods and services. This realization emerged slowly over the
15 years that I devoted my career to the financial services industry. During that time, I developed data and process models, and eventually, object class models for 3 different banks. To my
amazement, these models were identical. The information that was needed to run a bank, the business processes that had to be performed and the events that had to be recognized were universal, at
least within the retail banking industry.
I could accept that. After all, a bank is a bank is a bank. But when, as a consultant, I used my model to illustrate some of the issues that must be addressed in managing customer relationships, my
client, the CRM manager for the telecommunications company, became very excited about my depth of understanding of the telecommunications industry. I calmly explained that I knew nothing about his
industry and what I was showing him was a bank’s model. To which he replied, ” No, you don’t understand. This is a telecom model!”. That was when I realized that there exists a set of
common business concepts that transcend industry and corporate boundaries. If we can discover these fundamental business concepts, they can be reused in data, process and object models to form a
foundation that can be tailored to meet the specific needs of any enterprise.
I already was aware that there were patterns of logic that re-occurred in programs. Programmers routinely re-invent the wheel as they code programs that present menus or search databases based on
specific selection criteria and allowed you to scroll through the results. Code generation is possible because these patterns exist. Why not take the pattern concept beyond code to business models?
Wouldn’t this lead to the ultimate level of reusability?
Let the Documentation Generate the Code
I’ve had the privilege to work with some very enlightened application architects who share Data Management’s vision of applications based on shared data. One architect went as far as
developing a repository-based code development environment in which every program had to be defined to the repository, including links to all the data structures used by the program. The COBOL Data
Division was generated from this repository-based information. He even wrote a pre-compiler that detected if the generated code had been altered. A report was sent to him that identified all the
programs where the “don’t touch the generated code” policy had been violated.
When I asked why he had put such stringent constraints on his programmers, he said “If you want the code to match the documentation, then the code has to be generated from the
documentation”. The approach nearly guaranteed that data definitions were specified once and used often. When a data element’s specification had to be changed, the repository-based
impact analysis was 90% faster than traditional approaches. We never had a situation where a production installed failed because a data structure that was properly defined in the repository slipped
through unchanged.
Let the documentation generate the code certainly seemed like a cost effective business policy.
Let the Business Write the Documentation
In 1991, Barbara von Halle and Alica Sandifer (1) quietly planted the seeds of evolution with their first articles on the Business Rules Approach. For me, the timing of these articles
couldn’t have been better. At the time, I was working for a company that did not let data management people have access to the business user. We weren’t even allowed participate in
requirements sessions. This company’s information technology (IT) management believed that the business stakeholder should be able to write their own requirements specifications. So, a team
of “business analysts” was responsible for producing the requirements specifications for IT. We were to use these documents as the basis of our application and database design.
Unfortunately, what they produced were large documents of rambling text and spreadsheets that provided very little of what I needed to develop a good data model and database design.
Business Rules, as espoused by von Halle and Sandifer, seemed like something that could be used to teach our business analysts how to analyze the business with an information management perspective
in mind. Since the approach was based on the analysis of policy statements expressed in business terminology, I felt that our analysts would feel comfortable with the technique. If there was some
way that this business knowledge could be captured in a repository that could be used to generate the specification, and eventually the application code and database design, my dream of generating
the code from the requirements documentation could become a reality.
Let the business write the code. What a novel idea. But, what needs to exist to make this approach a reality?
Business Rule Grammar
The business rule approach is based on analyzing policy statements expressed in natural language and extracting the information that is needed to design information management applications and data
stores. So, it seems natural to draw on existing approaches for analyzing and understanding the English language, such as grammar.
The basic components of the English language are nouns and verbs. A noun is “anything that can be named (objects, feelings, people, places, ideas, qualities, states)” (2), while a verb
is “a word or phrase expressing the action, state of being or quality of belonging to a noun”. A verb phrase is used to link two nouns together to produce meaningful statements that
convey information. For example, in the statement “Customer purchases Products.”, Customer, a noun, is the subject of the sentence that is performing the action (purchases). Product, a
noun, is the object of the sentence because it has the action being performed against it (e.g. Product is being purchased).
Two types of verbs exist: Action and Linking. An action verb identifies an activity that the subject is performing, often to the object of the sentence. “Purchases” is an action verb. A
linking verb associates the subject with an object that complements or clarifies the subject is some manner, as in the statement: “A Booking Clerk is an Employee”. Adverbs and
Adjectives are words or phrases that are used to modify the nouns and clarify statements.
When analyzing a business, we listen to the statements expressed by our subject matter experts (SME) . We break these statements down to identify the business concepts and business rules that are
the components of business policies. As a child in school, sentence diagramming was used as a technique for teaching how to construct proper English statement and in verifying the exact meaning of
existing sentences. The idea was that if you couldn’t diagram it, the statement probably wasn’t going to communicate to everyone properly.
Sentence diagramming provides a set of statement types that can be formed. Each statement type dictated the pattern to be used in diagramming it. The two statements discussed earlier (Customer buys
products and A Booking Clerk is an Employee) are examples of two statement patterns: action and linking. Consequently, they have two different diagramming patterns.
Sentence diagrams are very similar to the diagrams we produce when developing a data or object class model. However, they address adjectives and adverbs much more explicitly than these other types
of models. Therefore, I decided to use sentence diagrams as the basis of my business rule grammar.
The two basic components of my business rule grammar are Business Concepts and Business Rules. A Business Concept is anything that the business must know about. A Business Rule is the
Business’ response to constraints that are imposed upon the Business. The purpose of a Business Rule is to overcome constraints, minimize risk and exploit opportunities in a manner that
improves the Business’ ability to achieve its goals.
Business Concepts
Have you ever had the situation where you were trying to think of a word and it just didn’t come to mind. You could visualize it in your mind, you could “see” all its
characteristics, such as its size, shape, color and usage, but still couldn’t conjure up its term. You are dealing with the separation of concept from terminology. The concept is what you saw
with your mind’s eye. The term is the words used to communicate that concept in written and verbal communication. No, you are not having a “senior moment”. There is scientific
evidence that the brain holds a concept and its associated terms in separate areas of the brain. (3) This phenomena account for much of the divergence in terms used across the enterprise.
A business concept is not the same as a term, which is a word or phrase that is used to refer to the business concept. The business concept is the definition of something of interest to the
organization. Within an enterprise, many different terms can be used to reference the same business concept. Some times, different communities within the enterprise have chosen the same term to
refer to different business concepts. One of the first challenges that an enterprise faces in integrating its lines of businesses, markets and products is unifying its disparate vocabularies. My
approach is to identifying the business concept behind a term, fully define that business concept and then link the term back to that concept.
Business concepts are the nouns of the business rule grammar. They are the things of interest to the enterprise. The first step in analyzing an organization is to build its business concepts
catalogue, a repository of definitions and the terms chosen by the various organizations within the enterprise to refer to those definitions. When developing the business concept catalogue, you
really have to resist the urge to classifying them according to the information management construct that is eventually going to support the concept. These business concepts are not entities,
attributes, relationships, object classes, responsibilities, or methods. They are simply things of importance to the business. Attempting to turn them into information management components can
stifle the creative process of extracting the knowledge from the SMEs who are not interested in the terminology of our Information Resource Management community.
The purpose of the business concepts catalogue is to start unifying the vocabularies used by the various communities that exist within the enterprise. In fact, the first business rule category that
will be discussed later in this series is “term usage” that links a term to the business concept it references (Figure 1). Since different communities can define their own business
rules, it’s necessary to identify for each business rule which communities subscribe to it. A community can assume different roles with respect to a business rule: the specifier, the enforcer
and the constrainee. Consider a regulated industry, in which the state or federal government specifies the business rule, a government agency enforces it and the organization, such as a bank, that
must abide by the regulation is the constrainee.
Business Category Classification Scheme:
Thingees and Characteristics
While the SMEs don’t need to categorize their business concepts as they discover and document them, I use a categorization scheme to help me ensure that each business concept is fully
understood. I start by determining whether the business concept is about a Thingee or a Characteristic of a Thingee (Figure 2). Thingee is a word I use to refer to things, whether they are physical
items or intellectual ideas. I’d prefer to use a term like Business Entity or Business Object, but these terms are so overloaded with meaning within the IT community, I felt it was best to
use some other neutral term that no one else wanted. People, product, household, address, market segment, customer, branch, car, insurance policy, account, sale, reservation and order are just a
few examples of thingees of interest to most business concerns.
A Characteristic is a property that can be used to describe a thingee. A characteristic takes on some sort of a value. It is a holder of information. Name, social security number, eye color,
height, weight, gender, age, birthdate and occupation are all examples of characteristics about a person. Just as associating a term with a business concept is a business rule category, linking a
characteristic to the thingee it describes is another business rule category. Most of these characteristics obtain their value through observation. Someone has to observe the person and then state
that the person’s name is “Mary Appleby”, her height is “5’ 6”, her weight is “135 pounds” and her birthdate is “5/6/67”. However,
Mary’s age can be derived by subtracting her birthdate from today’s date. So, we see that there are two different types of characteristics: observed and derived.
Distinguishable Thingee
A thingee can be further classified as a Distinguishable Thingee or a Business State. A distinguishable thingee is one that stands on its own. There is some mechanism, at any given point in time,
of distinguishing one instance of the thingee from another. Sometimes things are only distinguishable by observation. I can look at two people and observe that they are different from one another.
Their characteristics are different from one another. Sometimes, I can distinguish between two things only at a specific point in time. For example, I can tell that I have two pencils, even though
their properties are identical. They may have the same color, be the same length, sharpened to the same degree, but while each hand holds a different pencil, I can distinguish between them. But,
what if I set them down and leave the room? When I come back, will I still be able to distinguish between them. Yes, I can still observe that there are two pencils. I don’t really need to
know that the one I’m holding in my left hand is the same one that I held in my left hand before. All that’s important is that I can tell there are two pencils to be a distinguishable
thingee.
Distinguishable thingees can be categorized based on their characteristics and behavior. The Zachman Enterprise Systems Architecture Framework (ESA) (4) can be used in organizing the first level of
categorization: Things (What), Business Processes (How), Locators (Where), Business Party (Who), Events (When), and Motivators (Why).
The distinguishable thingee categories take us into the realm of “Write Once, Use Often”, as these categories are applicable to any enterprise engaged in commerce. They represent
fundamental business concepts that are universal across all business industries. While everyone may not agree with the term I’ve chosen for these business concepts, there are few who would
disagree that any enterprise will encounter these concepts in the process of conducting business.
Each fundamental distinguishable thingee can be further classified. For example, Business Party is classified as Person and Community; Community is classified as Household and Organization;
Organization is classified as Legal Entity and Internal Unit and so on. While these business concepts are still universal across most industries, there comes a point in the analysis where your
enterprise’s specific terms need to be mapped into these business concepts. Through this mechanism, any business concepts that are unique to your enterprise will be discovered.
Consider the business concepts that are associated with the car rental industry, as described in the EU Rent case study included in the Business Rule Group’s first paper. (5) This case study
provides a set of business rules that have been established by a mythical car rental company, EU Rent. Figure 3 illustrates how the business concepts that are unique to the car rental industry
(represented in green) are categorized within the fundamental distinguishable thingee classification scheme (represented in blue). When a business concept is categorized as a specific type of
“universal” business concept, it inherits all the characteristics and behavior associated with its parent business concept. For example, I know that most events initiate a business
process, can have several business parties involved, may involve many things (in this case, the car that is being rented and the rental agreement) and may occur at a specific geographic location,
identified by its locator. When a business concept is classified as an event, an entire series of questions must be answered to ensure that the nature of the event is fully understood.
For example, the event “Reserve a Car” initiates the “Reservation” business process. If the reservation is made by phone, then the event involves the Business Party making
the reservation and the “Customer Care Advocate” who handles the call. The things involved are a “Car” being reserved and the “Rental Agreement” that lays out
the initial terms and conditions for the rental such as the rental duration, car group, payment plan and the pick-up and drop-off branches. The car will be picked-up at an EU Rent
“Branch” located at (with a locator of) Los Angeles Airport.
Business States
Business State, another category of thingees, is a set of distinguishable thingees of the same category. Every business state has criteria that are used to determine whether a thingee qualifies as
a member of the set. As with Characteristics, there is a specific business rule category that addresses the linkage between a business state and the thingee it qualifies.
Business states are evaluated at a specific point in time. Consequently it is possible that a thingee instance may belong to a business state set at one point in time, only to fall out of that
state later because it no longer satisfies the qualification criteria. For example, the car rental agency has the business concept of a “damaged car”, which is a car that has sustained
mechanical or body damage due to some sort of accident. Once the car is repaired, it no longer qualifies to be called a damaged car.
Sometime, business states are mistakenly categorized as a characteristic rather than a thingee. I believe this occurs because we are allowing our information management classification schemes slip
into our business concept analysis process. For example, some might consider “lightly damaged” and “severely damaged” to be two of the allowed values associated with the
“Car Damage Status” business concept. However, both “lightly damaged” and “severely damaged” have their own definitions and qualification criteria. Consequently,
both satisfy the criteria to be considered business states on their own. Whenever I discover a code, indicator or enumerated attribute, I suspect that there are one or more business states lurking
behind these information management constructs.
So far, I’ve discovered three business state categories:, life cycle stage, role and classification. A life cycle stage identifies a specific point in a thingee’s evolution. Anything
that is managed evolves through a series of events in its life cycle, which can include planning, acquisition, use, evaluation, modification, retirement and disposal. The actual words used for
these stages can vary based on the industry and the thingee being managed. For example, during the planning stage, the car rental company must decide which types of cars it wants to rent. The car
is then acquired through a purchase event. Each rental constitutes a use of the car. At check-in, the car is evaluated to determine whether it is still in rentable condition (e.g. not damaged). If
the car is not rentable, its condition must be modified to put the car back into rentable condition, either by repairing the damage or performing routine maintenance. Finally, when the car is too
old, has been driven an excessive number of miles or is too damaged to repair, it is disposed of by selling the car or having it demolished.
Life cycle stage business concepts are important to identify because there are probably some business rules that control how thingees can transition from one state to another.
Many business rules exist to define the interaction that can occur between thingees. Some business concepts define the roles that thingees can assume in these interactions. For example, in an
employment relationship, one business party assumes the employee role while another business party is the employer. An employee is a person who has agreed to provide services to the employer in
exchange for a compensation package in accordance with employment laws. “Employee” is the name of a business state of type role. The qualifying criterion is that the person has entered into an
employment relationship with some organization. Therefore, that person is in the state of being an employee.
“Customer” is one of the most interesting and complex business states that an organization will encounter. The first step in a CRM initiative is to determine who qualifies as a customer. The
relationship must be closely examined to understand which roles in the sales and servicing process are included in the enterprise’s definition of customer. Typically, the customer is defined as
the party who buys products or services. However, in the realm of CRM, the scope of customer has been expanded beyond the buyer – for instance, those who influence the purchase decision, such as
other members in the household. Or the person who buys something that someone else is going to use. All the people who assume these roles are candidates to be called a customer.
To further complicate the decision about who is a customer, different areas of the business may be interested in different customer roles. For example, marketing cares about the ultimate decision
maker, but also about anyone who influences purchase. Accounts receivable is interested in the person to whom it sends the bill and expects payment from. To customer care units, anyone on the other
end of the phone is a customer. Finally, the enterprise must identify which roles it means when it determines how many customers it has.
The Classification Business State simply defines a set of thingees that satisfy the same qualification criteria. Unlike roles and life cycle stages, the classification business state has no special
business rule categories that govern its behavior.
Business states can be part of the qualification criteria of another business state. For example, Preferred Customer is defined in terms of Customer, another business state. Lightly damaged car
further qualifies the condition of a damaged car. Ultimately, every business state qualification criteria must yield a set of distinguishable thingees.
To determine if the business concept you’re analyzing is a business state, examine the business policy statement closely. If it contains linking verbs or adjectives, you are probably dealing
with a business state. If the definition contains words like “that”, “which”, “who” or “whose”, you are probably dealing with a business state. You
will be able to classify business concepts and business rule easier, if you have a good grasp of the rules of English grammar.
Business concepts and business rules are the core components of my business rule grammar. The next article (to appear in the next issue of TDAN.com in July 2002) will focus on how business rules
provide the glue that tie an enterprise’s business concepts together.
(1) Sandifer, Alice and Von Halle, Barbara, “Designing by the Rules”, Database Programming and Design, Volume 4, No. 1, January, 1991
(1) Sandifer, Alice and Von Halle, Barbara, “A Rule by Any Other Name”, Database Programming and Design, Volume 4, No. 2, February, 1991
(1) Sandifer, Alice and Von Halle, Barbara, “Linking Rules to Models”, Database Programming and Design, Volume 4, No. 3, March, 1991
(2) DeVincentis-Hayes, Nan, Straight Forward Grammar and Diagramming Sentences, Garlic Press, Eugene, Oregon, 1995 ISBN 0-931993-75-X
(3) Carter, Rita, “Secrets of the Brain’s Language Lab”, London Evening Standard, September 30, 1991
(4) Zachman, John, “A Framework for Information Systems Architecture”, IBM Systems Journal, Vol 26, no 3 (1987)
(5) Defining Business Rules – What are they really? Version 1-3 June, 2000, Business Rules Group (www.businessrulesforum.com)
