XX

Where Business Concepts, Enter= prise Integration, and Technology Converge - A Taxonomy Framework

Abstract:
The success of Enterprise Integration projects relies upon a clear understanding of terms and their relationships. Taxonomies are classification schemes for things: concepts, objects, actions, and events. They are built using controlled vocabulary se= ts. The result is a single source of the truth and an unambiguous starting point for communications between groups or individuals who typically use different terms to describe the same or similar things. Most business architectures require multiple taxonomies. Initial iterations should start small, leverage existing efforts, and be built manually. Once they become large enough, taxonomies benefit from specialized tools to mine documents for taxonomy te= rms and to classify documents according to their content.

In an enterprise that is organized, managed, and ana= lyzed through functions, projects, efforts, and timelines, it is easy to forget essential truths that apply to every person in every position across the enterprise. Several of these essential truths concern how we think, speak, organize information, and search for information.

Names for things

Ø If we don’t have a name for an object, concept, action, or event, it’s very difficult for us to manage it.

Ø If our name for a thing doesn’t match = the name used by someone else for that thing, we’re at risk for not takin= g others’ things into consideration when dealing with our things.

Ø Because we use our own names for things more often than others’, we’re more likely to forget theirs, rank th= em a lower priority, or consider them unrelated to what we’re doing.

Ø If we know that multiple names for things ex= ist, and if it’s easy to see what those names are, and if we believe it’s important to do so, we’re more likely to take the other person’s thing into consideration when dealing with our thing.

Organizing things<= /b>

Ø       Everyone has an internal classification sche= me for their things that - in the absence of other instructions - = they will use to think about and analyze their things.

Ø       If our classification scheme doesn’t m= atch someone else’s, we’re at risk for not taking their schemes into consideration.

Ø       Because we use our own organizational schemes more often than others’, we’re more likely to forget that theirs exist, forget that theirs may be more important in certain situations than = our, rank theirs as less applicable to any given situation, or consider them unrelated to what we’re doing.

Ø       If we know that multiple schemes exist, and = if it’s easy to see them, and if we believe its important to do so, we&#= 8217;re more likely to take the other person’s scheme into consideration when working with ours.

Where Business Concepts and Technology Converge

Because of the above truths, the natural state of an enterprise is to have significant disconnects. And so, an enterprise must m= ake a concerted effort to align the way its people speak about, organize, search for, and analyze information. The enterprise must support individuals’ and groups’ abilities to adopt work styles, practices, terms, and organization schemes that will make them the most successful at accomplishi= ng their particular strategic and tactical objectives. However, the enterprise must also provide a mechanism for translating, aligning, and prioritizing disconnected information when it is important to speak about, organize, sea= rch for, or analyze information from an enterprise perspective.

This becomes especially important when an organizati= on moves a function - such as organizing a set of documents - from= a manual process to an automated process.

A human is capable of having an Aha! moment, in wh= ich they make a connection and perform a course correction in the execution of their task to extend their results to account for the connection. Indeed, t= his ability to have frequent and valuable - but typically unheralded R= 11; Aha! moments is part of the value brough= t to organizations by their best Technical Writers, Customer Service Reps, QA Analysts, and Trainers.

What happens when information organization or retrie= val is automated? SQL queries don’t have Aha! moments. They execute the same way every time. And if an information retrie= val mechanism is set up to deliver only that information that fits a specific s= et of criteria - without considering synonyms, preferred terms, informat= ion hierarchies, and other options considered by every human being as they ment= ally formulate or refine a search - then the automated function may be mor= e of a disservice than a service to its users.

Even worse, most automated technology hides the step= s it employs from the user. This deprives the user of a mechanism for evaluating= the results against the process and to determine whether unexpected results are= the result of missing content or an inadequate process. This lack of transparen= cy can lead to lack of user confidence in the technology and therefore a refus= al to use the technology.

Inadequate information retrieval technology choices = or implementations can, therefore, result in user rejection of a valuable and = expensive set of content.

Enter Enterprise Integration

Enterprise Integration projects are typically though= t of in terms of technology and implementation challenges. They are often architected and implemented by individuals highly skilled and experienced in overcoming technology hurdles. They may be managed by individuals highly skilled and experienced in boundary-spanning project management.

