Many of our clients ask us how to maintain taxonomies at both the enterprise and the team level without duplicating effort, overcomplicating systems, or burdening end users with multiple metadata fields. Depending on the size of your organization, the size of your enterprise taxonomy, and the number of teams that desire their own specific metadata and taxonomies, there are steps that can be taken as part of design and governance to mitigate the burden of maintaining multiple taxonomies. In this blog, I will discuss a few ways to ensure continuity and interoperability between taxonomies of varying scope and impact both through design decisions and governance considerations.
What is the Difference Between an Enterprise and Team Taxonomy?
Enterprise taxonomies are controlled vocabularies that can be used by employees across the organization. These are most often fields such as Function, Content Type, System, or Topic. Team taxonomies, on the other hand, are more specialized taxonomies with a narrower scope that may be used by only one team or department within the organization. In some cases, team taxonomies are offshoots of an enterprise taxonomy. For example, the IT department may have additional, more IT specific topics than what is included in the enterprise taxonomy that HR and Marketing also use. Other than narrow scope and specialization, team taxonomies are also different from enterprise taxonomies when it comes to who governs and maintains them. One of the most common struggles we hear is “How do we give autonomy to teams who manage a team taxonomy AND ensure we don’t overlap with our enterprise taxonomy?” Structuring both the taxonomies and their corresponding governance structures to coexist can be difficult but can be done in many ways. In one large insurance organization alone, we identified five different team level taxonomies that all covered a portion of the enterprise’s business and content, but were managed independently and to different levels of maturity. In order to bring collaboration and continuity to their taxonomies at an enterprise level, we investigated the options below.
How can Enterprise and Team Taxonomies Coexist?
Depending on the scope and differences between the enterprise and team taxonomies, there are a few different options for interaction and alignment between multiple taxonomies including the Hub and Spoke Method and the Linked Method.
Option 1: Hub and Spoke
Hub and spoke is the process of taking a primary taxonomy and then creating another taxonomy with only specific topics from that taxonomy. An example hub and spoke model would have the enterprise taxonomy acting as the central hub providing multiple specific taxonomy terms mapping to separate team taxonomies (spokes) across additional content repositories or departments. In the image below, the Topic taxonomy is shared from the Enterprise Hub Taxonomy to each of the team taxonomies. However, each team taxonomy also has unique and specific taxonomies of their own. For example, the Learning Team Taxonomy has Modality, and the CMS Implementation Project Team has Project Milestones. The primary benefits of this model are the reduction of duplication across taxonomies and the flexibility provided on the non-shared taxonomies for each team.
For the insurance organization with five independent taxonomies, Option 1: Hub and Spoke did not meet their needs, as an enterprise level taxonomy did not yet exist. Instead, we realized the need to align their multiple taxonomies into one, enterprise level taxonomy and chose Option 2: Linked, in order to do so.
Option 2: Linked
Depending on where your organization’s taxonomies are stored and maintained, you may have the option of linking between taxonomies. By linking, I mean using the owl:sameAs or skos:exactMatch/skos:closeMatch functionality to allow for linking between enterprise and team taxonomies that contain the same terms. For example, in the image below, the term ‘Agile’ appears in the Topic taxonomies for both the Enterprise and CMS Project Team and is linked with skos:exactMatch. Many taxonomy management systems are built on information science standards such as OWL and SKOS, and these standards provide a process for identifying similar or same concepts across taxonomies. Depending on the taxonomy management system, identifying owl:sameAs or skos:exactMatch may merge the two terms to identify them as the same concept, or may just store that knowledge for use in querying the taxonomy or in integrations. Either way, it will help the governance teams to keep track of any terms that are used by more than one team.
For our insurance organization, we worked to align the five independent taxonomies, by identifying where they overlapped, and which taxonomy fields could be considered enterprise level fields for a new enterprise level taxonomy. Fields that were candidates for the enterprise taxonomy included fields that all business units either currently used, or would benefit from using moving forward. These enterprise fields were brought together into an Enterprise Taxonomy, and links were established using SKOS to link the Enterprise version to the individual taxonomies, much like the image below.
Now that our insurance organization had both an enterprise taxonomy, and linked team level taxonomies, it was important to establish a framework for managing multiple taxonomies and collaborating on changes or additions to any of the taxonomies.
Managing Multiple Taxonomies
Whichever model you choose it is important to form a regular cadence with the governance committee(s) to communicate and coordinate changes to the taxonomies. For example, while team taxonomies may be managed separately from the enterprise taxonomy ensure there are structured touchpoints from both governance teams that will ensure a more holistic taxonomy strategy. This might include notifications when changes are made to either taxonomy, or ensuring the right fields are applied to the right content.
Overtime, the development of different taxonomies could result in overlapping terms. There is a need from a governance perspective for a taxonomist or information architect to identify and correct overlapping terms and routinely assess the uniqueness of taxonomy terms. This could occur with either option. The “Hub” in the hub and spoke model could grow very large very quickly, and when linking between taxonomies it is always important to routinely look for duplication and capture those links. For more about taxonomy governance, check out my previous blog, Best Practices for Successful Metadata Governance.
EK has helped multiple clients navigate the challenge of multiple taxonomies by aligning the taxonomies themselves, and through creation of governance frameworks that allow them to coexist. Contact us to learn more.