Information Panopticon

Home » 2026 » May

Monthly Archives: May 2026

Taxonomy Obl(Iterations)

https://pixabay.com/illustrations/time-spiral-droste-clock-hours-1752164/

“Beware of allowing a tactless word, a rebuttal, a rejection to obliterate the whole sky” – Anaïs Nin, The Diary of Anaïs Nin

There is no better way to gain trust and buy-in for enterprise taxonomies than to iteratively develop vocabularies collaboratively with business stakeholders to meet their use cases. There is also no better way to lose trust and buy-in for enterprise taxonomies than endless iteration on taxonomy values as different business stakeholders representing new and diverse use cases push back on concept values accepted in previous reviews.

The success of enterprise taxonomies depends on acceptance and use by the business, particularly in the consuming systems required to do their jobs. If taxonomies can not meet the needs of the business, system owners may enable workarounds for metadata tagging and search needs, splintering metadata values across platforms and use cases. Developing centralized, enterprise-scale taxonomies is challenging, especially as consumers and use cases grow and diversify, but it is not impossible and enables consistency in domain thinking and for analytics.

How then do we work collaboratively with the business and technology product owners to ensure taxonomies meet business needs while avoiding an endless death-spiral of (obl)iterations?

Come Prepared

One of the fundamental skills taxonomists bring to the table is the ability to research. As the vast and nearly universally accessible repository of information that is the Internet has proven, especially since the advent of social media, having information available does not necessarily mean it is found or interpreted correctly. Taxonomists frequently have a background in academically-based research and information synthesis. They know how to apply rigorous critical thinking to information to develop individual taxonomy concept labels and larger ontological domain structures reflecting the nature of the business.

While a taxonomist should rely on input from organizational subject matter experts, they should also come prepared to meet the business with taxonomy concepts and structures reflecting the terminology and thinking of the business and the industry at large. Many taxonomists are generalists, not deeply ingrained in any one industry but instead applying their art as needed in any organizational domain. Their ability to research and learn from SMEs, organizational data and documents, and external sources, allows them to come prepared with suggested term forms based on real-world sources.

Coming prepared with taxonomy concepts, definitions, scope notes, and suggested properties and relationships can curb pushback from business users by establishing truth based on common taxonomy development principles.

Effective Project Management

There are often two scenarios for taxonomy development: the taxonomist is developing a new or refining existing taxonomies as part of a larger project (digital asset or content management, website redesign, Intranet search, etc.); or, the taxonomist is working solo or as part of a team on one or more projects to iteratively develop and expand existing taxonomies to meet ongoing needs. Whether taxonomy development is project-based or in the maintenance phase serving many projects and use cases, effective project management is essential to ensure endless iterative revision cycles don’t bog down progress. 

In the first scenario, the taxonomist is not likely to also be the project manager. One or more project managers is tracking multiple project workstreams and checking in with the taxonomist to see their work is progressing and on schedule to meet milestone and deliverable dates. These project-based milestones are very effective at reducing the risk of endless taxonomy iterations by establishing hard timelines and dates for delivery. Effective project managers will keep the project on schedule and reduce obstacles to milestone deliverables. Where needed, they can intervene in bogged down processes by identifying and escalating the risk to the overall project. 

In the second scenario, the taxonomist or a taxonomy manager leading a taxonomy team is effectively a project manager. They ensure taxonomy requests are handled in a timely way and the taxonomy values, or whole taxonomies, are delivered to support the projects as needed. What qualifies as a “project” may be loosely defined, such as search or product tagging which can be ongoing work, or a discrete project requiring taxonomy development or support. Like a project manager, the taxonomist needs to meet and enforce deadlines and identify and mitigate risks to meeting those deadlines. Taxonomists wear many hats, and project management is likely to be one of them.

Establish Taxonomy (and Beyond) Governance

Not having clearly defined governance processes for taxonomy work will confuse business stakeholders and cause misalignment with the rest of the enterprise depending on clear processes. Establishing clearly documented taxonomy governance, including how and where to request taxonomy work, service level agreements (SLAs) for taxonomy delivery, and ways of working on iterative taxonomy development, can enforce practices mitigating endless taxonomy iteration. 

Taxonomy governance should be part of a greater data governance framework including business and technical stakeholders from across the business. Establishing a data governance framework lends credibility to data handling across the enterprise and provides enforceable common ways of working. When signed-off and adopted by participating members, the principles can also be cited when taxonomy work begins to slow in endless review cycles and disagreements. Not only are taxonomy best practices a lever for moving taxonomy development forward, but data governance can provide clout for resolving stalemates.

The Right People

A common problem leading to multiple taxonomy reviews and revisions is not including the right people in the initial discussions. Not including the right people can be symptomatic of narrowly defined projects which only serve one business unit or a specific use case. Identifying the right subject matter experts and technical resources is essential to developing taxonomies that can scale across the enterprise and its many use cases. As part of the system, process, and content audit, be sure to identify anyone who is currently using metadata schemes which may include or be replaced by taxonomy values or processes which are automatically driven by current metadata values. Conducting interviews and taxonomy workshops to reach as many potential stakeholders as possible will help to mitigate the number of reviews a taxonomy will need. 

A natural outcome of establishing data governance is the identification and inclusion of the right business and technical stakeholders. Because these people are identified as part of data governance, they can be included as needed in taxonomy development conversations so potential needs–like legal or regulatory review for taxonomy concept forms or system impacts–can be immediately addressed rather than coming up later in the development process and effectively derailing the previous work and decisions.

Document Decisions

Another key task for mitigating taxonomy iterations and development deadlock is documenting decisions. In many taxonomy management systems, decisions can be documented within the taxonomy itself in the standard skos:editorialNote field. Decisions can also be documented in the documentation preference of the organization, such as a Confluence wiki page. Depending on the ticketing system, decisions made about the taxonomy with the business can also be noted in the ticket request itself, for example in a Jira ticket. A taxonomist may use one or all of these locations to note what decision was made, when, and by whom. Even if business stakeholders change or significant time passes, the decision indicating a concept form, why a property or relationship was added, or why a concept was changed or deprecated can all be viewed by the current parties involved.

While taxonomies are living, breathing, changing, and evolving data structures, these changes need to be logged to understand why decisions were made and what impacts, if any, those decisions have on taxonomy development and delivery.

Taxonomy development and iteration can grow and scale with business needs, but can also be subject to slowdowns and bottlenecks if there is no recourse to resolution. Hopefully some of the techniques above can help mitigate taxonomy stalemates and gain trust in taxonomies and their ongoing development cycle.