Definitions of items of data really matter, but there are a couple of ways to see the value in them. One is when we focus on an individual definition within the context of a project. From such a siloed perspective, there can be a temptation to simply accept whatever is “good enough,” especially if the project team has a good idea of what the data means and is not held up due to a lack of data definitions. The more important perspective is, of course, the enterprise level, where we will usually encounter a sea of data items requiring definitions. To the extent that whatever definitions exist have been harvested from projects, many of them are inadequate, and some downright misleading. If such definitions are relied on, they have a high probability for causing problems. Even if 85 percent of the data definitions across an enterprise could be made perfect, I for one am prepared to state that the remaining 15 percent could be responsible for serious damage. I am also prepared to submit that data modelers typically prefer to deal with boxes, lines and pigeonholing things more than they care to focus on forming definitions. Good modeling often seems to apply to the visual rather than textual components of data models.


Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access