SaaS- SF.com

Niel Robertson writes:

"In the last few weeks, Salesforce.com has made two pretty subtle but important announcements. First, they announced the concept of Salesforce.com sandboxes. A sandbox is essentially a copy of your production data which can be used for development and testing. As SF pushes AppExchange and users start to experiment with integrating 3rd party components, there is clearly a need to be able to "play around" in a development sandbox before releasing integration or application changes straight to production. Also, as SF.com applications become more complex and critical, you can imagine a testing phase similar to UAT (user acceptance testing) becoming part of the standard SF.com development cycle. All of this I find very ironic, as one of the key benefits of SF.com is that it does not have a development cycle and multiple environments. This is one of the curses of the packaged application infrastructure, where an implementation is not just production but development, testing, and in many other cases 1 or 2 more systems (e.g. DMO in PeopleSoft or Pristine in JDE). Any features must be systematically moved from DEV to TST to PROD in a labrious release process.

The second, more recent announcement is that SF.com (and SugarCRM) now are part of the Eclipse IDE movement. This means you can get SF.com plug-ins for Eclipse and develop composite SF.com apps in the same way you would develop other applications. So, whether we like it or not, the VP of Sales is no longer becoming your key SF.com developer, its headed back to the IT department. "

{emphasis is added}

IMHO: I had covered SaaS earlier, here. In my opinion, although SaaS is gaining, and will continue to gain, momentum it will be more due to the alternate pricing mechanism, rather than due to quicker development cycles or reduced complexity or higher efficiency. I see a convergence back towards the packaged application way of development, but the pricing and the pay-for-use model will make it an enticing option in the future.