Referenced in the previous blog post on “Center of Excellence Model for Salesforce”, critical to accomplishing a solid global deployment of Salesforce, it is important to understand release management in the cloud  and how best to execute in this model. This blog will focus on a modern way of handling release management in the cloud (like Salesforce.com, Eloqua ect) to accommodate not only long term strategic changes, but how to get more out of your cloud tool and affect change quicker. And as a result your end users will experience the new features in a matter of days and weeks vs. months with legacy tools such as SAP and Oracle. First, let’s discuss the ‘as is’ for most enterprise companies making changes in their legacy IT systems. If a change is to be introduced into the legacy (most likely client/server architecture)  system, this change will take months, and some times years, to get deployed. In addition, when the time comes for the change to go in and the end users see it, the business could have progressed by then rendering the change irrelevant. Garner (below) calls out  the business need for change way outpaces the ability for IT to consume this change.

So how does Salesforce or other cloud based tools allow for the business to innovate and IT still have control over key features such as security, integration and ensuring the stability of the application? The answer is easy; it’s a matter of getting your teams on board and educating them with the “Hybrid” release management methodology. Think of it as a mix between Agile and Waterfall methodologies, with an additional method added which allow your business to move much quicker in adopting change. The most important aspect to this is not the technology or the method itself, but ensuring you have full agreement to the plan from both IT and the business and the clear rules and definitions on how this new model works. Once you reach agreement from all sides, then you are mostly there. Here is the breakdown of how it works.

Major Releases

There are three parallel release paths to this Hybrid method and the first path I call “Major Releases”. The key components of a Major Release are strategic/transformational programs, which typically have a lot of custom code, integration with other legacy systems and need complete end to end testing. This release path is what most large enterprise companies do now and are typically are done through a Waterfall project methodology. Release frequency can be 1-4 times a year depending on your release calendar and is always owned by IT as indicated below.

Minor Releases

The second release path for this hybrid model is called a “Minor Release”. As the name would indicate this release type focuses on small changes, which can have big impacts to your business. These are always done with an Agile project methodology and you can have up to 8 releases a year (as you can see below). Major complex changes should NOT be a part of this release path and testing is still required for the changes to the system. Ownership of these changes can be either IT or the business, however if the business does take ownership of this release path, ensure you have certified, knowledgeable operations personal doing the changes. If you don’t have the right resources staffed on this release path executing the change and the time is not taken to train and certify your team, the risks for this process to fail are high.

Quick Hits

The last release path is something I used at my previous employer and we called it “Quick Hits”. As the name indicates these changes are quick, no testing required and can be turned around in 2-5 days. You can make these changes as quickly as five minutes, but you want to have some service level agreement (SLA) with your end users as to ensure you get are making the changes in the time agreed to by everyone. No testing is required for this release path and there is a clearly defined list of changes that can be accommodated. One of the more critical aspects of this release path (and I alluded to earlier) is to ensure all users understand what falls under a “Quick Hit” and what does not and has to be accommodated in a minor or major release. A few examples from the Salesforce side are below.

In summary, if you set up this model for your company I can assure a few great outcomes:

• Business users will feel the positive impact of the innovation and changes to their cloud application
• IT will have a shared seat at the table with the business as a partner of innovation and adapting to the new models the cloud has to offer

Hector Perez Jr

• Tags: Release Managment, Salesforce