Sharepoint Customization and Development

The Problem being is defining the grey area between development and Customization which produces to an end result of an Implementation of Sharepoint from the usual blue and white out of the box share point site. Almost all the implementations aren't just going to have content in them without some artifacts being created such as Custom Web parts, Site Templates, Site Definition, List Templates, Master Pages, and Page Layout etc.

Sharepoint Customization:

Customizations can be done by any person with correct Permissions in a Share point Web Application and with access rights to use the Web User Interface or Share point Designer.

Sharepoint Development:

The Development requires knowledge in:

1. Visual Studio
2. C#/VB.Net
 3. ASP.Net 2.0
4. HTML
5. CSS
6. XSLT and 
7. Share point Object Model at a minimum.

This is really dependent on out of the box functionality which we wish to Extend.

When does a proof of concept become a production application?

Another point brought up by the same client was around doing these Customization’s directly into Production. It is perfectly acceptable to improve the functionality by using Customization, but if the application is a important Business Process you do not want to break the application with your Customization. So, we end up having a Dev/Test environment to do these Customization’s. The Business Users making these Customizations get sick of repeating work and want to throw it back to the IT Department as soon as possible. This is where I suggest moving to Development and not Customization.

Reaching the Limits:

Another issue with Organizations going down the route of Customization is that at some stage they want to push their functionality past what is possible in the UI.

Migration Scripts and Change Scripts:

           The issue with then making the changes is that you simply can’t just overwrite what you've got in production because they will be live data in there. So what you have to do as a Developer is script up a change script to bring v1.0 to v2.0. This can be maintenance nightmare once you got v10.0 in the works as you can all imagine. The alternative is to just simply amend v1.0 and push this into production and migrate the from v1.0 to the newly built v2.0 vis migration script.