metadataforums.com (a bimethods initiative)
Home Home | Terms Of Us Terms of Use | Contact Us Contact Us | Site Map Site Map | bimethods bimethods

The Power of Meta-Data

Data within your database is just that, data. It becomes information only when you can effectively extract and distribute in an understandable form. Using meta-data has come a long way; it allows for free-flowing information and is putting the ability to extract information into the hands of end-users.

When I first started my career in data processing, I began as a COBOL programmer. Back then, meta-data was strictly “data about data” and, in those days, we had to rely on s FDs, copy books, and a scarce set of documentation that comprised our meta-data. Such resources told us where data was located and what particular objects (tables) and columns meant.

Today, meta-data has grown into a complete subject area encompassing such terms as Knowledge Management, Corporate Data Dictionaries, and Enterprise Meta-Data Repositories. All of these classifications have the single goal to categorize the underlying information buried within databases so that end users can get to information faster. They do this by employing tools that allow end users to unlock the mysteries of what information is available and where it is located.

Imagine that you are cornered in the break room by the CEO or called into a sales meeting and asked to produce a report that describes demographic information for current customers. This task seems to be quick and easy, at least at face value. But, you quickly remember that you have distributed databases that control different product lines, and the way objects have been defined within those databases are quite different. To compound the issue, your CEO is starting to describe “customers” as anyone who has purchased products or services from you including potential customers that are not stored in a database yet but are in multiple spreadsheets maintained by your sales reps. No doubt, it is becoming obvious that these requirements will be changing and you begin to feel like you will be trying to hit a moving target.

Almost every corporation and government agency has already built, is in the process of building, or is looking to build a Managed Meta Data Environment (MME). Many organizations, however, are making fundamental mistakes. An enterprise may build many meta data repositories, or “islands of meta data” that are not linked together, and as a result do not provide as much value (see “Where’s my meta data architecture?” sidebar).

Let’s take a quick meta data management quiz. What is the most common form of meta data architecture? It is likely that most of you will answer, “centralized”; but the real answer is “bad architecture”. Most meta data repository architectures are built the same way data warehouse architectures were built: badly. The data warehouse architecture issue resulted in many global 2000 companies rebuilding their data warehousing applications, sometimes from the ground up. Many of the meta data repositories being built or already in use need to be completely rebuilt.

The term "metadata" has been used for many years now. It dates back to the 60’s, 70's and 80's, when "metadata" was used to describe the COBOL, VSAM, and IMS copybooks that ran on IBM mainframe systems. In those days, Fortune 2000 companies would purchase and implement something called a "corporate data dictionary" to help them better manage their copybook definitions, generate COBOL records and DDL, etc ... Today, the corporate data dictionary has evolved into what we now call an "enterprise metadata repository" or "metadata management system". The term "metadata" was also embraced and popularized by industry groups such as DAMA, and by software vendor initiatives from IBM (AD/Cycle), Microsoft, OMG/CWM, CDIF, and others. The term "metadata" is also widely used within the geospatial, document management, and military software markets.

Developing and implementing a meta-data strategy has always been a tough proposition, as most of the senior management do not understand the importance of the subject. Let alone meta-data many IS community members don’t even understand the importance of data.

 

Meta-data in most simple terms means "structured data about data" or "data that describes something (that may or may not itself be data)". Examples of meta data include: definition of the data element, business names of the element, systems abbreviations for that element, the data type and size of the element, source location, data steward, alternate alias, alternate spelling etc. In other terms, meta-data is any information used to aid identification, description, characteristics, location of, access to, data elements and information.

Defining Meta Tags is much easier than explaining how they are used, and by which engines. The reason is very few engines clearly lay out what they do and do not look at, and how much emphasis they put on any one factor. So, we’ll start with the easy part

Meta Tags are lines of HTML code embedded into web pages that are used by search engines to store information about your site. These "tags" contain keywords, descriptions, copyright information, site titles and more. They are among the numerous things that the search engines look for, when trying to evaluate a web site.

Summary: Part 1 examined the phenomena of meta data repositories, identifying common patterns of process and technology. Part 2 defines a strategy for successfully implementing an IT knowledge management program based on meta data repository concepts.

In Part 1 of this article, we explored the concepts of detail and diversity in meta data. We noted that meta data projects tend to cluster into three distinct groups based on their mix of meta data detail and diversity. These three use cases can be described as "control," "inform" and "plan."

The "control" use case typically involves an individual IT technical service provider group (e.g., DBA, security, network, systems management) working within its domain. Existing system management tools are leveraged as collectors of meta data for better control, reporting and analysis of the environment being managed. Data is captured at the most detail level possible; however, including only that meta data directly controlled by the technical domain (i.e., low diversity). Virtually every technical service department in your organization has a homegrown database to track and manage IT assets, yet none of them are integrated or even known outside their department. These efforts are typically run as system management improvement projects and not necessarily recognized as meta data projects at all. Unfortunately, these projects also represent the source system or the system of record for all other meta data related efforts.

They say what goes around comes around and this certainly applies to the meta data information repository. Over the last 25 years, each great evolution of information systems technology and best practices has bred the same set of issues and the invariable vendor response - the meta data repository (or some derivation). What is this problem that keeps recurring? Simply put, as newer technologies are used to develop systems, the increase in complexity breaks the system management status quo. The answer always involves storing information about the system components in a central place for analysis - i.e., the meta data repository. It hasn't always been called this, but nonetheless, the basic approach to solving IT management complexity is the same. We are now witnessing this event playing out once more, but I'm getting ahead of the story.

The prefix “meta” comes from the Greek and can indicate change, as in metamorphosis; or it can mean beyond or after, as in metaphysics. In information technology usage, the word meta-data has come to be used as a definition or description of data: a small indicator that encompasses and points to a larger piece of information. The library card catalog is the standard metaphor for meta-data: each card represented and led the user to a much larger body of information, the book or other item cataloged.