SharePoint Customization Policies and Change Control

This post will cover different forms of customization, discuss the need for IT policies that support customization, and then provide a recommendation for how to manage the customization through change control processes.

What is considered customization?
There are different types of customizations and different ways to apply them. They can include custom styles, MasterPages, Web Parts, Custom Forms, Site Definition or even applications built on top of the API.

Bad customizations are applied manually by adding to or altering system files on the server. These changes are not saved into the configuration database which can cause problems when applying system patches or upgrades. It can also make it much more difficult to add an additional server to the farm as those changes have to be manually applied again. Therefore this should never be done in a production environment.

Well built customizations are deployed using SharePoint’s robust deployment framework for Web Parts and Solutions. This not only produces repeatable results, but it also helps keep multi-server farms in sync and allows those customizations to be pushed out automatically to new servers joined to the farm. This method is also much less likely to produce problems when applying patches, updates or even upgrades.


SharePoint Success without Customizations?

While I believe strongly that there is a lot of value in the base solution, I think that SharePoint is set apart by the expandability and integration options. This is what can take it from an ad-hoc workgroup solution to an enterprise platform.

Too many IT shops have taken a No Customization stance when it comes to Enterprise Software. They will quote ballooning implementation costs, reliability of the changes or the difficulty that exists in performing normal version upgrades. Many of these are valid issues to some degree with packaged software, but it is not an irrefutable law. SharePoint is a platform that is intended to be molded to meet an organization’s needs, and customizing it is not the same as rewriting core sections of an ERP system.

In more than on instance I’ve seen SharePoint workflow projects move forward with the decision that no “code” can be written, which means they cannot use Visual Studio or create custom actions. The alternative is for them to use SharePoint Designer to create those workflows. While that may be a good idea for small or simple workflows, there are limitations, but even worse there is no reusability in their work. If something similar is needed somewhere else it has to be recreated.

By making a unilateral decision that no customizations can be made, you are handicapping the system and limiting the value it can deliver. Business and IT leaders need to consider this before making any policy changes.

What about Change Control?
In organizations where there is a Change Control policy in place, it is important to categorize the types of changes. I would advocate grouping changes into the following groups Content and Site Configuration, Packaged Code, and System Level Changes.
Content and Site Configuration – This includes using the toolset to add and update content in lists and libraries along with the creation and design of Sites, Lists, and Libraries. These tasks should not require approval.

Packaged Code – This includes the installation of custom or third party web parts, solutions, workflow actions and templates. Since these packages can possibly cause harm, and should be part of the system’s documentation, it should pass through the Change Control process.

System Level Changes – This includes adding an additional server to the farm, changing a servers’ role, reconfiguring personalization features or rebuilding the Shared Service Provider. These changes can possibly have a huge impact on the entire system. It is important to capture the details of those changes in the documentation, and also make sure that all stakeholders are aware of the changes being made.

Tags: , , ,

Leave a Comment