The Business Rule Approach: Changing the Face of Data Models, Part Three


Published in January 2004

Articles in this series – Part 1, Part 2

The third of a three-part series based on Principles of the Business Rule Approach, the author’s groundbreaking new book from Addison-Wesley (2003). In this third part, the author
examines the impact of business rules for logical data models.

Fact Model versus Logical Data Model
The Difference is in the Perspective

A fact model is a diagrammatic representation of a structured business vocabulary, which is essential for expressing large numbers of rules in a consistent fashion. A fact model is central,
business-oriented deliverable of the business rules approach.

How does a fact model differ from a logical data model? We view a fact model as part of the business model a project should develop, whereas a logical data model is part of the system model it
should develop. A fact model provides a business-based starting point—a blueprint—for subsequent development of a logical data model or database design. A good fact model can be easily
transformed into a first-cut logical data model.

There are naturally significant differences in perspective, purpose, and success criteria between fact models and logical data models. In contrast to a fact model, a logical data model generally
places emphasis on the following areas.

  • Delineating the data and its proper format to support system-level requirements: In a fact model, a box represents a term and the business concept for which it stands. In a logical data
    model, a box generally represents a collection of attributes or fields that are structured to retain the appropriate data for storage and manipulation by applications.
  • Looking ahead toward the database environment and introducing features appropriate for database design in the given technical environment: Examples include normalization (or possibly
    denormalization), cardinality, associative entity types to support many-to-many relationship types, mandatory fields and relationships, and so on.
  • Addressing the complexities of time: In general, fact models do not concern themselves with history. They simply identify what should be known about the basic business process at any
    given point in time. A logical data model, in contrast, must concern itself with the points-over-time aspect of data so the business (and its rules) can deal with the past (and the
    future). Modeling this points-over-time structure of data is one of the most important (and difficult) challenges in data modeling.

None of the items above are appropriate for the fact model. Again, the primary audiences for the fact model and the data model are different. The primary audience for the fact model consists of
business-side workers and managers (and business analysts), whereas the primary audience for the logical data model consists of system and database designers. It is very important to keep these
distinctions in mind, especially since logical data models often use graphic conventions (boxes and box-to-box connections) that might appear similar to those used for fact models.

Getting to the Instance Level

A fact model and a logical data model also often have very different perspectives on the best handling of what is commonly known as type codes. Remember that the emphasis in fact models is
on standardizing the business terminology and then capturing rules. The emphasis in a logical data model, in contrast, is often on achieving the most flexible data design possible—usually the
best design for accommodating change.

The typical approach for logical data models therefore features special data objects or tables to handle type codes. The instances of such a data object or table represent valid type code values.
This data object or table is related to any data object that is to be given one (or more) of those valid types. Creating a table for the codes in this fashion allows changes to the set of codes
without impact on the database design. The logical data model itself, however, does not concern itself too much (if at all) with what the actual type code values might be.

Handling type codes in that manner is generally not adequate for fact models. In large measure, this is because standardized names for the instances of the type code are often highly
relevant to product/service-type rules. Capturing and standardizing the underlying business terminology is critical.

This requires a special kind of model that focuses directly on predefining these instances. (We can stop using type code in the discussion at this point—it only causes confusion.) We
call such models instance models. In all other respects, an instance model is basically like a fact model.

Consider the following examples.

  • Health care: An instance model might be created to organize all recognized health services—for example, Consultation, Office Visit, Hospital Admission, Surgery, and so on.
  • Ship inspection: An instance model might be created to organize all recognized parts of a ship—for example, Bulkhead, Hatch Cover, Railing, Deck, and so on.

In these examples and others like them, the business is likely to have hundreds of specialized instance-level terms and thousands of product/service rules that depend on them. Naming and
categorizing these product/service terms—that is, building the appropriate instance models—is therefore crucial.

What Is a Fact Model?
Building a Structured Business Vocabulary

A fact model structures basic knowledge about business practices from a business perspective. Basic means that the knowledge it represents cannot be derived or computed from any
other knowledge. It that sense, a fact model is a crucial starting point for developing more advanced forms of business knowledge, including measures and rules.

