Plan for site collections in an EPM/Office SharePoint Server 2007 extranet environment

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2015-03-09

This article describes how to plan for site collections in an Enterprise Project Management (EPM)/ Microsoft Office SharePoint Server 2007 extranet environment. For an overview of this chapter about how to plan for EPM extranets, see Plan an EPM/Office SharePoint Server 2007 extranet environment.

Site collections

Site collections bridge logical architecture and information architecture. The design goals for site collections in the model are to satisfy requirements for URL design and to create logical divisions of content.

To satisfy the requirements for URL design, each Web application includes a single root-level site collection. Managed paths are used to incorporate a second tier of top-level site collections. For more information about URL requirements and using managed paths, see "Zones and URLs" later in this article. Beyond the second tier of site collections, each site is a subsite.

The following figure shows the site hierarchy of Team Sites.

Given the requirement for a root-level site collection, the design decisions revolve around the second tier of site collections. The model incorporates choices based on the nature of the application.

Published intranet content

The assumption for the published intranet content application is that multiple divisions within the company will host published content. In the model, each division's content is hosted in a separate site collection. This provides the following advantages:

• Each division can manage and permission their content independently.

• Each division's content can be stored in a dedicated database.

The disadvantages of using multiple site collections include the following:

• Master pages, page layouts, templates, Web Parts, and navigation cannot be shared across site collections.

• More effort is required to coordinate customizations and navigation across site collections.

Depending on the information architecture and design of the intranet application, the published content can appear to the user as a seamless application. Or, each site collection can appear to be a separate Web site.

My Sites

My Sites have distinct characteristics, and the recommendations for how to deploy My Sites are straightforward. In the model, the My Site application incorporates a top-level site that uses the URL of http://my. The first top-level site collection that is created uses the My Site Host template. A managed path is incorporated (by using wildcard inclusion), which allows an indefinite number of user-created sites. All sites below the managed path are independent site collections that inherit the My Site Host template. The user name is appended to the URL in the form http://my personal/username. The following figure illustrates My Sites.

For more information about how to design a My Sites application, see Design My Sites architecture.

Team sites

You can use either of the following two approaches for designing site collections in a Team Site application:

• Allow teams to create site collections through self-service site creation. The advantage of this approach is that teams can easily create a site, as needed, without assistance from an administrator. However, there are many disadvantages to this approach, including the following:

  • You lose the opportunity to implement a thoughtful taxonomy.

  • The application can become difficult to manage.

  • Sites can easily be abandoned.

  • You cannot share templates and navigation across projects or teams that might otherwise share a site collection.

• Create a finite number of site collections for your organization based on the way your organization operates. In this approach, site collections are created by a SharePoint administrator. After the site collection is created, teams can create sites within the site collection based on their needs. This approach provides the opportunity to implement a thoughtful taxonomy that provides structure to the way team sites are managed and grow. There is also more opportunity to share templates and navigation between projects and teams that share a site collection.

The model incorporates the second approach, which results in a similar site collection hierarchy for team sites as for published intranet content. The challenge for information architects is to create a second tier of site collections that makes sense for the organization. The following table lists suggestions for different kinds of organizations.

Table 3. Different kinds of organizations

Type of organization	Suggested site collection taxonomies
Product development	Create a site collection for each product under development. Allow contributing teams to create sites within the site collection. For each long-term development project, create a site collection for each large team that contributes to the product. For example, create one site collection for each of the following teams: designers, engineers, and content developers.
Research	Create a site collection for each long-term research project. Create a site collection for each category of research projects.
Higher education institution	Create a site collection for each academic department.
State legislative office	Create a site collection for each political party. Government officials who share party affiliation can share templates and navigation. Create a site collection for each committee. Or, create one site collection for all committees.
Corporate law office	Create a site collection for each corporate client.
Manufacturing	Create a site collection for each line of products.

Partner Web

Partner Web is intended to be used for collaboration with external partners on projects that have finite scopes or finite durations. By design, sites within the Partner Web application are not intended to be related. The requirements for Partner Web include making sure of the following things:

• Project owners can easily create sites for partner collaboration.

• Partners and other contributors have access to only the project they work on.

• Permissions are managed by site owners.

• Search results from one project do not expose content from other projects.

• Administrators can easily find sites that are no longer used and delete these sites.

To satisfy these requirements, the model incorporates a site collection for each project. In this manner, the following benefits occur:

• Individual site collections provide the appropriate level of isolation between projects.

• Self-service site creation can be implemented.

Because the Partner Web application also hosts the site collections for developing content for the company Internet site, separate site collections are created for authoring and staging.