Understand what Governance Is We start with a definition of governance, its constituent parts, and their purpose Identify Core Taxonomy Governance Processes There are certain functions that any governance effort must perform . We show how these apply to taxonomy governance, and why Identify Standard Processes and Tools Business and supporting IT organizations already perform tasks that are in many ways similar to those needed for successful taxonomy governance. To minimize new investment in tools and training, it makes sense to use these where possible Tricks of the Trade We’ll show some of the detailed considerations that are important when setting up a taxonomy governance effort, and how we’ve handled them Context We’ll discuss how taxonomy governance fits in the broader operational context of an organization: specifically, how it connects with an IT organization and with business stakeholders

1. Taxonomy Governance
Through Metrics, Existing Tools & Process
November 09, 2007 @ 10:00am
Taxonomy Bootcamp, 2007
Alex Barnes
Tom Witczak

2. Session Objectives
• Understand what Governance Is
• Understand its Context
• Identify Core Taxonomy Governance Processes
• Identify Standard Processes and Tools
• Tips and Tricks for Governance
2
©2007 Hitachi Consulting. All Rights Reserved.

3. Taxonomy Feedback Loop
Executive Sponsors form Strategy and Objectives that
are driven by metrics and business objectives
Feedback and Requests for Change are captured through
periodic review, usability testing and feedback
Front End:
Applications
Published
Updates
Versions
Taxonomy Model
Taxonomy Back End: Taxonomy Taxonomy
Management Control and Publishing Users
Taxonomy Change Control
Execution is driven by approved change requests
3
©2007 Hitachi Consulting. All Rights Reserved.

4. Definitions
Governance is the management of
a system, usually political or
Organizational
organizational, involving mutual Structure
adjustment, negotiation, and
accommodation between the parties
Taxonomy
involved rather than direct control.
— Webster’s
Practices,
Standards & Processes &
Measures Procedures
Taxonomy Governance defines: Tools and Solutions
• Organizational Structure
• Processes and Procedures
• Practices, Standards and Goals are to define a repeatable,
Measures visible, accountable, process for
submission, review, approval and
dissemination of taxonomy
changes.
4
©2007 Hitachi Consulting. All Rights Reserved.

5. Components
Processes and Procedures
• Steps taken when performing taxonomy
governance tasks Processes
& Procedures
• “How-to” view of taxonomy governance
Organizational Structure
• Structure, membership, accountabilities,
organizations involved
• Who in the organization is responsible for each Organizational
Structure
aspect of taxonomy governance and how
delegations and escalations are carried out
Practices, Standards & Measures
• What will be done
Practices,
• How it will be controlled and monitored Standards &
Measures
Tools and Solutions
• What existing tools or solutions can be used
Tools and Solutions
• How can they be integrated and leveraged
5
©2007 Hitachi Consulting. All Rights Reserved.

6. Core Operational Processes
Request and Track Taxonomy
Changes
Request Fix & Commun-
• Change request and status visibility & Track
Assess
Control
Validate
icate
• Track changes thorough various
lifecycle stages, start to finish
Assess the Impact of Change observed defect observed fix
• Assess the validity of change requests
• Impact of the requested change on Validate Taxonomy Change
taxonomy, consuming systems and
processes • Continually validate with end users for
consistency and usability.
• Effort required to implement a change
• Can be analysis, scripted tests with
Fix and Control the Taxonomy automated tools, or contextual inquiry with
Baseline representative user populations.
• Consuming systems should know • Must identify the appropriate validation
content of the taxonomy, its ownership, method and coordinate verification efforts
change history, and any relationships Communicate Taxonomy Change
to downstream systems and
processes. • Consumers need to know the change, the
reason for change, known impacts, related
• Implies administrative metadata, changes, and their timing
versioning, knowledge of the context in
which the taxonomy is used
6
©2007 Hitachi Consulting. All Rights Reserved.

