Welcome to Office Zealot Sign in | Join | Help

How Many Site Collections Do We Need?

I get asked lots of questions about SharePoint.  One of the harder ones to answer is “how many site collections do we need?”  Why?... because, in my opinion, there is no right answer.  SharePoint implementation is a very personalized experience where you, as a member of the implementation team, make many choices of what functionality to use (or not use) and to set a definition for how it should be used.  Determining the appropriate number of site collections is (or should be) dependent on the choices you make in your information architecture and, in some ways, will ultimately depend on the bias of the information architect(s).

Never one to shy away from a question,  I answer in the following way…

Your decision on site collections will depend on your SharePoint knowledge.  This is split into two main categories, technical and tactical.  Technical knowledge is defined by terminology and concept information that you might find in places like here.  It sets the basis for understanding the limits of functionality within and across site collections.  The second is tactical and is focused on your business users.  It sets the basis for understanding how information workers in your environment best work and adhere to structure (including content organization, navigation, branding, and search).  The cross-section of these two help define your site collection roadmap (I use the term ‘roadmap’ to emphasize the need to consistently evaluate your information architecture and course correct – add/consolidate site collections as an example – as needed).  Remember, there is no “right” answer but your users will most certainly tell you implicitly or explicitly if they think you got it wrong.

When I lead a design session and we talk about site collections I lay out for discussion the items listed below.  In the case of an intranet design, I always start with two site collections (one for corporate content, one for ad hoc collaboration), walk participants through the technical and tactical decision points, and challenge the default design until we get to a comfortable place.  This is a very interesting experience as we often find that one item, navigation for example, will sway the decision making.  Sometimes, we end up with one site collection; often times, it is two or many more… but I NEVER set the number until we get to the appropriate level of detail to make an educated choice.

So, sometimes I answer “how many site collections do we need?” with another question “how many site collections do you think you need… and why?”

·         Quota

·         SharePoint security groups

·         Branding

·         Site columns

·         Navigation

·         Search

·         Backup/Restore

·         Features

·         Distributed site collection administration

·         Security

·         Governance

·         Service Level Agreement (SLA)

 

Published Sunday, January 31, 2010 2:36 AM by Mauro

Comments

Sunday, January 31, 2010 5:50 AM by ricky_elias

# re: How Many Site Collections Do We Need?

Our intranet also started with two site collections, one for publishing corporate content and one for team collaboration. I find the more frequent question is “Does this new site/solution require its own site collection?”. I generally respond by asking “Is the purpose of the site/solution part of an existing solution, or is it something new?” If it is new, I always try to put it in its own site collection. The rule of thumb we use is each site collection should provide a single business purpose (i.e. one solution per site collection).

A key component of our governance plan is to maintain a list of (SharePoint) solutions with the following details captured per solution:

 Purpose of solution

 Business owner (sponsor)

 Content manager (key business users)

 Designer/Support contacts

 Solution documentation (solution specific governance, guides)

 Quota

 Farm level dependencies (features, search config, etc)

 … other details for status, migration notes, etc.

Each solution having a single business owner for me has been helpful for administrating SharePoint as many decisions (security settings, branding, restore from backup, migrate to production, quota limits, etc) have impacts that can be scoped at the site collection level. This avoids issues when there a too many stakeholders with differing objectives.

Some solutions are very small, e.g. a single list with incoming email enabled. There is no significant overhead in putting this into its own solution (administratively). More complex solutions involving workflows and SPD customizations benefit from this mode as exporting an entire site collection is an effective way to migrate these solutions from dev to test and to prod.

The collaboration solution can be a SharePoint out of the box commoditized solution to minimise support effort. This includes procedures for requesting and maintaining a site and provides user guides and support for these sites. When the business start requesting extra features outside of this scope, it’s time to start thinking about giving them a separate site collection.

Sandbox solutions in SP 2010 seems to be scoped to a site collection which provides extra weight to the argument that business solutions should be aligned to one site collection.

We also classify each solution as publishing, collaboration or composite-application so that they can be grouped on web apps allowing caching to be configured according to the similar usage profiles.

While these guidelines are appropriate for our enterprise sharepoint environment, I am sure different models would be more appropriate in different circumstances.

# Twitter Trackbacks for Mauro Cardarelli : How Many Site Collections Do We Need? [officezealot.com] on Topsy.com

Tuesday, February 16, 2010 10:06 AM by uconndmb

# re: How Many Site Collections Do We Need?

Just wanted to let you know that this blog is AWESOME! I have been sifting thru it and it seems like just about every question I had / have is addressed here. Thanks Mauro!

Anonymous comments are disabled