Enterprise Integration projects find themselves operating at Ground Zero for concept= ual wars.

Unless the EI team is provided a mechanism for reconciling conflicting terms, concepts, organizational schemes, and priorities, they are limited in the level of value they can provide to various stakeholder groups across the enterprise.

If an enterprise Taxonomy Clearinghouse does not exist that can be tapped to resolve these issues, the EI project should include resources that can concentrate on conceptual issues throughout the life of the project.

However, training for these positions typically does= not include an emphasis on words: how people think, how they articulate their thoughts, the differences between different modes of spoken and written communication, the way the brain deals with terms that express similar or related concepts. These conce= pts, on the other hand, are core to the work performed by “word” peo= ple who work with individual content units - writers, editors, indexers, trainers, search engine optimizers.

Another skill needed by Enterprise Integrators is the ability to think about language sets as systems. Training for technical Ent= erprise Integration positions does generally include system thinking and working wi= th patterns. However, these systems and patterns are more likely to revolve ar= ound code and technical architectures than language. The way chunks of content a= re organized, maintained, and cross-referenced differs in significant ways, and requires input from those who work with content sets from a conceptual viewpoint: information architects, documentation managers, indexers, librarians, knowledge base designers, knowledge managers, and meta data managers.

The Role of Taxonomies

Taxonomy
(from Greek taxis meaning arrangement or division and nom= os meaning law) is the science of classification according to a pre-determined system, with the resulting catalog used to provide a conceptual framework f= or discussion, analysis, or information retrieval. In theory, the development = of a good taxonomy takes into account the importance of separating elements of a group (taxon) into subgroups (taxa) that are mutually exclusive, unambiguou= s, and taken together, include all possibilities. In practice, a good taxonomy should be simple, easy to remember, and easy to use.

Taxonomy definition from whatis.com

Understanding Taxonomies

Taxonomies are classification schemes for things: concepts, objects, actions, and events. They are often hierarchical, but th= ey don’t need to be. Successful taxonomies work with controlled vocabula= ry sets. The result is a single source of the truth and an unambiguous starting point for communications between groups or individuals who typically use different terms to describe the same or similar things.

A good taxonomy can also improve decision-making. It= can frame the way people make decisions, and also help them find the informatio= n they need to weigh all the alternatives. With a= good taxonomy, decision makers enjoy a new perspective, "drill down" to get details from each, and explore lateral relationships among them.

Imagine this scenario described from several perspec= tives.

Patient perspective

Physician perspective

IT System perspective

A person is sick. The person makes an appointment, sees a doctor, gets some medicine, and pays a co-pay.=

A patient calls the appointment line and is scheduled for an appointment.<= /u> Upon arrival, front office sta= ff check in the patient, = and the responsible party guarantees payment for a = standard visit and makes a co-p= ay, using a check. A nurse works up the patient, and the physician examines the patient, makes a diagnosis, and writes a prescription. Back office staff for the= practice process the visit, add the check to the night’= s deposit, and submit an insurance claim.

An appointment is entered= into the Appointment System= . A diagnosis is entered into= the patient record and the insurance claim. A prescription is entered i= nto the patient record and= the insurance claim and is la= ter extracted for prescription rep= orts. An insurance claim is = filed in the insurance system, and a co-payment and amount due are entered in= to the general ledger system.= A co-payment is added into = the nightly deposit record= .

<= /p>
How might this info= rmation be classified according to each perspective?

Patient perspective

Physician perspective

IT System perspective

Person

  &nb= sp; Roles

  &nb= sp;        Patient

  &nb= sp;        Responsible Party

  &nb= sp;        Insurance policy holder

  &nb= sp; Health

  &nb= sp;        Well=

  &nb= sp;        Injured

  &nb= sp;        Sick=

  &nb= sp;            =     Severity of illness

  &nb= sp;            =            Slight<= o:p>

  &nb= sp;            =            Moderat= e

  &nb= sp;            =            Severe<= o:p>

  &nb= sp;            =     Responses

  &nb= sp;            =            Ignore<= o:p>

  &nb= sp;            =            Self-tr= eat

  &nb= sp;            =            Visit doctor

  &nb= sp;            =            Visit hospital

  &nb= sp;            =            Call ambulance