7. Organizational Structure
R Responsible A Accountable C Consulted I Informed
A
Executive Sponsors meet quarterly to review summary
Executive Sponsors taxonomy metrics and analysis results, and to define
and refine strategy
Business Unit Leadership
Business Unit Leadership team meets monthly to
BU Taxonomy Owners Support Team R review/ prioritize requests for taxonomy change; to
plan training, communications, and strategy; and to
•Control/Approve Changes •Coordinate Changes in approve release and versioning plans
•Dependent Systems
Day-to-Day Taxonomy Management
Coordinates with the Business Unit Taxonomy Owners
Taxonomy Librarian Operations R as needed (generally online rather than face-to-face)
to assure compliance with processes and to plan the
•Administer Taxonomy •Content Admin content and timing of taxonomy releases
•Solution Admin
Execute processes, receive training, and recommend
System Users I taxonomy changes to the Taxonomy Librarian
Layered Model Thresholds
It is important to define a structure that separates policy and Escalation between layers is controlled by policies that define the
strategic direction, operational coordination, and day-to-day thresholds for communication, and what the content of the
management and operations. communications should be. This will vary widely from one
organization to another.
7
©2007 Hitachi Consulting. All Rights Reserved.

8. Governance Responsibilities
Define Objectives
Strategy
• For the taxonomy, its intended use, and how it
supports the organization’s strategic goals
Change Management
Planning
Manage Change Requests
Manage Manage
• Who are responsible parties for change requests, Change Taxonomy
Coordinate
Changes
maintenance and changes of the taxonomy Requests Baseline
• Define the tools and processes to manage
change
Communication
• Define and track metrics on the performance of
the process
Manage the Taxonomy Baseline
• Who maintains the current model of the taxonomy
Communicate with Stakeholders
• Notify Consumers of intended changes and
• Processes for reassignment of taxonomy current state of the taxonomy – stakeholders
components and whom should reassign them may want to browse or query the taxonomy,
Coordinate Change in Related Systems receive notification of planned changes
• Other systems and processes can be impacted – Plan and Prioritize
coordinate change to the consuming systems and • Define the criteria for prioritizing requested
processes changes; who decides on priorities, and
escalation processes in case of disputes
8
©2007 Hitachi Consulting. All Rights Reserved.

9. Delegated Management
Delegate
Disposition
It’s not feasible for all taxonomy changes to Item Action Member Action Closed No-Action
be channeled through a single individual or
group. Listing Removal Auction Restart Flag Item Warning Suspension Reinstatement Flag Member Billing Action
Investigate
Governance bodies should delegate
Bid Retraction Bid Retraction Move Item Account Closure Account Linking
Member
ownership of the representative context of a
Suspension
taxonomy and how changes to the parts are Warning
Policy Warning VeRO Warning Support Warning Safety Alert
Adjustment Collection
made without compromising the overall Indefinite
Suspension
Temporary
Suspension
structure. 30-day 90-Day
Suspension Suspension
Standards
• Ownership and Reassignment Organization A
• Structural Norms and Naming Organization B
Conventions Organization C
Organization D
• Versioning Criteria
• Validation and Testing
• Periodic Review and QA
9
©2007 Hitachi Consulting. All Rights Reserved.

10. Practices, Standards and Measures
Policies are a plan of action that
guides decisions and practices
based on stated objectives and Policy
strategies.
Practices are requirements that
establish guidelines for all business Practices
units and aligns with defined
policies.
Standards are specifications that Standards
Business Unit
Business Unit
Business Unit
Business Unit
Business Unit
details how to fulfill the practice; and
what is done? how often? Measures
Measures are numbers or
percentages that illustrate how well
a practice is fulfilled.
10
©2007 Hitachi Consulting. All Rights Reserved.

11. Metrics
Metrics can be gathered at each Real-time metrics
stage of the taxonomy life cycle, by the • Usage volumes by:
business unit and/or by dedicated
–User segment
taxonomy support staff.
–Channel
Metrics can improve: –Geography
• Taxonomy and Information Architecture: –Facet
– Elimination of ambiguity • Taxonomy usage:
– Identification of new taxa –Taxa that are never used
– Removal of redundant taxa –“None of the above” responses
–Search statistics
– Improved controlled vocabularies
(labels and synonyms)
• Taxonomy change request process Analytics
• User experience in both taxonomy • Accuracy of categorization (% of categorizations
management tools and the operational that are corrected in a later stage)
use • Abandonment rate
• Identification of consistent patterns of • Taxonomy change request statistics
issue, root cause, and change • Taxonomy defect metrics
resolution to enable automated • Usability test results
change resolution
11
©2007 Hitachi Consulting. All Rights Reserved.

