Welcome Guest. | Log In| Register | Membership Benefits

Intelligent Enterprise

Better Insight for Business Decisions

Intelligent Enterprise - Better Insight for Business Decisions
search Intelligent Enterprise
Home
Digital Library
Events
RSS | Newsletters
Webcasts



Data Modeling and the Canonical Conundrum | Intelligent Enterprise Blog
Third Eye View, by Rajan Chandras
Rajan Chandras is a consultant with a global IT consulting, systems integration and outsourcing firm. Write him at rchandras@gmail.com.
See More by Rajan Chandras

E-MAIL | Follow Us on Twitter FOLLOW US
Share
Data Modeling and the Canonical Conundrum

Posted by Rajan Chandras
Thursday, March 20, 2008
6:25 AM

A Forrester Research paper I read recently stoked my interest (again) in the canonical data/information model, a once hot pursuit that seems to have cooled down in recent times. In short, the paper states that the canonical information model excludes "at rest" data (legacy systems of record, packaged applications etc.) but includes information in motion (messages, service invocations, etc.). My first instinct was to disagree with this definition…

But then, I began wondering about what, exactly, is a canonical information model, and realized that this definition only serves to highlight the confusion out there around [enterprise] [canonical] [business] [data/information/object] models… starting, as you can see, with the term itself. As somebody (Confucius? African proverb?) once said: "If you don't know where you are going, any road will take you there."

The theme of the research paper, by Forrester analyst Mike Gilpin, is neatly captured in the title (Canonical Information Modeling Is Key To Many Information-As-A-Service And SOA Strategies), and is hard to argue with — in fact, I would substitute "Most" for "Many" in the title. Standardized information models (whether at the business/conceptual object level or at the data/entity level) will strongly boost your efforts to lay down a reusable service-oriented information infrastructure. On the other hand, disparate data/object definitions (whether at rest or in motion) will increase complexity and cost while reducing reliability and reuse.

As with most concepts, it is less important that we describe it neatly than that we do it well, but a common definition and understanding will help more of us reach that important goal. I suspect that a good reason many of us are mired in a morass of non-standard information and data models is that we don't know what the goal is. Is it to define a common business object model, or a common data model? What's the difference? Does this include packaged applications and existing (often legacy) data stores? Does this include data "at rest" and/or "in motion"? Whose responsibility is it? Where do we begin?

Here's another way to look it: If you don't know where you are going, you are already there — but it's not necessarily a good place to be.



E-MAIL | Follow Us on Twitter FOLLOW US
Share




This is a public forum. United Business Media and its affiliates are not responsible for and do not control what is posted herein. United Business Media makes no warranties or guarantees concerning any advice dispensed by its staff members or readers.

Community standards in this comment area do not permit hate language, excessive profanity, or other patently offensive language. Please be aware that all information posted to this comment area becomes the property of United Business Media LLC and may be edited and republished in print or electronic format as outlined in United Business Media's Terms of Service.

Important Note: This comment area is NOT intended for commercial messages or solicitations of business.


 




    Subscribe to RSS feed of all blogs