Establishing an effective and appropriate governance program for a broad-ranging platform like SharePoint is essential.
Adapted from “Pro SharePoint 2010 Governance” (Apress, 2012)
Why establish governance over any human activity? Why not just let everyone do their own thing? Isn’t freedom supposed to be a good thing? For an answer, take a look at any country in the world where the government has failed and a new one hasn’t replaced it right away. It’s not a pretty picture.
Of course, failing to assign storage quotas on your corporate intranet isn’t likely to result in hordes of crazed coworkers fighting to the death over the last of the copier toner. More likely, the system will just crash or be left in an unusable state. Developing policies and standards and assigning responsibilities to the appropriate departments creates a system that can support business needs without becoming an impediment. Or maybe users shouting angry slogans while waving burning torches are a normal part of your corporate culture?
The most important consideration in developing your governance strategy is determining the needs of the users and adapting the governance plan to meet those needs as effectively and unobtrusively as possible. This requires an understanding of the users’ business processes, preferences and working culture.
SharePoint is a widely varied product with many features that can be productive, useful, confusing or annoying, depending on the needs of the system’s users and how those features are leveraged. The two most common mistakes when establishing governance are to implement too much governance or too little.
There’s no such thing as a SharePoint installation with no governance. Anarchy isn’t a default; it’s a choice. Even if an organization has intentionally avoided putting any restrictions on users, that’s a governance choice. SharePoint sites where users have absolutely free reign are all too common. The result is most often a site clogged with massive amounts of data, but very little useful information. Users can’t find anything except the most recent content they added themselves. Older data or content contributed by others may as well be on a floppy disk in someone’s desk for all the good it will do them. Eventually, the site becomes slow and unreliable and falls into disuse.
Too much governance, on the other hand, robs users of the opportunity to innovate and use their creativity to find new ways to do business. If you have an inherently collaborative corporate culture, unnecessarily restricting access to the collaborative features of SharePoint—such as team sites, document workspaces, wikis and social networking—may cause that collaboration to shut down. Alternately, team members might abandon the portal to collaborate effectively. Overly aggressive security restrictions can also prevent users from finding valuable information they need in order to make important business decisions. Too much governance, like too little, is likely to result in a system that users don’t choose to use.
No one wants to live in total anarchy or a police state. That’s why effective governance must take a “Goldilocks” approach. Not too little, not too much. Not chaos, not prison. You want users to be comfortable using SharePoint. It should be as natural a part of their work day as opening their e-mail. Otherwise, they’ll seek easier ways to perform their tasks outside of the portal. After all, Goldilocks didn’t stay in the bed that was too hard or too soft, but in the one that was just right.
The first concept we’ll introduce is that of a service. In this context, a service is a set of features that the portal provides to the community of end users. In SharePoint, these services might include discrete sub-systems such as Excel Services or PerformancePoint Services, but they also include more general services such as authentication and secure site access via SSL. A service is the basic unit of functionality to consider when planning the governance of your portal.
A service has a lifecycle that starts with installation and configuration of the service, also known as provisioning the service. Once the service is provisioned, it must be monitored and evaluated to see how well it’s meeting user needs. When improvements are needed, the service might need to be reconfigured or upgraded to meet new or refined requirements. At some point, you may decide to remove a service because it’s no longer needed. When a service is decommissioned, it’s often necessary to migrate its associated data to another service or system.
Governing the lifecycle of a service is a continuous process that doesn’t end as long as the service is in production. This ensures that the service continues to meet the requirements of the organization in a sustainable way. This cycle of continuous monitoring and reevaluation will be a recurring theme as you examine all of the processes used to govern a SharePoint portal.
The first step for any SharePoint team is to identify the services to be provided. These services can be broken down into two general categories: mandatory and optional.
Some services provided by SharePoint are mandatory in the sense that those services are made at least partially available just by deploying SharePoint. You can’t turn them off completely. These services provide the infrastructure upon which the rest of the SharePoint site is built. You have to plan for these services before deploying any SharePoint solution. Some of the more important services are:
You must install, configure and monitor each of these services to keep SharePoint running well.
SharePoint has a large number of subsystems you can turn on and off, which are the optional services. Depending on the edition of SharePoint you’re using, you’ll have different optional services from which to choose. Here are some examples:
You can make additional services available by adding other Microsoft or third-party products designed to extend the functionality of SharePoint. Some Microsoft extensions include Project Server, SQL Server Reporting Services, Dynamics CRM and Visual Studio Team Foundation Server. Other third-party products and extensions provide additional collaboration, document management, data management and reporting capabilities within SharePoint. SharePoint is also a powerful development platform on which organizations can build their own custom applications.
All these services have different configuration options and security considerations. Planning for provisioning, monitoring and user training around these services is a critical first step. Once comprehensive service planning is complete, the next step of provisioning should be fairly straightforward.
One of the unfortunate truths to note about SharePoint, or any complex platform, is that it’s often more difficult to upgrade or reconfigure a service than it is to deploy it initially. This re-provisioning requires at least as much planning as the original installation.
Monitoring a service involves collecting data about how the service is being used and how well it’s serving its intended function. Monitoring can take several forms, depending on the service. You can use something like PerfMon to collect a variety of metrics about the use of each server such as CPU, memory, network and hard drive usage. You can also use system event logs and SharePoint log files to diagnose problems as they arise. Finally, the built-in SharePoint usage-tracking features can produce reports detailing how different services are being used in production.
Don’t forget to collect data from the most valuable resource you have—your users. Help desk tickets, complaints, compliments and any other form of feedback you can get are invaluable service-planning information.
Monitoring the services provided would be pointless without some way of using the data collected. The governance team needs to periodically evaluate the data collected to identify services that aren’t meeting the organization’s needs for some reason. These might include services not being used effectively due to technical problems, user unfamiliarity or changes in the needs of the users. Services may also need to be reconfigured to provide better functionality. Also, you need to consider services that haven’t been deployed for possible addition to the catalog of services provided.
The final stage of any service is decommissioning. In this stage it has been decided—for whatever reason—that the service will no longer be offered to users. Decommissioning a service is often difficult because there might be one or two users or groups of users that want to continue using the service.
In these cases, the organization must make the trade-off between continuing to maintain the service and transitioning these users to an alternative way of performing these tasks. In most cases, this will involve moving, or migrating, the data already present in the service to a new location—or, at a minimum, archiving that data so it can be referenced later as needed. Decommissioning a service shouldn’t be viewed as a failure, but as a strategic decision made for the benefit of all users and the organization as a whole.
Once the necessary service changes have been identified, planning must begin for provisioning, reconfiguring or decommissioning services to meet the needs of the user community. This closes the loop on the service lifecycle and allows the system to grow and change as needed.
For more information on this title and other similar books, please visit apress.com. ©2012 Apress Inc. All rights reserved. Printed with permission from Apress. Copyright 2012. “Pro SharePoint 2012 Governance” by Steve Wright and Corey Erkes.
Not a TechNet Subscriber?
Confidently evaluate Microsoft software and plan deployments with a Microsoft TechNet Subscription.