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.
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.