Chapter 24. Governing the SharePoint 2013 Ecosystem

Managing any software product takes time and energy, but few software products provide the number of tools and allow for the same range of interactivity with end users and their data and ideas as the SharePoint product line. With many software products, the work is mostly done when the servers are built and the software installed and working. But with SharePoint 2013 (and previous versions), it can be said that the work is just beginning when the environment is configured and in use.

Of course, SharePoint 2013 can be locked down so that a very limited number of users can add documents, use My Site sites, or add items to lists, but then the value of what is at the heart of a set of collaboration tools diminishes. At the other end of the spectrum, allowing complete freedom to all users to create sites, delete sites, and leverage every tool in the SharePoint 2013 arsenal would most likely lead to a state of anarchy where users would have little faith in security and stability of the environment.

The term governance in the context of SharePoint 2013 includes concepts of maintenance of the hardware and software that supports the tools, but is more focused on creating and enforcing policies, rules of conduct, and the process of understanding “what’s going on” in the environment. This chapter discusses governance from a conceptual and process-oriented level, while giving examples of specific SharePoint 2013 tools and components that should be included in the governance plan, many of which are covered in other chapters of this book in greater detail.

Ultimately, this chapter shares strategies and tools to consider for defining a governance plan for a SharePoint 2013 environment that any sized or shaped company should consider and helps provide impetus to get started on the road to effective governance.

An almost universal experience is that of data repositories that have not had the proper governance, whether it be paper-based files, file shares, or the email environment, and these generally tend to be inefficient and sources of contention. There are many strong reasons for putting governance in place for any applications, three of which follow:

Although maintenance costs of “unmanaged applications” seem low initially, the impact on the organization can be significant in the long term in less-tangible ways. User complaints about not being able to find anything, not understanding the purpose of different applications through lack of training, or not being able to get support when issues are encountered, erode the level of confidence in the application and ultimately in IT.

Unmanaged applications over time either become abandoned or fail to garner user adoption. Consider a poorly managed intranet. It may have cost a considerable amount of time and money to create, and there may be recurring software costs and resources dedicated to keeping it running, but without appropriate governance, it can become disorganized, the content stale, and users unhappy with levels of support provided.

Unmanaged applications are difficult to secure. If policies for entitlement and rights are not well defined from the beginning, securing vital corporate assets can be difficult later on. It is usually harder to take away user privileges and tools than just to control what is provided to begin with.

SharePoint is a powerful tool with tremendous potential. By spending time prior to or during the implementation of SharePoint 2013 on the governance plan, IT can help ensure that the project is initially perceived as a success, that the environment offers a well-defined set of tools to end users, and that it will be managed over time as it evolves.

A final thought for this section is that the governance plan does not need to fall into place all at once. There can certainly be phases to a governance plan, as there are phases to technology implementation projects.

This section discusses the importance of having vision and scope of work documents in place before diving into the governance plan, provides recommendations on a starting point for the governance plan creation process through a visualization tool, and then moves into the components of the governance plan.

It is understood that the temptation to skip the documentation process is very strong, but to show how simple this can really be, here is a simple vision and scope of a work statement that provides enough basic guidance to develop a governance plan:

Vision statement: The goal of SharePoint 2013 at Company 123 is to provide a better alternative to our current intranet and file share while providing enhanced collaboration tools.

Scope of work summary: SharePoint 2013 will be implemented by internal IT resources, with assistance from subject matter experts in a phased approach. The phases will be proof of concept (POC), pilot, implementation/migration, and finally governance and support. Best-of-breed backup, management, and add-on web parts will be identified in the POC phase. Documentation of server builds and recommended best practices for maintenance will be included, as will knowledge transfer to internal IT resources.

Guiding principles and steps such as these provide direction to the project and define basic milestones. Without at least a basic and agreed-upon foundation of vision and scope, the chances of a successful project are reduced; in fact, even determining whether the project was or was not successful will be difficult, because the success criteria and milestones were never set.

