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

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘verb concepts’

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

Bots “Communicating” (Funny!) … What about SBVR and RuleSpeak?

If you want to hear state-of-the-art machines (bots) talk to each other, see: http://goo.gl/LEIMI Funny! Rude and petty … just like humans sometimes. I don’t think we’re quite there on Star-Trek-style communication with machines(!). If you want to see a suitable set of guidelines for writing unambiguous business rules that machines should be able to understand, see www.RuleSpeak.com (free). RuleSpeak was one of the three reference notations used in creating SBVR, the OMG standard Semantics of Business Vocabularies and Business Rules. (SBVR doesn’t standardize notation.) Don’t try to read the SBVR standard – it’s for logicians, linguists and software engineers. For insight into what SBVR is about, see the SBVR Insider section on www.BRCommunity.com. SBVR itself is a structured vocabulary – essentially a concept system. Clause 11 provides a structured vocabulary for creating structured vocabularies. Clause 12 provides vocabulary for business rules. ‘Structured’ in this context means it includes both noun concepts (nothing unusual about that) and verb concepts (highly unusual). You need verbs to write sentences (propositions). Try writing a 100 business rules without standard verbs. Well, you can do it, but what you’ll get is spaghetti logic and hopeless, bot-like(?) communication.

Continue Reading