Over recent months, I have written a number of columns and articles about SharePoint governance. I’ve also spoken at numerous events and to hundreds of customers about SharePoint governance, including my recent presentation at the Australian SharePoint Conference, where my keynote address laid out a Twelve Step Program for governance.
As I’ve evolved the way I communicate with customers about governance, there’s been one message that has seemed to resonate with a lot of folks.
The bottom line is that it’s generally not feasible to lay out your governance policies and SLAs for SharePoint in a vacuum, without the context of the specific business solutions you are trying to attain with SharePoint. Therefore, it’s something of a folly to expect that you can fully and richly define all of your policies and SLAs in one fell swoop.
Governance isn’t a project, it’s a process. And it’s therefore critical that your governance plan define or at least account for how you will manage your portfolio of solutions, and how you will learn and evolve as you progress on your SharePoint journey. This week, I’ll discuss this concept in detail.
What Real Governance Is
It’s folly to rehash the details of my theories about and tools for SharePoint governance in a short weekly column, but I’ll emphasize that real governance encompasses strategic and political considerations, project management, change management, operations, and interfaces between each of these primary elements.
Governance should define—among other things—exactly how SharePoint delivers business value (functionality and service levels), the resources that the service requires to successfully deliver that value (money and people, for example), and the processes by which business needs are transformed into solutions, deployed, and maintained.
Central to the above “nutshell” of governance are the concepts of business value and business need. It all starts with requirements driven by the business—of course.
With some services, business needs don’t change significantly over the lifecycle of the service. Take email for example, with Exchange as an example platform. The business need is to communicate both internally and externally.
Email provides a proven and well-understood mechanism for doing so. It might actually not be the most efficient service for supporting communication across all workloads, but in the context of broad requirements that might include “universal” availability (both internally and externally), and minimal cost for training and support (for a well-understood tool), email and Exchange often ends up being the service of choice.
When you deploy Exchange, you understand the requirements of the business, which might include a certain amount of email traffic, archiving and e-discovery, calendaring, shared contacts, and resource scheduling. You can architect a solution that supports projected needs.
And experience has shown that most organizations maintain a relatively static Exchange service for many months or years. Business needs—other than perhaps sheer quantity of email—don’t change much.
SharePoint is Different
SharePoint is a very different beast. Whatever business problem you deploy SharePoint to address, it’s never going to “sit still.”
If you deploy SharePoint to improve collaboration within teams and projects, six months later someone will be asking you to expose data from back end sources for business intelligence purposes, or to deploy social networking features, or to extend search, or to migrate the legacy intranet to SharePoint. And as soon as that project is finished, the next one will come along.
SharePoint itself is a work in progress, rather than a static service.
When you deploy your first solution—let’s use team sites as an example—you can and should evaluate business requirements to architect a solution that optimizes all requirements. (Note that I use the term “solution” in the generic business sense, not in the technical sense of a “SharePoint Solution”--.wsp package.)
Notice I said “optimizes” not “meets” requirements. Very few projects can meet all requirements, in my experience, because the business typically wants “everything”, “tomorrow”, “for free.”
Something has to give. Choices—often difficult choices—have to be made. One choice you have to make is related to service level agreements—uptime as an example.
You might choose to support a 95 percent uptime for team sites, which allows for 18.25 days per year of downtime—less than two days of downtime for maintenance per month.
Guaranteeing a 2-nine (99 percent) uptime (3.65 days per year of downtime) or 3-nine (99.9 percent) uptime (8.77 hours per year of downtime) are exponentially more expensive to provide, and so a choice has to be made to optimize service levels and cost.
That’s all fine and dandy. Governance—project management and solutions architecture, specifically in this case—should provide mechanisms for making these decisions.
Now it gets tricky when the business comes to the service with the second (or third, or fourth…) request. Each subsequent request must be evaluated within the context of the existing service, and all previously deployed solutions.
For example, let’s assume that the business wants to support a workload related to responding to Requests for Proposal (RFPs). And, let’s assume that the level of business criticality for this workload is high—the business relies heavily on this workload and revenues are at risk if anything goes wrong. Therefore, high availability is required.
Governance—again, project management and solutions architecture in this case—should account for the state of the existing service, which supports only a 95% uptime. Decisions will have to be made about whether, or how, this workload can be supported on the existing farm.
Perhaps the farm can be scaled with additional web front ends, and by migrating the SQL database from a stand-alone server to a cluster. Or perhaps you will decide to host this workload on another farm. Either of these approaches or any other method for raising SLAs carries costs, which must be factored into the cost of the new workload.
You must also evaluate the impact that the new workload will have on the currently deployed solutions. Will the new workload adversely impact the service’s ability to continue to meet the requirements of the existing solutions?
You can see, through this simple example, that it’s critical to build an inventory and an understanding of what you have done and what the service is doing. We’re talking about one of the fundamentals of portfolio management. You have to know what you have in place.
And you have to know what you agreed to do with each of those solutions: what were the requirements, the agreements, and the metrics for success? Only with this information can you confidently begin to layer on additional solutions for new workloads.
One of the other things that will happen, inevitably, is that you will make mistakes, and you will learn. You must be prepared to incorporate lessons learned, decisions made, compromises reached, risks assumed, and costs accepted into an evolving and ever-developing set of governance policies and processes.
Governance is a Journey
So what is a governance plan then? In my opinion, it is not a blueprint or a set of policies for what SharePoint will look like forever.
Rather, it’s a definition of how you will move forward, how decisions will be made, how solutions will be built, deployed, and maintained, and how the requirements for and lessons learned from each solution will be incorporated into the next step forward.
A governance plan is a plan for evolving a service, not a specifications document. As each solution is brought—by governance processes—from business need to deployed solution, the requirements and specifications of that solution become part of the service.
So over time, the service certainly evolves a technical reference of policies, procedures, and specifications. But those details come out of the repeated journeys through the process, rather than from some massive “governance project” before the service is deployed.
Governance defines the journey, not the destination. Requirements (of each solution) determine the specifications and policies of the resulting service. Happy journey’ing!