SharePoint 2013 Readiness - It's the metadata, stupid!

SharePoint 2013 is coming!  Act busy!

OK, that's maybe not the best preparation plan.  But when KMWorld asked me to submit an article for KMWorld based on my years of consulting on KM systems and SharePoint, I thought a lot about taxonomies and folksonomyies.

SharePoint 2010 introduced a new capability - the Managed Metadata Service.  It was the subject of my first book and presentation at KMWorld, and I'm a little (over) passionate about the topic.

In case you haven't heard, Microsoft SharePoint 2013 is becoming broadly available in Q1 2013.  It extends the Managed Metadata Service ("MMS") as both a key feature of social collaboration and as a visual navigator among diverse streams of content in information storefronts.

During the past six months, I've consulted with many users and stakeholders about how to plan and prepare for a SharePoint upgrade.  Most of these elements are technical:

• Upgrade Windows & SQL
• Inventory current environments and content
• Eliminate unneeded custom code
• Plan for capacity and performance
• Establish governance
• Consolidate and groom content

I've spend a lot time talking about how to find unneeded content, stale document versions and unused applications PRIOR to an upgrade.  All important stuff, true.  But I've overlooked the metadata!

When I speak to IT engineers, I talk about how to use PowerShell to discover custom installed solutions.  Superficially, I remind them to be on the lookout for packages that look like this:

BobTestPartv1.wsp - 27 July 2010

Why?  Well, SharePoint was released in May 2010.  In a loosely governed environment, it's not uncommon to see a lot of tests and false starts that went into "production" that first summer, or later.  Some of those solutions were never used - so there's no need to test them for capability and install them in a new system.  They should be pruned.

I believe the same thing is true with metadata.  Some companies have never gone back and reviewed the tags and term sets they created originally.  MMS2010 was a great first effort by Microsoft - but it was very much a v1.0 release.   There were many shops that didn't know where they wanted to put managed terms for geographies, or products.  So you see term set hierarchies that started like:

• States

› Alabama
› California
› Massachusetts
› Etc.

But then they grew to include:

• Geographies

   › North America

•Canada
•US

•States

•Alabama
•California
•Massachusetts
•Etc.

› EMEA

•France
•UK
•Etc.

Over time, the latter set of terms has become the principal set of definitions for defining MMS fields.  But the original set of redundant state names is still out there, and still sometimes gets selected during keyword tagging.

The good news is that MMS is managed.  You don't have to just purge those terms - you can merge them so you don't lose the benefit of all that end user tagging just because they unknowingly picked the "wrong" version of Massachusetts.  (There's only one.  Trust me on this — I live there!).

Folksonomy poses a different set of challenges.  It's centrally stored, and somewhat messy.  You're likely to see typos and redundancies in there.  There are many opinions about how much you should manage or purge end user tags which were created directly by users.  "KathyFavoritePixMay6" may look meaningless, but it may also be the way Kathy finds her final photos for next year's marketing plan.

However, you can gain some additional management capabilities if you "promote" those user keywords to a place in the managed taxonomy.  Then you can aggregate relate terms and obvious typos "Masachusets" without deleting the original tagging activity.

Why should this matter?  Well, tags and keywords get much heavier use in 2013, especially in the social interface.  And social becomes the collaboration interface, instead of an adjunct.  If you have 500 poorly understood tags today, you're likely to see many, many more tags crowding around them in 2013.