META DATA IS THE ANSWER; NOW WHAT WAS THE QUESTION? PART II
by Robert S. Seiner -- Spectrum Technology Group

3. Is meta data a component of data quality initiatives and data quality improvement?

There are several reasons why companies initiate data quality efforts. The driving reason may be poor quality data discovered during the integration of several legacy systems into packaged solutions such as SAP, PeopleSoft, or Oracle Financials. Another reason may include the same discovery during the development of a decision support environment. One more reason may include known and documented faults in operational data that are causing business problems such as delayed and/or rejected transactions. These are all legitimate reasons for focused efforts on improving data quality.

Companies that initiate (or have on-going) data quality efforts spend a large amount of resources investigating data make-up and definition, documenting data accountabilities and responsibilities (stewardship), and mapping data across the corporation. This information can be found in meta data.

If the meta data that is used for the corporate data quality efforts is available, the company has a tremendous competitive advantage over similar efforts at companies that do not manage and make available meta data. If the meta data necessary for the data quality effort is not available, companies should consider taking advantage of the research and documentation created during the data quality initiatives by capturing and maintaining meta data in a centralized data asset catalog (repository) to support future IT & data quality programs.

4. How do you control or reduce data redundancy without using meta data?

It is very difficult to manage something if you know little or nothing about its existence. This observation holds true about data and the prevention of duplicate or redundant data. In many companies, the data administrator or the data modeler is the first line of defense when defining new data. Often, how well these individuals define and reuse data is a result of the information on hand about existing data.

As an example, the "best practices" approach to data modeling includes sharing entities and attributes from an enterprise data model across multiple project (or subject area) data models. In the absence of an enterprise model (or some form of reusable data model entities), the same data becomes defined repeatedly by different individuals in the organization. Data modeling by itself, on a project by project basis, does not provide the ability to share data unless there is access to the meta data (data about data models) that already exist.

If the intent is to share data across the enterprise, each application development area needs to know what data structures already exists before it can define the requirements for what does not yet exist. The data documentation that provides this ability to see what exists, and to share and re-use data, is meta data.

5. Is there a relationship between data modeling and meta data?

The information that is manually entered into the CASE (data modeling) tools is meta data (or data about the logical or physical components of the data). Therefore, if data modeling is a part of your IT processes and data modeling information is important to your organization, meta data is important as well.

When the data modeler creates an entity relation diagram (ERD), they define the way that data is represented logically and physically in your company. The modeler creates data entities and their attributes, the relationships between the data entities, the logical and physical names for the data, domains, and more ... that represent how data is defined for that enterprise, project, or subject area. All of this information is meta data.

The first question in this article mentioned the use of meta data beyond the IT tools themselves. In this case, the modeling meta data remains in the CASE tool where no one other than the modelers can view it. The business names and definitions that originate as meta data in the CASE tool should be shared with knowledge workers and application developers that are interested in how the data of the organization is defined and related.

6. Is meta data helpful when forcing compliance to IT standards?

Forcing compliance to IT standards is typically an on-going battle. Some companies are successful and some companies are less than successful. Often the success or failure of following standards is a result of the corporation's environment (use of packages, merging companies and IT functions, centralization of IT service functions, etc.). Other times, the success or failure is based on the company's ability or willingness to force individuals to comply to the rules of IT development.

Most IT standards are based on meta data. Component naming, storage location, and component interaction, are a few examples of meta data that can play a significant role in IT standards.

Naming standards, for example, define specific ways in which components are named. Examples of standards for naming include embedded component types (identifying JCL, program, table, etc.), embedded owning applications or contexts (through prefixes/application coding), or the identification of the platform and tier on which the component is based (personal, departmental, organizational, etc.). Many common standards are created and controlled by meta data (ex. component A can not move to production because it does not have an appropriate application code in positions 2 and 3 of the name and it does not start with the letter "P" for production).

Meta data (stored in a repository) can be used to identify components that do not follow naming standards. Meta data can be used to identify how many versions of each component exist and where they exist. In an ideal environment, standards based on meta data could be built into the change management environment making it impossible to process components that do not follow standards. Since many IT standards are based on meta data, the ability to track and report on that meta data is very helpful when forcing compliance to IT standards.
---
The concluding portion of this article will appear in the next edition of D S * .
---
For more information, see http://www.spectrumtech.com