You don’t often hear “metadata management” and “business initiatives” in the same sentence. It’s time for that to change. Metadata management is the secret ingredient that enables successful and sustained corporate performance management (CPM), governance and other business initiatives that feed on business data. The problem is that the different kinds of metadata are often confused.

Business initiatives require not only getting the data, but that the business understands what the data means, how it was transformed from creation to consumption and its associated data quality. Using the classic definition of metadata as “data about the data” then delving deeper, IT needs to understand how the metadata will be used in order to develop a successful metadata strategy.

When talking about metadata, the conversation often turns to tools, interfaces between tools and industry standards. After all, each tool that touches data – databases, data modeling, ETL (extract, transform and load), enterprise application integration, enterprise information integration and business intelligence (BI) – has metadata to enable data manipulation and storage. Historically, each tool had its own set of metadata applicable to its use of data. Metadata usage inevitably turns to exchanging data between tools using interfaces and potentially pooling all this metadata together in a repository. Metadata integration across these multiple tools has become the holy grail. But just like the holy grail, it seems to be a never-ending quest fueled by the belief that technology is going to solve all our problems.

When technology folks discuss metadata, they seek a solution. But does their perceived solution match what their business users need? Maybe not.

Think about what metadata really is to different people. “Data about data” may mean totally different things based on who needs it. This brings us to categorizing metadata into technical (the tool-specific metadata used by IT and vendors) and business metadata (what a businessperson needs to know about what data represents).

Too often, the technical community thinks that the businessperson wants to know the technical or tool-specific metadata and confuses business and technical metadata. This false assumption is sometimes validated by power business users who are not really representative of the business community.

How do you get everyone to understand the difference? Start small by examining what a number on a report represents. The technology person thinks about a data column – how it’s defined in a database, represented in a data model, mapped and transformed in the ETL tool and defined in the BI report. All of this, however, is very much related to how the tools store and process the data. The primary challenge is gathering and integrating the metadata across tools.

The businessperson thinks about where the data came from, its associated data quality level, how it was filtered from its source and what types of business rules and algorithms were applied to it. What’s surprising is that most of this metadata is either not stored in the tools or needs some serious translation from technical terms to business language. The problems start because much of the business metadata is contained in the business requirements used to build the DW and design the business reports. However, once IT implements the IT solution, what’s left of the business metadata is its technical interpretation stored in the tools. The business language has then been lost in translation! The principal challenge for business metadata is to recapture what’s been lost and translate the tool metadata. The most significant hurdle to getting to that challenge is even recognizing that there is a challenge.

By understanding the difference between technical and business metadata, business and IT can start using metadata to increase the success of their critical business initiatives.