=

Office procedures

  &nb= sp; Front office

  &nb= sp;        Appointment=

  &nb= sp;            =     Schedule

  &nb= sp;            =     Check-in
       = ;            = Update phone #

  &nb= sp;            =     Receive payment
       = ;            = guarantee

  &nb= sp;            =     Log in co-pay

  &nb= sp; Medical

  &nb= sp;        Nurse

  &nb= sp;            =     Work up patient

  &nb= sp;            =     Assist physician

  &nb= sp;        Physician

  &nb= sp;            =     Diagnose

  &nb= sp;            =     Prescribe

  &nb= sp; Back office

  &nb= sp;        Process co-pay

  &nb= sp;        Update patient rec.

  &nb= sp;        Update general ledger

  &nb= sp;        Process nightly

  &nb= sp;          deposit

<= o:p>

IT Applications=      Appointment system

  &nb= sp;        Create module

  &nb= sp;        Check-in module

  &nb= sp; Patient system

  &nb= sp;        Contact module

  &nb= sp;        Responsible party
       = ;    module

  &nb= sp;        Insurance module

  &nb= sp; General ledger system

  &nb= sp;        Receivables module

  &nb= sp;            =     Co-payments
       = ;            =    function=

  &nb= sp;            =     Insurance payments

  &nb= sp;            =        function=

  &nb= sp;        Deposits module

To successfully build, integrate, or support the IT systems in this example, IT must clearly understand the data that the syste= ms will process as well as the business processes they will support. For examp= le:

·= ;      =    The data architect must unequivocally unders= tand the difference between patient, responsible party, and insurance policy holder. Th= ese are all types of people, but it would be poor practice to assign the name person to all the data fiel= ds that store this data. Such a practice would inevitably lead to confusion, mistakes in data sourcing, and mistakes in data integration.

·= ;      =    It would be poor interface design to use the label person for each of= these fields when they appear within applications. Such a practice would probably lead to confusion and data entry mistakes, with errors being propagated thr= ough data records.

·= ;      =    It would be poor form design to use the labe= l person for each of these fields when they = appear on patient forms. Such a practice would lead to poor productivity, since fr= ont office staff would need to perform quality checks on forms and correct erra= nt data. It would also lead to degraded customer satisfaction, since a signifi= cant percentage of patients could be expected to experience frustration.

Aligning Multiple Taxonomies

In the example above, communication between patients= and their physicians does not require patients to adopt system terminology or t= o be burdened with categories of information that do not concern them but do con= cern the physicians’ staff. It is good practice to present information to different user groups using the terminology that they are familiar with. Mo= st business architectures require multiple taxonomies.

However, employing multiple taxonomies within an enterprise requires that data and application architecture groups must accommodate these taxonomies. Processes must enforce mapping of local or specialized taxonomies to each o= ther and to the appropriate terms in a master thesaurus, or controlled vocabular= y list.

Benefits Of Aligned Taxonomies

Once classification schemes and controlled vocabular= y lists are in place, IT and the busi= ness should realize the following benefits:

·         Less ambiguous communications

·         Increased ability to map data to business entities

·         Increased ability to conceptualize business processes

·         Greater alignment between process naming and data naming standards

·         Easier migration to Services Oriented Architecture

·         More consistent Business Process Mapping

·         Easier migration to Rational Unified Process=

·         Higher data quality

·         Users can more easily and more quickly find information they need

·         Supports inventory and monitoring efforts to knowledge resources.

Deciding Scope for Your First Set of Aligned Taxonomies

The first iteration of your set of aligned taxonomies should have a modest scope. It should encompass limited set of data about the data, concentrating on a few types of concepts and objects as described by a few groups. The goal should be compiling a working taxonomy set in just a few weeks. After this is made available to the enterprise and is in use, it sho= uld become apparent how to best add to the taxonomy set in future iterations.
In establishing scope for iterations of the taxonomy= set, consider the following characteristics of the language sets and classificat= ion schemes you’ll be collecting:

·         Value to the business

·         Complexity

·         Knowledge required to understand underlying conceptual models

