SharePoint Application Development: The Process

SharePoint Application Development: The Process

  • Comments 2
  • Likes

SharePoint Applications Again 

In previous blog posts, I have shared some ideas around SharePoint applications (especially ones without any code), including “Packaging, Deploying and Instantiating SharePoint Applications”, “The risks around SharePoint application deployment” and “The Case for SharePoint Applications”. You can read those from this tag search URL:

Now the team that developed the famous “Fantastic 40” SharePoint Applications Templates (available for download from has finalized a white paper on how they developed their applications. The nice Word document covers several aspects of those projects, including the methodology they used, some patterns they have identified in the process and some technical details around the development of SharePoint customizations. Check it out at

I also see clearly the growing appetite for SharePoint development in Enterprise customers and Microsoft partners, the latter encouraged further by the keynote presentations delivered during the Worldwide Partner Conference a few weeks ago. With all that, there’s still a limited amount of content (white papers, books, training) on the topic. I mean there's not enough guidance on how to properly develop, test, package and deploy those applications and especially around the development process itself. In spite of that, the buzz around SharePoint applications continues on. I did notice, however, that there are a some recently released books on the topic and some more coming, already available for pre-ordering. 

That was enough to get the topic restored from tape and right back into my RAM (or my CPU registers).

Data Design for SharePoint Applications

SharePoint application development, especially when restricted not to include any code, is a special case of application development. It has something in common with plain HTML web site development (although more structured and including some data design elements) and it resembles Microsoft Office Access development (which never got enough respect anyway), minus all the VBA code.

It’s interesting to see how a SharePoint “Power User” (think Access user) can do a lot by him/herself and how they get stuck in the last half of the project, usually due to lack of a solid knowledge of data design and workflow development. It’s also painful to observe as someone coming from HTML development pours generous amount of content editor web parts while ignoring the potential of SharePoint’s data model.

In both camps there’s a lot of confusion on whether to use a single site or many subsites under the top-level one, if their data goes into many lists or in one big list with a category column. There’s little use of custom lists and even less use of custom views with filters and group bys. I don’t even get me started with the untapped potential of calculated columns, custom data views, connectable web parts and other similar hidden gems. Still without any code, using nothing but the site itself and possibly a little SharePoint Designer as "development tools".

A Simple Process

We could also use more guidance on exactly how to manage a SharePoint application project. If we could come up with a good process, it would be a lot easier to farm out the development of these SharePoint applications. Treating these as those old-style monolithic development projects will have you spending too much time on each iteration, resulting in lengthy design documents and the usual late and expensive projects. Going straight to creating the site without proper planning will probably lead to poor quality results and a no obvious point to transition from design to development to production.

For instance, I’ve seen a small team work like this:

a) Meet once to gather basic user requirements
b) Work on a prototype site based on user requirements
c) Meet with users to check if prototype is good enough (if not, go back to previous step)
d) Save prototype as a site template and deploy to production

More Process

The process described above is probably too simplistic and will only work well in very limited environments. If you’re planning to host your applications in a shared environment or need to have a multiple teams working on different phases of the projects, that will certainly not suffice.

I have seen a larger team adopt a process that looks somewhat like this:

a) Gather requirements, scenarios, user stories
b) Document all requirements
c) Validate requirements and get sign-off
d) Design data model (subsites, out-of-the-box lists, out-of-the-box columns, custom lists, custom columns, relationships between lists, BDC connections)
e) Design user interface (custom list views, custom data views, custom forms, custom pages, navigation, master pages, CSS)
f) Design behavioral elements (out-of-the-box workflows, custom workflows)
g) Validate design and get sign-off
h) Create a prototype (complete site structure and data model, mocking up complex components as static HTML)
i) Validate prototype and get sign-off
j) Hand over prototype to development team (save as template, backup up site or use SharePoint Solution Generator)
k) Develop and test SharePoint application functionality (including master pages, workflows, custom forms, data views, etc.)
l) Stabilize SharePoint application and get sign-off
m) Package the SharePoint application for deployment (solution package)
n) Validate packaged SharePoint application after deployment to stage environment and get sign-off
o) Deploy final packaged SharePoint application to production environment

The Next Level 

This second process clearly isolates the prototype, development, stage and production environments. It also provides good milestones to track progress and the possibility to have separate design, implementation, test and operation teams working together. It even facilitates scenarios where the actual development is done by a third party or your application is to be deployed to a hosted environment.

I also believe that, since most of what we do with these apps is focused on a specific set of components, we could come up with some sort of template to help with the design documentation. Since the template files are not human-readable, a simple Excel spreadsheet with some wiring could be a great help in describing our lists, columns, lookup fields, etc. Or maybe this is a better fit for a Visio diagram template (are those still called stencils?). I wouldn't be surprise someone created a tool to load ONET.XML or WSP files and do all kinds of things with them, like turn them into human-readable documentation. Now how about creating a SharePoint application that will help you describe SharePoint applications? Most teams would try anything communicate more efficiently. And I'm only half kidding there...


Your specific methodology and process might be simpler than the first process I mentioned or more complex than the second one. In any case, you’re probably not happy with it yet. You see, the whole idea of SharePoint solutions, introduced in RTM form just last November, is in its infancy. We also have a recently updated toolset to build these applications, including interacting with the SharePoint sites directly, customizing sites with SharePoint designer and creating solutions with Visual Studio 2005 and the WSS extensions. The intense release of additional documentation and guidance is finally giving us enough to feel comfortable with it, just in time to be rocked again by the beta of Visual Studio 2008.

SharePoint as a collaboration tool is already a great success. Now many Microsoft partners see the potential opportunities around SharePoint applications and are frantically working to design, develop and host this next generation of solutions. Do you also feel the "gold rush"?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Siguiendo con la recopilación periódica de recursos sobre WSS 3.0 & MOSS, esta semana en el número

  • There are too few out there discussing how to design an application using Sharepoint. You are asking the right questions, but no one answers them :-)

    One such issue is the data model, sites or lists? How course should the objects be?

    I am creating a simple crm-app, so there is a hierarchy: Market-Customer-Project-Solution.

    Should all 4 be lists? Or should Market and Customer be WSS sites? The advantage of making the sites, is that we then authorization on Customer level. Also, having a web page per customer per customer is a good idea, because extra information needs to be stored somewhere, for example contacts, what the customer sells etc.

    However, when I look at WSS-samples, there are few who creates a lot of sites, and if I would create a site per customer, I would have about 100-200 sites. I also notice the customization is on site level, and is not inherited by subsites.