A SharePoint Consultant on IA and IM

by Paul Olenick

In "A SharePoint Consultant on Information Architecture Part 1," we laid out a description or two of information architecture and talked about why it is so important.  In this follow up, we’ll cover the following:

What is Information Architecture, Specific to SharePoint?

In general, SharePoint IA requires attention to the same topics that any other website does.  But SharePoint does warrant a specific discussion because there are SharePoint-specific mechanisms and structures that must be addressed and because SharePoint's nature is to empower users to create sites and content on their own. 

If the IA is not well thought out (as well as executed and adhered to), site sprawl and other undesired results are sure to emerge.  Some of the SharePoint-specific topics that must be addressed are these:

Content containers - By this I mean, deciding whether content or sites will reside in a specific farm, web application, site collection, or subweb.  Decisions about where to provision a specific site will include, among other things, configuration requirements, compliance/data segregation/encryption, specific SLAs, and navigation.

Metadata Structure - This includes defining Managed Metadata term sets, site columns, content types, content type hubs, and more.

Search Schema - SharePoint Search managed properties and crawled properties (and their mappings) must be well thought out to ensure quality search results as well as setting the system up to create search-based applications.

Now, I mentioned this isn't a full list, but even so, you might have noticed there are some obvious things missing.  Which leads me to the next topic.

What is the Difference Between Information Architecture and Information Management?

At a high level, I think of IA as the design and planning of your application whereas IM is the implementation, application and execution of that design. 

So as an example, your IA may define a metadata taxonomy for tagging content and a content type hub to manage those terms centrally.  The IM part of this would be, perhaps, configuring auto-tagging on this library to make sure that the tags are actually applied.

Another way to look at this is that IA describes where and how content is organized, while IM is an application of tools and configuration that describe how this information behaves.

Some of the areas of IM that need to be addressed follow:

Permissions/Security - Who has access to the content?  What different permission levels are available to apply?

Content Lifecycle - When does an item become a record?  When and how is old content archived?  Is content ever expunged from the site?

Policies - What type of auditing and reporting is required for the content?  Can the information be printed or emailed?

Provisioning Process - How are sites provisioned?  Which site templates are made available?  Where can sites be created?

Again, there's more to consider here, but this should get you thinking about the types of things to plan for and configure in your implementations.
 

When Should Information Architecture be Addressed?

There's an easy answer to this question.  You should address IA early and often.  If there's one thing to take away from this blog it is that last sentence. 

IA should be planned for very early in the project.  In my opinion, it should follow the initial governance planning.  This is because the governance plan will in some way or another define then IA. 

IA should be revisited often.  Requirements change over time, sites change over time.  Your SharePoint application is a living breathing thing and your IA (as well as many other aspects of your SharePoint solution) should be reviewed and updated on a frequent basis to make improvements and address the current needs of the business.
 

Wrap Up

I hope this has been a good intro or refresher on the basic tenets of SharePoint information architecture.  The key takeaways I hope you'll get are as follows:

For more information, see these other resources:

Paul Olenick (SharePoint MVP, V-TSP) has been dedicated to SharePoint for the past 7 years. Paul has helped clients worldwide solve business problems leveraging SharePoint and shares his experiences with the greater community by contributing to books, blogging and speaking at industry events. Paul is the moderator of SharePoint Shoptalk.
Blog:  Paul Olenick's SharePoint and Search Blog
Twitter:  @olenickSP
LinkedIn: Paul Olenick