One way to define this diagram is to call it an equalizer chart, referring to the piece of audio hardware. This brings to mind the process of determining different settings for the components that comprise the SharePoint 2013 environment and then adjusting the individual settings as time goes by to tune the overall levels of governance. A distinction to make at this point in the governance process (brainstorming) is that the chart is driving the output rather than data driving the chart. For example, if the IT department is locked in a room working on this chart together, the CIO might simply say, “We don’t have budget for new staff or any additional software and we’re not supporting My Sites.” That would immediately result in the removal of the My Site component from the chart and “shorten” the bars across the board because the component of support resources is reduced.

To further understand how this chart can be useful, review Figure 24.1 in more detail. It is suggested that on the far left, the bar that represents governance of the servers that support the SharePoint environment (for example, Windows 2012 servers, one or more Structured Query Language [SQL] servers, and one or more SharePoint 2013 servers) represents a maximal level of governance. Company 123 governs these servers very carefully, fully realizing that if they aren’t stable, the entire environment suffers. Therefore, the bar takes up the full height (or ranks an 8 of 8 in governance). To be more specific, there are standards for the operating system configuration in place, as well as for which version of Windows Server will be installed, how patches are applied, and antivirus use. Standards are also in place for backup software, maintenance plans for the SQL databases, as well as strict controls over which Active Directory (AD) groups and users have permissions to manage these servers.

Moving to the right in Figure 24.1, the Central Administration site will also be tightly controlled in terms of the configuration of the various components, such as web applications, jobs, reporting, and groups and accounts, that can make changes, and ranks a 7 out of 8. The service applications will be governed at a similar level. Site collections will be slightly less controlled and governed (6 of 8), sites still less (4 of 8), workspaces still less (3 of 8), and My Site sites the least (2 of 8). The lists and libraries will be governed to a medium degree, while the overall taxonomy more highly managed, and business processes (which include workflows) in the medium range.

Continuing with this visualization, each bar on the chart can be broken down into components, including the following:

Resources involved in the governance process: This should include full-time and part-time resources as well as consultants and contractors.

Level of security and privilege constraints implemented: A higher level of security translates to added governance, or control over the specific area that generally requires more time to manage than “looser” controls.

Templates used for creating the site collection, site, list, workflow, and other components: Templates take time to create, manage, and update, as well as time to verify they are in fact being used.

Reporting and auditing to track events and activities: This includes the built-in tools in the operating system, Internet Information Services (IIS), and SharePoint 2013, and can include third-party tools such as Microsoft System Center Operations Manager and products from AvePoint, Axceler, Metalogix, Quest, or other third party.

Policies and procedures to define acceptable usage of the resources: These can be enforced to a certain degree by the tools in place (SharePoint and third party, group policies, and so forth), but these also need to be documented and communicated to the user community and at some level enforced.

Third-party tools to add functionality: Besides the possibilities mentioned previously, third-party tools can be used to add functionality to SharePoint 2013 in every conceivable area, or tools (such as new web parts) can be created internally.

Figure 24.2 gives an example of what generates the height of several sections of the chart, which should be translated as cost and level of effort. In this example, starting at the right, the My Site environment will be minimally governed at Company 123. Support staff is a fixed number, but no additional training will be provided to them on My Site support; the basic out-of-the-box templates will be provided, but no new ones created; and policies and procedures on My Site usage will be loosely defined, to essentially clarify that users can do what they want within the constraints of the software. Moving to the left, workspaces will be allowed, which translates to users having self-service site creation privileges, and the regular templates for meetings and document workspaces will be provided. The policies and procedures for using the sites will be loosely defined, and out-of-the-box auditing and reporting will be in place. However, IT will not be responsible for policing or cleaning up idle or abandoned workspaces. Moving to the Sites column shows a higher level of governance where the governance items security constraints and third-party tools have been added, increasing the level of governance. IT wants to strictly control privileges for the sites themselves that house the workspaces, lists, and libraries that users will be using. Finally, to the far left, the site collections will have additional constraints and auditing tools in place. IT will track carefully the different levels of usage of the site collections (as opposed to the sites themselves, which won’t be as carefully managed) and have tools in place to manage the site collections.

