When planning out the site structure of a new SharePoint system, here are five things I take into consideration. Taking these into account during your planning phase will hopefully reduce the amount of rework needed as your system evolves.
Amount of data
If you are expecting a large data set, perhaps you are scanning all supplier invoices and using SharePoint for Content Management, its important to consider the size of a Site Collection and the underlying Content Database from an Administration standpoint. Larger Site Collections and Content DBs require more care and attention along with a more advanced skill set. There have been a number of discussions on what the guidelines are, but I aim to keep Content DBs under 40Gb unless there is a real exception. In this case, the size of the data over rules any of the other answers.
For site collections I expect to grow large, I set them up in a dedicated Content DB right from the start. This saves the trouble having to move it to a different content DB later which can take some time with large sites.
Type and Purpose of the Sites
In a small to mid-sized organization I typically treat sites that support Intranet or department level collaboration a little different than cross-functional or project type sites. Its easy to define the groups around the functional areas and you can reuse those groups in other sites where there is overlap.
In larger organizations sites typically require more isolation. There may be a some interaction between the groups, but not within divisions. In this case the Site collections can be structured to support the organizational boundaries.
Groups Definition and Membership
Groups are defined within the site collection container. If you setup a group called “Management” in Site Collection A, it wouldn’t be available to Site Collection B unless its setup separately. It may not sound like a big deal, but it gets very tedious when you have to manage the same group in multiple places. To make matters worse administrators often take for granted who is in the group based on the name. When setting Site Permissions a group’s members is not directly visible.
WSS and MOSS have some good out of the box navigation systems. They are limited though when it comes to trying to tie together multiple Site Collections. There are solutions like defining custom providers but then you are introducing sophisticated customizations that not every company can support. A last ditch option is to manually link to sites and resources but then everything becomes much more difficult to manage.
If it is important to have a consistent horizontal navigation scheme, look to keep as much as possible within a limited number of site collections.
Aggregating or Reusing Data
One of SharePoint’s greatest values is in its ability to support syndication and aggregation of content to deliver it where the users need it. You can aggregate the content using tools like the Content Query Web Part or DataViews. These techniques get a little more complicated when content is in different site collections. Custom code or third party tools are then required to accomplish bring things together.
Agree? Disagree? Let me know, I would love to hear your feedback.