Information Architecture (IA). Big term for a simple concept. In the context of SharePoint, it’s a way of bringing organization and structure to your company’s digital assets. In my opinion, the success of any SharePoint implementation is dependent on the quality of the underlying Information Architecture.
Of all things I’ve worked on in SharePoint, IA is my “jam”. 🙂 Although this is not a new topic, time and time again I’ve seen SharePoint sites where little or no thought has been put into IA and digital mayhem ensues. This is why I’ve decided to write a series of posts on Information Architecture touching on a myriad of topics as they relate specifically to SharePoint.
In SharePoint, there are some key building blocks to Information Architecture including:
- Site collections (logical Site Architecture)
- Sites and sub sites
- Document Libraries and Lists (how many will you have and how will they be organized? By content type? By company structure with multiple content types in each?)
- Folders (will you allow them? If not, how will you train your content contributors to not use them?)
- Metadata (what is the sweet spot for the amount of metadata you want to retain on each content type? what are the different types of metadata you should be using?)
- Managed Metadata (centrally controlled location for terms across an organization)
- Content Types (understand them and use them!)
The need for Information Architecture generally increases as the breadth of your audience increases. As the diagram below depicts, the higher up you are in the triangle, the more important it becomes for a solid Information Architecture to organize and structure your content.
Steps for defining an Information Architecture are:
- Define the content you want to keep in SharePoint, focusing on the top half of the diagram above. (Example: corporate announcements, company procedures, customer records, etc.)
- Decide how you want to lay out your site collections/sites across your environment. This has a significant impact on how you configure any content types/site columns as well as the navigation.
- Define any consistent terms you want to use across your farm/tenant. You can define these in your Managed Metadata Service Application if in an on-premises environment or in the Term store if in SharePoint Online. (Example: department names, division names, product names)
- Define site columns for the metadata you want to retain for your content. I used to suggest a “rule-of-thumb” of 3 to 5 pieces of metadata for each type of content however I hesitate to do that now as the number is very dependent on the particular use-case. If you define too few pieces of metadata, your content may be hard to find. If you define too many pieces of metadata, it may be too laborious for user’s to fill in the metadata. Deciding what’s “right” for your organization and any given piece of content is more art than science, perhaps 8 is right for your particular use-case. You need to balance compliance and user experience. This is the hardest part of IA in my opinion and the ability to do it well only comes with experience.
- Decide on your content type hierarchy. Are there common columns that will be shared across ALL content in your organization? If so, that is a great candidate for a base Content Type. You can define children of that content type to define the more specific types of content you have in your organization. Child content types will inherit properties and behaviour from their parent which makes this a very powerful feature of SharePoint. Be warned: this takes a lot of up-front planning before ever opening up the SharePoint UI. [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]
- Will you use the Content Hub to publish your content types? This will be dependent on the layout of your site collections and your content type hierarchy. If multiple site collections will be sharing content types, you definitely want to use a content hub to provide one place to update and publish content type changes from.
- Only after the preceding steps have been done should you start entering your content types in SharePoint.
Tip: Don’t rush into adding your content types and site columns into SharePoint. Have a complete picture of how your organization’s content will fit into the Information Architecture before ever touching the keyboard.
8. Once you have the content structured like this, you can then begin to layer on some of SharePoint’s Data Governance capabilities on top of it. (Example: retention/disposition policies, data loss prevention, etc.)
I’ve experienced both kinds of environments – ones where no forethought was done on the IA and others where it was planned ahead of time. I suspect there are lots of SharePoint environments out in the wild where IA has not been pre-planned and rework has to be done after-the-fact to retrofit content. This is significantly more difficult than having it set up prior to content being added. If you have the opportunity to define your IA ahead of time, spend the time and do it. It will pay off in the long run.
Thanks for reading.