A survival guide for managing enterprise taxonomies on the web

Even with the best intentions, enterprise taxonomies can become bloated and unwieldy over time.

When different teams are working across different technology platforms, inconsistencies are bound to occur. Taxonomy issues might not pose problems day-to-day within an organization, but if the resulting complexity makes its way onto the website, the user experience will suffer.

Ideally, the enterprise taxonomy includes simplified, web-specific classifications alongside those used for other purposes. However, this isn’t always practical—resistance to change and the effort of reclassification work against the ideal of consistent and logical taxonomies.

Taxonomy problems come into sharp focus on enterprise-level websites where the source of truth for some content is not the CMS, but a repository such as a Digital Asset Management system. Metadata for that content, including assigned taxonomies, is often defined and managed in the external repository.

Too often, content from different repositories and their corresponding taxonomies are presented in separate sections of a website, or worse, as different websites altogether. Users must find content by separately discovering each repository and searching or filtering for what they are looking for several times—perhaps using slightly different terms each time.

So what are the options?

To allow users to search and display content from multiple repositories in a single interface requires filtering and faceting provided by the CMS. To do that the taxonomies that support those operations must exist in the CMS.

This requires a definition of how the taxonomies in the CMS map to the enterprise taxonomy. There are three typical approaches, described below.

One-to-one

The most basic solution is a repository of assets and a defined taxonomy applied to those assets that is then used in the CMS and on the web. In this scenario, all that is required is a relatively simple one-way synchronisation.

However, in many cases, the taxonomy used in the repository is not suitable for use on the web. It may be too granular, outdated, or simply not use terms that users are familiar with.

Additionally, complications arise if the repository taxonomy is applied to content originating in the CMS. If taxonomy items are changed or deleted in the external system, then how is the content in the CMS affected?

Business rule mapping (black box)

In cases where the taxonomy in a content repository differs from what will be used on the web, it can be tempting to create business rules that perform mapping between the two taxonomies as part of the synchronisation itself.

Unfortunately, despite this approach being able to cater for a very complex integration if necessary, it results in a “black box”—a piece of core functionality only understood by developers. Constant vigilance is required to maintain accurate technical documentation.

Configurable mapping

A more strategic approach would be to think about asset repositories and taxonomies in a more abstract way.

Ideally, content editors should be able to fully control the configuration and mapping of taxonomies without requiring engineering support. To achieve this, a configurable mapping mechanism can be developed, which first synchronises the repository and the CMS as in the one-to-one approach above.

Following synchronisation, configuration of the mapping process in the CMS involves defining the schedule, the steps to perform during the mapping process, and the actions to perform within each step based on a set of criteria.

In most CMS, much of the configuration can be done simply by constructing necessary entity types and structure in the content tree. The development effort required to implement the actions will vary depending on the CMS. The screenshots below show how this could be constructed in Sitecore, but this approach is certainly possible in other CMS such as Umbraco.

Taxonomies play an important role for any content management system. When external taxonomies must also exist in the CMS, choosing the most suitable synchronisation method can save a lot of headaches later on.

One-to-one mapping should only be used in the simplest of cases. The choice between business rule mapping and configurable mapping often comes down to budget. While the initial build of a “black box” synchronisation may require less effort, configurable mapping usually provides the better long-term ROI since changes to business rules can be made more quickly and without incurring development cost.