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


We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Moving the Goalposts for Data Models … Deliberately

A practitioner recently said this: “Even if we assume that a technical methodology might exist to generate a complete and correct data model from a set of articulated business rules / facts, in my opinion this approach just moves the target from the data modeling area to the need to verify the articulation of business facts / rules for completeness and correctness.” Exactly! And why would that be a problem?! Here’s an additional advantage: The core concepts (concept model or fact model) of an operational business area are very, very stable. Don’t believe it? As proof see http://www.brcommunity.com/b594.php (short case study, well worth a quick read). The problem with current data modeling practices is that a large gap often exists between the business view of things (operational business things) and the ‘data’ view of those things – even when trying to keep to a ‘conceptual’ view. This gap gives business-side people a ready excuse to drop out. But data modelers alone can’t provide the necessary business know-how for a robust, complete model. The problem is so big, it’s hard to see. Current data model practices evolved bottom-up, from database designs. (I believe I can speak with some authority here. I was editor of the Data Base Newsletter, 1977-1999, and wrote three books related to the matter in the late ‘70s and early ‘80s.) It’s time for us to approach the problem top-down. There is a natural way to build concept systems – it starts with basic business communication. The standard for such an approach already exists – SBVR. (For discussion see BRCommunity’s SBVR Insider section.) We’re already living and working in a knowledge economy … We need to start acting like it!

Continue Reading

Data Modeling: Art or Science?

A practitioner recently commented: “Everyone has their biased view of what a data model is. Data modeling is art – not science. Give 6 data modelers one set of requirements and you’ll get 7 solutions all distinctively different.” My response: To me that’s a huge problem. No, ‘data’ modeling is not a science, but nor should it be an art. Actually, it should be engineering. Engineered solutions have to stand up to rigorous tests. But we lack that in ‘data’ modeling. Why? Because ‘data’ modeling is divorced from its initial business context, which is operational business communication, including business rules. You need nouns and verbs for that, and those nouns and verbs should stand for well-structured concepts. Give me a model of well-structured concepts that has been ‘proven’ by verbalizing business rules and other formal business communications and I guarantee I can come up with the best data model. I’m talking of course about concept models (sometimes called fact models).

Continue Reading 1 Comment

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

What Exactly is a ‘Conceptual Data Model’ … and Why in the World is It Called that, Not Just ‘Concept Model’?

I’m kicking off 2012 with a couple of things I just don’t get. Here’s the second one: What exactly is a ‘conceptual data model’? Why in the world is it called that instead of just ‘concept model’?  ~~~~~~~~~~~~~~~ Did you ever pause for a while to ponder the meaning of the term “data”? Most of us don’t. The term is so familiar and pervasive we simply take it for granted. For IT professionals, “data” is about as basic as it gets. Taking terms for granted, unfortunately, is the surest path to confusion. It’s the deep assumptions about the terms lying at the very heart of a subject matter that usually trips us up. So let’s take a moment to examine the meaning of “data”. Just so you know where this is headed, I’m embarking on a full frontal assault on the term “conceptual data model”. I’ve disliked that term for years. I think we should kill it off once and for all. Why? Three fundamental reasons:
  • No business person would naturally say “conceptual data model” in everyday business conversation. If we mean something by “conceptual data model” that business people should be able to talk about, then why have a name for it they can’t easily understand? Jargon just makes things harder.   
  • I believe what you really mean when you say “conceptual data model” is simply “concept model”. If “conceptual data model” doesn’t mean that, then what in the world does it mean?! 
  • “Concept model” has recently been adopted by SBVR 1.1 replacing “fact model”. The SBVR reasoning for the switch is directly related to this discussion, but I’ll save it for some other post.
Why Not “Conceptual Data Model” The Wikipedia entry for “data (computer science)” says, “… information in a form suitable for use with a computer. The entry adds, “Data is often distinguished from programs … data is thus everything that is not program code.” Now let’s substitute “… information in a form suitable for use with a computer” for “data” in “conceptual data model”. The result of the substitution is “conceptual information (in a form suitable for use with a computer) model” or simply “conceptual information model”. What exactly does that mean? As far as I can tell, not much at all! By all rights we should be permitted to terminate the analysis there. In IT the Wikipedia definition is what “data” has meant for well over half a century. If you’re interested and have the patience, however, let’s be charitable and look more broadly at the term “data”. See the footnote[1] (long). Skip it if you like – it leads nowhere and life is short. As the footnote indicates, any attempt to make sense of “conceptual data model” through fair-minded dictionary analysis of “data” leads to nonsense or a dead end. So the term “conceptual data model” must have an origin all its own. Indeed it does – one definitively IT-based. Reviewing the Wikipedia entry for “conceptual data model” we find the synonym “conceptual schema”. “Conceptual schema” is a technical term dating at least from the 1970s. I can vouch for the overall accuracy of the Wikipedia entry since I wrote several books touching on the subject in the 1970s. Ironically, Wikipedia provides a great definition for “conceptual data model”: a map of concepts and their relationships. Bingo! So why all the mumbo jumbo? Why not just say “concept model”?! Let’s toss “conceptual data model” and be done with it!
[1] Definitions of “Data” in Merriam-Webster Unabridged Dictionary 1a: … SENSE-DATUM  : an immediate unanalyzable private object of sensation *a sharp pain, an afterimage …* Surely that’s not what a “conceptual data model” is about. 1b(1) material serving as a basis for discussion, inference, or determination of policy *no general appraisal can be hazarded until more data is available*   Most meanings of “material” are physical (e.g., metal, wood, plastic, fiber), however one [1b(2)] is not: something (as data, observations, perceptions, **ideas**) that may through intellectual operation be synthesized or further elaborated or otherwise reworked into a more finished form or a new form or that may serve as the basis for arriving at fresh interpretations or judgments or conclusions (emphasis added). For the sake of argument, let’s assume that “data” in “conceptual data model” is meant as “ideas”. So “conceptual data model” then becomes “conceptual idea(s) model”. What exactly are “conceptual ideas”? Or more precisely, what ideas are not conceptual?!? So in the very best case, this definition of “data” results in the awful signifier “conceptual idea(s) model”. 1b(2) detailed information of any kind  You can go through the various definitions of “information” if you desire, but I’ve already asserted that “conceptual information model” is nonsense. This whole matter can’t be all that hard(!).

