Skip to content

Take sides

December 14, 2010

Over the next few weeks, I’ll be spending a few cycles digging in to my approach to taxonomy, which I introduced in a previous post (Irrelevant Taxonomies), both to contrast it with how I see taxonomy typically done as well as to solicit feedback, comments, and general heckling from you all out there–nothing like industry scorn to sharpen your ideas, right?

In that initial post, I introduced a number of dichotomies about relevant versus irrelevant taxonomies; in this series of posts, I’m taking the time to explain more about each of these dichotomies.

That having been said, let’s dive right in to the third dichotomy: being application neutral versus being application specific.

Nothing against Switzerland, but…

When you hear folks talk about taxonomy best practices, you often come across this idea of application neutrality, i.e., the taxonomy you adopt should be what it is irrespective of the specific systems or applications your content will be stored in.

And looked at from one perspective, this is absolutely correct: you wouldn’t want to have different taxonomies for each system or application, because a common goal of taxonomy projects, after all, is to permit you to find information across repositories.

However, looked at in another way, application neutrality can turn into a bit of a cop-out, a way to push off critical decisions about the taxonomy and its use until implementation (or sometimes UAT). Here’s what I mean…

Take a stand, close the gaps

Let’s say we’ve just created an enterprise taxonomy independent of any given system or application. We’d have the usual boxes and arrows to indicate parents and children, maybe even a spreadsheet that presented these same parent-child relationships in a more structured, less-sexy way. So far so good.

Now imagine an implementation team for an ECM platform like Open Text, EMC Documentum, IBM FileNet. We deliver them the taxonomy and tell them to use it to structure the content in their respective system.

How would they do this? With great difficulty is the short answer.

The longer answer is that they wouldn’t be sure exactly how to do so, not because our taxonomy isn’t clear, well-formed, or high-quality; rather, they’d face difficulties because by and large you don’t just “put” a taxonomy into an application like it’s some kind of configuration setting. Things are more complicated than that.

In reality, the taxonomy you’ve delivered them is more a formal design principle than a detailed design specification. It shapes the implementation of the content management application by guiding implementation activities, such as metadata design, the creation of document classes and types, and navigational design (folders, site hierarchies). But until someone completes these implementation activities, the taxonomy will remain abstracted, intangible…and irrelevant–at least from the point of view of the end-users of the content management application.

What has to happen to ensure the relevance of our taxonomy is to take that extra step away from the abstraction of application neutrality and toward application specificity by first acknowledging that our work is going to be used for a specific purpose in a specific application. Then we need to close some of the gaps between our boxes-and-arrows representation of the taxonomy and the realities of implementing the taxonomy by working side-by-side with the implementation team to help design the metadata, create doc classes and types, and weigh in on navigation.

The final word

The goal in all this is not to reinforce content silos, introduce competing or conflicting taxonomies, or abandon the more formal aspects of a taxonomy project. Rather, the point is to make sure your taxonomy is relevant–to the project team members you’re working alongside, to the applications they’re building, and to the end-users who are the ultimate beneficiaries of the project. By not allowing there to be gaps between the abstraction of your taxonomy and the realities of implementation, you increase your chances of doing so.

In the next post, we’ll focus in on the importance of creating tangible, measurable business impact with your taxonomy project. But for now, weigh in and let me know what you think of my take on application neutrality–as always, I’d love to get a good conversation going.


Advertisements
3 Comments leave one →
  1. December 15, 2010 9:53 am

    Growth of the organization’s taxonomy would come into question if it is allowed to expand where specificity is applied . I’m suggesting the resulting size of it would hinder its own maintenance. The established taxonomy, those terms in the hierarchy itself, should be fairly constant over time, growing some, but certainly not out of control, based upon app-by-app or unit-by-unit additions. You’ll need a system that allows things like “related terms” to reign in the differences between competing business units in the same organization. This will allow the taxonomy to represent the competing units plus provide the umbrella context for the organization as a whole to classify their electronic data.

  2. December 15, 2010 10:15 am

    Adrian,

    Couldn’t agree more!

    You’re right to point to systematic methods to handle taxonomy management (i.e., addressing related terms): especially as the number and complexity of repositories and applications grows, making sure all those application-specific taxonomies are in synch becomes increasingly difficult…if not impossible.

    And while there have been tools out there for some time now that do this (e.g., SchemaLogic), it’s only recently that I’m seeing them used in enterprise deployments with enough success to make them valuable–I’m excited to see where this space evolves over the next 12 to 18 months…

    Thanks for jumping in!

    Cheers,

    Joe

  3. December 16, 2010 5:14 pm

    Another great post.

    What I think you have identified is not limited to taxonomies. There are product best-practices and business requirements that drive better consultants to take sides early enough in a project to help it succeed, but not so early that it seems they are just an extension of the sales engineer.

    Without getting down to the specifics of the application and what the product can deliver best leaves you just analyzing stuff that may never fit in the real world. From what you are saying, it sounds like taxonomies just make this even harder. So I’m really looking forward to your next post on the “tangible, measurable business impact”.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s