In particular, a fact model focuses on assertions (called facts) involving core concepts of the business. In a fact model, concepts are represented by terms. Facts connect those terms in a
manner that should reflect the real world. Both terms and facts in the fact model should be basic in the sense defined above.

A fact model focuses on the knowledge part of a business problem—that is, on how knowledge underlying business operations (the “flow”) is organized. Literally, the fact model
indicates what you need to know in order to do what you do.

A good fact model therefore tells you how to structure your basic thinking (or knowledge) about the business process based on a standard vocabulary. This ensures that you can communicate
effectively about that knowledge with other project participants. It also allows you to exploit this standardized knowledge and vocabulary to express other types of requirements,
especially rules—and to communicate about those effectively too.

A focus on structuring how business people can think and communicate about the business process has an important additional benefit. Inevitably, it helps bring into clear relief alternative ideas
about how the business capacity itself can be best structured to satisfy business goals. When and by whom should such issues be resolved? As I have discussed, these are issues that should be
resolved by business-side workers and managers before the project moves into system design or coding.

How do you know when you have done a good job on the fact model? Your test is below. By the way, excruciating level of detail[1] in this test means thorough business analysis but not system design.

Real-World Test for a High-Quality Fact Model

Once you have completed the fact model to an excruciating level of detail, you should be able to communicate with knowledgeable business workers about the core operational knowledge for the
business process as if you had been in the business just as long as they have.

There should be only a single, consolidated fact model within the entire scope of a problem domain. The goal is to unify basic business knowledge within that scope and to express each element of
that basic business knowledge uniquely. This can be expressed as the following fundamental goal for fact models.

Fundamental Goal for Fact Models

One fact, one place, one name.

What is not important when you create a fact model is how you will organize the data or design the database to support it. Putting those things aside is often a challenge for IT
professionals trained in that difficult discipline.

Nonetheless, the key to success with the fact model is keeping the model focused squarely on the business perspective. All specifications (including the graphic model) should be aimed toward
structuring how business people can think and communicate about the business capacity in an organized fashion. Everything in the fact model is about the business vocabulary needed to
support such structure.

Defining Terms

Whenever possible, a native English[2] word or word phrase should be selected as the term of choice to
represent a concept unless there is simply no such word in the language. Our experience is that this circumstance arises less often than might be imagined.

Moreover, instead of composing new definitions, a standard definition from Webster’s (or another dictionary) should be selected and used for a term whenever possible. This not only
saves work but also avoids arguments—it’s hard to argue with standard definitions! If it is not possible to use a standard definition as is, the next choice is to extend or revise a
dictionary definition as needed (carefully!). Only in the last resort should a new definition be composed from scratch.

Some approaches recommend that fundamental terms used in exactly their real-world sense (for example, person, time, and so on) need not be defined explicitly. This guideline can be
followed with due caution, recognizing, however, that even native English words often have multiple meanings. For this reason, we prefer to make explicit the intended meaning of all terms,
even when such meaning is simply taken verbatim from the dictionary.

If you are thinking that all this intense focus on terminology might create the need for a special skill on the project, you are right on track! Refer to the discussion in the special boxed item.

The Terminator


In everyone’s life, there is always someone—a teacher, a mother, a friend, a business colleague, whoever—who insists (maybe gently, maybe not) that things should be
called by their right names. This is a person who always seems to have several words to choose from to put just the right spin on things. He or she forever has a dictionary at the ready and is
never loath to use it no matter what the nature or objective of the discourse. Someone who excels at word games. Easily coins nicknames for new ideas. Knows that coining new terms is called


Such people are the ones always called upon to do wordsmithing (usually not meant as a compliment). They are naturally good at turning a phrase. They think writing definitions is a really
fun thing to do. As for grammar, where the rest of us see purgatory, they find poetry. They might have even been liberal arts majors!


Be that as it may, wordsmithing is a must-have skill for your business rule project. I mean fluency in BusinessSpeak, as opposed to SystemSpeak or TechnoSpeak. You need
at least one team member who insists that things are always called by their right names and that proper definitions are always worked out and written down.