12. Use the Existing Tools
Many of the goals and techniques of taxonomy
governance are common to other IT and data Source Mgmt.
governance methods. It’s better to reuse existing
tools rather than build or buy new ones. The
learning curve is shorter and the costs are
lower.
Taxonomy
Lifecycle Model
Workflow Bug Tracking
• A taxonomy’s lifecycle is similar to that of
standard software change request
processes.
Baseline Control
• A taxonomy, just like code, should be Capturing Feedback
controlled and versioned. • Both “suggest new content” forms, customer-
Branching and Forking service ticket-trackers and bug-tracker tools
can be used to capture user requests for
• Ability to maintain concurrent models in change.
different states is common to many source
control systems. Release Planning
The Draft/Review/Publish Model • Existing project portfolio management
systems often include version description
• Existing systems already have workflows that
and release-planning functions.
can be reused to control publication and
notification of changes.
12
©2007 Hitachi Consulting. All Rights Reserved.

13. Tool Requirements
Modeling
Essential features:
• Web access
• Ability to delegate ownership Model Publish
• Versioning capability, both coarse and fine- Change
grained
• Rollback
• Flexible taxonomy metadata model
(administrative and engineering)
• Change history– traceability of changes to Change Request Tracking
CR
Must have:
Publication • Ability for end users to report issues and see
resolution status
Must have:
• Resolution workflow
• Integration with model • Integration to model
• Integration with change request solution
Should have:
• Version description/release notes capability
• Notification
• Flexibility in publication format (DB dump,
XML)
• Metrics capture and reporting
13
©2007 Hitachi Consulting. All Rights Reserved.

14. Summary
You now should understand Taxonomy Governance:
• Processes and Procedures
• Organizational Structure
• Practices, Standards & Measures
• Tools and Solutions
You now should understand its context:
• Taxonomy exists to support organizational goals and their supporting business
functions. As such, a taxonomy governance model is needed.
You should be able to identify core taxonomy governance processes:
• Not much is unique to taxonomy governance, as it resembles similar governance
processes (data, code, etc.).
Identify Standard Processes and Tools:
• Many opportunities for reuse with existing solutions; adoption is better with reuse.
Tips and Tricks for Governance:
• For more info, see appendices.
14
©2007 Hitachi Consulting. All Rights Reserved.

15. Questions?
Alex Barnes Tom Witczak
Senior Architect Senior Consultant
Hitachi Consulting Hitachi Consulting
www.hitachiconsulting.com www.hitachiconsulting.com
Mobile: 415.297.0712 Mobile: 415.412.2915
abarnes@hitachiconsulting.com twitczak@hitachiconsulting.com
Inspiring your next success! ® Inspiring your next success! ®
15
©2007 Hitachi Consulting. All Rights Reserved.

16. Appendices
A. Integrations
B. Organizational Change Management
C. Taxonomy Defect Types

17. Integration with Process & Workflow
Process Analysis Framework
Taxonomy does not exist in isolation. It should be informed
by a process analysis framework: a model that is used to
understand key business processes. It will serve to interpret
as-is processes and to scope subsequent process
development iterations.
Developing a process framework is an activity outside the
scope of taxonomy governance. It requires a coordinated,
global effort touching upon several facets of business
process management. These components include:
formulating a consistent strategic view of processes,
mapping current state processes, assessment and
prioritization of processes, establishing development and
modeling standards, process governance, and finally
process management. Supporting the framework are the
technologies, such as orchestration, infrastructure and how
processes are realized and presented to the user.
The process framework, as it is executed, will yield
requests for taxonomy change, potentially including the
identification of new taxonomic facets.
If the process framework includes elements of participatory The taxonomy is exposed within the process framework
design, valuable stakeholders will actively contribute their through taxonomic views that are task-specific. By some
knowledge to the process models, translating to increased definitions, these taxonomic views are regarded as part of
end user adoption of the solution. the information architecture of the solution.
17
©2007 Hitachi Consulting. All Rights Reserved.

