You can’t argue that SharePoint is one of the biggest sellers for Microsoft, in the past 10 years the product has come a long way since its humble roots as code name Tahoe. In the early days, SharePoint 2001 was a large complex ASP page that was difficult to customize, the web part framework difficult to leverage and the Web Store from Exchange 2000 as a database – you either loved it or hated it!

Ten years later and three major versions we now have SharePoint 2010 which promises to deliver greater scalability and features over 2007. While the product has come a long way since 2001 the customization aspect is still troublesome.

Many organizations have deployed SharePoint and customized the product through branding, the feature framework and many other customizations such as page templates .net code that ties into the core SharePoint assemblies. In doing so IT has delivered on the promise of composite applications that deliver a rich user experience. From an IT perspective, the customizations have resulted in performance and supportability issues.

For example, one of my previous clients invested $2M to customize SharePoint in attempt to replace their EDRM toolset and two years later realized they wasted their money. The platform was riddled with scalability, performance and manageability issues. They shut the project down and then deployed SharePoint with only some basic (Color and logo) modifications.

So back on the topic of issues, they tend to surface as one or many of the following:

  • Degraded performance and reduced scalability
  • Unexplained performance spikes
  • Application pool resets occurring for unknown reasons
  • In ability to backup and restore the platform
  • SPs and CUs overwrite customizations
  • Troubleshooting difficulties

So you might ask, why doesn’t Microsoft provide a Whitepaper that details what can be customized and can’t be customized – the associated risks to your farm(s)? Who would know that that by utilizing the rich feature framework and .Net you would hinder scalability, choke performance and capacity and adversely impact your ability to back up and recover.

You might ask, why not create standards for development? But isn’t this boiling the ocean? Look at Microsoft patterns and practices site, would take forever to create, costly to maintain and drive adoption. Instead why not hire senior developers, a skilled and reliable development team of full-time staff and contractors and adopt quality processes.

So aside from rigorous testing and a healthy dose of paranoia, the following are some ideas to help:

  • Invest in an experienced team of developers – build a trusted team lead by senior developers with a solid background in SharePoint.
  • Follow development best practices for SharePoint – .net developers are not always the best SharePoint developers
  • Isolate your customizations – use farms, site collections and application pools dedicated to the customizations.
  • Architect SharePoint based on SLA – group high value data separate from low value data and tailor your backups accordingly.
  • Deploy non-customized farms – CSS mods only, use these farms to deploy collaboration, my sites and knowledge sites to the larger community.
  • Create farms/site collections that provide generic services – for team sites, search and My Sites create farms and or site collections that are branded only.
  • Disable SharePoint designer – you either love it or hate it. It enables users to reach into your SQL database – enough said. If you have to use it, isolate its use to a site collection on an isolated farm.
  • Publish Service Level Objectives – communicate service levels and other expectations and risks surrounding customizations and administration. Get the facts to your end user community – it’s a never ending process that build good karma.
  • Monitoring and performance testing– make sure you have baselined your farm and know how it behaves when its healthy and when it’s not. Have a plan for when it’s misbehaving, you must be able to troubleshoot quickly and resolve with certainty.
  • Publish Guidelines for customization and administration – make people are or tested best practices specific to your environment. Let they know what the options and risks are – transparency and education is key.
  • Audit your farms – do this quarterly to make sure settings are enforced, usage is inline with policy, administration process and policy is enforced.
  • Don’t let the business take you down a hole – just because the business wants certain functionality doesn’t mean SharePoint is the correct platform. Be prepared to push back intelligently and escalate to senior management if required.