Often, the emphasis is placed on the IT administrator, whereas little emphasis is placed on necessary business roles, designer roles, or even IT support structures. It’s common to find entire roles undefined and failures can definitely happen as a result.

To start with, the organization should define the SharePoint farm administrator and site collection administrators. Key stakeholders, project managers, and business analysts can also add value to the governance process. For example, defining a “SharePoint steering committee chairperson” and “taxonomy czar” can enhance the involvement of individuals in specific areas of the ongoing maintenance of the SharePoint 2013 environment. Members of the SharePoint steering committee might not be technical in nature, but they will bring their individual perspectives to the process and help drive adoption of the technologies (and often, funding for specific initiatives).

Many organizations use a RACI charting strategy, which stands for responsible, accountable, consulted, and informed. A RACI chart is a simple and powerful vehicle for communication. It is used for defining and documenting responsibility. For each aspect of the project, both the initial rollout and the day-to-day management should have the people and their roles identified as well as the level of their involvement. This helps keep resources focused on their tasks and levels of involvement and usually enhances communications paths. Often, roles and responsibilities cross group and team lines. Figure 24.3 shows a RACI table example for Company 123.

To begin, the organization should work through the different components of Central Administration. Chapter 6, “Managing and Administering SharePoint 2013 Infrastructure,” gives a thorough walkthrough of the basic management categories that are broken out in Central Administration, as follows:

Application Management

System Settings

Monitoring

Backup and Restore

Security

Upgrade and Migration

General Application Settings

Configuration Wizards

The following is a partial list of important topics for which systemwide policies and standards should be defined:

Site collection creation standards: Important items to cover in governance include which templates will be used, the use of managed paths, and the creation of different content databases for site collections. In addition, the use of site quotas, and their settings, is included. The site collection administrators need to be defined for each site collection and whether self-service site creation will be allowed.

“Standard” service application standards: For the required service applications, the settings should be reviewed. For example, the Search Service application has a number of settings that need to be configured, such as Content Sources, Crawl Rules, File Types, Authoritative Pages, Query Rules, and other settings. The User Profile Storage Service application performs a vital role in syncing with AD, and has numerous other capabilities that can be configured, such as compiling audiences. Usage and Health Data Collection is generally considered a vital component for IT to manage and monitor farm usage. Some less-familiar service applications like the Secure Store Service application and Managed Metadata Service application should also be reviewed and tested to see whether and how they will be used in the farm.

“Optional” service application standards: If SharePoint Server 2013 Enterprise is being used, a number of additional service applications can be rolled out, including Access Service application, Excel Services Service application, PerformancePoint Service application, PowerPoint Service application, Visio Graphics Service application, and the Word Viewing Service application. The organization needs to decide which of these will be deployed, to which users, and at what point in the project. Rolling out “everything” during the initial phases of a project is generally considered ill-advised unless both the user community and IT are fairly advanced in their SharePoint skills and training is provided for resources who will be managing these tools. Figure 24.4 illustrates a portion of service applications available in the Enterprise edition of SharePoint 2013.

Managing services on servers: For multiserver implementations, decisions should be made concerning which services will run on which server. This can impact performance and the user experience, since overloading servers will impact their responsiveness.

Monitoring settings: Pay special attention to the tools in this section of the Central Administration site because they allow the farm administrators to review problems and solutions, review rule definitions, review job definitions and job status, view administrative reports, configure diagnostic logging, review information management policy usage reports, view health reports, configure usage and health data collection, and view web analytics reports. Chapter 11, “Monitoring a SharePoint 2013 Environment,” provides more information about these built-in tools and provides information about Microsoft’s System Center Operations Manager (SCOM).

