Everyday more customers are hesitant about development and question if custom work against SharePoint is a good idea. Often they lean towards the opinion that only out-of-the-box solutions are allowed to be created. They believe this will pose less problems when upgrading to a next version or they just have an overall no-code policy.
This poses the question of what exactly is out-of-the-box. There have been jokes that a SharePoint installation is only out-of-the-box as long as you only add content through the browser without changing anything else. There is a reason for those jokes. Out-of-the-box does not always mean there will be no problems during upgrade and code does not always mean there will be. That is why we have been thinking about what is customization, what is configuration and what is development and why we have created a vision about which should be used and when.
Defining what is what
- Configuration is:
- Adapting the intended effect of Out-of-the-Box functions through the offered configuration options.
- Adding new functionality through productized Solutions, Apps or WebParts that can be bought including a support contract.
- Changes to a site that can be made through the browser or with the aid of SharePoint Designer or InfoPath Designer. These changes are stored in the content database.
- Customization is:
- Adapting the intended effect of Out-of-the-Box functions through code.
- Adding new functionality to SharePoint through code.
- Development is:
- Customization can, by definition, only be done by developing something. But not everything that is developed should be considered customization because they do not change the intended effect of Out-of-the-Box functions and/or add new functionality to SharePoint. Sometimes development is just making configuration repeatable.
- Besides customization development for example also entails:
- Farm solutions containing only CAML definitions for content types and lists
- (Farm) solutions for deploying masterpages, styling and branding
- (Cloud) Apps for deploying masterpages, styling and branding
- Code using Client Side Object Model (CSOM) to create content types and lists
- Powershell scripts to for instance support deployments, rolling out site structures, etc.
- Files in farm solutions are often deployed to the file system (14 or 15 hyve) of the front-end web server(s). This means that someone with rights to the server has to install the solution.
- Farm solutions using features and element files to roll out content types can create dependencies that are difficult to resolve when upgrading to the Cloud App Model later.
How and what to choose
Taking a configuration only stand point seems the safest route for clients. But what if configuration only causes higher maintenance costs? What if realizing configuration adjustments is time consuming and error prone?
In these cases the underlying reason for preferring configuration to customization is ignored when keeping to the configuration only stand point.
- Reasons to choose configuration over customization are:
- Least risk of problems or costly changes when upgrading
- Least risk of problems with availability and reliability
- Least risk for support and of high maintenance costs
- Most flexible for end-users and site administrators
- Down sides to configuration are:
- No version history
- Cannot be rolled out to other (for instance from development to production) environments or other sites
- Not repeatable
- Higher risk of user errors/typos
That is why we should look at the impact of the requested change when deciding on configuration only vs customization vs development:
- Configuration is preferred to customization when:
- it is in line with the underlying reasons for preferring configuration: less problems and costs with upgrades, less problems with availability, etc.
- it does not result in unacceptable loss of functionality, issues with maintainability, etc.
- New functionality should preferably be added using configurable, productized and supported WebParts or App(Part)s.
- Adjustments to configuration should preferably be implemented using reusable apps, solutions/features (wsp) or supported by repeatable Powershell scripts.
The feature framework should not be used when it creates dependencies on those features that will hinder later upgrades:
- For example defining a CAML only solution to create content types that exactly mimic what can be done manually through the browser. By using a solution it is repeatable and it does not contain code. It will create a dependency on the features so should only be considered if the client has a no-code rule and is not considering moving to a pure Cloud App Model approach.
- Using a solution with features for implementing styling and themes is still a valid approach.
- Only when
- a. When functionality, maintainability, etc. mean that configuration only can result in limitations
- b. No productized solution is available or it is not an option to buy
… only then is development a good option.
Development should follow the new App Model which is designed to prevent issues with upgrades and availability of SharePoint.
Of course the world is not always black and white and there are a lot of grey boundaries.
For a client not using SharePoint 2013, the best option for their problem can be different from that of a client that does use SharePoint 2013 or one that uses Office 365.
For those interested in reading more, those boundaries are described in more detail in a whitepaper around this topic which is available upon request.