Meta data management and its use in enterprise data management have become one of the critical information technology (IT) focuses for both global 2000 corporations and large government agencies. As these entities look to reduce their IT portfolios and control escalating IT costs, they are turning to the technical functionality that a meta data repository can provide. This approach is very sound; and the organizations that have built well-architected, enterprise-wide meta data repositories have achieved a tremendous amount of success. Unfortunately, as with most popular IT trends, companies are making key mistakes in building and moving forward on their meta data management investments. One of the chief problems is that companies and agencies are not building one meta data repository; they are building several meta data repositories, none of which speak to each other and without an overall meta data management strategy. In this month's column, I will discuss this proliferation of unarchitected and disjointed meta data repositories and the problems that they cause.

The problem of disparate initiatives is not unique to meta data management. Technologies such as data warehousing, enterprise resource planning (ERP), supply chain management and all flavors of transactional systems have suffered with needless duplication and redundancy. The four most common problems with disparate meta data repositories are: missing meta data relationships, repositories built by non-meta data professionals, costly implementation and maintenance, and poor technology selections.

In past columns, I have discussed the different types of meta data (see table) that companies and government agencies need to properly manage and the importance of having these meta data objects linked.1 For example, it is very valuable for an IT developer to have the capability to look at the technical transformation rules in the meta data repository (technical meta data) that are being applied to a particular physical field name on a report that is being analyzed. Once the developer has reviewed this meta data, he/she could then navigate through the repository to find the business rules defined by the business users for that field. If a discrepancy between the transformation rules and the business rules exists, the developer could then use the meta data repository to contact the data steward that defined the specific business rules and resolve this discrepancy. This is the true power of a meta data repository: it bridges the gap between business and IT systems. When meta data is not managed from an enterprise perspective, this type of clickthrough analysis is impossible because the relationships between the meta data (both business and technical) are not being captured or maintained.

At EWS, we work with a good number of large corporations and vast government agencies. In the course of working with these groups, it is common to find many disparate meta data repository or repository-like initiatives. For example, we have one client that has more than 14 meta data repository initiatives (either in production or currently being developed) and another client that has more than 25 disjointed meta data repositories, most of which have significant monetary expenditures associated with them. Disparate meta data repository initiatives can come in many different flavors, sizes and shapes. There are large repositories that utilize enterprise-level meta data integration tools or are even custom build (typically with Microsoft SQL Server or Oracle). Also, there are lower technology meta data efforts using Microsoft Excel or Microsoft Access –­ the most popular forms of meta data repository technology. Does this surprise you? Let's consider this fact for a moment. Neither Cognos nor Business Objects is the most popular form of data warehouse access. Microsoft Excel is still the most popular data warehouse access technology. This is one of the dirty secrets of data warehousing. With this in mind, it is not surprising that Microsoft Excel and Access are being improperly used for storing and retrieval of meta data.

References:
1. For more information on this topic, see Chapter 2 in my book Building and Managing the Meta Data Repository: A Full Life-Cycle Guide (Wiley, 2000).

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