18. Integration with Consuming Systems
Dependencies
Taxonomy is seldom exposed directly on a user interface. Instead, task-
specific views of the taxonomy are shown to the user. These may have
a structure that is significantly different than that of the underlying System A
taxonomy: for example, a node may have multiple parents on the UI.
Load time
But it is important that traceability is maintained between the taxonomic
views and the underlying taxonomy, so that changes to the taxonomy
lead to changes in the user experience.
Taxonomic views may be surfaced in a number of ways:
• Navigation Real time
• Workflow/routing Taxonomy System B
• Filtering
Compile time
Along with the hierarchical relationships depicted in the taxonomy, user
interfaces (and system behavior) may also be responsive to frequency-
of-use considerations. This frequency-of-use data must be measured by
observation of system usage, and can be tracked as additional
metadata on taxonomy nodes.
Binding System C
Different systems consume taxonomy in different ways:
• Realtime: the system looks at, and responds to, the current taxonomy
as it is needed, on a case-by-case basis
• Load time: the system is initialized with a snapshot of the taxonomy at
the time it is started Coordinating Change
• Compile time: the system is built in a way that incorporates knowledge • Metadata should exist in the taxonomy model to reflect these
of the taxonomy differences in the impact of taxonomy changes on consuming systems
While realtime binding is a desirable design goal, most systems are not and processes
this adaptable to taxonomy changes. • When a taxonomy update is published, it must be synchronized with
changes to systems and processes that are sensitive to that part of the
In addition, business processes are also sensitive to taxonomy: taxonomy
• Categorization processes
• Metrics
Like systems, processes respond to taxonomy changes with varying lag
times and varying costs of change
18
©2007 Hitachi Consulting. All Rights Reserved.

19. Organizational Change Management
Approach
The key to a successful transition from the legacy state to the
new taxonomy governance model is to:
• Understand the Organizational Landscape and develop
an a change management approach consistent with the
organization’s needs
• Establish and support Leadership and Stakeholder
Commitment to actively lead the initiative
• Develop an effective Learning strategy that educates the
organization on new processes and functionality from the
system and also builds enthusiasm, adoption and skills in
stakeholders through exceptional training.
• Creation and execution of an effective Communication
plan that delivers the right message to the right person at
the right time.
The goal of OCM is to assist and drive the following key
activities to project success:
Key Work Products
• Methodology adoption by BU, tech team, and SMEs
• OCM risk diagnostic • Management Model
• Definition of critical success factors
• Appropriate analysis of the stakeholder landscape
• Stakeholder analysis • Training Approach
• Definition and execution of the communication plan to • Champion Framework • Communication plan
inform all relevant stakeholders and stakeholder groups • Channel assessment • Leadership Action Plans
• Communication with involved groups to make sure SME’s
are aware of tasks and complete tasks on time
19
©2007 Hitachi Consulting. All Rights Reserved.

20. Taxonomy Defect Types
As analysis is performed on Taxonomy Change Requests, they must be categorized. This determines
resolution workflow, and provides a basis for ongoing measurement of taxonomy quality. A change
request can be tagged with one or more defect types. These codes are based on software engineering
and data quality defect codes.
Code Definition
Completeness/Consistency This category of taxonomy defects is for incomplete (missing child nodes) or
inconsistent (conflicts with, duplicates or overlaps with other nodes) nodes.
Incomplete Not all of the node’s child nodes are specified.
Conflicting The node wholly or partially conflicts with another node.
Wrong parent The node is placed incorrectly in the hierarchy.
Duplicate The node is the same as all or part of another node (not mutually exclusive).
No Longer Required There is no longer a business requirement for the node to exist.
Missing A required node is not present.
Correctness This category includes defect codes for nodes that are incorrect, unverifiable or cannot
be implemented.
Incorrect (Not a Node) The requirement for the node is logically flawed, or is not needed to support the business
process.
Ambiguous The definition is ambiguous.
Dimensional Problem The node or nodes are repeated due to dimensional problems with the hierarchy.
20
©2007 Hitachi Consulting. All Rights Reserved.

21. Taxonomy Defect Codes, cont’d.
Code Definition
Presentation/Style This category includes taxonomy defects of an editorial nature.
Unclear Wording The wording of the definition or label is difficult to understand.
Typo/Grammar The definition or label has spelling, typographical or grammatical errors.
External Taxonomy This category includes defect codes for changes introduced by an external change control
Change process in response to changing business requirements or project scope.
New A new node (or nodes) has been added.
Modify An existing node (or nodes) is to be modified.
Delete An existing node (or nodes) is to be deleted.
Miscellaneous This category includes other taxonomy changes.
Changes
Synonym A taxonomy node is identified by, or searchable by, more than one name.
Not a Node The node should not be in the taxonomy at all.
Update Metadata Change administrative metadata (ownership, related systems, etc) for a node.
21
©2007 Hitachi Consulting. All Rights Reserved.