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

Dan Holmes

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 had with 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 look forward to your feedback and will work to help clear the noise and the buzz around “governance.”

Governance is, without doubt, a big, hairy topic, but it’s made worse because the community has blurred concepts of governance with concepts of management. The way you deploy, secure, configure, and audit a service is-in services outside of SharePoint-called management. These are operational issues 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 for managing 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 the service 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 not SharePoint’s fault… it’s a systemic fault.

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-related events 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 into what 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. And really, 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 useful to 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.

Let me give you a simple example. If the business goal is to “collaborate more efficiently,” governance will translate that goal into a definition of how 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 created within 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 must have an expiration date specified, at which time content in the workspace will be archived. The expiration date can be extended on request.

Broadly speaking, governance should be providing requirements (policies) to the management layer that drive information architecture, information management, 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 metadata about the business criticality and the confidentiality of documents. The business must provide the values for that metadata, and the service must account for those classifications.

> Information management requirements define the lifecycle and security of content. Here we see definitions of security and auditing. We also see that collaboration 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 for critical and confidential information that is implying tighter management, higher uptime and better recoverability; and there’s a fork for other collaboration.

In a real-world scenario, more requirements would be elicited-requirements that would enable the service to fully support the business, and to apply those requirements into the management of the service. In this example, management might define two web applications-or more likely two farms-to support 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. The other a more free-form environment that might support more customization and experimentation.

It’s really tough to capture the breadth and nuance of challenges faced as you take business requirements through governance and project management to define and architect a solution to those requirements. But the bottom line of my musings this week is that enterprises need to recognize that there is a 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 a locked 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 functionality it 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 and rewards 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 and can’t get from the service.

Dan Holme, AvePoint’s Chief SharePoint Evangelist was a speaker at the European SharePoint Conference 2011. Stay tuned for more content from our speakers by joining our community or by following us on twitter or facebook!