Establishing and governing a SharePoint service (SharePoint Server 2010)

Article
07/22/2014

Applies to: SharePoint Server 2010

A successful Microsoft SharePoint Server 2010 deployment relies on an enterprise's ability to govern the service and ensure that the service meets the business needs of the customers in a secure, manageable, and cost-effective way. This article describes typical elements of an IT service that hosts SharePoint Server 2010, suggests key success factors in governing an SharePoint Server service, and provides an example of a three-tiered SharePoint service.

What is a SharePoint service?
Elements of a successful service
What to govern in a SharePoint service
Creating multiple services
Service-level agreements

What is a SharePoint service?

A SharePoint service is an IT service that offers hosted sites based on Microsoft SharePoint 2010 Products. Among the things that a service provides are the following:

Sites at a scope, such as site collection, Web application, or server farm
Backup and recovery
Content storage
Support for customizations
Security
Service levels that are based on speed and availability

Elements of a successful service

As you envision and implement your SharePoint Server service, consider the following elements that can contribute to the success of the governing effort:

Form and use a governing group

Your IT service that supports SharePoint Server should be governed by a group that includes executive stakeholders, business division leaders, influential information workers, IT managers, and IT technical specialists, among others. The goal of the governing group should be to oversee the service. In this capacity, the governing group defines the initial offerings of the service, defines the service's ongoing policies, and meets regularly to evaluate success.
Communicate about the services

The governance policies that you develop must be publicized to your enterprise. Maintain a Web site that describes the set of services.
Encourage use of the service

Discourage or block users from deploying their own servers. Instead, encourage them to use the service. Isolated servers may not be configured in accordance with IT security policy and the enterprise’s regulatory requirements. Furthermore, users who deploy their own servers may fail to properly back up their servers or fail to keep servers up-to date with software patches and updates. Finally, content on servers that are not governed by the service may not be crawled by the enterprise’s indexing service, which may create isolated pockets of content.
Create multiple services

You should offer a set of services that support SharePoint Server. For example, one service could provide thousands of sites for collaboration and another could support very large, mission-critical sites, such as enterprise intranet sites. A set of SharePoint Server services enables you to apply unique governance rules and policies at various levels of service so that you can vary the cost that you assess to organizations based on their level of service. Lastly, a tiered service enables you to phase in services in a manageable way.

What to govern in a SharePoint service

As you design IT services that support SharePoint Server, a governing group should determine the limits and policies to control the services. If you choose to use the multi-tenancy features in SharePoint Server for hosting services, you can enable an IT group to delegate common administrative tasks for a set of sites to the business unit owners. This allows an IT group to focus its attention on the service itself. For more information about multi-tenancy, see Hosted environments (SharePoint Server 2010).

Determine limits and policies for the following elements of services:

Quota templates

A quota template consists of values that specify how much data can be stored in a site collection. The value also indicates the limit that triggers an e-mail alert to the site collection administrator. You can associate quotas with sites that are offered at various service levels to govern the growth of SharePoint Server in an enterprise. Note that you can set separate quotas for sandboxed solutions.
Maximum upload size

At the Web application level, you can set limits on the maximum size of uploaded files. All sites within the host Web application use the same limit.
Site lifecycle management

You can govern how sites are created, the size of sites, and their longevity by using self-service site management and site-use confirmation and deletion. You can also set expiration and access policies to control the lifecycle of content in sites.

Self-service site provisioning enables users to create their own top-level Web sites by visiting an IT-hosted page and supplying data about the site’s intended use. The site can then be provisioned based on a custom workflow. For various levels of service, you can govern the size of such sites and control their longevity.
Customization policy

A primary benefit of using sites that are based on SharePoint Server is the ability of site owners to customize them. For example, site owners might change a site's appearance or provide new functionality, such as a custom Web Part or workflow. Carefully consider the type and amount of customization that is allowed and supported at each level of service because some types of customizations are global to the server farm.

Consider using sandboxed solutions to limit the impact of customizations in a farm. For example, services that allow self-service site creation may include thousands of sites that share a single Web application. In this instance, you could limit customizations to only those sites that are supported by the user interface, such as adding Web Parts to pages. If you use sandboxed solutions, the customizations apply only to that site collection. In a service that provides virtual or physical isolation of the server farm, such as for an enterprise intranet site, you might allow a large range of customizations, such as custom event handlers and workflows.

At the Web application level, there is also the ability to control whether SharePoint Designer can be used to modify sites in that Web application. For more information, see Configure settings for a Web application (SharePoint Server 2010).

