State
of the State
What's one of the first things we learn in data modeling? It's that an entity is a person, place, thing, event, or concept of interest to the enterprise. As we analyze the business's terms, we dutifully classify them as entities using this scheme.
But nouns encompass
more classifications than just those identified in the definition of an entity.
According to Nan DeVincentis-Hayes, in Grammar and Diagramming Sentences
(Garlic Press, 1997), a noun is "anything that can be named (objects,
feelings, people, places, ideas, qualities, states)." I
understand why data modelers ignore feelings and qualities as potential
entities. But why doesn't the definition of an entity include state? Our limited
definition puts us in danger of incorrectly classifying nouns that really
represent a state of interest instead as a person, place, thing, event, or
concept.
The concept of a
business state is so fundamental to how an organization thinks about itself that
business state needs to be addressed as its own type of business rule. Three
definitions of state are relevant to the business world's perspective:
In many cases,
conditions are so important that the organization gives them a name. Once named,
a business state can easily be confused with an entity. At this point, they may
quietly slip through during the analysis phase, represented as a traditional
entity, an attribute, or an allowed value of some other attribute.
How do we find the
business states an enterprise is interested in? First, we examine the
grammatical structure of the business rule statement. If we see any nouns
modified by adjectives, a business state is probably lurking there.
For example, to a car
rental agency, we encounter the concept of an available car. Before you
can assign a car to a rental agreement, the car must be available. To determine
whether a car is available, you must check that it satisfies the following
criteria:
"Available
car" is a business state of interest to the agency. The qualifying criteria
for one business state may include other business states, each with its own
qualifying criteria. Most of the states used are really life cycle states that
the car can assume at any point in time. A given car might also be in several
states at the same time.
Sometimes, we
encounter an unmodified noun that still represents the state of an object. To
identify these states, we must examine the definitions of terms for any embedded
qualifying criteria. For example, a man is a person whose gender is male, while
a woman is a person whose gender is female. Therefore, the nouns "man"
and "woman" represent a state that a person can assume.
An unmodified noun
might also represent a stage in a process. What's the difference between an
order and a sale? Isn't an order really an incomplete sale? The sale progresses
through a variety of stages: Item selection, ordering, fulfillment, delivery,
and payment. These steps compose a sale.
At a grocery store or
a fast food outlet, the sale progresses through all these stages almost
instantaneously. But the sales transaction still progresses through all its life
cycle stages.
How much time have we
spent analyzing the order management process and its various states, when it was
just part of a larger sales process? The order management process had to be put
in place to handle sales that couldn't be completed immediately. Consequently,
"order" became an entity on its own, rather than being recognized as a
state of the entity "sales event."
Another interesting business state in disguise is the "role." Every relationship, by definition, involves at least two entities. In an employment relationship one party assumes the employee role while another 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. 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. 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 a 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.
Business states are
critical to an enterprise, yet many of them are disguised as traditional entity
types in business rules. Look beyond the noun to determine whether it qualifies
as state - and treat it accordingly as a special type of business rule.
Terry Moriarty, president of Inastrol, a San Francisco-based information
management consultancy, specializes in customer relationship information and metadata
management. She authored Enterprise View (originally the Repository Report and later the
Data Architect) column for Database Programming & Design. You can reach her via
email at terry@inastrol.com.
Copyright © 2001 Terry Moriarty ALL RIGHTS RESERVED