Part 1 – What is the SharePoint Platform
Part 2 – What capabilities to start with
Part 3 – How to start with the SharePoint Platform
Part 4 – Levels of leveraging the SharePoint Platform
Part 5 – Why use SharePoint as a Development Platform
Part 6 – Lessons learnt from Leveraging the SharePoint Platform
We are coming near the end of this 6 part series, but don’t worry, it’s not the last you’ll hear of me! This part focuses on ‘Why develop leveraging the SharePoint Platform?’. This is really targeted at ASP.NET developers specifically, but also other web application developers from other walks of life also. Or anyone currently working with Vanilla SharePoint and wanting to dig a little deeper!
As discussed in the Part 1, SharePoint leverages ASP.NET and NET WF among other languages such as XHTML, CSS, XSLT, XML and JavaScript. Most ASP.NET developers will already be proficient with these languages making the learning curve pretty much around the Framework itself. The Collaborative Application Markup Language (CAML) is about the only new language that is new to SharePoint Developers which is used to build queries in XML.
One of the first things to remember is that SharePoint is a Platform and NOT a Product. SharePoint is there to be leveraged. It is pretty much useless vanilla out of the box from a fresh installation as an end user. It needs customisation and development implementations for a Solution to be usable and successful.
As discussed in Part 1 and Part 2, there is a lot of functionality out of the box and it is worth being aware what this is to see if you can get any wins out of reusing this in your solution implementations.
SharePoint provides lots of plumbing out of the box that you’d typically be writing yourself or plugging together a bunch of components. Common bits you have to put together are: User interface Framework, Windows Services, SQL Databases, Persistence Layers, CRUD UI screens, Security, Workflow engines, File Upload, Deployment Framework etc. All this is there at you disposal with a few lines of code or clicks in the User Interface. This saves a significant amount of time up front.
Like the .NET Framework, some things are hidden away in various namespaces and often you’ll find developers writing functions that already exist. There’s plenty of content out there to ensure you don’t make this mistake. I personally find MSDN currently a bit dry as the structure is based on each object in the object model hierarchy and it’s methods and properties. Often these don’t fit into a scenario where you’d use them in isolation. The scenario based examples are littered all over the blogosphere and more recently being structured on the SharePointDevWiki.com. MSDN do have these scenarios, but they are just written into one long list of articles with no structure which makes it hard to discover what you’re looking for. SharePointDevWiki.com gives you the best of both worlds.
As I discussed in Part 4, there is more than one way to skin a cat in SharePoint and it is important to agree on a standard approach within each SharePoint environment for consistency. Being aware of each approach and it’s strengths and weaknesses is just the start of the implementation process!
SharePoint is becoming more and more common across IT infrastructure and you can bet your bottom dollar it’ll only get more common as time marches on. The platform allows you to build solutions and not have to focus on things such as: Scalability, Disaster Recovery, Performance, Interface Design Frameworks, Security and Deployment. All this stuff is part of the plumbing of SharePoint Infrastructure and managed by your Infrastructure team and propeller head Architects. More often than not, they’ll be a few guidelines to follow when building your solution and that’ll be the last you hear of them! Please don’t get into the habit of doing this stuff as well as development, see my recent post on ‘The SharePoint Implementation Market needs to grow up!’ to find out more on this.
One thing to remember with Frameworks is that they evolve over time. SharePoint has already gone through 3 major versions with another just around the corner in Q1 2010 (SharePoint 14). When you implement your solutions on top of SharePoint, without any extra effort (if you’ve done things correctly) you get a whole heap of extra functionality when you upgrade to the next major version.
You’ll find people rewriting functionality because it doesn’t work “quite right”, but realistically people should be extending the framework. Often this is purely down to the skill level as a .NET Developer or in Power Users case…no skill level at all. If you rewrite or hack the current functionality, you’ll find that updates will overwrite your changes, extending the framework ensures they still exist. You’ll probably have to do some integration testing to ensure your extensions still work on top of the new version. This is happening more and more as Power Users find ways to work around the Development approach with tools such as jQuery, see my post on ‘jQuery: the SharePoint Band Aid’ for more information on this.
As I mentioned recently the SharePoint Development community has got a long way to grow to be respected. I would recommend reading that post to get a deeper understanding of what I mean. I’ll cover off a few things here that are relevant to the objective of this post:
Like any platform, SharePoint is great a rapidly building applications and is therefore great for Prototyping. Be extremely careful to set the expectations to the End User that these are Prototypes and not the real thing. You will need to build the end solution with a lot more rigour than throwing components together to get an end to end solution running to pilot.
Because you can rapidly build solutions you will find development teams having very short iterations producing extremely rich functionality. This lends itself well to an Agile approach to development, which is where the Development Market should really be, moving away from the traditional Software Development Lifecycle (SDLC).
Andrew Woodward is leading the charge with SharePoint and TDD. There is also ongoing documentation on the community happenings around this on the SharePointDevWiki.com. Eric Shupps has just posted an anti-TDD SharePoint post here which has caused a lot of discussion around the whole paradigm. I take the stance that it is suitable in certain scenarios, those of which I have not had time to define yet, but will do on the SharePointDevWiki.com shortly. If you are currently in th e.NET space and using TDD, the community would welcome your feedback as it is still in limbo!
A lot of implementations can be done without writing a single line of code and some can be written with a few. Often it is just all too hard to keep a repository of these “little” changes..but we’ve all seen an avalanche right? Don’t be fooled by teams that say you can’t use source control with SharePoint Implementations or by those who say SharePoint does it for you! That is not totally true! You should place as much in source control as possible outside of the SharePoint environment and it is completely feasible!
Unfortunately the Development tools aren’t what they should be for such a used Platform, so much so that the community has had to lend a hand! I advise you to get familiar with the tools that are available and their limitations. I also advise you to take a look at what could be possible in the future with a community project to build the Ultimate SharePoint Development tool!
There has been some sneak peeks into VS2010 (and VS2010 UI look and feel) as well as the introduction of VSeWSS 1.3 CTP which has come along way from VSeWSS 1.2. But the community still seems to be backing WSPBuilder very strongly due to the limitations of the VSeWSS product paradigm where it doesn’t conform to the 12 Hive structure like WSPBuilder and STSDev.
As discussed in a recent blog post, the SharePoint community is simply unprecedented against any other platform out there! I have never seen a community so eager to share their knowledge. Go to Google and do a search for OpenText ‘RedDot CMS’ or ‘SAP’ or ‘Business Objects’ and see how much information is online to help the community on implementing that platform. There are 500+ blogs, forums, the SharePointDevWiki.com, podcasts and webcasts, I listed a few below but keep up to date with this list here.
At a minimum you should read these blogs to keep up with SharePoint Customisation and Development:
There is an enormous amount of options with regards to training in SharePoint Customisation/Development.
Classroom based training is spreading like wildfire with a variety of options in most countries across the World. These courses tend to focus on the Framework fundamentals currently rather then leveraging the tools to give Developers a grounding…without this, and knowledge just of the tool would mean that debugging code would be incomprehensible.
Microsoft along with other Vendors are providing lots of rich online training, including Virtual Labs. As a trainer myself, I find that online training is not suitable for everyone and that class room training supported by a trainer who knows the platform inside out is a lot more valuable.
As I’ve mentioned before there are some great places to start learning:
There are paid labs too:
It seems every time I check Amazon there is another SharePoint book being released. They are getting more and more specific to the particular capability areas of SharePoint such as BDC, Workflow, InfoPath which allows Developers to deep dive into the areas they are trying to implement.
Check out Amazon for SharePoint or the SharePointDevWiki.com book list.
There is plenty of cool activity in the development space to keep us Developers happy and challenged…which will obviously need keep passionate about the Platform. It is also a great way to differentiate yourself in the SharePoint Community as mentioned when listing the bloggers out there.
Silverlight is making inroads into the Internet with its powerful Video Streaming technology but also because of the implementation process that separates Design from Development. There has been some posts already surfacing on integrating Silverlight into SharePoint and also rumours of SharePoint 14 improving the UI using Silverlight.
As mentioned above, TDD is a hot topic, and would also be a great area to focus your existing skills on and apply them to SharePoint Implementations. I encourage you to check out the posts around on TDD.
WCF is still relatively new and with those long horrible xml configuration files going to take a while for the majority of Developers to move away from standard .NET Web Services. SharePoint doesn’t support WCF out of the box but there are posts out there on this.
A post for Developers wouldn’t be ‘cool’ if I didn’t mention Cloud Computing 
SharePoint Online is SharePoint in the Cloud. There are plenty of post on it and what you can/can’t do if the platform is hosted up in the cloud.
So I caused a bit of a storm in a teacup with my ‘jQuery: the SharePoint Band Aid’ post. jQuery + SharePoint is not going to go away and there are some great examples of how powerful it can be. Microsoft have picked up jQuery and are running with it for SharePoint 14 also.
PowerShell (PoSH) is another scripting language that seems to have taken the SharePoint world by storm. If you are a PoSH wizard, then you should start showing off your stuff by manipulating the SharePoint Object model. Check out these PoSH posts to see what others are already doing. SharePoint 14 will also have a lot of PoSH stuff going on for you to leverage.
So hopefully this gives you a feel for what SharePoint can do for you as a Customiser/Developer and also where to find more information to help you.
I encourage everyone who is going down this path to help collaborate on the SharePointDevWiki.com to make experiences for new people moving in this direction easier in the future.
Jeremy Thake is a Senior Consultant at Readify specialising in SharePoint Technologies. He has been based in Perth for the last 5 years on Microsoft Platform Development and Enterprise Content Management projects.
Contact the author | Other Posts by Jeremy Thake (6) | Author's Website
Loading ...
