Meta Data Silos (part 1)

By David Marco

Meta data management and its use in enterprise data management have become one of critical information technology (IT) focuses for both global 2000 corporations and large government agencies. As these entities look to reduce their IT portfolio and control their escalating IT costs they are turning to the technical functionality that a meta data repository can provide them. 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, like 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 lots of meta data repositories, none of which speak to each other and without an overall meta data management strategy. In this article 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. On the contrary, it is a common issue that has plagued many areas of IT. Technologies like 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 created by disparate meta data repositories are:

  • Missing Meta Data Relationships
  • Typically Built By Non-Meta Data Professionals
  • Costly Implementation and Maintenance
  • Poor Technology Selections

Missing Meta Data Relationships

In past columns I have discussed the different types of meta data (see Table 1: “Types of Meta Data”) that companies and government agencies need to properly manage1 and the importance of having these meta data objects linked together. For example, it is very valuable for an IT developer to have the capability to go to the meta data repository to look at the technical transformation rules (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 they 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 then 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 as it bridges the gap between our business and our IT systems, because in truth, our business is comprised of our IT systems. When meta data is not managed from an enterprise perspective this type of click-through analysis is impossible as the relationships between the meta data (both business and technical) are not being captured or maintained.

Table 1: Types of Meta Data

Poor Technology Selections

In At EWSolutions we work with a good number of large corporations and vast government agencies. It is common that in the course of working with these groups to find many disparate meta data repository or repository-like initiatives. For example, we have one client that has over 14 meta data repository initiatives (either in production or currently being developed) and another client that has over 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 which 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 that come in the form of Microsoft Excel spreadsheets, which, along with Microsoft Access are the most popular from of meta data repository technology. Does this surprise you? If let’s consider this fact for a moment. Neither Cognos nor Business Objects are 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 fact in mind it is not surprising that Microsoft Excel and Access are being improperly used for storing and retrieval of meta data.

In next month’s column I will examine the remaining two issues with disparate meta data repository environments.

1For more information on this topic see Chapter 2 in “Building and Managing the Meta

 
Free Expert Consultation