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

It’s been a long while since I wrote the last part and had to find myself reading through all three parts again to realize how much my SharePoint knowledge has matured since then. This is something familiar to a lot of people in the SharePoint community that are evolving at a rate of knots with the Platform.

You may already be aware that I have started a SharePoint Development Wiki that I am encouraging the entire community to contribute to. You can anonymously add comments to any wiki page content or can sign up for free and instantly create/edit new wiki pages. I will reference various wiki pages in this article and encourage you to add comments or content if you have things you’d like to contribute.

The ‘Leveraging Levels’

This part will try and identify the main levels of leveraging the SharePoint Platform. As discussed in Part 3, there are plenty of different SharePoint People/Roles out there which are broken down into how you interface with SharePoint:

· SharePoint Site Web User Interface

· SharePoint Designer Interface

· InfoPath Designer Interface

· Visual Studio Interface

· SharePoint Central Admin User Interface

· STSADM Interface

· PowerShell Interface (direct to Object Model)

As I highlighted in Part 2, there are plenty of “quick wins”, medium term and long term solutions that can Leverage the SharePoint Platform. You may notice that the “quick wins” can all be implemented using the Web Interface, albeit they are made easier by SharePoint Designer and STSADM in some circumstances (mainly for simplified/wizard development interface and automated deployment respectively).
One thing to point out is although it might make deployment more manageable, it does require significantly more skills and more importantly more liberal access to servers.

Limitations of the ‘Leveraging Levels’

I came across a great quote on Twitter the other day which stated that “he spent all his time coding around the limitations of the SharePoint Platform”. I follow the same train of thought as many others on this one and that is that SharePoint is a Platform that is there to be leveraged. It is the building blocks to create solutions and it is not meant to provide full enterprise solutions out of the box on installation. I think this is where a lot of Organisations perceptions of SharePoint are incorrect, as Organisations do not realise the effort that is required to get a full blown solution operational in SharePoint. Organisations overestimate the Platform out of the box functionality and underestimate its complexities and do not provide the correct level of training to the administrators, developers, power users and end users.

On the SharePointDevWiki.com there is a wiki page that outlines the different Levels that you can Leverage the SharePoint Platform and highlights what can be done and can’t be done. What this highlights is that there is significantly more “leveraging” available when you start getting into Solution Packages (.wsp’s) and the Object Model. Please keep in mind that this is only available in the Visual Studio and PowerShell interface (or with Gary LaPointe’s STSADM extensions and other 3^rd Party Products).

When deciding on which ‘Leveraging Level’ you choose, please take into account the limitations – as this will lead to dead ends in your project where you simply can’t push the Solution any further without changing paths and using another ‘Leveraging Level’. Sometimes dead ends can be mitigated by hacking away at the ‘edges of the Earth’ around the ‘Leveraging Level’ you have chosen for the project, but be aware of the risks of these hacks with regards to upgradeability of the Platform. Another useful wiki page is the Comparisons of Implementation Approaches which highlights the pros and cons of using each ‘Leveraging Level’.

Source: SharePointDevWiki.com – SharePoint Implementation Approach Comparison Chart

SharePoint Development vs SharePoint Customisation

Another interesting area that has been discussed recently is related to the ‘Leveraging Levels’ which dictates what the difference is between Development and Customisation. Mark Miller put it well by saying anything that can be done without touching the SharePoint server, for instance, not modifying the 12 hive, inetpub or GAC is a customization. EndUserSharePoint.com focuses on this approach in their articles.

A lot of organizations do not want to run the risk of going further than customization due to the complexities of configuration management. Be aware of the limitations of going down this route. Another common reasons to do it is because of skill sets, when Organisations bring in external expertise to implement a solution, they often want to take on the support internally. This will obviously mean sticking to the skill set of the internal staff which has its limitations also. This is covered in more detail on the Defining SharePoint Development wiki page.

The People and the ‘Leveraging Levels’

As discussed in Part 3, I have found that the People tend to grow with the layers:

From this table you can see that the skills required for each Person outlined in Part 3 varies significantly. This is just one way of slicing through the implementation approaches and its complexities, so please don’t underestimate the intricacies of the Platform.

The ‘Leveraging Levels’ in more detail

SharePoint Site Web User Interface

Requirements

· Local Access to SharePoint Site via Web Browser

Skills Required

· Understanding of SharePoint Site Collection Architecture

Limitations

· Manual stepsrequired, so in a scenario where you want to add a web part to 50 internal Site home pages, the user is going to have to repeat the steps 50 times, once for each Site within an instance of a Site Collection.

Examples of use

· Creating Sites within an instance of a Site Collection

· Adding Web Parts to pages within a Site that is part of an instance of a Site Collection

