Meta Data Silos (part 2)

By David Marco

In the first part of this series, I discussed the issue of disparate meta data repositories. During this column I listed the four most common problems created by this phenomenon and I discussed, in detail the first two issues.

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

In this article, I will address the final two problems and discuss why they exist.

Costly Implementation and Maintenance

Typically business units and technical groups need meta data to properly run their business and their IT systems. Therefore, these groups will not want to wait around for their company to start building an enterprise-wide meta data repository, assuming that they may not even have such a project in their current IT plans. As a result, they run off and build these disparate meta data repositories solutions that are designed to only handle one or two specific problems/challenges. If executive management knew the cost of these meta data repository point solutions they would see that it far outweighs the cost of a truly sound enterprise-wide meta data management repository. This situation closely follows the path that many companies have taken with data warehousing. For example, the average company needlessly replicates their data warehousing efforts across many of their lines of business, as opposed to centralizing this function. It has been my experience that this approach typically increases the costs of data warehousing by over 300%. These companies could provide all of the data warehousing functionality that they provide today at less than a third of the cost, if they just managed their IT systems properly. The types of organizations that build point meta data solutions, are traditionally concerned by the cost of building an enterprise-wide meta data repository. However, the cost of this enterprise-wide repository would pale in comparison to the costs of all of the disjointed meta data initiatives that are currently underway or in production (see Figure 1: “Meta Data Management Costs”. Doing it right the first time is always less costly than doing it wrong and trying to fix it later.

Figure 1: Meta Data Management Costs

Typically Building By Non-Meta Data Professionals

When government agencies and corporations have disparate meta data repositories, invariably most of these applications are being built by both consultants and employees that are not qualified to do so. This is highlighted by the fact many consulting and software firms are entering the meta data management field even though they have little to no experience in this area. Meta data professionals are like data warehouse practitioners. They are professionals that study their craft and have made it their full-time and in many instances life-work. You cannot take an operational systems person or even a data warehousing person and expect them to work in the meta data arena if they are lacking the proper knowledge.

A meta data repository is not a data warehouse or an operational system. Building the meta data repository incorrectly will only lead to having to rebuild it again in the future. I have published over a hundred articles in my career; however, only once did I ever write a predictions article where I attempted to say what will happen over the upcoming years. It was October of 1999 and I needed to write my January 2000 DM Review column. In approaching this column I thought that if I’m ever going to write a predictions article it must be for my first article of the new millennium. How could I resist? My number one concern for this column was making sure that the predictions I made would come true, as I knew that someone would inform me if I missed any of my “Nostradamus” forecasts. Therefore, my first prediction was that “During the 1990s, corporations raced to build their decision support systems as quickly as they could…in their zeal to do this too many of these organizations neglected to build the architecture necessary to grow their systems over time.1

1Data Warehousing Trends for 2000”, David Marco, DM Review, January 2000.

Free Expert Consultation