Introduction to SharePoint Information Architecture

So your business or nonprofit has acquired Office 365 / SharePoint Online. You made it to the homepage of SharePoint. What is your next step? Well, many just start uploading documents into the default library that appears on the homepage. I know, it is tempting. But as I stated on previous posts – SharePoint is not DropBox. The reality is – unless you want to turn your SharePoint into “Wild West” of documents, you need to first have a plan of what you want your future SharePoint environment to look like. Before the builder builds the house, they put together an architectural drawing which gives you an idea (even before the first shovel of dirt is moved) of what the house will look like, location of all rooms, how big each room will be and how you would navigate around the house. Same applies to SharePoint. You need to have an idea of types of sites you plan to have, who will have access to what site, what you plan to store on those sites, will you share documents externally, etc.

NOTE: December 2018 update

Since I originally published this post, there have been a few significant developments and changes to the site structure best practices. While the below topics still matter, we now have Office 365 Groups and Hub Sites. Please reference this post for the new best practice.

What is SharePoint Information Architecture?

Since we are not architecting houses, but rather are architecting information (documents, data, etc.), in SharePoint we use the term SharePoint Information Architecture. The official definition of SharePoint Information Architecture can be found below:

“SharePoint Information Architecture is the art and science of organizing and labeling the content (documents, data, sites) to support findability and usability”

So how do we even approach the whole SharePoint Information Architecture?

In reality, SharePoint Information Architecture is made up of a lot of different components. However, in my opinion, and to keep it simple, SharePoint Information Architecture consists of the following 4 major building blocks:

• Site Hierarchy
• Navigation & Search
• Taxonomy
• Security

 

I have prepared a slide deck to visually capture and summarize each of the items above, you can check it out at the end of this blog post. What I would like to do now is expand on each of the building blocks and provide more context of what each one means and why it is an important aspect of SharePoint Information Architecture.

SharePoint Information Architecture Building Block # 1: Site Hierarchy

This is the first, but the most challenging step. You kind of need to layout an overall vision/strategy for your SharePoint environment. You really need to have a general idea of how SharePoint will be used by an organization. Some of the questions you need to ask yourself are:

1. Are you looking to migrate all your documents from file shares to SharePoint and make it THE single source/repository for all of company’s documents?
2. Are you planning to share any content with external users (users who are not part of your organization)?
3. What are the types of sites you plan to have in your SharePoint? For example, project sites, department sites, portals to store policies & procedures?

Depending on how you answer questions above will depend on what the Site Hierarchy will look like. SharePoint structures the sites in so-called Site Collections. By default, with SharePoint online, you get a single site collection, which has an address in the following format: http://your_company_name.sharepoint.com In SharePoint we call it a site collection. Essentially, like the name suggests, it is a collection of sites that has 1 site (top level) and sub-sites underneath)

If you are a small organization you can typically get away with just 1 site collection and host all your organizational sites and content on just 1 site collection.

Many organizations just stay within a single (default) site collection and build hierarchies of sites under the Homepage. This is fine if you only plan to have few sites. However, if you are building a true Intranet with a mix of Project sites, Department Sites, sites for external sharing, business portals with workflows – the best practice is to separate those site into several different site collections. There are many reasons for doing so. But the main ones being: Administration, Security and Performance. One clear example is external sharing. Say you want to setup sites that will be externally shared. You are better off sticking them into a separate site collection altogether. This way you can control (enable/disable) external sharing at the site collection level and avoid a situation where your users accidentally share sites outside which were not meant to be shared (i.e. Internal Department sites).

Once you segregate your sites into separate site collections, you need to decide the hierarchy for each site collection. For example, all of the project sites need to sit under a single PMO / Project Dashboard Homepage. This way all new project sites created won’t be lost in the site collection jungle and will all be organized neatly under 1 parent site. Same applies to other types of sites – you want to keep them organized and together. You also need to try and keep the overall site hierarchy as flat as possible (do not build sub-sites under sub-sites under sub-sites!)

