Research firms such as Gartner and Forrester have experienced a surge in requests for material on release management in recent years, which is widely attributable to the adoption of alternative development methodologies, e.g., Agile with its increased release frequency, as well as the emergence of industry standards, e.g., ITIL, at the enterprise level. Businesses, and business processes, struggle to keep up with the plethora of new and customized products supporting dynamic online markets that are developed through evolving methodologies running on systems with high churn due to short lives and modernization efforts. The struggle often manifests at the go live phase where software updates are cobbled together in attempts to meet changing customer demands. A majority of large software shops establish means to manage product releases along with change management, but most are rudimentarily managed via email and spreadsheets that are limited in scope to a single department. Few companies adopt release management as a practice that spans the entire enterprise.
While the definition of release management varies from expert to expert, there is generally a common thread among definitions that includes the three P’s: a) process, b) preparation, and c) production. In simple terms, release management is about support and enforcement of processes centered on preparing software for deployment to production. There is no minimum threshold for when release management is appropriate to be implemented, whereby companies serious about RMS rely on it for updates ranging from minor fixes to entire modernization. However, it’s rarely this simple and many instances involve elements that include organization adjustments and new disciplines within an already complex software development life cycle (SDLC). Finally, you can’t manage what you don’t measure, and as such release management must include definition of key performance indicators (KPI) along with the means to measure and report periodically.
Many companies today have some form of release management controls around either software development or operations support, but few companies view release management in a manner that integrates both areas under a common oversight. In fact Gartner suggests the difficulty in implementing a successful enterprise RMS in their Strategic Planning Assumptions for 2011 by indicating through 2014, 90% of IT organizations will attempt and fail to achieve end-to-end change management, due to poorly scoped change process workflow and single-tool reliance. In addition, through 2015, 80% of mission critical outages will be caused by people and process issues, of which greater than 50% of those outages will be caused by change/configuration/release integration and handoff issues. (Ronni J. Colville P. A., 2011) These are very humbling projections for companies embarking on plans to shore up release management.
A key driver pushing some companies toward adopting release management at the enterprise level is the difficulty faced when integrating release management for both software development and systems operation support. While most companies recognize an indicator of IT value contribution is how well it is aligned to supporting long-term business objectives, one cannot avoid recognizing the inherent diverging goals of the software and operation support side of IT. The business funds application development and seeks to achieve market objectives through introduction of innovative automation that provides key value to the customers, while measuring the success of products in time to market and quality. On the other hand, the business funds operations support to deliver high availability and performance, while minimizing risk. (Ronni J. Colville J. D., 2011) One side of the equation is to promote change while the other side is about minimizing change. These differences are driving companies to adopt release management as a means to bridge the inherent differences between the goals of operations support organizations and application development.
Implementing release management at the enterprise level takes significant coordination as you will be integrating both systems and processes affecting disparate organizations with legacy processes and business controls that have been in effect for many years. Overcoming these obstacles often requires removing corporate cultural barriers.
Goals
While Gartner takes a pragmatic look at the potential for success around implementing release management, most companies see ever increasing support costs, e.g., M/PS, eroding their ability to deliver new value to the market and are driven by the need to “get it right the first time.” A successful implement-ation could mean a reduction in regression errors, lessening impact of system outages, decrease in problems spawned from new releases, and probably most important to minimize the revenue impact to botched releases. (Schwaber, 2007) Other benefits include consistency of “live” services over many locations and an overall safeguarding of software assets.
Challenges
Because going live to production by nature occurs toward the end of the software development life cycle it can be impacted simply because it’s the only component remaining to make up for prior deficiencies. The three constraints of software development: time, funding, and quality are a constant throughout the entire life cycle and many times the resulting pressures from these constraints materialize at release time. While there is movement toward more automation in release management, it is more an art than a science and it will remain that way for the foreseeable future.
The growth in RMS is a result of companies pursuing more stringent controls over software releases; however, this also can become a vicious cycle in that the more controls introduced the more the tendency is to circumvent the controls, so companies can find themselves back at square one. Proper release management finds a balance between control and flexibility to change at the speed of business, but the release management function must have enforcement capabilities or the entire effort becomes a window dressing activity.
Best Practices
Forrester describes release management in its 2008 research paper, “Best Practices In Release Management” as the convergence of separate disciplines from software deployment to configuration management to quality assurance and even project management. Forrester goes on to describe four key elements in RMS: 1) creating and maintaining release schedule; 2) monitoring the progress of changes targeted for each release; 3) verifying release is ready for production; and 4) handing the release over to IT operation for deployment.
A key element to implementing release management is consistency among its various components and supporting processes. This means consistency across organizations, but also consistency across platforms. Deviations in the way companies perform release management are the very reason release management is desired. Forrester recommends the following best practices for release management. (Schwaber, 2007)
No. 1: Build a strong release management team
· Create a formal release manager position to oversee each release
· Group release management with related functions, such as Test, Build, and SCM
· Position release management as a centralized interface between App and Ops
· Identify and invest in relationship managers who can represent business needs
No. 2: Get serious about production readiness standards
· Verify all parties have followed the release process
· Confirm the release meets all quality standards
· Ensure everyone in the business and IT is prepared for the release
No. 3: Continuously tune release frequency and type
· Reduce the number of releases by grouping changes by content or by date
· Maintain different classes of release with clear criteria for inclusion in each
· Increase release frequency to grab competitive advanatage
Getting Started
Most experts recommend a phased approach to implementing release management that involves a multi-step initiative beginning with establishment of the engagement scope with clearly established returns and benefits. It follows with a maturity assessment to determine in advance areas of potential roadblocks and additional focus. A critical step is the sanctioning of an organization that will have oversight of release management program, along with a reporting structure and necessary authorization to enforce company policy. At this point, the processes that guide the overall program must be defined that take into consideration the business objective and the need for cross-organizational alignment. The processes must be rigid enough to drive efficiencies, yet flexible enough to change with the business needs.
Key Performance Indicators
Companies that implement release management should invest in establishing the key performance indicators (KPI) that will be used to not only gauge the success of the implementation against the target returns defined in the scope phase, but also as a tool for fine tuning the performance over time. Equally important to defining KPI is the means by which the indicators will be measured and reported. Governance of the program will depend on timely periodic assessments of the implementation performance and the KPI will be an important piece of the ongoing audit.
· Reduction in the use of non-standard software and hardware
· Reduction in the use of unauthorized software and hardware
· Reduction in the number of failed distributions to remote sites and in the percentage of urgent releases
· Reduction in the build failures, in number of urgent releases, in releases causing incidents, and in releases implemented without testing
· Reduction in releases backed-out and in failed releases
· Releases built and implemented to specifications and on schedule
Executive sponsorship
Like any company initiative the one common element at the top of all lists is executive sponsorship, and particularly with initiative like release management that span multiple organizations there is a need for a “C” level sponsor that can clear hurdles, sanction policy, and empower the team with the authority needed.
Roles
Tools and processes are innate without an owner with clearly defined roles and responsibilities along with empowerment to enforce policy. This is even more important with release management where there is a strong tendency to circumvent required steps in order to get exceptions handled. Experts like Gartner call for the establishment a Release Manager who oversees all activities related to code going live. Other supporting functions can be virtual and assembled on demand, while remaining matrixed back to a particular organization.
Policies
Policies are the glue that binds all components of release management together. It sets the standard for what is acceptable and what is not. It defines how exceptions are to be handled and any resulting escalation path. Policies should be defined by a cross-functional team with interests that span the enterprise, but they also should be tied back to the business objectives set for release management.
Vendors and Tools
In a 2011 article by Gartner the analyst highlights four companies that offer solutions supporting application life cycle management (ALM). (Ronni J. Colville K. B., 2011) There is a sense from the industry experts that release management automation solutions are maturing, but there is not one single product that will satisfy all the needs of a large enterprise. However, if companies are to be successful in release management they must move in toward automation for policy enforcement and avoidance of legacy processes that are mired in spreadsheets and email. It should be noted that missing from the Gartner article were key software companies, including IBM, HP, and CA, which is probably because the article focused on release management specific applications and products, such as IBM Rational, which are considered configuration and change management based.
Developer
|
Product
|
URL
|
Nolio
|
ASAP
| |
rPath
| ||
StreamStep
|
Smart Release
| |
Urbancode
|
AnthillPro
UrbanDeploy
| |
XebiaLabs
|
Deployit
| |
IBM
|
Rational
| |
Computer Associates
|
Change Manager
| |
HP
|
CCRM
| |
Plutora
|
Release Manager
|
Summary
In this short paper I attempted to distill the knowledge I acquired while researching release management through industry publications, with the hopes I brought light the issues while giving credit to those who did the real research. My objectives were to provide a concise definition of release management along with background and ongoing trends in the area and to answer the question of why companies are investing in RMS. I provided my ideas on the challenges companies face in implementing release management at the enterprise level and some Best Practices in mitigating these challenges.
I found that companies who are successful at release management develop processes that align across contributing organizations and are focused on the outcome of business needs and not driven by tool capabilities. In addition these companies assign key roles with authority to enforce policies on release management. Finally, release management is not a onetime initiative, but an ongoing discipline that must permeate the entire IT and Product organizations. It must be funded, prioritized, and managed as an ongoing life-cycle that must be adaptable to the business needs and market conditions.
References
ITIL® Service Support – Release Management
Ronni J. Colville, J. D. (2011). Release Management: Key Considerations for Getting Started. Gartner , 2.
Ronni J. Colville, K. B. (2011). Cool Vendors in Release Management, 2011. Gartner , 5.
Ronni J. Colville, P. A. (2011). Aligning Change to Configuration and Release Management. Gartner , 2.
Schwaber, C. (2007). Best Practices In Release Management. Forrester , 18.
