|
THE DATA ADMINISTRATION NEWSLETTER – TDAN.com |
 |
|
|
The Business Rule Approach: Changing the Face of Data Models, Part Three
Published: January 1, 2004
Published in TDAN.com January 2004
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 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.
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.
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? 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
neology.
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.
________________________________________________________________ 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. Go to Current Issue | Go to Issue Archive Recent articles by Ronald G. Ross
Ronald G. Ross -
Ronald G. Ross serves as Executive Editor of www.BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. His gives popular public seminars through AttainingEdge (www.AttainingEdge.com) and in Europe though IRM-UK (www.IRMUK.co.uk). Mr. Ross is recognized internationally as the “father of business rules.” He has served as Co-Chair of the annual Business Rules Forum Conference (www.businessrulesforum.com) since 1997. He was a charter member of the Business Rules Group in the 1980s, and an editor of the two landmark BRG papers, “The Business Motivation Model: Business Governance in a Volatile World” and the “Business Rules Manifesto”. He is active in OMG standards development, with core involvement in SBVR. Mr. Ross is Co-Founder of Business Rule Solutions, LLC (www.BRSolutions.com). At BRS, Mr. Ross co-develops ProteusR, its landmark business requirements methodology, including the popular RuleSpeakR. Mr. Ross is the author of eight professional books. His newest are: Business Rule Concepts (2005), a 2nd edition of his popular, easy-to-read 1998 handbook, and Principles of the Business Rule Approach, Addison-Wesley (2003). |