·         Size

·         Availability of documentation (glossaries, indexes, data dictionaries, etc.)

·         Tagging Approach

·         Usage

Leveraging Existing Efforts

Often, the enterprise will have already addressed taxonomies, although the efforts may not have been labeled as such. It is possible to jumpstart a taxonomy collection by identifying and leveraging t= hese efforts.

Leveraging Documentation and Training Efforts

Look for system documentation, glossaries, and back-of-the-book indexes. Ask if staff members have notes that have not been published, but help them do their jobs. Ask for XML DTDs and keyword lists. Don’t overlook training vocabulary lists.

Leveraging Meta Data Management Effo= rts

Meta data managem= ent programs generally include logical descriptions of data. It is good practice for the naming standards and documentation standards for these programs to = call for using terms from the single source of the truth. However, most knowledge workers in the data department will also use work products: term definition= s in embedded meta data, case tools, data dictionaries, etc.

Leveraging Web Site Authoring and Optimization Efforts

One key to successful web marketing is an integrated taxonomy that encompasses categories, keywords, and hierarchical structures required for multiple business functions. While it is possible to focus onl= y on the taxonomy required to navigate the site, such an approach invariably lea= ds to higher costs and lower results, as the company discovers disconnects bet= ween the terms used to index and market the site and those used to describe data that is collected, inferred, and analyzed to better understand customers and sell to them.

Ø       For instance, users need to understand the r= ight words and organizational schemes to:

·         Navigate the site
They’ll use Page titles, Headings, Navigation bars, links, Site Maps, Topic trees, Menu items, and Buttons.

·         Retrieve information once in the site
They’ll use find functions, knowledge bases, FAQ topic schemes. When = they use internal search engines, they’ll also be able to take advantage of ALT text, meta tags, and page/document metadata, if the site has been tagge= d.

·         Find the site (and content in the site)
They’ll use search engines and directories, which utilize both visible text and metatags visible only to the search engine.

Ø       If the business wants to employ suggestive selling through personalization of the site, they need to:

·         Develop category/keyword master trees

·         Develop and implement consistent personaliza= tion categories for:

·         page function

·         page content

·         relationship to marketing campaign

·         visitor information

·         Associate pages with consistent personalizat= ion keywords from the controlled vocabulary list:

·         page function

·         page content

·         sales/product

Ø       If the business wants to use the site to reinforce marketing campaigns, they need to:

·         Align language from the marketing campaign w= ith language used on the site

·         Modify page-level metatags to support tracki= ng of the campaign

Ø       If the business wants to collect information about users’ browsing habits, they need to:

·         Align language from the clickstream records = to language describing the pages visited

·         Align clickstream language with user informa= tion available from other sources:

·         Volunteered data

·         Non-volunteered data

·         Purchased data

Managing Taxonomies Strategically

Managing taxonomies strategically requires the manag= ing group to avoid certain temptations and apply best practices that are someti= mes counter-intuitive.

Ø       Temptation: =       It may be tempting to assemble a single, master taxonomy.

Ø       Best Practice: The group should collect specialized taxonomies from across the enterprise. They may find that one taxonomy is used by so many groups that = it is a defacto standard. However, this does not diminish the need for -= or the value of - other specialized taxonomies. Collected, these form the taxonomy set that will be managed.

Ø       Temptation: =       It may be tempting to think of a taxonomy as a single entity

Ø       Best Practice: Any taxonomy consists of a set of terms describing concepts and objects, the classification scheme used to organize those terms, and references to how a= nd where those terms are used. An aligned taxonomy set also includes

To get started, think globally= , but work locally. That is, consider the enterprise conceptual model, but don’t fall into analysis paralysis.

Collect specialized taxonomies, making note of how they relate to the assumptions you’ve made about enterprise needs or conceptual models. Be flexibl= e, and adjust your collection as more information becomes available and your scope increases.

an enterprise thesaurus that compiles the terms used in specialized taxonomies= .

Ø       Temptation:&= nbsp;      The group may be tempted to thoroughly investigate and document enterprise conceptual models prior to beginning to collect vocabulary sets and special= ized classification schemes.

