Site Hierarchies

Determining the site hierarchy of your SharePoint implementation may seem like a straightforward task: break out the latest organizational chart and start creating sites to match this structure. While this isn’t always a bad approach, it's important to understand the business, how it is broken down, and how each unit interacts with the others. Some common breakdowns of site hierarchies include:

• Line of Business
• Geography
• Product Line
• Organization Chart

To really know the business and its structure, it's important to get input from different people within different levels of the organization. What you will find is that these individuals or groups have slightly different hierarchies based on their level and needs within the business. A good approach to determining a logical hierarchy is to work with the different business units to get their take on a hierarchy. Once all the feedback from each group is captured, a hierarchy can be created based on the feedback. Keep in mind this can be done at a high level, but also at a lower level within each business unit. The starting and ending point of the hierarchy is dependent upon the size of the business. Once a common hierarchy has been determined, be sure to share the results with the business, as this provides a great opportunity to get buy-in and show that feedback was taken into consideration.

SharePoint Hierarchy Considerations

Understanding the hierarchy provided by SharePoint is important to consider when determining the hierarchy of your SharePoint farm. SharePoint provides the hierarchy shown in Figure 9-1 for creating a SharePoint farm.

Figure 9–1. SharePoint Hierarchy

Most time is spent determining whether a new site should be created as a site or a site collection. It's important to understand the pros and cons of creating a site collection vs. a site and how that impacts your taxonomy. Some important items to consider when choosing a site vs. site collection include the following:

• Storage Quotas: Storage quotas provide a great way to keep data growth under control. SharePoint provides this capability at the site-collection level, but not at the site level. Defining a storage quota depends on the type of content being stored and the storage space available. 100 MB is a common storage quota for a My Site, and is sometimes used for collaboration sites as well.
• Security: SharePoint security is controlled at the site-collection level. By using multiple sites within the same site collection, it can become necessary to break inheritance. This can lead to numerous SharePoint groups being created which can lead to a security nightmare. Since SharePoint security is limited to the site collection, SharePoint groups defined in one site collection do not carry over to another site collection automatically.
• Content Database: A content database can store one to many site collections, but a site collection cannot span multiple content databases. A site collection can be moved into a separate content database, perhaps on a separate server, if needed. This could be for disaster recovery, capacity, security, or all of the above. A single site within a site collection is tied to the site collection, and therefore cannot be moved in its current structure.
• Navigation: Defining the navigation scheme is probably the biggest challenge when referring to site hierarchy. Sites within the same site collection appear automatically within the site navigation. Since site collections don't have a hierarchy, there is not automatic support for cross–site collection navigation. Most solutions that utilize cross-site collection rely on a custom navigation solution that reads an XML file to create the appropriate navigation.

Even with the information above, it is still difficult to create an effective site hierarchy. Microsoft provides a site planning data worksheet that can aid in this effort. This worksheet can be found at the following URL: http://go.microsoft.com/fwlink/?LinkID=167837.

Search vs. Click

There are two types of users within SharePoint: users who will click through the navigation and site hierarchy to find what they need and users who will go right to the search box and type in the key word of the content they are trying to find. With the advancement and emphasis placed on search in the world today, more and more users are utilizing search to find the content they need. However, it's important to satisfy both types of user, the searcher and the clicker. The clicker can be satisfied with a well-planned site for navigation and site hierarchy. If the site navigation and hierarchy follow the business and are intuitive to navigate, the chances of the end user finding what they are looking for is high. The searcher can be satisfied with a rich set of search results. This can be accomplished by having a strong information architecture utilizing content types and metadata across the enterprise. SharePoint 2010 has introduced metadata navigation, which aids both those using search and those who click through the hierarchy. As stated before, it's important to support both types of users. However, it's even more important to understand the users and how they interact with SharePoint. Ask the users how they find content in SharePoint. Through search? Through clicking through structure? This simple question will provide great insight into how users are interacting with the information and if there is a potential issue with the information architecture that needs to be addressed.