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 ‘fact models’

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

Confession Time … I Fell into the Same Vocabulary Trap I Warn Everyone Else About

I have been involved in a great on-going discussion on LinkedIn about data models. I posed the question: Is there any proven way to demonstrate data models are correct, complete, and stable with respect to the operational business and its needs? You might enjoy joining in: http://goo.gl/MsnXu It was literally 25 messages into the discussion that I realized “data model” was being used in two distinct ways in the discussion. And even then it had to be pointed out by a participant who seemed to know one of the other people.
  • I always mean “data model” in the ‘old’ way, in which the data model supports real-time business operations (or close thereto). In that world, you must design for integrity, which generally means ‘highly normalized’ in the relational sense.
  • In the old-but-not-nearly-as-old world of OLAP, real-time operations and updates are not a concern, so de-normalization (and redundancy) are presumably acceptable. (I’ll leave that question to the experts.)
That’s always the problem with vocabulary – deeply buried assumptions that prevent you from hearing what you need to hear. From experience, I know the trap oh-so-well, but here I fell right into it myself. What’s the answer to the question I posed for “data models” (of the kind I meant)? Focusing on the meaning and structure of business vocabulary, not data, as a core part of business analysis.  Note to self (a rule): When you enter any discussion, be clear what you mean by the terms you use – even (and maybe especially) the ‘obvious’ ones.

Continue Reading 2 Comments