SharePoint Configuration vs. Customization
For those of us who attend a lot of SharePoint events, we hear the question often: when is the right time to configure, and when should I customize SharePoint? What are the best practices?
Well, there really aren’t any best practices, per se. What is a best practice for one organization may not be the best path forward for others. Microsoft provide guidance on working with the platform, and has hard-and-fast rules around what changes will negate your support agreement (you don’t want to do that). But the platform provides ample leeway in how you build out your system.
I define “configure” as taking an out of the box component (list, library, web part) and modifying its various settings and attributes, including adding things like columns, fields, metadata, and so forth. All of it is done within the supported “framework” of SharePoint, and should be, by definition, supported by Microsoft and scalable/upgradable to the next version.
I define “customize” as using SharePoint Designer, Visual Studio, or .Net code to modify SharePoint outside of its normal framework, which could make the site difficult or impossible to scale/upgrade, and could cause support issues with Microsoft. I’m not trying to make this option sound overly negative – many customizations are well-built and do not cause problems inside of SharePoint. More importantly, they are necessary to help the organization meet its operational vision for SharePoint, and deliver a platform that meets business requirements. But SharePoint development does not equal .Net development, and I cannot emphasize enough the strategy of first understanding what is capable out of the box, then understand what can be done through configurations, and finally resort to customizations if the first two cannot deliver what you need.
There is plenty of online documentation around specific configurations and customizations, but there are no “standards” for doing so, as the standard may be different by organization.
At the end of the day, if the business value of “breaking” SharePoint to build, in effect, a custom .Net application inside of a SharePoint shell exceeds the cost of support and future upgrade, then by all means break the SharePoint framework and deliver value to your customer.
But if your strategy is to build a system that can be readily be upgraded in a year or more, it probably makes sense to build within the SharePoint framework.
Many programs require some type of exterior configurations information. SharePoint offers designers many options for saving customized options configurations outside of the program itself
I always suggest SharePoint customization when someone asks me to give an advice. Reason being with SharePoint customization we can develop a proper functional website or web app.
Mark, that’s where the definitions above don’t really fit — you’re right, modifying the XSLT is the expected/approved/supported method for changing the search results. I’d call it a customization, however, because there is a lot of rooom for “breaking” things once you move into SPD, and should only be performed by someone who knows what they’re doing.
Great post, Chris. I agree with your definition of “Configuration” vs. “Customization”. And your comment on “a standard” is also interesting. The whole “is it customization,or configuration?” question can cause the loss of a chance to really create a great user experience.
What are your thoughts on modifying things such as search results? This is done through xslt. I’ve seen several post on the internet that describe it as customizing. But it is, really, something that can be done out-of-the-box.