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 ‘terms’

Controversial Concepts: How to Tackle Defining and Naming Them

Guest Post by Markus Schacher We should first agree on the semantics of underlying concepts and only then start to think about the best terms for those concepts. One particular technique I often apply in such cases is the following: 1.    Name controversial concepts with proxy names such as “Greg”, “Mike” or “John” (or whatever name you prefer) to get potentially misleading names and their implicit connotations out of the way of progress. 2.    Draw a concept diagram showing those concepts as well as important semantic relationships among them. 3.    Formulate intensional definitions for each concept – still using the proxy names. Ensure that those definitions are consistent with the relationships shown on the concept diagram. 4.    Identify one or more communities that “baptize” those concepts by giving them better names. If synonyms and/or homonyms appear among those communities, that’s just how the world is; we simply have to live with it. This is why SBVR formally supports semantic communities as well as speech communities. ~~~~~~~~~~~~~  www.BRSolutions.com

Continue Reading No Comments

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