&nbs= p;

Whitepaper:
Best Practices for Assembling Aligned Taxonomies

Abstract:<= br> What do you do if one group in your enterprise calls an apple an apple, another calls it fruit, and a third refers to it as produce? You need to create a collection= of their specialized taxonomies -- their vocabulary sets and classification schemes. The price of failure can be great, since bad integration of data c= an be worse than no integration. Companies attempting enterprise integration should provide their knowledge workers with an Enterp= rise Meta Data Toolkit. Assembling this toolk= it involves acquiring universal taxonomies if applicable, and collecting others from functional groups across the organization.

Currently much has been written and said about moving toward an integrated enterprise. It is common wisdom that IT must support m= ore effective integration and must be more flexible to meet the needs of the business.

This is not easy. Especially when you consider that sometimes IT and Business seem to be speaking entirely different languages. Even different groups within business units can use entirely different vocabularies to describe the same or similar ideas. A requirements analyst = who is not fluent in a specialized vocabulary can spend as much time level sett= ing on concepts as gathering requirements. And without a single source of the t= ruth to validate the completeness and accuracy of those requirements, the analyst and other project members must trust that requirements reflect the true des= ires of stakeholders.

What do you do if one group calls an apple an apple, another calls it fruit, and a third refers to it as= produce? This may not present a pr= oblem for many members of those groups. But some resources, such as data architec= ts and those sourcing executive reports, must match apples to apples.

The Price of Failure

If those who need to connect concepts, data, or proc= esses with absolute precision are not able to do so, the enterprise can expect problems.

Ø Good data can turn into bad data.
Apple data can be moved into produce fields, or vice versa, pol= luting the target repository.

Ø Poor decisions can be made.
Suppose an executive decides to invest heavily in apples, based on their phenomenal success for the company. What= if it turns out the numbers that influenced that decision were not an accurate roll-up of apple activities, but instead actually refer to totals for apples, premium Italian olives, and ora= nges?

Many companies have learned the hard way that bad integration is worse than no integration.

Ø The company can fail in compliance efforts.<= br> The Sarbanes-Oxley Act of 2002 requires pubic company CEOs and CFOs to personally sign off on corporate financials. They must also report events t= hat will materially affect the company’s financial health. What if a disa= ster wiped out the company’s supply of oranges? “No problem!” the executives may conclude, looking at their erroneous reports. “Our strong showing in apples will more than make up for it!” They may not uncov= er the data problem until apples b= egin to inexplicably decline. By the time the data problem is uncovered and address= ed, the company will have lost time to recover and may have committed a complia= nce violation.

Avoiding Integration Disasters

The solution seems obvious: Before you integrate sys= tems and automate the movement of data from one system to another, be very certa= in you’re comparing apples t= o apples. Make sure you’re rol= ling apples up into fruit, but you’re not dumping all of produce down into buckets of apples.

Isn’t this the job of those building your requirements and system designs? Yes! But if these individuals are working without the right tools and information sources, they can’t be expect= ed to be totally successful.

What tools might they be lacking? To minimize risk in enterprise integration projects, they should have access to a collection of= the classification schemes used across the enterprise to organize business conc= epts and objects. These schemas are called taxonomies.

The words used in taxonomies to name and describe co= ncepts and objects should come from controlled language sets. These sets probably = vary from group to group, serving the needs of different functions. The enterpri= se should collect these so that all requirements analysts know that “local” vocabularies are in use and can adjust their analysis accordingly.

An Enterprise M= eta Data Toolkit

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.&n= bsp; 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 controlled language sets together, taking an apples-to-apples approach to matching synonyms, related terms, = and usage or translation rules

· A collection of the taxonomies used by specialized groups.

2.&n= bsp; 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.

Purchasing Taxonomies

Pre-packaged taxonomies are sometimes available for = free or for a fee. If you’re working in a highly regulated environment, you’ll need to use approved language. Industry-specific taxonomies wi= ll never serve all your needs, however. You’ll need to supplement them w= ith taxonomies gathered from your organization that represent how your knowledge workers conceptualize and describe concepts and objects within your unique environment.

Unearthing Specialized Taxonomies in Your Organization

Although they might not use the term taxonomy, funct= ional groups across your enterprise use specialized vocabularies and classificati= on schemes. Gather them from:

Ø Product Development

Ø Marketing

Ø Sales

Ø Customer Support

Ø Training

Ø Documentation

Ø Operations

Ø Business Intelligence

Ø IT

Ø Web Teams.

Budgeting for Internal Taxonomy Integration Efforts

It can be difficult to sell a wholesale taxonomy effor= t. Instead, consider a budgeting approach that allots resource time to the department or division level or to a shared services bucket. Use this bucket to address s= tandards, infrastructure, thesauri, and training materials. Provide guidance to decentralized groups so they can align to enterprise standards as they cont= inue with ongoing content creation and selection, specialized taxonomies, traini= ng, and application development.

Update project and support workflows to give additional emphasis to improving the quality of content. Lay out clear expectations for stewardship of content and documents - more meaningful titles, better structured documents, accurate metadata, and links to contact information.<= /p>

Implement centralized governance but decentralized stewardship for taxonomies and m= eta data.

Implement centralized governance but decentralized stewardship. Editors and subject matter experts can serve as stewards, sele= cting the highest quality and most relevant articles for external audiences (i.e. readers outside the department) to minimize the total number of documents available.

Note: Remind them to include "informal" communication formats such as e-mail, interviews, and discussion groups .

Reusing Meta Data, Vocabularies, and Schemas

Reuse = - but carefully. Remember that strategies for scoping, defining, and storing specialized business taxonomies have evolved to serve the needs of the specialized group - not the enterprise.

For instance, fields and values in a general purpose relational database will include meta data that would fit in a taxonomy. So will parameters in a proprietary application program and document propertie= s in published reports, manuals, or presentations.

Also, every collection will reflect the needs and bias= es of those who created it. Library catalogers and indexers tend to focus on cont= ent when developing taxonomies. Why? That's what they’re concerned with. Database designers model a business processes. Journalists, trainers, and documentation specialists tend to focus on user needs and interests. In all cases and types of source collections, important taxonomic data can be miss= ing or incorrect. Validate information as it is migrated into a centralized repository.

Loose vs. Tight Integration

Any type of Integration can be "tight" or "loose." If computer programs are the primary taxonomy users, the integration must be "tight" (technically compatible, no ambiguiti= es). Tightly integrated taxonomies can reduce transaction and reporting costs. However, as with any tightly coupled system, they can be expensive to maint= ain.

If human beings are the primary users of taxonomies, c= ollections can be designed to optimize for human comprehension. Integration can be "loose," more of an alignment than an integration. Links can point to a variety of res= ource types (including people). Knowledge discovery can be prioritized over techn= ical compatibility. A higher level of ambiguity can be tolerated. Think of web directories and online publications, which include links to authors, related articles, resource centers, cited sources, etc.

If you’re aligning structured meta data and unstructured meta data, you probably won’t attempt a tightly-coupled approach. Instead, 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 ne= ed to change their work styles, and the integrated taxonomy can manage artifac= ts generated from structured work products.