Consolidation is not the same thing as integration.  What does it really take to integrate business practices?  Let me illustrate with a thought experiment. Imagine that the U.S., Canada, Cuba, Jamaica, and Japan were completely closed societies.  However, to invigorate their sports, each allows one visitor for one day each century to bring a new game idea. For the 1800s, baseball is chosen.  Abner Doubleday arrives in each country, and talks about bases, runs, strikes, balls, innings, and all the other things of baseball.  At the end of the day he leaves.  Nobody knows what happens until the next visit, a hundred years later. As it turns out, each country has embraced the game enthusiastically, and each now has a century of competitive results. So taken are the countries with the game, they express a desire to merge their results, and to begin an international league.  A commission is chartered for that purpose and hires business architects. The initial results are promising.  Each country uses the same nouns (i.e., bases, runs, strikes, batters, etc.), and many of the same verbs (e.g., “run is scored in inning”).  A data model emerges that meets general approval. Then the trouble begins.  Not surprisingly, substantial differences have arisen over a hundred years in how each country plays the game.

• In Japan, a batter loses so much face after one strike (not a foul ball) he is immediately retired.
• In Canada (being a tolerant country), an unlimited number of strikes per at-bat is permitted but, to compensate, only two outs per inning.
• In Cuba (being a socialist country), strikes are charged to the pitcher, rather than to the batter.
• In Jamaica (suffering from earlier British influence), only two bases are used, the ball is bowled, ‘pitch’ refers to the playing field, and games may continue for two days.

Can the results be merged?  Yes and no.  Because they are based on the same words, they can be consolidated (lumped together).  However, because each country plays the game differently, they cannot be integrated (compiled meaningfully). What does it take to achieve true integration of business practices?  Without common standards for how the game is played, integration is impossible. To play ball you need business rules and a shared rulebook.

John Zachman says you can (and probably should) develop each of the following three kinds of artifacts to “excruciating level of detail”. 1. For the business management’s perspective (row 2), a conceptual model (roughly CIM in OMG terms). 2. For the architect’s perspective (row 3), a business logic design (roughly PIM in OMG terms). 3. For the engineer’s perspective (row 4), a class-of-platform design (roughly PSM in OMG terms). Because each is a different kind of model, there is a transform from one to the next. One implication is that it is possible to make a clear distinction between analysis (CIM) and design (PIM).   Another implication is that concept models and logical data models are clearly distinct. Unfortunately, many people blur the line between them. That’s wrong.

• A concept model is about the meaning of the words you use, and the business statements you make assuming those meanings. It’s about communication.
• A logical data model is about how you organize what you think you know about the world so it can be recorded and logically manipulated in a systematic way.

I started my career in data. It took me as much as 15 years of intense work on business rule statements (1990-2005) to fully appreciate the difference. But now I am very clear that concept models do need to be developed to excruciating level of detail in order to disambiguate the intended business communication. Most businesses don’t do that today. They jump in at data design (conceptual, logical or even physical). And they unknowingly pay a big price for it. By the way, a good concept model can be readily transformed into a first-cut logical data model – just as Zachman says. ~~~~~~~~~~~~~~~ www.BRSolutions.com

OMG released version 1.3 of SBVR (Semantics of Business Vocabulary and Business Rules)[1] last month – comprehensively reorganized for approachability, but not changed.[2] Some thoughts … ~~~~~~~~~~~~~~~~~ Ever hear the conversation that three baseball umpires once had? If you don’t live in a baseball country, it’s an archetypical story, so you’ve probably heard some variant. By the way, in American English a ‘pitch’ is a throw of the ball for the batter to try to hit, not the field of play. Meanings matter!

• The first umpire says, “Some pitches are balls and some are strikes. I call them as they are.”
• The second umpire says, “Some pitches are balls and some are strikes. I call them as I see them.”
• The third umpire says, “Some pitches are balls and some are strikes. But they aren’t nothing till I call them.”

Most modeling techniques primarily focus on modeling the real world as it ‘really is’. They essentially take a first-umpire point of view or maybe second-umpire. I come from that tradition too. My 1987 book Entity Modeling was about doing that … modeling the real world as it ‘really is’. Pretty much all professionals with some IT background come from that world. Working with business people and business rules for the last 25 years, however, has taught me that business is really more of a third-umpire world. Think of laws, regulations, statutes, contracts, agreements, terms & conditions, policies, deals, bids, deeds of sale, warranties, prospectuses, citations, complaints, receipts, notices … and business policies. Even businesses that deal with tangible stuff (e.g., railroads, electrical transmission, infectious diseases, etc.) live in a third-umpire world. And many of the most automated organizations around have no tangible product at all (e.g., finance, insurance, government, etc.). They really exist only in a world of words (between people). It’s humbling to realize that the way the business world ‘really is’ is more directly the product of words exchanged by the players in a conversation game than anything IT professionals can model directly. But why would it be otherwise? Do IT professionals really know better than business owners, business managers, lawyers, engineers, subject matter experts, etc.? Really?! SBVR, in contrast to almost all other standards, doesn’t try to model the way the real world ‘really is’. Instead, its focus is on modeling what is said about the way the world really is. It’s fundamentally a third-umpire standard. You simply have to understand what the words mean – and that’s a human-communication issue. Yes, the SBVR world view is a game changer. It also happens to align closer with some of the most exciting new work in computerization today including cognitive computing and machine learning. I stand accused by peers in the standardization community of wanting to go beyond the ‘capture, exchange and production of information’. Sure, I can live with that. ~~~~~~~~~~ www.BRSolutions.com

When you show business people class diagrams or data models, you’re not really talking business. Class diagrams and data models are design artifacts that inevitably focus on how knowledge about real-world things is to be represented (and manipulated) as data in machines. If we want business people to talk business to us, we must talk business back. That means talking about their words, concepts and meanings. To do that you need to develop business vocabulary in a structured way – i.e., develop a concept model[1]. Practitioners are slowly starting to ‘get’ this. Examples: 

• IIBA’s recently released Business Analysis Body of Knowledge (BABOK) version 3 devotes a new section to concept models.
• A solid standard exists for concept models – OMG’s Semantics of Business Vocabulary and Business Rules (SBVR).[2] Version 1.3 of the standard, comprehensively reorganized – but not changed – is due out this week.
• Proven methodologies support concept modeling.[3]

~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

I certainly understand the need for data models, and that fact they should be coordinated/integrated with process models. Who would question that these days?! But to re-engineer business decisions or knowhow-intensive business processes (or both), you need a structured business vocabulary – i.e., a concept model. The purpose of a concept model is to provide the terminology and wordings to write hundreds (or thousands) of rules coherently and consistently. Building such blueprint is not an insignificant undertaking. Yes, a concept model can be used as the basis for designing a model of the data needed to support processes, but that’s not its primary objective. Rather its purpose is to understand what the business rules and decision logic are talking about business-wise at ‘excruciating level of detail’ (to borrow a phrase from John Zachman). A concept model involves hundreds of terms, some whose meanings are obvious, some whose meanings you think are obvious but aren’t, and some whose meanings are simply mysterious. We constantly have to caution against setting expectations too high about how much integration based on business semantics can be achieved on relatively short notice. Even though it seems like ‘defining business terms’ should be relatively easy, concept modeling is by far the hardest work we do. The problem in virtually every organization in the world today is that these business semantics have never been developed well enough (think semantic, rather than functional, silos) to take automation of logic to the next threshold – i.e., to white-collar automation. Yet that’s exactly where a great many organizations currently want (and urgently need) to go. www.BRSolutions.com

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!

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).

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!

---

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.