SharePoint and ALM – application types/classification

I’ve been doing some work on aspects of application lifecycle management with our version 2 SharePoint guidance currently in development.  In version 1 of our published guidance, we looked at some ALM aspects with managing code developed for SharePoint, in particular we looked at team development, packaging, factoring, environment setup, and process considerations.  We also covered upgrade, which has a set of challenges in SharePoint due to the power of the framework, in particular the ability to customize the application after developed assets are deployed.

We’re now starting to dig deeper into this arena with different types of SharePoint applications – taking a look beyond the development and management of a packaged application into what we are calling content driven applications.  Really what we mean by this is moving into applications which are less structured from a development perspective, that mix developed assets, assembled applications, and generated content.

We are defining application assembly as the process of building an application by composing parts using the browser and SharePoint designer.  SharePoint has a powerful model for assembling applications, a key reason for its huge popularity with information workers.  But once we move into this arena we introduce new complexities into ALM:

• How do I manage the lifecycle now of these assembled applications?
  • How do I deploy the applications
  • How do I maintain the applications
  • How do I upgrade the applications
  • How do I preserve customizations
• Where do I build these sort of applications?
  • In production?
  • In authoring?
  • In staging?
• How do I test these applications
  • When do I need to test the applications?
  • Where do I test developed components vs. assembled components?
  • How do I make sure that the dependences of my developed components are explicitly managed (not dependent upon authored definitions?)
  • How do I manage differences in scope between developed components (farm or web application level) vs. assembled application logic (site collection/site level)?

I came up with this table to try and get some shape around the different types of scenarios to frame the different demands from an ALM viewpoint based upon the intent of the application.  I’m looking for feedback – does this make sense, or is it hogwash?  If it makes sense, does it seem complete enough, or are there missing aspects?