Backup and restore: A high-level decision to be made here is whether the native SharePoint backup and restore tools will be used or if third-party backup tools from Symantec, Commvault, AvePoint, or others will be used. If the native SharePoint tools will be used, the farm administrators need to become familiar with the use of these tools and understand their strengths and weaknesses. Although a basic service level agreement (SLA) may be separate from the governance plan, the capabilities of the tools will affect the farm administrators’ ability to meet end-user requests. Chapter 10, “Backing Up and Restoring a SharePoint Environment,” provides additional information about this topic, including using PowerShell for backup and restore and backing up IIS configurations.

Security: This page provides access to tools such as the farm administrators group and its members, web application security policies, managed accounts, service accounts, blocked file types, web part security, information rights management, and whether labels, barcodes, auditing, and retention will be available for use. Chapter 15, “Implementing and Validating SharePoint Security,” gives additional information about this topic.

General application settings: As shown in Figure 24.5, these settings include tools such as External Service Connections, InfoPath Forms Services, Site Directory, SharePoint Designer, Search, Reporting Services, and Content Deployment. Each of these tools should be reviewed and decisions made about their configurations.

Having reviewed this list, you might think it sounds like an overwhelming task to define how each and every component will be configured. However, it might suffice, based on the organizational needs, to just create a grid of which features and tools will be made available during the initial phase and not delve too deeply into the individual configurations of the tools.

Chapter 18, “SharePoint Foundation Versus SharePoint Server 2013,” provides a number of charts that can easily be adapted for use in the governance plan, to provide a summary of high-level organizational decisions about which tools and features will be used and supported. For example, Table 24.1 provides a grid that could be used to define the decisions that are made in the area of service applications with a minimal investment of time, and without delving too deeply into the details of the configuration of each service application.

As mentioned previously, other chapters in this book review features at this level and can help designers and planners determine which features offer the most value to the organization and should therefore be governed.

For some organizations, the activity of reviewing the functionality can be done in the scope of a few hours; in others, this process might take months. In either case, the end result is a list of functionality that helps give shape to the governance plan in terms of which tools and features will be supported by IT and therefore need to be governed.

Another key element of the governance plan is defining the scope for which functionality will be governed. Whereas some settings are global to the farm, others are specific to the web application or the service application, and therefore can be made available to limited groups of users. This can, of course, complicate the governance process, but in most organizations, there is a demographic of users who are highly advanced and can be trusted to use more advanced functions, whereas a majority of users would simply get confused or not be interested. Being able to cater to the more advanced group is often where innovation and improvements come from. For additional granularity, features can be activated/deactivated at the site, site collection, web application, or farm level. Depending on how your organization decides to develop its taxonomy or information architecture, activate the features at the appropriate scope to simplify management. The web application and site collection level are usually a better place to manage most functions.

Chapter 21, “Designing and Managing Pages and Sites for Knowledge Workers,” provides a thorough exploration of the different tools available to the site collection administrator and the subsets available to the site administrator. Figure 24.6 shows the Site Settings page when a site collection administrator logs in to a site collection where most of the site collection features have been enabled, which enables additional management tools. Not all the tools need to be included in a governance plan, but the governance plan should address several key areas:

To begin, the question of which site collection features and site features should be enabled needs to be addressed. For example, IT may not want end users to use the legacy SharePoint 2007 workflows, PerformancePoint site collection features, Document ID Service, and In Place Records Management site collection features. IT might also want to make sure that SharePoint Server Publishing Infrastructure site and site collection features are not enabled.

Managing the site columns and content types in use can be critically important if the organization is serious about taking advantage of the metadata-oriented tools in SharePoint 2013. Ensuring that the different site collections stay in sync can be a challenge and often requires the use of custom scripts or third-party management tools.

Providing an approved set of list and library templates can greatly facilitate governance because it allows site collection and site administrators to simply choose an approved template and set a couple of settings, and it can be used immediately. For example, this helps ensure that required columns are in place, managed metadata is properly leveraged, and versioning settings are consistent.

Look and feel tools can dramatically affect the user experience and should also be governed to a certain extent. Approved master pages and page layouts should be set, as well as themes, navigation standards, and related standards.

