Based on Brian Farnhill's
comments, we need to define what consists of SharePoint Development on this page to scope the dev wiki.
The problem being is defining the grey area between Customisation and Development which leads to an end result of an Implementation of SharePoint from the usual blue and white out of the box SharePoint site. Pretty much all implementations aren't just going to have Content in them without some sort of artifacts being created such as Master Pages, Page Layouts, Custom Web Parts, List templates, Site Templates, Site Definitions etc. etc. This is something we need to define and also distinguish where this can and cannot be done. It is also important to understand the limitations of both approaches.
SharePoint Customization
Customization is typically anything changed in a vanilla SharePoint installation. Customization can be done by anyone with the correct permissions within a SharePoint Web Application and access to it using the Web User Interface or SharePoint Designer. There is a limited amount of things that can be done with this approach. Mark Millerput it well by saying anything that can be done without touching the SharePoint server, for instance, not modifying the 12 hive, inetpub or GAC.
SharePoint Development
Development is using Solution Packages and Features to automate these same changes PLUS other things that simply can't be done via Customization out of the box. The skill set required for Development requires knowledge in: Visual Studio, C#/VB.NET, ASP.NET 2.0, HTML, CSS, XLST and SharePoint Object Model at a minimum. This is really dependent on what areas of out of the box functionality you wish to Extend.
Limitations of SharePoint Customization
There are big problems using the Customization approach over Development approach. The biggest issue as I've discussed before is around Deployment in a version 2.0 scenario from a Dev environment to a Test environment to a Production environment.
For very basic extensions to functionality you could simply repeat the customization in each environment based on a script (or more dangerously from memory). This raises issues around inconsistencies in environments and reliance on particular resources.
The draw back of Development is the skill set required and therefore the related cost. Most Organisations will not be able to get a full-time SharePoint Developer on board and will have to outsource the Development. There is a significant overhead with producing the equivalent end result using Solution Packages and this can be made easier by a lot of the tools I've mentioned before. My recent Readify RDN presentation (slides/samples available here) highlighted the issues with SharePoint Development currently.
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 over time improve the functionality by using Customization, but if the application is a important Business Process you don't want to break the application with your Customization's. So you end up having a Dev/Test environment to do these Customization's. This is really the line drawn by having a proof of concept that moves into main stream production with a larger Business User base than ever imagined. Again, making these Customisation's in Dev/Test will then need to be repeated in Production again later.
The Business Users making these Customization's soon 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 Organisations going down the route of Customization is that at some stage they will want to push their functionality past what is possible in the UI. This again comes back to the version 2.0 scenario where you require to pull the hard work they've done back into a Development environment and then recreate this using Solution Packages. Fortunately some tools are out there to help with some of the reverse engineering such as SPSource.
What we need is some scenarios of when to use Customization and when to use Development. Also with some scenarios of when to move from Customization to Development.
Migration scripts vs 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'll 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 a maintenance nightmare once you've 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 data from v1.0 to the newly built v2.0 via a migration script.
There is currently no tools out there to do either of these approaches which is unfortunate. My gut feel is that Microsoft aren't going to provide anything to do this either. My personal opinion is that this is something that is commonly done and in training courses I've run is constantly asked of....with replies that result in blank faces and the pin dropping in the back of the room!
In Conclusion
SET THE EXPECTATIONS early with Business Users. Make sure they are aware of "the v2.0 scenario" and the difference between Customization and Development. This will mean wiping the stored memories from all the Sales Presentations about SharePoint as a Collaborative Provisioning Platform that is easy for Business Users to build new applications on. For the first 18 months Organisations may get away with Customization's directly into Production, but it will not last forever.
Comments (5)
Dec 04, 2008
Rich Finn says:
When I was part of the SharePoint Partner Readiness Program, the MS technical sa...When I was part of the SharePoint Partner Readiness Program, the MS technical sales rep leading the program said something interesting. "85% of 'SharePoint development' is really customization. When working with content files (aspx), SharePoint Designer (SPD), and XML files containing CAML (list/site definitions, Features) you are really doing SharePoint customization. Microsoft considers SharePoint development as the creation of code which utilizes the SharePoint API"
If this is true, it would change what most people think of the definition of SharePoint Developer.
In my opinion, the definition of SharePoint development is based on the tool used to complete a task. If using the Web UI or SPD, then that is Sharepoint customization, while using Visual Studio is SharePoint development. Similarly to what is stated above, the UI and SPD are used to customize a specific SharePoint Site or Web. Visual Studio is used to create solutions and Solutions that are installed across multiple SharePoint instances and provides the ability to have a more traditional development lifecycle.
I think that the future of SharePoint development will be something completly different than what we see now. I would love to have a tool that is in the middle of where SPD and Visual Studio are today. Something that provides the power of Visual Studio with the connectivity of SPD. Maybe SPD with Code Behind would be a start. This would be huge for WCM and is what SPSource
is in essence trying to accomplish, but could we create web parts in this new tool? Chris O'Brien is on to something when he says SharePoint dev is not all about Features
, so maybe the future of SharePoint development doesn't include Solutions.
Dec 04, 2008
Jeremy Thake says:
When I get time Rich I'll merge your thoughts into mine as I totally agree with ...When I get time Rich I'll merge your thoughts into mine as I totally agree with where you're coming from on the tools defining it (unless you've got time to change it
). I'll also ask Chris O'Brien if he wants to contribute on this as his post is great too and gets close to an answer on when to customise and when to develop.
May 18, 2009
Steven Fowler says:
Chris O'Brien wrote "Why go through the extra hassle of packaging up artifacts i...Chris O'Brien wrote "Why go through the extra hassle of packaging up artifacts into Features and be faced with difficulties managing updates when the artifacts will only ever exist in one site collection anyway? Sure, they may need to be deployed between environments but we have other ways of doing that."
Developers are well versed with feature/solution development at this point, and the SharePoint community has great support for packing and deployment (WSPbuilder, etc.). We have a custom Visual Studio project template that with a few configurations will handling packaging/deployment for you.
Mar 19, 2009
Anonymous says:
[URL=http://cfozyamo.com]icbuxyow[/URL] qyboigyr http://xirryl...[URL=http://cfozyamo.com]icbuxyow[/URL] qyboigyr http://xirrylkl.com
xliogjxa btftyazp <a href="http://rniowaux.com">nraxdonm</a>
May 18, 2009
Steven Fowler says:
When does configuration of SharePoint become customization? When does administra...When does configuration of SharePoint become customization?
When does administration of SharePoint become development?
Because SharePoint is both a product and a platform the relationship of configurations to customizations and administration to development is blurred.
As a product it is possible to install, configure, deliver, and support SharePoint without ever writing a single line of code. In its extreme form a organization could decide to use OOTB site templates, lock down site owner permissions to only manage people and groups, and call it a day. A more likely scenario is to allow for full Site Actions administration, but not support anything beyond an initial SPD branding effort (especially Visual Studio customizations). 99% of these would fall in the Portal vertical of SharePoint as BPM requires SPD or Visual Studio, and by definition is application development.
As a platform is it possible to customize SharePoint to the point where you're only utilizing its APIs. There are some deployments out there where you can barely detect that SharePoint is behind the scenes (URLs give it away).
For the most part configuration of SharePoint becomes customization at XML/CAML, Features, and Solutions.
This too is somewhat blurred as I have had some pretty savvy Site Owners perform amazing alterations to SharePoint with the CEWP and CQWP.