Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence


We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘verbs’

More on Concept Model vs. Conceptual Data Model

As part of a continuing dialog, I recently asked these questions: What does the term “conceptual data model” really mean? Is it the best term for what is meant? To me, it sounds like “conceptual data model” might be about “conceptual data”. Surely not(?). What exactly then? (Some of my thoughts on the matter: http://goo.gl/8GX5o.) A practitioner responded with the following 3-part challenge below. With each challenge is my response. Challenge part 1: Which of the following, if any, would you see in a conceptual data model: primary keys, foreign keys, abstract keys, constraints, nulls, non-nulls, 1:1s, 1:Ms, optionality, cardinality, etc.? My response: Wrong approach. Bad definition practice one three counts. 1. Things should be defined in terms of their essence, what they are, not in terms of what are allowed or disallowed. 2. Suppose none of the above were allowed. You’d end up simply with a description of what the thing is not, not what it is. Since you can’t possibly list everything it’s not, the definition is woefully incomplete. 3. The list attempts to describe something in terms of an implementation or design of the thing, not in the thing’s own terms. That’s simply backwards. Challenge part 2: So let’s turn the question around. What would be the minimum types of objects you need to explore a concept, produce a mini model, and convey knowledge about the concept and its relationship to other concepts? My response: To develop a concept you need: 1. A concise definition for the concept, which distinguishes the concept from all other concepts and conveys its essence to the business. 2. A business-friendly signifier (term) for the concept that has only that one meaning (or is properly disambiguated by context). 3. A set of facts that indicates the place of the concept within a structure of other concepts (e.g., classification, categorization). 4. A set of verbs that permits the business to communicate unambiguously about how the concept relates to other concepts (e.g., customer places order). 5. A set of structural rules for the concept and its relations to other concepts, as needed. Why the verbs? Because you can’t write sentences without verbs and business rules can always be written in sentences. ‘Requirements’ should be too(!). Challenge part 3: When you are finished do you call that a ‘conceptual data model’? My response: You notice that I didn’t say anything, directly or indirectly, about “data”. That term is irrelevant. Taking away “data” leaves “conceptual model”. But that term suggests what the model is made of (concepts), not what it is about. Of course the kind of model we’re talking about is made up of concepts – it’s certainly not made of physical material (e.g., wood, plaster, etc.) or through use of math (some formula). That leaves “concept model” (also sometimes called “fact model”). Bingo. Is there a standard for this kind of model? Indeed there is: SBVR (Semantics of Business Vocabulary and Business Rules). See the SBVR Insider section on www.BRCommunity.com for more information.

Continue Reading 2 Comments

Why So Much Ambiguity and Miscommunication in Requirements? … Something We’ve Learned from Business Rules

Let me share something we’ve learned from our work on business rules. The world’s leading cause of ambiguity in expressing business rules is missing verbs. Stay with me now. Consider this sample business rule: An order must not be shipped if the outstanding balance exceeds credit authorization. As a first-cut statement, that’s perhaps not bad. The more you read it, however, the more ambiguity you’ll find. Clearly, important ideas are hidden or missing. For example: The outstanding balance of what? …order? …customer? …account? …shipment? The credit authorization of what? …order? …customer? …account? …shipment? The hidden or missing ideas are all verb-related. To eliminate the ambiguity, the relevant verb concepts (called fact types in fact modeling) – must be discerned; then the original business rule restated. Suppose the relevant verb concepts can be worded: customer places order customer has credit authorization customer holds account account has outstanding balance Using RuleSpeak (www.RuleSpeak.com – free) the business rule can now be restated: An order must not be shipped if the outstanding balance of the account held by the customer that placed the order exceeds the credit authorization of the customer. Although the resulting statement is a bit wordier, it is far less likely to be misunderstood, misapplied, or mis-implemented. It is now enterprise-robust. The key insight: Wordings for relevant verb concepts should always appear explicitly in expression of business rules. For that matter, wordings should appear explicitly in any form of business communication you want to be understood correctly – including IT requirements. Note: You probably noticed use of the preposition of in the revised business rule. Stand-in prepositions for verb concepts are considered lazyman’s verbs. (Literally, you can’t make complete sentences with only prepositions!) Yes, you can use a preposition to stand in for a full wording, but do so with caution. As a rule of thumb, prepositions are safe only for two cases: (1) properties – e.g., credit authorization and outstanding balance as above. (2) role names – e.g., owner as in the earlier example, owner of a vehicle. ~~~~~~~~~~~~~~  This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php    

Continue Reading