Should we customise SharePoint?

I have been having lots of discussions with my clients recently regarding whether to customise SharePoint 2013, especially SharePoint online and I thought I would document some of my thoughts in regards to this scenario.

My thoughts on this subject have evolved over the last year or so.  Having spent some time working directly for Microsoft, my view is probably slightly biased against delivering customisations to SharePoint, as I spent almost three years listening to the configuration over customisation arguments coming from the product group.  However, as more and more clients are moving to Office 365 the argument is becoming more urgent.

My view on this topic is that there are potentially four different options for developing on Office 365.

These methods, at a high level could be classified as:

• Development\Customisation
• Out of the box with manual configuration
• Out of the box with custom deployment (via script or app)
• Hybrid approach (i.e. customisation and OOTB)

I believe that the decision regarding which method to use is entirely dependent on the workload of the solution you are thinking of deploying.

Let me clarify, although SharePoint is a large product, and provides an abundance of capabilities, in my experience projects tend to fall into three or four distinct categories, publishing, collaboration, document management and search.  If we include publishing as intranet\extranet scenarios this is really the only workload where I would consider doing any customisations on SharePoint itself.  These customisations would include normal branding elements such as master pages, page layouts, css as well as more complex solutions including custom web parts etc.

In the Office 365 world, this is still ok, but consideration has to be given to areas such as the ribbon, suite bar and my recommendation would be to leave these areas alone, as this is an area where Microsoft make changes quite frequently and these changes

The other side of this would be the more standard collaboration, document management workloads.  In my opinion these areas should solely use out of the box features.  If this does not suffice for some reason, then a custom app would be the logical way to proceed, at least in this way any changes to SharePoint should be abstracted from the application.

Following this logic the discussion then moves onto deployment.  One of the advantages of developing a solution is that you can easily move the solution through your non-production environments as well as providing support for upgrades etc.

Using OOTB features can mean that there is a push to deploy configuration based solutions manually, this is not necessarily the case.  Microsoft have released the Office 365 Patterns and Practices solution which allows users to hook into this solution and deploy configuration and other solutions using supported PowerShell or as an app in SharePoint.  This solution enables us to deploy through various staging environments (if required) and allows a level of management for upgrades and enhancements.

Microsoft have realised that users will want to customise their SharePoint environments and have started to provide advanced warning of new features, via the published roadmap and users can now opt-in to the early release programme, which will provide a couple of months early access to new features such groups, app launcher etc.  It is worth noting that I do not believe that every update appears to go through this programme

In conclusion, the question of whether to develop solutions on SharePoint is a decision, which should be based on a number of criteria.

1. Is the solution on-premises or in Office 365
2. What is the workloads i.e. publishing intranet or team site collaboration
3. Is the functionality available OOTB in SharePoint, if not is the requirement a valid “must have” requirement
4. Can an app be developed to support the required functionality
5. How will you manage the solution in an evergreen environment