Where to draw the line between SharePoint Customisation and SharePoint Development

November 25, 2008 · Posted by Jeremy Thake
5 Comments · Trackback Url

I was recently on a client site where they have spent the best part of a year going through the process of making the decision and getting approval to purchase Microsoft Office SharePoint Server 2007 Enterprise Edition. Part of that presales process actually included attending one of my discussions on Enterprise 2.0 along the lines of "Facebook for the Enterprise" with a 15 minute segment at the end that demonstrated what MOSS 2007 had out of the box that could be used.

There seemed to be a large disconnect between using the Out of the Box functionality and extending SharePoint to meet their needs. One of the biggest questions I get is "where to draw the line between Customisation and Development".

The client was under the impression that the changes they required to the Out of the Box functionality based on their Business Requirements could be simply done via Customisation. They raised concerns that this required Development due to the skills required and costs implicated.

SharePoint Customisation

Customisation is typically anything changed in a vanilla SharePoint installation. Customisation 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.

SharePoint Development

Development is using Solution Packages and Features to automate these same changes PLUS other things that simply can't be done via Customisation 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 at a minimum. This is really dependent on what areas of out of the box functionality you wish to Extend.

Drawing the line is hard

There are big problems using the Customisation 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 customisation 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 Customisation's directly into Production. It is perfectly acceptable to over time improve the functionality by using Customisation, but if the application is a important Business Process you don't want to break the application with your Customisation's. So you end up having a Dev/Test environment to do these Customisation'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 Customisation'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 Customisation.

Reaching the limits

Another issue with Organisations going down the route of Customisation 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 Customisation and when to use Development. Also with some scenarios of when to move from Customisation 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 on 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

"So Jeremy...what are you advising?"...well basically...SET THE EXPECTATIONS early with Business Users. Make sure they are aware of "the v2.0 scenario" and the difference between Customisation 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 Customisation's directly into Production, but it will not last forever.

Tags:

5 responses so far

Tuesday, 25 Nov 2008 09:11 by Tom Clarkson
The content deployment wizard is quite helpful in the migration scenario - if you just want to deploy a packaged version of the existing lists the process is reasonably straightforward. Of course any schema changes still need to be handled on a case by case basis, which can be an interesting challenge.
Wednesday, 26 Nov 2008 12:56 by Thomas Vochten
Hello, just a quick note to let you know that the images on this article don't render...
Wednesday, 26 Nov 2008 02:00 by marijn somers
I think your conclusion says it all. I 've had a couple of customers who chose SharePoint "because all they want is out-of-the-box"..until they start using it, resulting in days/weeks/months of writing code. The goal is to set the expectations of the business owners at the earliest stage (presales)! Yes, SharePoint is an awesome platform and you can do a lot of amazing things with it, BUT it is not the holy grail that will solve all your problems. Be prepared to look for a) customisations b) development c) buying 3d party tools Next to that, to choose customisations vs development you have to look at a number of items: what is the client's budget? how many people are going to use this? how big are the changes? Another way to look at this is: how 2.0 do you want to go? Do you want an analist to gather functionalities and write them down, so IT can create solutions and deploy them? Or do you want creative solutions that emerge from you end-users? Personally I believe there has to be a mix from these 2. Let end-users create their sites and workspaces, while important stuff (like workflow, search, structure) should be created by IT. Just my 2 cents, great article !!
Thursday, 27 Nov 2008 05:01 by Darryl Wells
Great article!!! I think the main issue here (as you have alluded to) is the way in which SharePoint is marketed and sold. Users are told that they can use the OOTB collaboration tools, which translates to "we can do the work ourselves" = "Less cost of ownership". This is generally not the case, and we are having to re-align client's expectations AFTER the fact. So, yes set the expectations upfront, I just worry that doing this will prevent clients from choosing SharePoint in the first place.
Thursday, 27 Nov 2008 07:14 by Richard Greene
Although I totally agree with the conclusion that expectations are the root cause of these issues with SharePoint, I would point out that Microsoft has not made the job any easier for us in setting these limits in the minds of the business. Having used SharePoint from it's first, less than reliable version, it has always been pitched as a productivity tool, something that the business can customise to meet their specific needs. Indeed the mere existence of the numerous functions in the UI, SharePoint Designer, Workflow, and add-ins for Visual Studio are testament to that; therefore the business has a right to expect customisations to the handled by the platform. The failure as I see it, is in the implementation of the customisations within the platform and across multiple environments. As a developer I like the idea of keeping all the power in the hands of the experts, developing everything in Visual Studio means we have total control and oversight on the change management process, but that's not how a productivity tool should operate. Power Users with sufficient training and understand need to be able to complete customisations. They know their business, they make the innovations, they are in a far better position to provide real business value for the product. They should not have to come to the overworked IT department every time they need a new view or webpart! I feel the platform should provide more functionality to address the change management process, however until then it's left up to the technical staff to provide guidance to the business on what they can and can not do.