Everywhere you turn, rules dictate how you work, how you act, how you dress, how
you conduct yourself. And as onerous as these personal rules are, rules that control a business can be many times more complex and burdening. Business rules can (and
often do) contain contradictions that can make interpreting them difficult.
Wouldn't it be wonderful to create a graphic representation of your business rules so
that you could clearly map out what to do in any given circumstance? In IT, we have
business process models that lay out business processes in a visual format and data process
models that visually depict the processes that operate on the data as it passes through a
system. We have entity relationship models and object models that help you visualize
how data is stored inside a database. We have systems models and network models and
even Web site and Web page models that visually represent these IT components. So
why don't we have business rules models?
One explanation might be that rules models extend beyond the scope of traditional
IT. All the other models I mentioned relate to business components that fall under the
auspices of the IT department. People in IT use the collection of visual tools I listed
above to help them understand their universe. Describing a system with a picture is
much faster and, in many cases, more accurate than writing it out in thousands of words.
If you can't imagine why you'd want to do this, remember that the traditional scope
of IT has been significantly blurred. You need to think about the needs of your whole
organization.
The concept of a rule model isn't new; business rules engines such as the Eclipse
plugin and Fair Isaac's Blaze Advisor have been using rule models to organize the
thousands of business rules that typical customers struggle with every day. However,
these software packages are expensive and complex to deploy. What about those of us
who work with budget and time constraints? What can we do to better organize and
formalize the rules and regulations by which we run our businesses?
To address this situation, information system development expert Ronald Ross has
been developing a style of modeling called the Fact Model, which is part of his business-rules approach. Because of space limitations, I can't describe Ross's entire methodology
(which you can read about in his book Business Rule Concepts: Getting to the Point of
Knowledge, Second Edition). However, I can say that one of the fundamental principles
of Ross's business rules approach is a structured business vocabulary and a mapping of
this vocabulary into a Fact Model.
What's the difference between a rule and a fact? A fact is an unconstrained rule composed of two terms connected by some action verb. A Fact Type, in Ross's methodology, is a non-judgmental, non-constrained
sentence (no adjectives, no adverbs). The
following two sentences are Fact Types:
customer places order
shipment includes item
A term is a basic word or phrase (in
English or any human language) that's
used in the business; a term has some
specific, defined, unique business meaning.
A collection of terms about your business
constitutes a structured business vocabulary. You should already be storing business
terms in a catalog, to which everyone
in the company has access. If you don't
have a business catalog, consider going to
http://www.wikispaces.com and establishing a wiki for your company.
What Constitutes a Rule?
A rule is a fact that has been constrained.
By extending the fact customer places order
to a customer places at least one order, you've
changed a fact to a rule. A business runs
on rules. So why would we want to create
a Fact Model?
Facts are the basis of rules. Recording
facts in a visual format, as the Ross
methodology explains, is so simple that
you can easily teach business users the
technique and let them record what they
do and how they do it. Encourage them
not to qualify the Fact Types (the nonjudgmental sentences that make up the
core of the Fact Model) so that you can
get to the core facts. When you review the
Fact Models with them, you can fill in the
constraints, whatever they might be.
Figure 1, shows a basic Fact
Model from which you can derive facts
such as a student enrolls in a class, a class
is offered by a university, a university
offers a class. This simple model tells you much about this business. For one thing,
students have to buy their books; books
aren't provided for students as part of the
class-registration process. This is an inferred
business rule that's expressed as a Fact Type.
Isn't This Just a Concept Model?
You might argue that this Fact Model is
just another form of conceptual data model,
but in fact, there are significant differences
between a Fact Model and a conceptual
model. The original intent of a conceptual
model is that it's a graphical representation of a set of business rules (not facts).
However, the various methodologies that
you use to render a conceptual model have
evolved to produce highly complex drawings that aren't intuitive to a non-database
person (i.e., a business user). The conceptual
model is step one in the database-design
process, so it tends to limit itself to data that
will be stored in the database being modeled. Arguably, you could use a package of
conceptual models or a master conceptual
model comprised of child models to better
express the business rules of the company,
but conceptual models tend to be limited
to expressions of data storage.
Prev. page
[1]
2
next page 
