Bernard Hennecker's Blog

Within the numerous features, configurations and setups that are offered by SharePoint (see previous article for the ones we focus on in this series), the choice of powering communities with one or more sites collections seems to be a difficult one to do.

Ideally

In the scope of a community, the preferred choice would be to work with one site collection because of the many integration possibilities available and the simplified administration. Within one site collection, it is easy to:

• Manage resources in separate sites, lists or libraries while being able to easily display them together
• use similar metadata and content types across all sites, lists and libraries
• control the look and feel from one central place

At the same time, one single site collection provides simple administration by allowing users and permissions, galleries, settings, reporting and logging to be controlled from one place.

Such choice is also driven by IT constraints and should carefully be planned by taking those into consideration. In a nutshell, they include: database size, backup and recovery and capacity planning. Several excellent articles are available about this specific topic, and I can only recommend you to look at Tips on Site Collection Sizing by Joel Oleson and Plan for software boundaries on Microsoft Technet.

In practice

In reality, there are chances that site collections supporting similar communities may already have been deployed in another group or geography. They may provide a subset, a similar or quite different list of the resources planned in your new community. People in your group may be aware of this community, already use some of their resources, and, as your role is to help leverage data and information across the company, you probably have no other choice than providing some level of integration with those existing site collections.

So, instead of spending too much time in carefully designing your site collection, taking into account its space consumption usage, its backup and recovery constraints, etc… I would rather recommend to concentrate on the possibilities your site collection will have to integrate with other site collections. This will avoid endless discussions because, sooner or later, due to an organizational or people change, you will have to reconsider your original design and, either split the resources managed or on the contrary, consolidate with other resources.

Conclusion

Site collections provide numerous possibilities to manage community resources together while still allowing the possibility to handle and present them in separate contexts via separate sites, lists, libraries and pages. You should use those as much as you can, but do not expect to support all possible scenario’s. Integration with other site collections should be part of your original design to allow a flexible and adaptive architecture. In addition, that will help when you will have to integrate with repositories or tools that are not running on SharePoint.

See also

• Determining Between SharePoint Site Collections and Sub-Sites by Steve Goodyear
• Determine sites and subsites needed on Microsoft Technet