Ø       Best Practice:   Collect and document the conceptual models and specialized controlled vocabulary se= ts from various groups, and use those to iteratively revise the aligned taxono= my set.

Ø       Temptation:&= nbsp;      It is tempting to try to create a textbook taxonomy.

Ø       Best Practice:   Remember the purpose of the taxonomies you build: the business problems they’re trying to address, the problems they’re trying to avoid or minimize, = and the habits or disciplines they’re trying to support. Value serving the needs of real users over building what looks like an ‘”ideal’” taxonomy.

Ø       Temptation:&= nbsp;      It is tempting to build a broad and deep taxonomy quickly.

Ø       Best Practice:   Adopt a scope that will allow a quick first iteration. Focus on categories of information that customers use and the places they look for information. Be sure to include layman's term= s as well as technical terms, to develop the thesaurus for cross references as y= ou go, and to include documents, people, and informal communications as source= s.

Ø       Temptation:&= nbsp;      It is tempting to set a goal of establishing a dominant, common mental model.<= /p>
Ø       Best Practice:   Again, remember to think globally but work locally. It is both natural and best practice that knowledge workers’ predominant mental models will be ba= sed on the terms and classification schemes they use frequently. An aligned tax= onomy set allows for smoother, more complete, and more consistent translation of ideas and concepts, as well as a resource to be used when thinking outside = of a default mental model.

Taxonomy Development Teams

Taxonomy development in the corporate environment is= a multi-disciplinary activity that spans boundaries and crosses organization lines. The typical = centralized taxonomy team consists of representatives from the following information specialties:

Ø       Information technology

·         Data architecture and management

·         Records/document management

·         Content management

·         Meta data management

Ø       Library or information center (whatever group organizes and indexes large information sets)

Ø       Web site management

Ø       Corporate communications

Ø       Documentation specialists: writers, editors,= and publishers.

Within this group, it is important that representati= ves from the last four categories - those whose day-to-day work deals with words, content creation, information organization, and information retrieval - maintain the prominent voiced when determining the focus, goals, and processes for the team. Technology’s role should be to support goals,= not to set them.

As this centralized group moves beyond early iterati= ons, they will naturally uncover specialized vocabulary sets and taxonomies in u= se in additional groups across the enterprise. They will need to plan to expand their efforts to seek input from - and to provide input to - ot= her functions:

Ø       Product Development, which develops new term= s as it plans for new products, services, and uses for them.

Ø       Marketing, which specifies terms used in specific marketing campaigns and also determines terms that are favored, te= rms to be avoided, terms and taxonomies used by competitors and industry analys= ts.

Ø       Sales, which uncovers terms that are success= ful in selling products and services, and also uncovers terms and taxonomies us= ed by customers to describe desired products, services, attributes, concepts, = and activities.

Ø       Customer Service, which uncovers terms used = by users who have been unsuccessful finding the information they need or who n= eed assistance beyond what has been presented to them by the organization. Cust= omer Service also uncovers terms used by customers for the problems they encount= er and the tasks they perform.

Ø       Training, which often brings a unique perspective to how different classes of users think, talk, and find information.

Ø       Search Engine Optimization specialists, who = have access to specialized tools to understand how users search for and navigate through online content. They also should be aware of how tagging, labeling,= and naming choices affect competitive ranking of web pages for major search engines.

Ø       Business Intelligence, which needs to unders= tand the relationships between related terms - and the differences between similar terms - so they can provide the right sets of information for analysis and reporting.

Ø       Data Architecture and Application Architectu= re, which need to ensure that their models encompass the enterprise’s true needs.

Ø       Governance and Compliance, which need to ens= ure that reporting and controls across the enterprise compare apples to apples,= and oranges to oranges.

Sources to Mine for Taxonomies

Controlled vocabulary sets - specialized lists= of terms and their synonyms - can be compiled from typical project documents.

Ø       Glossaries

Ø       Back-of-the-book indexes

Ø       FAQs

Ø       Knowledge base entries

Ø       Keyword lists

Ø       Pick lists

Ø       System documentation

Ø       Data dictionaries

Ø       Training materials

Ø       Meta data embedded in case tools and business intelligence applications

Ø       Library card catalogs

