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.
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
neology.
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!
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.
business rule approach. Build on a weak foundation, and your whole business logic becomes a house of cards.
well as an honorable profession (I presume).
willfully misleading interpretation.” That is not going to do.
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?
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.
