One of the more basic “value-adds” of SharePoint is the abstraction of IIS web sites and data stores as “web applications” and “site collections”. Because this abstraction has worked well, there has been no fundamental change to these concepts in SharePoint 2013.
In cases where there is a need for a larger number of site collection within a web application, SharePoint 2013 provides a new option known as “host named” site collections. In SharePoint 2010, site collections can be configured to reside in locations/URL via paths (either explicit or wild-card inclusion). While setting up site collections via paths is easy, path-based site collection come with certain limitations including number of site collections and URL format. Host named site collection allow a more flexible mapping of site collections to URLs, web applications, and zones. This mapping is accomplished via Windows Power Shell. (Click here for details and limitations)
One of the on-going challenges of the site collection model is the handling of content-intensive applications. Since site collections can only, as a practical matter, hold 200GB, multiple site collections sometimes must be created when there is no functional or business need. Unfortunately, each site collection has unique site permissions, groups, web part gallery, master pages, and page layouts, which must then be individually managed. Multiple site collections also present other challenges including UI/navigation usability and inability to use key web parts (e.g. content query) across all the content in the web application.
Since SharePoint 2013 does not provide a means to allocate storage independently of site collections, the following options can be pursued:
- Partition collaboration and portal sites into separate web application. This is, in the great majority of cases, a best practice and will provide more flexibility for both types of sites.
- Insure multiple site collections are REALLY needed for your portal application. The majority of available guidance presumes multiple site collections are need or, at the least, does not consider the feasibility of a single site collection. If multiple site collections can be avoided, deployment and maintenance of applications is much easier.
In cases where multiple site collections ARE needed the site content should be organized into a small number of stable site collections. Some options include:
- Collaboration Applications – rather than creating a site collection for each team, allocate a site collection for each department. Then, departments can manage creation of sites/sub-sites within the site collection.
- Portal Applications – allocate site collections based upon a functional, content oriented site map (not an organization-based site map). This will avoid the problem with re-factoring department-based site collections after every company re-organization and goes hand-in-hand with Information Architecture best practices.
- “Hot Spots” – site collection can be allocated for active, large volume content areas such as corporate-wide document sharing sites.
- Live with multiple site collection and keep site collections consistent vis manual processes – this, of course, is the first and last resort. If you can stabilize you site collection architecture to a small number, this can become a practical. Out of the box capabilities, such as Content Type Hub, can be used to ease management burden
- Acquire a 3rd party product to keep site collection framework in-synch across multiple site collection. Multiple vendors offer such solutions, at a cost.
Note that this advice applies equally well to SharePoint 2010 as 2013.
Thanks Bob, your suggestion to allocate a site collection for each department is a sterling tip.