SharePoint Development Blog by Jeremy Thake - Where to draw the line between SharePoint Customisation and SharePoint Development

Welcome to my blog on all things SharePoint. I have a range of articles that will interest you if you've made it as far as visiting my blog. I was awarded as an SharePoint MVP by Microsoft in July 2010. I currently live in New York and am an Enterprise Architect at AvePoint Inc.. I co founded www.NothingButSharePoint.com with Mark Miller in 2010.

MVP Award Jeremy Thake Profile Photo

Whitepapers

NBSP

Check out my articles on NothingButSharePoint.com

Solution Development in SharePoint 2007

This series was inspired by the chatter amongst SharePoint blogs on the best ways to approach customisations in SharePoint using Solutions.

Part 1 - Part 2 - Part 3 - Part 4 - Part 5 - Part 6 - Part 7 - Part 8

Leveraging the SharePoint Platform

This series was inspired by a discussion had with Andrew Coates at a Perth SharePoint User Group meeting. This then turned into a 6 part series on Arno Nell's SharePointMagazine.net web site.

Initial post - Part 1 - Part 2 - Part 3 - Part 4 - Part 5 - Part 6

Webcasts

I have recorded various web casts that I present at User Groups or just on a specific topic by request:
How ASP.NET Developers can leverage SharePoint webcast
SPSource Webcast: Reverse engineer Lists to ListTemplates and much more
SharePoint Development with Unit Testing webcast
Perth SharePoint UG Web Cast on approaches to deploying artefacts (SPSource)
More...

Podcasts

I have been interviewed about Leveraging the SharePoint Platform by the SharePoint Pod Show: listen here .

Feed your read!

Where to draw the line between SharePoint Customisation and SharePoint Development

Tags:

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.

Posted by Jeremy Thake on 11/25/2008
5 Comments | Trackback Url | 3 Links to this post | Bookmark this post with:

Links to this post

Trackback from Microsoft SharePoint Server on 7/6/2011 9:14 AM
Is it necessary to have many customizations in your SharePoint 2010?

[...] I suddenly think about customization in SharePoint 2010. To be honest, I haven’t been SharePoint [...]

Comments

Tom Clarkson commented on Tuesday, November 25, 2008 9:11 PM

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.

Thomas Vochten commented on Wednesday, November 26, 2008 12:56 AM

Hello, just a quick note to let you know that the images on this article don't render...

marijn somers commented on Wednesday, November 26, 2008 2:00 AM

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

Darryl Wells commented on Thursday, November 27, 2008 5:01 PM

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.

Richard Greene commented on Thursday, November 27, 2008 7:14 PM

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.