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 SharePoint governance.

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 implementation.

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 clearly enumerated.

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 important things.

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 world.

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 failed.

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 clicking here>>

Stay tuned for more SharePoint content by joining our community or by following us on twitter or facebook.