A SharePoint Information Architecture recipe

Blog post: 5 minute read

I recently received a request to prepare an Information Architecture(IA) plan for an organization. This organization plans to migrate from a legacy version of SharePoint, SharePoint Server 2010, to the newest version of the on-premises software, SharePoint Server 2016, and decided a prudent first move would be to redefine their IA for the new environment. Smart!

I suspect there are other organizations out there in the same position who may be dissatisfied with the way their current SharePoint environment is functioning for one reason or another and want to do a course correction. Perhaps there was no IA plan prior to implementing SharePoint in the first place and over the years it has organically grown into an ineffective environment. Perhaps even if there was an IA defined it may have outgrown its effectiveness over time due to re-orgs and acquisitions, or just plain lack of attention to the original IA plan. I believe these are common scenarios for many organizations having deployed SharePoint. Without experienced and knowledgeable SharePoint staff being involved right from the beginning, many organizations don’t often realize what they’re “getting into” and neglect to lay the necessary groundwork to leverage the platform over the long haul.

Fast forward several years and organizations like this may find themselves at a cross-roads. Should they take a “lift and shift” approach and migrate the mess from the old to the new platform (rhetorical question, please don’t do this) OR should they take the time to rethink the underlying information architecture, take stock of their current environment, do some housekeeping and start new? Yes!

I call this a golden opportunity – the chance to learn from past mistakes and improve on the things you’ve done right. IA is a critical and necessary step in the planning and preparation phase of any SharePoint implementation whether you’re moving to an on-premises or online environment. Some things can be difficult to change after-the-fact so it’s best to do IA planning up-front prior to any content being added.

To be clear, the need for Information Architecture is particularly important in more structured and controlled areas of SharePoint such as corporate portals and divisional areas. It’s of lesser/little importance in the collaboration areas of team sites and Office 365 Groups although it still applies in some aspects.

How should you tackle IA for your SharePoint environment? First and foremost you must understand the organization’s content and how people within the organization will interact with it. This may include things like:

• what is the organizational structure?
• what are the personas that represent the typical user groups across the organization?
• what types of content does each business area need to track?
• what are the business processes that will interact with this content?

Once you have a solid understanding of the organization’s content needs, you can start to think about how you might design this within SharePoint via an IA plan. What are the steps to prepare the plan? Glad you asked… I have a recipe. 🙂

This recipe is for both building and executing on a SharePoint IA plan. It follows the same methodology you would use for a recipe you prepare in your kitchen. There are 3 parts:

1. The ingredients
2. The tools, techniques, and steps to build it
3. The X factor

1. The Ingredients:

“SharePoint Information Architecture Building Blocks”

The following building blocks are important components you will need to identify for your organization.

• Site collection layout
  • what defines a site collection across your environment?
• Subsite layout
  • how will subsites be laid out within your site collections? Will you have subsites?
• Navigation
  • what will the navigation be and what type of navigation best supports this?
• Corporate Taxonomy
  • what are the candidates for corporate terms in your organization?
• Content types and metadata
  • what are some good candidates for content types and is there shared metadata across them?
• Document Libraries and lists
  • what are some key libraries and lists that will need to be provisioned based on your understanding of the content?
• Security Models
  • what is the security model you will use for your environment? Consider AD groups, SharePoint groups, individual user assignment.

2. The Tools/Techniques/Steps:

“SharePoint Information Architecture Features”

Organizations should consider how/if they will use the features below to work in tandem with the SharePoint building blocks above.

• Content Type Hub
  • depending on your site collection layout, is there a requirement to use the Content Hub to store/deploy your content types from? [Update March 14, 2017: Please refer to this excellent post by Jasper Oosterveld titled “Dear SharePoint Online Content Types & Hub: What’s Going on with You?” where he talks about the current limitations with the Content Type Hub in SharePoint Online]
• Content Organizer
  • will you use the organizer to help route your content within your environment? If so, how will you set up your content to allow you to do this?
• Records Management
  • what are the compliance/regulatory requirements of your organization? Do you need to utilize any of the RM features within SharePoint to accomplish this?
• Information Management (Retention, Audit, etc.)
  • similar to RM, what are the IM requirements for your organization as it pertains to retention and audit? This can dictate how you will set up the content across your environment.
• Search Integration
  • how can you increase the “findability” of the content across your organization? The way content is set up has a significant impact on your ability to be able to find it later.
• Data Governance
  • what are the security controls within your organization and how should you set up your content to be able to leverage features that can implement them? (i.e. Data Loss Prevention, Rights Management)
• Governance Plan
  • define a governance plan to ensure you are staying roughly within the bounds of your IA plan. Try to keep this plan simple yet flexible. A sample of things that should be covered are:
    • Security governance: who should administer permissions in your environment?
    • Container governance: who/what should control the creation of a new site collection/site in your environment and what controls should be placed within it?
    • What does it mean to be a Site Owner in your organization? How will you ensure site owners have the required knowledge to effectively do that?
    • Who will administer your corporate terms?

3. The X Factor:

“Experience”

Like any good chef/baker knows, there are things you can’t teach from words on a page. You need to have quality ingredients, excellent technique and use your experience to know how to turn an “average” recipe into a blue ribbon winner. In the SharePoint world, an effective execution of an IA plan comes from having worked with the product, having lived first-hand through both good and bad decisions and knowing when and how much to use of any one ingredient or feature in any given situation at any given time.

Examples of this are:

• what should/shouldn’t be a content type?
• what should/shouldn’t be defined in a corporate taxonomy?
• what are the pros/cons to each type of navigation?
• what are the drawbacks of defining content types in a content hub?
• how should we set up the content to make it easily findable by users?
• timing… what should you do at the beginning and what can be added after-the-fact?

This adept touch can only come with experience.

Parting thoughts…

Although Information Architecture is not the most exciting aspect of SharePoint, it is a necessary step. My recipe is of course only one way of approaching the preparation of an IA plan. No matter which technique you use, at the end of the day the most important thing is to actually build one for your environment. Doing this up-front planning lays important groundwork for SharePoint and will definitely pay dividends in the long run.

Thanks for reading.

-JCK