Ø       Bibliographies

Ø       Product lists

Ø       File systems

Ø       LAN directory structures

&nbs= p;

Taxonomy Applications

Taxonomy structures can be used in a variety of applications. These applications may be standalone or embedded in other applications. Either way, they can help:

Ø       Developers

·         web developers, as they create navigation schemes to help visitors search for information or navigate through informa= tion

·         search engine technicians, as they optimize = the site for searches and configure the search engine to look for synonyms and related terms

·         IT workers, as they build filtering tools, e= mail alerts, or other keyword-based utilities

Ø       Users

·         researchers, as they find source materials&n= bsp;

·         readers, as they locate information in a book or electronic content

·         buyers, as they locate products and services

·         decision makers, as they locate sources of expertise

Ø       Analysts

·         executive decision makers, as they review and analyze corporate data

·         compliance officers, as they review breadth = and depth of their efforts

·         functional managers, as they plan for taxonomy-related efforts.

Taxonomies and Technology

A taxonomy does not require technology.= It is, at its core, a mental model captured so that it can be shared. It is be= st practice that proofs of concept and early iterations eschew specialized technology, instead capturing information in easy, accessible document form= ats.

However, once baseline taxonomies are in place, the enterprise might to mine their content to uncover additional terms and conc= epts to fill out the taxonomy. They might also want to move taxonomy information= in the opposite direction, automatically reading content, classifying it, and assigning keywords from the approved taxonomy.

Vendors offer an array of taxonomy software and rela= ted applications to address these needs. These tools promise many benefits, especially to enterprise customers. They offer boons to content management efficiencies, portal usability, information retrieval, and knowledge discov= ery. They employ automatic categorization, tagging, keyword extraction and analy= sis, and workflow.

It’s important to remember, however, that taxo= nomy products represent emerging technologies. And they don’t eliminate the need for human input, since even the most automated systems require some ma= nual assistance from people who know how to classify content. They are not out-of-the-box solutions, and should be considered as automation tools that greatly enhance the output of humans.

Also, most technologies are expensive, with license = and implementation costs running in the hundreds of thousands of dollars. Best practice is to prove the value of taxonomies in your environment and culture before considering expensive technology investments.

Once this value is proven and carefully crafted prot= otypes have been customized to your environment and culture, then consider employi= ng auto-classification tools to rapidly increase the breadth of your taxonomy efforts. Consider, also, data visualization tools such as the Brain, which helps people visualize where information resides across the organization.

Security, Access, and Governance

Just as with any centralized repository of enterprise information, a taxonomy repository will require policies and procedures to oversee security for its contents, to ensure appropriate access only by authorized users, and to provide careful governance and stewardship to ensu= re that content is appropriate, current, and accurate.

When planning a taxonomy program, remember that sing= le sources of the truth offer great benefits, but also increased risk: It now becomes easier to make mistakes faster, more efficiently, and more consistently.

Plan for standards and oversight for areas such as:<= /p>
·         Scope of contents

·         Formats of content

·         Acceptance of material into the repository
·         Change control

·         Scheduling

·         Decision-making

·         Issue resolution

·         Monitoring / input by user groups.

When deciding what approach to take for managing this program, carefully consider standards and practices that have been successf= ul in your organization for similar repositories and knowledge bases.

Patient perspective	Physician perspective	IT System perspective
A person is sick. The person makes an appointment, sees a doctor, gets some medicine, and pays a co-pay.=	A patient calls the appointment line and is scheduled for an appointment.<= /u> Upon arrival, front office sta= ff check in the patient, = and the responsible party guarantees payment for a = standard visit and makes a co-p= ay, using a check. A nurse works up the patient, and the physician examines the patient, makes a diagnosis, and writes a prescription. Back office staff for the= practice process the visit, add the check to the night’= s deposit, and submit an insurance claim.	An appointment is entered= into the Appointment System= . A diagnosis is entered into= the patient record and the insurance claim. A prescription is entered i= nto the patient record and= the insurance claim and is la= ter extracted for prescription rep= orts. An insurance claim is = filed in the insurance system, and a co-payment* and amount due are entered in= to the general ledger system.= A co-payment is added into = the nightly deposit record= .*