Continue in 2 seconds

What Should You Expect from the Meta Data Vendor Community?

Published
  • November 13 2003, 1:00am EST

One question seems to come up time and time again, is what should you expect from a meta data vendor? By definition, the meta data vendor is one that sells an application or services that enable you to effectively implement your meta data strategy. What should you expect, desire and border-line demand from the vendor community. Some of these items are pet peeves while others truly should be delivered with any application purchase.

Let’s start with the obvious; the meta-model. At some abstract level, the repository is just another database application. Data comes in, is stored and integrated with other applications. Why wouldn’t we expect the meta data meta-model to be the first database loaded? Perhaps this is too logical. We bring repository applications into the organization for many reasons: archiving knowledge of our technical community, expressing relationships between objects and providing conceptual understanding with model abstractions. Did someone make the decision that these benefits are not a good thing for the meta data team? It seems to me that if we are going to purchase an application for the user community to assemble structures, define semantic meaning and understand the logical definition of data then the meta data team should also gain these benefits.

Why shouldn’t this data come with the system out of the box?

Why? Because we don’t demand it! Our customers demand it from us, but we don’t demand it from the vendor community. When was the last time you demanded the conceptual, logical, UML and physical models from a vendor? Yes, I have heard the arguments of intellectual property, but what about understanding the product and functional utility? What are you paying those millions of dollars for? We don’t buy a car just to get from point A to point B, we want to see the owner’s manual. We drive to the auto supply store to buy a Chilton’s guide to see the electrical, engine and exhaust diagrams. We even expect out service stations to have access to this information, but don’t you dare ask a vendor for this information; it’s "intellectual property." Or perhaps there is another reason – they don’t actually produce conceptual, logical and physical models of the meta data database. If that is the case then just say it, "We don’t have data or procedural models for the meta database." Of course, the next logical question would be, why not?

OK, I am getting myself worked up so I better move on to another topic. I would also like to see the vendor community develop a clear vision of direction. Where do they believe meta data is heading and what will a meta data services group look like in the future? In my opinion, our vendor organization should be the authors and presenters that take us to the next levels of products and services. When was the last time you read an article or white paper from a vendor that didn’t require you sign up via the Web, which then resulted in 15 sales calls? What ever happened to the expansion of the body of knowledge or a rising tide raises all ships? Is it any wonder that we are still deploying technology that was built more than 5-10 years ago, and we still don’t have a universal meta data standard.

Now that I have alienated the vast majority of the vendor community, let’s keep right on pounding. How about that customers that failed in their meta data efforts? Vendors have no problem providing references for the successful implementations, but we can learn a tremendous amount from those that have tried but could not break down the barriers. Instead of giving me the top three customers, how about your last three? Or maybe three in different stages of completion or three different budget levels. Learning from those that have gone before us is the best way I know to jump start an implementation and get it started on the right track.

How about a standard system configurations or an easy start guide? When my new Dell computer arrives (not ordered yet, but soon), there will be an easy start guide that sets up the machine in a basic configuration. What!!!! You mean I don’t need to hire 25 Dell consultants to come to my house to gather requirements for five weeks before I can see any results. Perhaps one day, software built for the corporate side of the house will be as easy to implement as many home-based products. And it’s not just the installation side of the house. Why do I need to train my staff and the user community on how to use the product? Does Amazon.com have a three-week training course in order to buy a book? Does Quicken require financial certification before you can see if your checkbook is in balance? Of course not, then why can’t I buy meta data software that is simple to install and simple to use. Don’t tell me that the principles of meta data are any more complicated than an income statement or balance sheet. I don’t buy that and neither should you.

As you move into your meta data implementation you will come across opportunities to bring in information from other sources. Wouldn’t it be nice to have a collection of sample files and sample scripts that demonstrate how this particular type of information can be integrated into the repository? Rarely does a data load work the first time you try the process. This is especially true when you try to load different types of data or utilize different methods of loading. Since the vendor company tested the load processes, why not include some sample data so that repository administrators can test and learn the new functionality without having to create the data from scratch or use production data?

I would also like to ask that my sale representatives to have some level of knowledge about the world of meta data. Sometimes it sounds like a bunch of parrots in the office. In fact, we should fire all of the sales reps and replace them with parrots. Then, they could just wonder around the shop squawking "Can I help you? Can I help you?" with just as much effectiveness as many representatives do today. I don’t want to come across insensitive to the way people make a living, but my Home Depot paint salesman should know something about paint, my banker should have a basic understanding of finance, my garden center should have knowledge of what plants grow well in the south and my stock broker …Well he’s in the doghouse right now, but you get the picture.

What I really want from the vendor community is a partner. Webster’s Dictionary defines partner as "one that is united or associated with another in an activity or a sphere of common interest." Someone that shows up with concern when I have money to spend and when I don’t. A group that is willing to commit to the success of the project and the support the basic principles of meta data. As the song says, I want vendor that will stand beside me, not in front of or behind me. We want a long term relationship, plain and simple.

What will the response of the vendor community to this article? Some will get mad and try to defend their practices; others will soft shuffle around the issues. But maybe, just maybe, someone will listen to the customer base and begin to take steps in the right direction. I can only hope that the future implementations of meta data will not resemble the ones of the past. Now I need to go take a Diazepam, better known as a Valium…

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