SharePoint Governance vs. SharePoint Management: Drawing the Blurry Line

If you’ve followed my writing and speaking over recent years, you know that I regularly share the experiences I gain helping customers understand whathas become one of the most overburdened and misused buzzwords in SharePoint: governance.

This week, I’d like to muse a bit on the difference between governance and management. These are educated musings, based on the experiences I’ve hadwith 80 percent of the Fortune 500 and with some of the smartest people in the SharePoint and IT space, but they're musings nonetheless, so I lookforward to your feedback and will work to help clear the noise and the buzz around “governance.”

Management: Deploy, Secure, Configure, and Audit

Governance is, without doubt, a big, hairy topic, but it’s made worse because the community has blurred concepts of governance with concepts ofmanagement. The way you deploy, secure, configure, and audit a service is—in services outside of SharePoint—called management. These are operationalissues and one of the major concerns in operations is making operations more manageable—more automated.

Management is, in my opinion, close to the technology, as opposed to close to the business. It’s not a problem, then, that IT is responsible formanaging a service like SharePoint.

A problem arises, though, when decisions about the architecture, configuration, and administration of a service are based only on how to make theservice most manageable. What you end up with is a “locked down” service that can’t respond to the changing needs of a dynamic business.

A chasm grows between the business and the service. Users can’t get what they want done, and SharePoint’s reputation is sullied, even though it’s notSharePoint’s fault… it’s a systemic fault.

Governance: Meeting Business Requirements

What’s missing in these cases is governance. The role of governance—broadly speaking—is to ensure the business is moving in the right direction. And,in the case of SharePoint governance, that means ensuring that SharePoint is meeting business requirements.

Governance is the “service interface”between the business and SharePoint. For you developer-oriented types, you can think of governance as the API that the service exposes to the business.Governance defines how business methods are called on the service, how properties of the service are exposed to the business, and how service-relatedevents are handled by the business.

Governance is closer to the business than to the technology. In fact—in my models—the role of governance is to translate business requirements intowhat I call “service specific requirements” or—in short—“real” requirements—that drive the decisions made in the management layer.

Any technical person who has tried to get requirements out of a business customer knows that it’s like trying to get a donkey to speak Latin. Andreally, business customers shouldn’t have to tell you all of the requirements.

It’s (almost) enough to get an answer to the question: “What do you want to achieve?” which is often easier for the customer to answer, and more usefulto the service, than questions like “What do you want?” or “What do you need?”

Governance takes these business requirements and translates them into requirements that the service can implement to support the business requirements.

Simple Example

Let me give you a simple example. If the business goal is to “collaborate more efficiently,” governance will translate that goal into a definition ofhow collaboration will be supported. For example:

• A project, team, department, or business unit can request a workspace for collaboration, and on approval of a manager, the workspace will be createdwithin 15 minutes.

• The documents in a workspace will be secured so they can be accessed only by members of that project, team, department, or business unit.

• Team workspaces that contain information that is classified as highly confidential must be audited for all create, view, modify, and delete access.

• Team workspaces that contain information that is classified as business critical must be available with an uptime of 99.9 percent, and must beresilient to the catastrophic loss of a business site, with maximum data loss of six hours. In addition, all documents classified as business criticalmust, if deleted or corrupted, be recoverable within 15 minutes to a point-in-time no longer than three hours.

• Team workspaces must have an expiration date specified, at which time content in the workspace will be archived. The expiration date can be extendedon request.

Broadly speaking, governance should be providing requirements (policies) to the management layer that drive information architecture, informationmanagement, and service management. The list is longer than that, but those are the big three that drive architectural decisions, at least.

We see examples of all three above:

• Information architecture describes content that is part of a solution. Components of information architecture include metadata and content types(“taxonomy”), the site map, and search-related elements. In the examples above, we already see that governance has specified that we must have metadataabout the business criticality and the confidentiality of documents. The business must provide the values for that metadata, and the service mustaccount for those classifications.

• Information management requirements define the lifecycle and security of content. Here we see definitions of security and auditing. We also see thatcollaboration content will have an end-of-life (expiration date).

• Service management requirements define IT assurance characteristics of a solution, including availability, recovery, resiliency and performance.

And out of these requirements we see hints of two forks in the architecture and management of collaboration in this example. There is a fork forcritical and confidential information that is implying tighter management, higher uptime and better recoverability; and there’s a fork for othercollaboration.

In a real-world scenario, more requirements would be elicited—requirements that would enable the service to fully support the business, and to applythose requirements into the management of the service. In this example, management might define two web applications—or more likely two farms—tosupport the two major types of collaboration.

One farm would be supported with more expensive systems that ensure the uptime and resiliency that’s required of business-critical information. Theother a more free-form environment that might support more customization and experimentation.

Governance Should Be the Referee

It’s really tough to capture the breadth and nuance of challenges faced as you take business requirements through governance and project management todefine and architect a solution to those requirements. But the bottom line of my musings this week is that enterprises need to recognize that there isa distinction—albeit a blurry one—between governance and management.

When that distinction is lost, you end up with an unmanaged, Wild-Wild West that meets lots of business needs but is at high risk of collapse, or alocked down service that’s tighly managed but doesn’t support the diverse and changing needs of the business.

Both results are risky if you are starting from the assumption that SharePoint is a strategic platform that will evolve and scale in the functionalityit delivers to your enterprise over time.

Governance should be the referee… the middleman… the interface… where needs are accounted for, options are identified, costs and benefits and risks andrewards are evaluated, decisions are made, and expectations are set.

Governance creates the great compromise, so that management knows what it needs to do to support the business, and the business knows what it can andcan’t get from the service.