Taxonomy discussions in an enterprise setting

Why ‘small’ and ‘big’ information architecture are hard to separate. Why we need to focus on useful application of taxonomies rather than precise definition. And a hint at manual versus automated content classification. 

In this highly recommended article by Christina Wodtke about information architecture, the author complains IA professionals spend too much time defining their own tasks and responsibilities. Regardless of the job title, she sees an important role for people making "sense of the world of data to the humans who live in it."

Big and Small IA

Wodtke refers to an historical information architecture scoping debate with Big IA practitioners on the one hand - concerned with the structural design of information environments - and Small IA professionals on the other - concerned with organizing and labeling single parts of such an information ecosystem.

Put differently, big IA is about a conceptual understanding of cross-channel information retrieval and navigation, where small IA improves findability and usability of individual channels through library-inspired tools: metadata, taxonomies, and controlled vocabularies.

Classification is crucial

Today I'll share a professional experience that illustrates the overlap between small and big, and the need to focus on usefulness rather than terminology. It concerns a client-facing project at a large financial institution where the term 'taxonomy' is used internally by many people to mean many different things.

The most important application of the taxonomy in this context is in the content management system where all external content will be maintained. Classification of content will be crucial to providing relevant and personalized information to the company's (potential) customers.

The editor’s use case

One of the internal debates centers around the question whether the taxonomy should be hierarchical and closed, or nonhierarchical and open. This is assuming there will be a single taxonomy. We'll probably need more than one, and both closed and open lists. The use cases of the taxonomy will be crucial in deciding.

I try, for example, to direct the conversation towards the editor we'll ask to classify the piece of content s/he is creating in the CMS. Until more sophisticated, automated ways of classification come into play, the editor should be able to manually add the necessary terms with a minimal effort. This part of the undertaking could be labeled small IA.

Internal taxonomy alignment

Another interesting point of attention is aligning the taxonomy needed in this project with all kinds of existing ordered lists within the (large!) organization. This alignment is needed from a business process perspective - to make collaboration between business units more efficient - and from an IT-architectural perspective - to simplify connections between applications.

Collecting the existing lists alone brings inconsistencies to the surface that need to be smoothed out. A potential enterprise-wide project of its own. Particularly because the client wants to involve taxonomies in use on internal channels as well, such as the intranet. This part of the project is definitely big IA.

Flexible, big, and small

Since I'm hired by IT, there is a natural tendency towards automated solutions. There is definitely potential for automating content classification later on. The project organization currently places a large responsibility upon the shoulders of the editors to manually classify the information with aspects directly related to the contents of the content. In the future we might be able to alleviate this burden.

For now, in the spirit of Christina's plea and for the client's sake, let's combine small and big IA, and allow for taxonomy definition flexibility, to come up with a useful and usable classification system that can be implemented within a reasonable timeframe and is embraced by the business, IT, and the content editors.