Continue Reading 2 Comments

Typical Dialog When You Don’t Know the Concepts or Vocabulary … Can Anyone Explain This Soccer Rule to Me??

I’m an avid fan of soccer … and, of course, business rules. I recently found the following business rule via a Twitter search and just had to ask what it meant. FootballRascal – Can’t sign a player and then loan him out to another Premier League club in same window, business rule as fee charged Ronald_G_Ross – For U.S. audience, but avid football fans, what is motivation for not-in-same-window business rule? MeJonWhite – Personally, I have no idea, can’t see the logic. He could go on loan internationally, but not domestically. Ronald_G_Ross – Just one more ques. re not-in-same-window business rule. Uh, what’s a window? Period of time? Season? MeJonWhite – Summer window is July 1st – Sept 1st, it’s just the off season registration period. January is the Jan window. I am still in the dark, but I didn’t want to bug the kind folks any more. What I need is a blueprint to the concepts, a fact model, to bootstrap my way into a meaningful conversation quickly.

Continue Reading

Thou Shalt Not Kill … Could Anyone Mistake that Commandment for a Process?! Or the Process with a Concept?

My Analysis: There are three clearly different things involved here …
  • The process of murder transforms a live person into a dead person by killing them.
  • The concept of murder is defined as the act of killing someone.
  • The rule about murder is that there shouldn’t be any of them.
The first is about doing; the second is about knowing; the third is about prohibiting. Three very different things. So it should be in business analysis and analysis of business rules.  ~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 1 Comment

Something Important All Business Analysts Owe to Business People … Probably Not Something You’d Expect?

One of the first rules of business analysis should be never waste business people’s time. One of the fastest ways to waste their time is not knowing what they are talking about … literally … and do nothing about it. So you end up just wasting their time over and over again. Unacceptable. Is there a way to avoid it? Yes, by taking the time to understand exactly what concepts the business people mean when they use the words they use.  I believe business vocabulary should be job one for Business Analysts. If you don’t know (and can’t agree about) what the concepts mean, then (excuse me here for being blunt) you simply don’t know what you’re talking about. (And sometimes, unfortunately, neither do the business people … which is something important BAs should find out as early as possible.) So structured business vocabularies (fact models) are a critical business analysis tool. How else is there to analyze and communicate about complex know-how in a process-independent way?! Looking at the issue the other way around, you can make yourself look really smart about a complex area in a relatively short time by having and following a blueprint. We’ve had that experience many, many times in a wide variety of industries and problem areas. (Try jumping between insurance, pharmaceuticals, electricity markets, eCommerce, race care equipment, credit card fraud, trucking, taxation, healthcare, banking, mortgages, pension administration, ship inspections, and more! We do.) There’s no magic to it – like contractors for the construction of buildings, you must have or create structural blueprints. For operational business know-how, that means bringing an architect’s view to structure the concept system of the problem space …  just a fancy way of saying develop a well-structured business vocabulary. Then a whole lot of things will fall right into place for you. P.S. By the way, I’m not talking about any form of data modeling here. Also, there’s no real need to use the ‘S’ word (semantics) for it.  

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

Moving the Goalposts for Data Modeling … Deliberately. Hey Guys, We’re in a Knowledge Economy.

Is there any proven way to demonstrate data models are correct, complete, and stable with respect to the operational business and its needs? No. That’s distressing.  Is there an alternative that does? Yes, fact modeling, which is to say structured business vocabularies (concept systems). The core concepts (fact model) of an operational business area are very, very stable. I have outstanding proof (short case study).  See: http://www.brcommunity.com/b594.php. Definitely worth a quick read. I recently made these statements in a data modeling forum, and a practitioner came back with this: “Even if we assume that a technical methodology might exist to generate a complete and correct data model from a set of articulated business rules / facts, IMO this approach just moves the target from the data modeling area to the need to verify the articulation of business facts / rules for completeness and correctness.” Missed the point. Concept anaysis is brain work. You’ll never generate a ‘complete and correct data model’ … you must create it … ith business people and SMEs. The problem with data modeling as practiced today is that there is a large gap between the business view of things and the data model. It gives business-side people a ready excuse to drop out. And its an art rather than a science. You really have no justification building a system until you have a concept blueprint. Currrent data models evolved bottom up, from database design. (I know, I watched it happen. I was editor of the Data Base Newsletter, 1977-1999.) It’s time to approach the problem top-down. There are natural ways to build concept systems. The standard for the new approach is SBVR. (For more, see BRCommunity’s “SBVR Insider”), which in turn is based on ISO 1087 and 704.  We (all of us) need to start practicing like we’re living in a knowledge economy … which in fact we actually already are.

Continue Reading

Our Clients

[cycloneslider id="our-clients"]