Information architecture is a relatively new field.
Despite the creation of libraries in the 500 BC era, we’ve spent relatively little time focused on information architecture. Forty years ago, computers weren’t even remotely popular.
Twenty years ago, we didn’t have a global network which connected those computers so that they could share information.
Fifteen years ago, we got our first search engines to change information architecture from browsability (finding by navigation) to findability (finding by navigation or search.)
SharePoint brings its own transformation to the information architecture landscape. The following five tools make it easier to implement an information architecture in SharePoint and help us think about metadata differently.
Taxonomy Term Store
Lions, and tigers, and bears, oh my! There are all sorts of animals in managing the values that people put into fields, but none of them are as powerful as SharePoint 2010’s Taxonomy Term Store.
The words we use, our terms, are notoriously complicated and slippery. Where one person uses the term "car," another uses "auto," and another uses the less descriptive term "vehicle," and still another uses "Lexus ES300."
So the question is: which one is right? To some extent, we don’t have to care with the taxonomy term store.
We can create a hierarchy of terms, including synonyms, to hold the relationships. We create term sets (taxonomies) which contain the hierarchy of terms.
Figure 1 shows a term set with a hierarchy of mechanical objects, starting with a top level entry of vehicles, which contains automobile, which in turn, contains Lexus ES300. Car and Auto are set as synonyms for automobile.
By including these in a hierarchy, we can help encourage the most specific term possible. In addition, by mapping car and auto as synonyms we can simultaneously make it easy for content creators to tag content the way they think and enforce consistency.
Figure 2 shows what happens when a user types "car" into a metadata field attached to our term set.
A term set can be used in multiple site collections and can therefore encourage consistency of terms across the enterprise. Taxonomy term stores also make it easy to merge or change terms later. It will manage the process of pushing the changes to all of the site collections everywhere.
This can be exceedingly helpful if you’re using a tentative or code name for something and then later need to change all of the documents to the new name.
Common uses for the taxonomies are to define the corporate organization of business units, divisions, and departments, as well as defining products.
You’ll also find other uses like storing the officially recognized holidays, days of the week, months of the year, and other standard things that it would be easier for everyone to be able to draw on a central library for.
The taxonomy term store allows for two different kinds of taxonomies (or term sets). The first kind is a closed taxonomy, where an administrator defines all of the terms, and the other is an open term set where every contributor is allowed to create their own tags.
A closed term set is a classic taxonomy where an open term set is more like a social tagging framework (called a folksonomy) as found on Flickr.
In the struggle for consistency, there’s more than defining a list of values that must remain consistent. Don’t forget that not every piece of data can be organized into a list of options. Things like a purchase amount, a due date, and a title are just three quick examples of types of data that can’t ever be reduced into a terms store.
Defining a due date, including validation rules to ensure its set at least a day in the future, on every list that you need it on, can be tedious.
That’s why SharePoint allows for a column to be defined once. That one definition can then be added to lists. Thus the due date can be the due date no matter where it appears.
Having a place to store the data that’s consistent is just one part of the puzzle. Content types contain a list of fields as well as a collection of behaviors and rules for the collection of the data.
Consider the idea of a purchase order request. You can record the requestor, the amount, the requested date, etc., but there’s probably a form template that this information goes on.
There is also a process around a purchase order request. It might have an approval process. It might have document retention requirements that require it be protected for seven years or that it be disposed of seven minutes after it becomes an official purchase order.
That’s what the content type does. It defines the fields that are collected, the information management policies, workflows, and templates that are a part of the content being described.
Once a content type is created, it can be associated with lists inside the site collection so that it’s reusable. It’s key that you can use the same pattern in multiple sites in a site collection, but it’s also key that SharePoint allows you to have multiple content types in a single list or a library.
This means that you can have one library of information that has different fields and behaviors. You might have a document library per office which contains expense reports, purchase order requests, and manufacturing reports.
Content Type Syndication
The primary limitation of the content type is that it’s stuck in a single site collection. Its powers don’t extend beyond the site collection boundary.
Thankfully content type syndication allows content types to be placed in a content type hub and then synchronized to every site collection in the SharePoint farm. This allows you to have one definition of a purchase order request across the entire enterprise.
One limitation that’s important to mention: the content type hub will replicate all of the content types and site columns to the destination libraries but it won’t replicate content.
The big challenge with not replicating content is workflows that are built with SharePoint Designer. You’ll have to manage pushing the workflows to all of the site collections yourself.
Last but not least in the top five tools for information architecture is search. Whether you’re using the out-of-the box SharePoint search or are using FAST, search will transform how you work with information.
By defining managed properties you can convert the metadata that you’re using into refiners and create a way for users to quickly filter results by specific metadata fields.There you have it, five amazing tools for information architecture in SharePoint.
Robert Bogue is a Microsoft MVP for SharePoint, an internationally renowned speaker, and author of 22 books including the SharePoint Shepherd’s Guide for End Users. You can find out more about Robert’s work to encourage business value out of SharePoint at http://www.sharepointshepherd.com/ or more about his technical solutions at https://www.thorprojects.com/blog.