A couple of years ago, BellSouth ran a commercial that presented a local elementary school career day where a technician parent showed up to discuss the merits of working for the local phone company. After a few minutes of discussing switches, central offices and network backbones, the students interrupted him asking if he drove the truck. He replied, "No" and continued with his discussion. As he described the process of hooking up a neighborhood phone system, the students once again asked him if he drove the truck.
After a couple more interruptions, he finally relented and said that the only thing he does is drive the truck. The students followed with a chorus of, "coooool."
I found myself in a similar situation a couple of weeks ago when I joined a threesome on a local golf course. The conversation went something like this:
Playing Partner: What do you do for BellSouth?
Todd: Well, we collect, store and provide access to meta data information that is built on industry standards such as OMG, CWM and Dublin Core. Our access points provide both active and passive access to a wide variety of users that include the CIO, CEO, DBA, DA, programmers, etc. This information is then used to create the information architecture, supported by the corporate data architecture.
Playing Partner: Yeah, (pause) now where did my ball go!
Todd: Actually, we provide library-like card catalog services within the technology community.
Playing Partner: Oh, wow that sounds really cool.
Yes, I failed the enterprise meta data world again. I reduced the context of our job into a simple analogy that makes most meta data experts cringe. In my defense, this person was a small business owner in another industry, and I doubt he had enough time or enough golf beverages to listen to an hour overview of the merits of meta data. The usual comment from meta data experts is that true meta data expands far beyond simply cataloging data or any other asset. True, but on the other hand library science goes far beyond simply sticking a number on the cover of a book and ensuring that book is placed in the correct location. Can we learn something from the library science crowd?
First, a solid card catalog not only indexes books but also journals, microfiche, magazines, newspapers, government documents, annual reports, etc. The vast majority of the information is based on a simple ontology of information architecture. Figure 1 provides an example of a card that catalogs a fictitious book.
Figure 1: Card Catalog Book Entry
What are some of the meta data components included here?
- Location instructions
- Author, publisher, etc.
- Alternative hierarchical structures
- Unique identifier
Remember, there were several types of card formats depending on type of media being described. These formats are still used today, except now we use a computer versus a physical card. This allows for an extensive relationship analysis of the meta data. Now, the million-dollar question: What would you trade or spend to accomplish what every local, university or private library has accomplished? The only exception is that instead of books you’re going to have technological assets. Every data asset will be described as follows:
- Name of the asset (Customer entity)
- Keywords (customer, CRM, party, client)
- Physical and logical location identifiers (Logical model, Entity = Party, attributes, CRM database, Table XYZ, field PartyName)
- Business definition of the customer (One who pays the bills)
- Data steward, application steward or architect
- Hierarchical structures (Party-Customer-Name-Last)
Before you answer that question, let me add a bonus here. I am talking about every system, interface, application, component, metric or what ever asset you can define within the technology community. Since I can’t hear your answer, let me say I would trade all that we have built for that passive repository. But wait, isn’t everyone telling you that active utility is far more important than passive. While that is another conversation all together, the reality is that locating, loading and delivering quality meta data is the hard part. Building neat, functional and creative utilities for the data is the easy part. It’s really too bad that most people fail to see or acknowledge the utility of tracking the inventory of the greatest asset we have. Next time you get a chance to visit your local library, take a look around. Image all of those books are data components, entities, attributes or tables. To the left is the current system and inventory map. Back in the right is the data access room filled wall to wall with common components.
And at the center of it all is your enterprise meta data catalog. Every entity, table attribute, field, transformation, business rule, steward, component, etc. will be cataloged with a solid description, keywords, owner, location, business meaning and all of the other normal meta-model constructs. Wow, wouldn’t that be nirvana?
Is it time for a meta data librarian in your organization? Is it time to start to focus on the real hard part of meta data? Or should we continue to talk about what could be, what should be and what would be in world of active utility?
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
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access