Should you customise your SharePoint deployment?

One of the most important things to remember about SharePoint is that it’s much more than just an application for making intranets. It’s a fully fledged platform that companies can use to create almost anything, from executive decision-making dashboards to customer-facing websites. As such, it offers enormous scope for customisation – SharePoint developers have dozens of toys to play with, from Web Parts to APIs for integration with other applications.

However, the question of whether or not you should customise your SharePoint deployment is actually an issue that prompts impassioned debate among even the platform’s most ardent proponents. Many are of the opinion that as far as possible, SharePoint should be used as an out-of-the-box solution and developers should eschew the temptation to add so much as their companies’ own branding.

So, should you listen?

The drawbacks of SharePoint customisation

Perhaps surprisingly, one of the parties that espouses the use of SharePoint without modification is Microsoft itself. In its official SharePoint 2013 announcement, it made its stance unambiguous: “Use SharePoint as an out-of-box application whenever possible,” it said, adding that developers should focus their energy on “working with users and groups to understand how to use SharePoint to improve productivity and collaboration”.

It also cited three potential risk factors of customisation: complexity, performance and upgradeability. None of these is particularly controversial – it stands to reason that modifying SharePoint can make it more difficult for other developers to inspect and debug its code, create performance bottlenecks and increase the challenges associated with migrating from one version to another.

However, it’s also fair to say that some SharePoint users might well reject Microsoft’s insinuations here. Surely a decent developer would factor migration issues into their customisations from day one, for example, as well as pay attention to the performance implications of their work?

Making SharePoint work for the business

It’s easy to get hung up on questions like these, which can in turn make it difficult to see the bigger picture. We’ve written before about the perils of buying SharePoint for its features rather than its benefits, but it’s worth pointing out that on the other end of the spectrum, some companies buy SharePoint without the first idea of how to map its features to their business requirements. Then, instead of putting the platform to use, they pay a developer to turn it into what they imagine their ideal SharePoint deployment to be.

This is, of course, fundamentally wrong-headed. SharePoint has a powerful set of out-of-the-box features that, as Microsoft argues, can be used to “improve productivity and collaboration” right from the word go. A company’s first port of call should be to work out how much mileage it can get out of these features, as well as how quickly it can start using them to drive process improvements.

Then, and only then, should it start thinking about whether or not it’d be judicious to expand SharePoint’s functionality, weighing up the productivity benefits against factors like complexity, performance and upgradeability.