After weeks of feverish speculation (if you follow cloud computing, that is) Salesforce.com (SFDC) and VMware have revealed what VMforce really is.
First off, it’s not an SFDC offering for private or hybrid clouds (kudos to SFDC for it’s continued purist public cloud stance) nor is it entirely similar to Amazon’s EC2, what some were dubbing virtualisation-as-a-service.
It’s billed as the world’s first enterprise Java cloud. I see it as something between force.com platform-as-a-service and the EC2 infrastructure-as-a-service which leverages off VMware’s SpringSource acquisition. Essentially, apps and services can be developed in java and can run on force.com and therefore enjoy the benefits of all things java and the force.com value-add features: access to analytics, workflows, triggers, chatter, user access control and the database. And it’s scalable and open.
Existing java apps can be ported without having to be re-written in Apex, investment in java resources can be leveraged and there is therefore no real fear of lock-in.
All of the above should find further favour with hitherto skeptical CIOs.
As a side note, I’m surprised that the current copy on the VMforce home page does not emphasise the force.com benefits but focuses on the other important aspects: scalability, openess and trustworthiness.
This is a promising development and one to be watched.
Migrating applications to the cloud poses a particular set of change management challenges for organisations.
The many benefits of cloud computing are well known. At a high level these can be grouped into infrastructure and application management benefits.
Let’s focus on some of these benefits from an application management perspective: scalability, rapid deployment, ease of configuration changes and a culture of iterative releases. These benefits inevitably result in key stakeholder groups requiring a change in mindset especially during the post roll-out release cycles.
The typical implementation consists of a rapid deployment to either the entire user base or a subset of users. This is then followed by a series of new functional releases and a roll-out to the remaining user base. This can be described as a rolling roll-out and requires the deployment team to think differently.
From the requirements gathering process right through to the training sessions the deployment team has to adjust to running multiple mini-releases in a compressed time frame. This is not sustainable indefinitely but can be done over a 12 to 18 month period as opposed to a having one massive release at the end of, say, a 15 month project.
The key to success lies in the ability of the deployment team to re-engineer and re-imagine the old way of doing things. This means defining the nature of application changes and developing a strategy to manage each of these types of changes. For example, basic configuration changes will not require the full suite of change control tasks while new functionality which requires some level of code customisation will require a more rigorous approach.