Sometimes, you just have to stop trying to fix what is so broken
that the cost of fixing doesn't warrant the benefit. This is
especially true of
During recent months, my work has focused heavily on helping
organizations across all verticals and sizes tackle governance. As
I've written in recent columns, one of the challenges that
organizations face is how to incorporate "lessons learned." This is
a nice way of saying the mistakes they've made in previous
iterations of SharePoint are now causing pain.
Sometimes, such mistakes include locking down a SharePoint
environment so tightly that it's not able to respond to and support
business needs. More often, SharePoint did respond to business
needs and grew organically and quickly into a "hot mess."
Now the company must untangle that mess, either in the current
farm or as part of upgrade and migration, in order to start
managing the service more effectively.
The latter scenario is all too common. A stereotypical customer
looks at their SharePoint farm and realizes that they've got to
implement governance-from the business requirements to the service
management layers-and wonders how to do that with their existing
Often, they're thinking about doing this as part of the upgrade
to 2010 which is-in theory-a great time to take a step back, assess
the situation, and modify architecture, processes, policies, and
skillsets to ensure that the "new world" doesn't inherit the
problems of the old.
I typically guide such a customer through a process that
effectively "reverse engineers" the current environment back to the
original business requirements for each scenario, workload, and
solution. In many cases, these requirements were never fully and
Now-understood requirements then drive us forward through an
improved governance framework for the new environment.
Unfortunately, the "old world" can be quite a mess, making such a
post-facto, "reverse engineering" process complicated and costly
from a resource perspective.
And, in the end, there's something to be said for "if it ain't
broke, don't fix it" or, at least, fix it after doing some more
What I'm proposing is this: Rather than trying to make
everything that's in place perfectly manageable and governable
first, consider instead focusing on delivering the next high-value
business solution correctly. This might very well mean deploying a
new farm, where you implement lessons learned, better governance
and management, and higher service level agreements (SLAs) than in
your current environment.
Draw a line in the sand. Everything new needs to be handled
better. And, over time, you can slowly revisit, evaluate, and
migrate solutions from the existing implementation into a better
Consider a representative customer I met recently. A business
need had arisen that was mission critical by their definition. It
was worth lots of money if it went well and high risk if it
The requirements around this need were actually pretty
straightforward to implement in SharePoint. But the current farm
was so unmanaged and ungoverned that the executive leadership
wasn't comfortable that the solution could be delivered by the
current SharePoint service with any reasonable level of SLA. The
risk was too great.
At the same time, the organization was starting to feel the
pressure of an organically grown SharePoint environment. It was
becoming difficult to add customizations-for fear of one thing
breaking another-and challenging to patch and update the farm. All
of these are symptoms of management and governance that weren't
aligned correctly. They can all be fixed, but not overnight.
The customer was in a bit of a pickle because their mentality
was "SharePoint = Farm." That's simply not true.
SharePoint is a service… a platform that delivers value to the
business. It's not one specific configuration or component. It must
be architected to support a particular business' needs. With this
customer, as with many, there are often certain types of business
workloads that are more mission critical than others.
When you look at the full scope of requirements around such
mission-critical workloads, you often find yourself facing a
decision about adding another farm to the service to support
tighter management, higher SLAs (availability, redundancy,
recoverability, performance), and chargeback.
Sure, there's a cost-server licenses and effort-but that's
exactly the cost-benefit decision that governance should be set up
to expose and guide the business through.
In the field, customers discover many reasons why they require
multiple farms to isolate significantly different
workloads-standard collaboration, mission-critical collaboration,
services (Search, Profiles, Metadata), Project Server, business
intelligence, extranets. So why not just accept that fact to
facilitate moving forward in your service?
So I propose to all of them, and to you, to evaluate the cost
and benefit of just saying "What's done is done." Manage that
"done" part well, and improve it over time, but don't sink so much
effort into making it perfect that you fail to move the platform
forward in its value to your business.
This article was originally posted on SharePoint Pro.
Dan Holme, AvePoint was a speaker at the
European SharePoint Conference 2011. Check out his
speaker presentations by
Stay tuned for more SharePoint content by joining our community or by
following us on twitter or facebook.