The SharePoint Deployment Maturity Model

MOSS has been the most successful server product Microsoft ever released. Sales are growing much faster than Microsoft ever expected and apparently the UK is outstripping worldwide growth. Unfortunately this quick growth is also highlighting one of the major problems that everyone seems to be struggling with – deployment. I’ve been working with MOSS since Beta 2 and I have debated this issue with other colleagues and we are all in agreement: deployment is one of the biggest pains on any SharePoint project. It’s one of the areas that will give you more problems and cost you more money. What is curious is that all companies adopting SharePoint seem to go through the same evolution path. Finding a way to measure where my customers are on this path gives me a good idea on the challenges that I will be facing when moving their projects forward. The kind of measure that I’m talking about it’s called a Maturity Model so I called it the Deployment SharePoint Maturity Model (SDMM).

Like the Capability Maturity Model (CMM) I divided the SDMM is divided into 5 levels (except for level 4, I have used the same names has the CMM because they are a good match):

• Level 1 – Ad hoc (Chaos): Companies in level one normally do all development directly in the production system using SharePoint Designer. There is no development or system test environment because no one knows how to move the site to a different server. These companies are normally just starting using MOSS and they do not have experienced MOSS resources.
• Level 2 – Repeatable (Backup/Restore): Level 2 companies have found that SharePoint content and configuration can be moved across environments using backup and restore. As such they have a repeatable deployment process. Unfortunately these companies soon realise that using backup and restore will cause a series of problems that are not immediately noticeable like:
  1. Publishing pages still pointing to page layouts on the previous environment – It seems that SharePoint stores a full URL to the page layout and this URL does not get updated when content pages are moved with backup and restore.
  2. Exceptions raised when trying to edit publishing page settings – this can happen when the source domain (the domain where the backup is taken from) is different from the destination domain ( where the backup is restored to). This happens because the “author” and “last changed by” properties are holding references to a user account in the old domain.
• Level 3 – Defined: Companies normally get to level 3 after learning with their mistakes and spending a lot of time and effort going through levels 1 and 2. In level 3 companies have learned that there is a better way to deploy their applications by using CAML in Features, Solution Packages and Site Definitions. Unfortunately there are quite a few configuration artefacts (like security, search, etc) that cannot be deployed via CAML. To overcome this problem companies develop a mixed automatedmanual deployment process where some artefacts are deployed via CAML scripts and others by following a long list of manual steps.
• Level 4 – Automated: At this level companies have managed to fully automate their deployment process by using a mixture of CAML and .Net code using the Feature and solution Framework. This normally comes at great cost because not only developers will need to learn CAML but they will also need to learn the SharePoint API so that they can automate the deployment of configuration artefacts not covered by CAML.
• Level 5 – Optimised: This is the SharePoint deployment Nirvana. At this level companies not only have their deployment process fully optimised and automated but they have also started to manage those processes as shared Intellectual Property (IP) across projects. At the end of every project there is an IP harvesting process that brings any new deployment code into a central location so that it can be reused and shared by future projects. The time required by these companies to setup a new SharePoint project is minimal and quality of their deployment scripts is high because it’s based on tested code used several times before.

I’m a strong believer in using the SharePoint Feature and Solution Framework for the development and deployment of SharePoint sites and I’ve been using it for a few years now. But I know that there are many limitations with this framework and that it does not cover everything that we might want to do. That’s why in Collaboris we have created SAF. SAF is an XML framework that can be seen as an extension to CAML. It still makes full use of the Feature and Solutions Framework but it addresses some of the areas not covered (or badly covered) by the out of the box framework. We have been using SAF for several years now and have recently made it available to the SharePoint development community via the SAF CodePlex site.