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.
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 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
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
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
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
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
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
> 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
> 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 be resilient to the catastrophic loss of a
business site, with maximum data loss of six hours. In addition,
all documents classified as business critical must, 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 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
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
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
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!