Information Architecture Building Block # 2: Navigation & Search

The whole reason you probably migrated to SharePoint was to simplify for your users the process of searching and finding information in your repository. Now that you figured out how you will structure the sites and tag your content, it is time to think about how your users will find it.

This has to deal with how your users will navigate and search for information. One important thing to understand is that the navigation structure might be different from the site structure (site hierarchy) we covered in # 1 above. Site hierarchy / structure we covered above has to deal with physical (behind the scenes) structure of the sites. However, the navigation structure deals with how SharePoint will look and feel to the end user. For example, you might have setup a special project site for external sharing with vendors. So from Site Hierarchy standpoint, you stuck that external site into totally separate site collection. However, from the end user (navigation) standpoint – it is accessible from the same menu as rest of the project sites. Does it make sense?

There is another way to look at this:

• Physical site hierarchy (site structure) serves content owners (users who own / upload the document / information)
• Navigation structure serves content consumers (users who access the documents / information)

Once your users navigate to the right site, they need to be able to find information they are looking for quickly and easily. So proper search configuration is a major aspect here as well. The successful search largely depends on taxonomy which I will cover in next paragraph. If you did a good job with taxonomy (metadata) – you can create various views to sort, filter and group documents so that end users can find them quicker and easier. For advanced users, you can also customize Keyword Search screens and queries so that the search results are presented certain way on a screen.

Information Architecture Building Block # 3: Taxonomy

What is SharePoint Taxonomy?

“The classification of organisms in an ordered system that indicates natural relationships. Division into ordered groups, categories, or hierarchies”

From some of my previous blog posts and presentations, you probably know by now that I am a big advocate for using SharePoint Metadata in place of folders to organize content. This building block does not really apply if you are a hardcore folder user, but if you are willing to entertain the modern ways to organize content – read on.

This is somewhat of an abstract exercise – however, say you are rolling out a mix of project sites, department sites and other sites to store some sort of content (documents).

With folders, you would just create a site, add folders and you are done. Each site is independent of each other and has no common nomenclature or common structure in terms of document management.

This leads to document duplication, inconsistencies with naming conventions, etc.

With metadata that is unique to your organization, you can standardize on “global” (enterprise-wide) terms. For example, if you are planning to roll out department sites – metadata property called “Department” with choices like Marketing, Engineering, Finance, etc. is a good candidate. “Document Type” is another common one (i.e. Project charter, Budget, Schedule). You can also create metadata based on Client Names or Project Names. Of course, this depends on your business. Once you determine you metadata (taxonomy), you will need to organize all the global parameters in such a way that they are available across the whole SharePoint application (not just sites, but all site collection). You can either utilize Managed Metadata (Term Store) or Content Type Hub. Please reference this blog post which describes all the different options available.

Information Architecture Building Block # 4: Security

Last but not least is SharePoint Security. This is where you essentially decide who will have access to what site. This step goes hand-in-hand with Step 1 (Site Structure). You can control security by site, document library or a list, folder (if you are into folders) and even an individual item or a document. The best practice is to stay at the site level in terms of security hierarchy. It is hard enough to manage security for multiple sites, so if you break it down to individual lists, libraries, folders and documents – it will quickly become an unmanageable mess. Another best practice is to organizers users into groups. This way you just add users to respective groups, rather than individual sites. For example, if you have Finance Department Sites and 20 people who are part of it – create a security group called: Department – Finance and add your users in there.

External Sharing is another aspect of security you need to worry about. As given in an example in Step 2, you might have a business need to share documents externally. There are multiple ways to share content externally. You can share whole site or an individual library or an individual document. You can also share documents with or without authentication. There are lots of choices to make, so make sure you make appropriate decisions before the first document is shared externally!

I hope you found this blog post helpful. SharePoint is a complicated application and like an above mentioned example with houses – requires constant attention and maintenance. For those of you who are more visual, I prepared a quick slide deck which summarizes everything we covered above.

Enjoy!