For a full discussion of the range of customizations that SharePoint Server 2010 supports and the risks and benefits of supporting each type of customization at various levels of service, see the white paper SharePoint Products and Technologies customization policy (https://go.microsoft.com/fwlink/p/?linkid=92311). Although this content is specifically written about Microsoft Office SharePoint Server 2007, much of the information applies to SharePoint Server 2010. For more information about sandboxed solutions, see Sandboxed solutions planning (SharePoint Server 2010).
Asset classification

You can develop and implement a classification system for sites and content supported by a service that identifies the impact and value of the information to an organization. For example, metadata can classify content as having high, moderate, or low business impact or value.
- Impact is related to exposure and content: if the content were distributed externally, would it hurt your business? Or would it expose personally-identifiable information about users or customers? If so, that's high business impact content.
- Value is related to availability: if the content were unavailable, could it impact the enterprise's day-to-day business? If so, that's high value content.
Each classification would then cause other behaviors – for example you could require that high business impact content be transferred only in encrypted form, or you could require that an approval process be run on medium impact content before it can be published on a public-facing Web site. Perhaps high business impact content should be hosted on a service that provides more restrictive policy and aggressive disaster recovery processes.
Lifecycle management

A service should provide lifecycle guidelines or tools for active sites and unused sites. For lower service levels, you could, for example, implement a mechanism that lets only site owners create sites that last six months before the user would have to extend the request for the site. Also, you can implement a tool that looks for sites that have not been used for a specified period of time and deletes them. Lifecycle management also means integrating a service with the records management tools and processes in place in an organization. For more information, see Records management planning (SharePoint Server 2010).
Branding and navigation

Consistent branding with a corporate style guide makes for more cohesive-looking sites and easier development. Master pages and templates help create the visual brand of a site. Store approved master pages in site galleries so that site designers use them consistently. A consistent design helps users confirm that they are in the right place when they look at the site. Define the parts of the template that can and cannot be changed by site owners. Allow room for sub-branding of individual team or project brands.

Consistent navigation is also key to ensure that users do not become lost as they navigate the services looking for content.
Data protection

Features that provide data protection include backup and recovery. You can vary the level of data protection based on the service levels that you provide. Higher levels may require charges to the site owner. For each level of service, plan the frequency at which you will back up sites and the response time you will guarantee for restoring sites. For more information, see Plan for backup and recovery in SharePoint Server 2010 and the Business Continuity Management Resource Center (https://go.microsoft.com/fwlink/p/?LinkID=199235).
Security, infrastructure, and Web application policies

Maintain the infrastructure and monitor access to the infrastructure and content to make sure that you have a stable and secure environment. Use Web application policies to allow or deny access to the content in accordance with compliance rules or business needs. Keep the infrastructure current with software updates to make sure that you have the latest improvements and fixes.
Training

A well-trained user community provides benefits to IT. It reduces support calls, encourages adoption, helps ensure proper use of SharePoint Server, and helps users understand their responsibilities when using the SharePoint Server service. For each level of service, consider an appropriate level of training requiring as a requirement. Even for a basic service, users with site administration permission will have access to many features that affect the functionality of the site. Online training, such as tutorials, for these users can help them take the best advantage of their site.

Training for a user community is available at SharePoint 2010 Resources for End Users (https://go.microsoft.com/fwlink/p/?LinkID=199542)

Creating multiple services

Users of an enterprise’s SharePoint Server service require sites that meet a range of purposes:

Short-lived, single-purpose workspaces for planning events and managing meetings and projects
Team sites for general collaboration
Divisional portals for large workgroups to manage their business processes
Enterprise intranet sites to broadcast information and supply services to the entire organization

Consider dividing a SharePoint Server service into a set of services that meets the range of needs in an enterprise. Each user of a particular service would get the same level of support and would be charged a similar cost. As more complex or costly solutions are needed, you could add new services to support them. One benefit of this approach is that you can introduce one service at a time, which eases the burden on your IT staff. Work with executive stakeholders, business division leaders, and IT managers to determine the requirements of each level of service and the order in which services are introduced.

The following table illustrates a sample approach to creating a tiered set of services. In this example, three service levels are offered. Note that provided values are not recommendations but are supplied as samples:

Sample approach to a set of services

	Basic Service	Advanced Service	Premium Service
Description	A server farm that is used to host tens of thousands of customer site collections. It is intended to support short-lived sites along with small team sites.	A server farm that is designed to host a small number of portal sites. It is applicable to customers with some requirements for server-side customizations that will not interfere with other sites that are hosted on the same servers.	A server farm dedicated to hosting a large, highly customized or highly critical site. The topology is scalable depending on the agreed upon hosting requirements between the customer and the hosting team.
Example	Collaboration site to plan an event	Division portal including integration with line-of-business data and custom workflows	Enterprise intranet site that includes large-scale integration with multiple back-end systems
Scope	Site collection	Web application	Server farm with multiple Web applications
Customizations	Only customizations available in the user interface are supported.	Some server-side customizations, such as custom site templates, are supported. All customizations are tested and reviewed before being accepted for deployment. Alternatively, customizations are allowed only as sandboxed solutions.	Extensive customizations are permitted. All customizations are tested and reviewed before being accepted for deployment. Alternatively, customizations are allowed only as sandboxed solutions.
Cost to user	None to minimal	Moderate	High
Self-service provisioning?	Yes	No	No
Content storage limits	500 MB	2 GB	Unlimited
Backup frequency	Twice weekly	Daily	Daily
Backups maintained for	14 days	30 days	60 days

Service-level agreements

Establish service-level agreements for each service level. A service-level agreement should include the following items at a minimum:

The length of time and approvals that are necessary to create a site.

What's the process to create a site? Who's involved?
Information about the costs for the service to users or departments.

Who gets charged, and for what?
Operational-level agreements that specify the teams that perform operations and the frequency.

Which team applies updates? Which team performs backups? How frequently do these occur?
Policies about problem resolution through a help desk.

When a user gets stuck, who do they call? What's the escalation path?
Negotiated performance targets for the first load of a site, subsequent loads, and performance at remote locations.
Recovery, load balancing, and failover strategies.
Customization policies for the service.
Storage limits for content and sites.
Multi-language support.

Which languages will be installed and supported?

Establishing and governing a SharePoint service (SharePoint Server 2010)

What is a SharePoint service?

Elements of a successful service

What to govern in a SharePoint service

Creating multiple services

Sample approach to a set of services

Service-level agreements

See Also

Concepts

Other Resources

Additional resources