What you need is a terminator. That is what they have been called—with respect, I hope—on some of our business rule projects.[3]


Why is a terminator so fundamentally important? Remember the business rule mantra: Rules build on facts, and facts build on terms. Terms and their definitions are the foundation in the
business rule approach. Build on a weak foundation, and your whole business logic becomes a house of cards.


The job does need a bit more dignified title than terminator, of course. Let me share a little dictionary research I did on this matter.


Ever heard of a glossographer? In case you are wondering, no, a glossographer is not someone who is good at glossing things over. I did not make up the term, either. It is a real term as
well as an honorable profession (I presume).


As it happens, one of the definitions of gloss is “a brief explanation . . . of a difficult or obscure word or expression.”[4] A glossographer, then, is someone who writes down stuff like that. Unfortunately, another definition for gloss is “a false and often
willfully misleading interpretation.” That is not going to do.


What about lexicographer? This term means “the author or editor of a dictionary or lexicon.” A lexicon is “the vocabulary of a language, an individual speaker or
group of speakers, or a subject.” This sense is exactly right for what we need, but the word itself is somewhat obscure and a bit hard to say. Are there any other candidates?


The New Oxford Dictionary of English indicates terminologist to be a word in contemporary usage.[5] That label is a good one. So officially at least you should probably call your “terminator” a terminologist.

Relationships to Other Architectural Products in the Business Model

A fact model relates to other key deliverables in the business rule approach in the following ways.

  • Concepts Catalog: The collection of all terms and definitions for the knowledge part of the business process is called a Concepts Catalog. Every term used for the fact model
    (and for any rule as well) should have a business definition in the Concepts Catalog. By the way, coordinating the Concepts Catalog is a fundamental part of rule management.
  • Policy Charter: As described earlier, a Policy Charter is a battle plan identifying the key elements of the business solution (including core business rules). Each of these elements is
    implicitly based on basic knowledge that needs to be structured and standardized. Therefore, the Policy Charter is a rich source for terms (concepts) and facts that need to be included in the
    fact model.
  • Refer to part 2 of this series for more discussion on Policy Charters.
  • Workflow models: Workflow models outline the “flow” part of a business process. Performance of any given task produces knowledge (things that can be known) that should be
    represented by terms and facts in the fact model. Therefore, workflow models are another rich source for terms (concepts) and facts that need to be included in the fact model.
  • Rules: A central deliverable in a business rule project is the (automated) Rule Book. Each rule will depend directly on the terms and facts developed in the fact model (or instance
    model). Therefore, no term should appear in a rule that has not been defined therein. In addition, the fact model provides reusable sentence patterns (the facts) for expressing the rules.
    Following these standard sentence patterns is essential for ensuring consistent expression and interpretation of the rules, a basic principle of BRS RuleSpeakTM.


To obtain the sentence patterns of BRS RuleSpeakTM, visitwww.BRSolutions.comfor a free download.


[1] Excruciating level of detail is John Zachman’s term for being very, very thorough but always staying carefully at the
correct perspective for the given audience—in this case, the owners.

[2] Or whatever language is being used (for example, French, Mandarin, and so on).

[3] To our knowledge, the first usage was by (and for) Karel Van Campenhout, a business-side subject matter expert who participated in a
client project.

[4] This and other quoted definitions in this section come from Merriam-Webster’s Collegiate Dictionary, 10th ed. (1999).

[5] Thanks to Donald Chapin of Business Semantics, Ltd.

Share this post

Ronald Ross

Ronald Ross

Ronald G. Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994. With BRS’s client roster of Fortune 500 companies and governments, Ron consults,speaks and teaches worldwide. He has served as the chair of the International Business Rules & Decisions Forum conference since 1997, now part of the Building Business Capability (BBC) conference. Ron is also the author of 10 professional books, as well as the executive editor of the Business Rules Journal. Through these publications, as well as on the online forum BRCommunity and his blog, Ron enjoys sharing his knowledge and experience in consulting and business rules. Outside of work, Ron enjoys walking his dogs, travelling with his three children, and tweeting. For fresh nuggets of information, follow him @Ronald_G_Ross!

scroll to top