· Creating List Templates, Content Types, Site Columns in an instance of a Site Collection

SharePoint Designer Interface

Requirements

· SharePoint Designer Client installed locally

· Local Access to SharePoint Site via Web Browser

Skills Required

· Understanding of SharePoint Site Collection Architecture

· CSS, XHTML, ASP.NET (Page Layouts, Master Pages)

Benefits

· The User Interface is a lot more powerful and easier to operate than the Web User Interface and more options exposed.

Limitations

· Manual steps required, so in a scenario where you want to add a workflow to a List within 50 Sites, the user is going to have to repeat the steps 50 times, once for each List within a Site within an instance of a Site Collection.

Examples of use

· Creating a new Page Layout and Master Page for an instance of a Site Collection

· Creating a Basic Workflow on an instance of a List within a Site that is part of an instance of a Site Collection

InfoPath Designer Interface

Requirements

· InfoPath client installed locally

· Local Access to SharePoint Site via Web Browser

Skills Required

· InfoPath development

· VB Script experience

Benefits

· Lots of functionality that is typically required for Business Forms and extremely fast to prototype forms rather than traditionally writing ASP.NET forms.

Limitations

· Often the forms created require extra functionality that is not available without heavily working around the features of InfoPath.

· Manual steps required, so in a scenario where you want to add the Travel expense form in a List to each of the 30 Department sites, you will need repeat the steps to create the List and deploy the InfoPath form for each Site within an instance of a Site Collection.

Examples of use

· Creating Business Forms e.g. ‘Leave Request Form’

Visual Studio Interface

Requirements

· Requires access to SharePoint Server to install Visual Studio on directly (recommend a Development Virtual Machine)

· Requires WSS SDK and MOSS SDK

· Remote Access to SharePoint Server required (for deployment)

Skills Required

· C#/VB.NET and XML experience

· Understanding of the SharePoint Object Model

· Understanding of the SharePoint Solution Package API

· Optional: CAML, XSLT, CSS, XHTML, Web Services

Benefits

· Repeatability and automation

· Self documenting automated scripts and versions of these scripts. Especially useful in a Solutions Integrator where they may repeat the same steps at each client site.

Limitations

· To do what you can manually do in the Web UI or SharePoint Designer often takes a lot longer to construct in a Solution Package within Visual Studio.

Examples of use

· Advanced Workflow

· Creating Feature Receivers to provisioning elements e.g. in a Site

· Creating Custom Actions to modify user interface of a Site

· Creating List Templates, Content Types, Site Columns programmatically

SharePoint Central Admin User Interface

Requirements

· Local Access to Central Admin Interface via Web Browser

Skills Required

· Understanding of SharePoint Architecture and Topology

· Experience with SQL, Active Directory, Networking , DNS, Firewalls

Examples of use

· Configuring SharePoint Farm

· Configuring Shared Service Providers for Enterprise Search, My Sites, BDC, Excel Services

STSADM Interface

Requirements

· Remote Access to SharePoint Server required

Skills Required

· Same as ‘SharePoint Central Admin User Interface’

· Experience with command prompt and .bat files

· Understanding of STSADM commands available

Benefits

· Repeatability and automation

· Self documenting automated scripts and versions of these scripts. Especially useful in a Solutions Integrator where they may repeat the same steps at each client site.

Examples of use

· Configuring SharePoint Farm

· Configuring Shared Service Providers for Enterprise Search, My Sites, BDC, Excel Services

PowerShell Interface (direct to Object Model)

Requirements

· Remote Access to SharePoint Server required

· PowerShell installed on Server (included in Windows Server 2008)

Skills Required

· Experience with PowerShell scripting

· Understanding of SharePoint Object Model

Benefits

· Repeatability and automation

· Self documenting automated scripts and versions of these scripts. Especially useful in a Solutions Integrator where they may repeat the same steps at each client site.

Examples of use

· Programmatically adding Web Parts to Pages in a Pages Library

· Programmatically adding Files to a Document Library from a File Store Directory with Meta Data into the Columns of the List Item

You can see from the limitations that are listed that it highlights the issues of constructing complexed Sites with forms, lists and workflows as one scenario. It immediately highlights the benefits of using Solution Packages within Visual Studio for repeatability and automation of construction of these sites. One thing to take into consideration which comes up immediately with Organisations with more than one environment (e.g. Dev, Test, Pre-Prod, Prod) is the time it takes to do things manually over having these things automated and repeatable.

In Summary

Hopefully you’ll have an idea of the different leveraging levels in SharePoint Platform now. Next month I will place this content on the wiki page to allow others to contribute to the requirements, skills and examples as I’m sure there are many more. This is just a starting block.