Taxonomy Design

From MIKE2.0 Methodology

Activity: Taxonomy Design

Objective

The Taxonomy Design activity defines the structures for relating content to one another. It may be focused departmentally, across the organisation or may extend to external partners and the internet. Traditionally, the terms taxonomical model has been in reference to unstructured content such as documents and web pages although there is increasing convergence between unstructured content and structured data. It follows a more structured approach than the folksonomic approach that is discussed in the Collaborative Framework Design activity.

Taxonomy Design makes use of the existing architecture framework, Information Standards and Information Governance Policies defined earlier in the project. It will be built for an initial increment and then refined through the Continuous Implementation Phases.

Major Deliverables

• Lexicon of Terms
• Taxonomy Design

Tasks

Define Lexicon of Terms

Objective:

This task defines the common vocabulary of terms in the taxonomy. At this stage the focus is on gathering the list of terms as opposed the hierarchies or relationships between terms. Not all terms need to be captured at this stage as the list will be continually refined.

Input:

• Detailed Business Requirements for Increment
• Solution Architecture Definition/Revision

Output:

• Lexicon of Terms

Define Taxonomy Style

Objective:

The Taxonomy Style is essentially the structure of the taxonomy. This is a key design decision as it determines whether the taxonomy will follow a model that is completely flat, hierarchical or networked-based. It will also provide a design on how centralised the taxonomical approach will be, helping to answer questions such as:

• Will there be a single taxonomy for the organisation?
• For multiple taxonomies, how will they be integrated?
• How much will the taxonomy structured be fixed - will users will be able to influence changes at a structure level?
• How will the taxonomy structure evolve over time?

These style decisions are effectively the architecture for the taxonomic approach. Unlike relational Data Modelling techniques, there is more variability in best practice standards.

Input:

• Detailed Business Requirements for Increment
• Solution Architecture Definition/Revision

Output:

• Taxonomy Style/Conceptual Design

Define Taxonomy Relationships

Objective:

Once the style/conceptual design has been defined and the main lexicon of terms identified, the key relationships can be defined. The goal in this task in not yet a formal model but the first attempt to define hierarchies and relationships within the taxonomy.

Input:

• Lexicon of Terms
• Taxonomy Style/Conceptual Design

Output:

• Relationships between Terms

Design Logical Taxonomy Model

Objective:

This task builds on the work from the prior tasks to produce a formal logical model for the taxonomy. The model is defined within a tool whereas the other steps may have followed a less structured approach. At the completion of this task the model represents how content will be stored when fully formed.

Input:

• Lexicon of Terms
• Taxonomy Style/Conceptual Design
• Relationships between Terms

Output:

• Logical Taxonomy Model

Define Techniques to Populate Taxonomy

Objective:

Different techniques may be applied to populate the taxonomy, either with new content or existing artifacts. The technique would apply to interfaces from existing systems, migration of content or new population mechanism that will be in the future.

Input:

• Logical Taxonomy Model

Output:

• Abstracted Model to populate taxonomy

Develop Physical Taxonomy Model

Objective:

The physical taxonomy model optimises the logical model based on techniques for how it will be updated. Physical model changes into relation to the logical model typically relate to performance and reducing complexity.

Input:

• Logical Taxonomy Model

Output:

• Physical Taxonomy Model

Core Supporting Assets

Yellow Flags

Areas to look out for include:

• Strong resistance from the organisation to follow iterative development techniques
• Poorly formed information standards and policies, especially those related to information modelling

Key Resource Requirements

• Solution Architect
• Information Architect

Potential Changes to this Activity

This activity is still being defined and will likely undergo a number of changes.

• There are times for traditional taxonomy models within corporates, although a comparison of when to move to more of an organic Folksonomy model. The Collaborative Framework Design activity provides coverage of this approach.

• The Taxonomy Style is more of an architectural/conceptual design activity and may be moved from this activty.

• Taxonomy_Design, Data Modelling and Message Modelling are currently defined as separate activiites. It may be better to converge this to a single activity.