Site collection audit settings and report settings should be governed to ensure the appropriate events are tracked, audited, and can be analyzed. Figure 24.7 shows the Configure Audit Settings page for the site collection. In this example, IT wants “everything on” so that user usage patterns can be analyzed, but they only need to retain the data for 90 days.

Site collection policies provide options for enabling retention and retention stages, enabling auditing of opening or downloading documents, editing items, and checking out, moving, or deleting items. Barcodes and labels can also be enabled if used by some or all groups that use SharePoint.

Record declaration settings can be important to define, as well. When an item has been declared a record, additional restrictions and retention policies can be applied. The ability to manually declare a record can be enabled or disabled, and the declaration of records and undeclaration of records can be set to be performed by members of specific SharePoint groups.

SharePoint Designer settings are used to enable SharePoint Designer 2013 use, enable detaching pages from the site definition, and enable customizing master pages and page layouts. IT might want to disable some or all these tools.

These bullets give some suggestions as to areas that should be governed for sites and site collections, but this list is by no means exhaustive. Each project differs, and each SharePoint 2013 environment has unique purposes, so the governance plans should focus on the components and tools that are most important in the overall vision and scope of the project. Once again, without a defined vision and scope for the project, it becomes very difficult, if not impossible, to adequately govern the environment.

What is (and often more important, what is not) a record?

What are the stages and life cycle of the record?

What are the critical requirements for the proper management of the record?

Only after these basic questions are understood at a detailed level can technology begin to enable records management within an organization. That said, after those questions have been answered, SharePoint can provide valuable tools to simplify and improve the management of business-critical records within the organization.

Content types with associated workflows are the most flexible and likely to fit a specific requirement. The downside with this approach is that it is practical only when the declaration is something triggered in SharePoint, such as an approval or change in a metadata field. Also, this approach is complex particularly if it requires integration with the systems initially generating the files that become records. Think of an enterprise resource planning (ERP) system that generates invoices. This method is particularly effective when there is not a person responsible for gathering, classifying, and stewarding records.

The Records Center is a site template that provides a way for users to declare records by uploading directly to the site and identifying the type of record. This method is good when a user or group of users is trained specifically on the record types and has a basic understanding of records management. The Records Center also provides a hold capability to facilitate eDiscovery.

eDiscovery can be a hugely resource-intensive activity for organizations, particularly if litigation is common for the organization. In addition to the hold capabilities with SharePoint, consider using SharePoint’s search engine to search all repositories and enable select staff to then access these search results.

Developing a mechanism to solicit user feedback and make refinements to the plan is a great way to proactively manage the application. Developing a governing board that includes application/system administrators and end users is a good way to discuss issues, requests, and build out new templates or expand features.

To be able to really take advantage of a governing board, an agenda needs to get built, and materials should be brought together. A good starting point for these meetings is a review of the usage trends, user feedback, and any issues that have arisen since the last meeting. Consider using a meeting workspace to capture agendas as well as tasks or takeaways.

Governance includes maintenance of the SharePoint 2013 environment but extends to include policies and procedures, roles and responsibilities, and periodic review to ensure that the myriad SharePoint tools are being used in productive ways that meet the needs of management and end users.

Any sized organization should have a SharePoint governance plan in place. It doesn’t have to be hundreds of pages long, but should at least be defined from a high level, as suggested in this chapter, with specific roles and responsibilities defined for the tasks that should be performed.

One key component of the governance plan should focus on the Central Administration site settings that will impact the tools and features made available to the site collection administrators, site administrators, and end users.

An important subset of the Central Administration site settings are those that apply to the web applications that house the site collections and the service applications that IT chooses to provide to the user community.

In addition, specific settings for site collections and sites should be governed, to ensure that the right combination of tools is provided to the user community. Just “turning everything on” is generally not an actionable governance plan, because many of the tools are complex to use and administer.

If SharePoint is to be used for records management, the tools and processes made available by SharePoint should be governed closely.

The governance plan should be reviewed periodically to ensure that it continues to meet the organization’s requirements and those of the end-user community.