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.
Articles of Note:
Salesforce.com Sandbox Site, C|Net
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. Notable other members of Eclipse: Oracle (with Fusion Toolset Plug-ins), SAP (NetWeaver Web Dyn Pro plug-ins), and pretty much everyone else under the sun (except Sun ironically). 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.
Articles of Note:
Computer Reseller News Article, LinuxWorld Article
What I am taking away from all of this is the following: as applications become more complex and more mission critical, the development lifecycle simply becomes more complex as there is more at stake. My guess is that 3 years from now, SF.com, while still hosted, feels a lot like other packaged applications in terms of the change management lifecycle. Being involved in a company focused on packaged application change management, you can bet we're watching this very closely and are laying appropriate plans in the background.
