Whitepaper:
Using Metadata And Taxonomies To Enable Enterprise Integration

Abstract:<= br> To manage the risk inherent in enterprise integration efforts, the enterpri= se needs to be able to name and describe enterprise data. This requires a meta data strategy and approach. In determining the appropriate approach to mana= ging structured and unstructured meta data, IT should look to successful approac= hes to integrating structured and unstructured data. The organization should consider a Meta Data Tool Kit that inclu= des a collection of taxonomies - the classification schemes used for concep= ts and objects and the terms employed in those schemes. These taxonomies help knowledge workers from different functional groups, with different backgrou= nds and skills, to work from a single source of the truth.

To manage, manipulate, and integrate data, we need t= o name it and describe it. These names and descriptions are meta data - literally “data about data.”

Any knowledge worker across the enterprise who works= with data - whether it is structured data or unstructured data/content = 211; is used to working with meta data. This is true even if these knowledge wor= kers don’t use the term meta data. It is true whether the meta data is sto= red separate from the data or instead buried inside document properties. It is true even if the knowledge w= orkers don’t consciously distinguish between the data they use and how they = name it and describe it.

Because metadata is used by many groups across the organization, typically an enterprise has many approaches to meta data. For example:

Whether they realize it or not, all knowledge workers across the ente= rprise who work with data - whether it is structured data or unstructured data/content - are also used to working with meta data.

Ø Data architects will use the term meta data = to describe data elements: field names, lengths, data types, etc. stored in ca= se tools. They will also use the term meta data to describe names and descript= ors for systems and applications. This type of meta data may be stored in system configuration tools, asset management systems, meta data repositories, or o= ther repositories.

Ø Technical communicators who write system documentation will also name and describe the data managed by the systems. = They’ll capture this information in indexes, glossaries, section headings, and other document elements. They’ll often employ multiple sets of vocabularies= to describe the same objects and concepts - for example, a language set appropriate for system administrators and developers, and a less technical vocabulary for end users.

Ø Customer service representatives will support the same systems architected by the data group and documented by the writer= s. Meta data used by customer service will appear in keywords, FAQs, and topic trees.

Ø Marketing groups describe systems in marketi= ng collateral. The words they choose when naming and describing systems will probably be less technical than those preferred by development groups.

Ø Web authors use meta data to optimize websit= es for search engines. They help users find and navigate through information by using the same meta data as words in page titles, headings, and other page elements.

Ø Meta data - in different flavors and used for different purposes - can al= so be found in Training departments, project offices, and many other enterprise functions.

The Challenge

Collecting and managing meta data across the enterpr= ise can be challenging.

1. = The meta data is spread out across the enterprise.

2. = Not everyone who uses meta data is accustomed to considering it as data separate from the data itself.

3. = Meta data is sometimes captured as structured, and sometimes as unstructured meta data.

4. = Different groups across the enterprise often use different terms to describe the same= or similar concepts and objects.

5. = Different groups organize and classify those concepts and objects differently, accord= ing to their needs.

Meeting the Challenges of Meta Data Integration

Challenge #1.
The meta data is spread out across the enterprise.

The soluti= on: Spread out.
Gather meta data from across the enterprise. This process should be iterati= ve - don’t try to be comprehensive during your first attempt. Start with a few groups and a few subject areas.

Challenge #2.
Not everyone who uses meta = data is accustomed to considering it as data separate from the data itself.

The soluti= on: Knowledge-sharing.
Education helps. Equally important is providing those who are gathering meta data with a detailed list of the places they’re likely to find i= t, and the forms it will take in those places.

Challenge #3.
Meta= data is sometimes captured as structu= red, and sometimes as unstructured meta data.

Consider this question: “How do you tightly couple structured data and unstructured content?” The answer is… “You don’t!”

The soluti= on: Build on successful models.
We don’t try to tightly couple structured and unstructured data. Instead, we create another layer to sit either on top of or between the two. That way, those who work with the original data/content don’t need to change their work styles or

sInstead, you create another layer to sit either on= top of or between the two. That way, those who work with the original data/cont= ent don’t need to change their work styles or standards. Instead, they accommodate extra steps that make their data available to a system that organizes it, aligns it with other data/content, and takes advantage of a presentation layer that can be accesses by all who need it.

The key to addressing the challenge of aligning structured and unstructured meta data is to remember that meta data is “data about data.” Base your meta data strategy on a data management approach that has been successful in your organization. For example, are your knowledge workers comfortable with portals, knowledge bases, or content management? If so, consider giving them access to the meta data embedded in case tools and other specialized applications by exporting models, diagrams, and tables in= to images and documents. These artifacts can then receive their own document m= eta data and can be managed using familiar approaches used for other unstructur= ed data.

Challenge #4.
Different groups across the enterprise often use different terms to describe the same or similar concep= ts and objects

The existence of different vocabulary sets can be a= critical problem. If unaddressed, it can lead to miscommunications and mishaps. A be= st case scenario is that every cross-functional effort will encounter addition= al risk that requires extra time, attention, and effort just to level set and validate terminology and expectations. In worse case scenarios, this level setting is not completely successful, and projects and products experience disconnects, delays, and even unacceptable results.

The soluti= on: Build a thesaurus.
In such cases, the obvious solution is also the best practice. Create a master thesaurus for the compa= ny. Start small, by picking a few subject areas and groups. Collect terms and t= heir variations. Note which groups favor which term from a synonym list, and why. Make this thesaurus available to the enterprise, and enlarge it iteratively= .

Challenge #5.
Different groups organize a= nd classify those concepts and objects differently, according to their needs.<= o:p>

Classification schemes for concepts and objects are called Taxonomies. It is both natural and best practice that different grou= ps classify and organize concepts and objects differently. It is also natural = that each group choose their own preferred terms to include in their specialized taxonomies.

The soluti= on: Collect Taxonomies.
Specialized taxonomies should be collected from around the enterprise. Why? They provide valuable insight into how their users think.

Taxonomies and controlled language sets do not have= to be physically merged to be useful. Even if they exist as simple word lists and concepts arranged in lists, outlines, or tree formats, they can provide valuable insight to project teams. They can help avoid costly disconnects, oversights, and errors.

The Meta Data Tool Kit

To integrate data across an enterprise, you need to = name it and describe it using meta data. To avoid inconsistencies, cross-functio= nal teams should have access to a Meta Data Tool Kit containing:

1. = A Taxonomy Collection, including:

· A list of groups across the enterprise that = use meta data and the places (documents, files, reports) that typically house t= he meta data used by these groups

· A collection of the preferred terms used by = each group

· An enterprise thesaurus that brings these co= ntrolled language sets together

· A collection of the taxonomies used by specialized groups.

2. = A strategy and approach for working with both structured and unstructured meta data. This includes mechanisms for:

· collecting individual contributions (artifac= ts) for the repository

· categorizing, tagging, and managing these artifacts

· displaying the collection to knowledge worke= rs

= ;

A Meta Data Tool Kit can help knowledge workers realize the gains that come from working = from a single source of the truth for enterprise data and meta data.