Three Key Elements for Application

Release Management Success

Written by,
Derrek Seif
Product Manager
Quest Software, Inc.

White Paper
© Copyright Quest® Software, Inc. 2007. All rights reserved.
This guide contains proprietary information, which is protected by copyright. The
software described in this guide is furnished under a software license or
nondisclosure agreement. This software may be used or copied only in accordance
with the terms of the applicable agreement. No part of this guide may be reproduced
or transmitted in any form or by any means, electronic or mechanical, including
photocopying and recording for any purpose other than the purchaser's personal use
without the written permission of Quest Software, Inc.

WARRANTY

The information contained in this document is subject to change without notice.

Quest Software makes no warranty of any kind with respect to this information.
QUEST SOFTWARE SPECIFICALLY DISCLAIMS THE IMPLIED WARRANTY OF THE
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Quest Software
shall not be liable for any direct, indirect, incidental, consequential, or other damage
alleged in connection with the furnishing or use of this information.

TRADEMARKS

All trademarks and registered trademarks used in this guide are property of their
respective owners.

World Headquarters
5 Polaris Way
Aliso Viejo, CA 92656
www.quest.com
e-mail: info@quest.com
U.S. and Canada: 949.754.8000
Please refer to our Web site for regional and international office information.

Updated—June, 2007
CONTENTS
INTRODUCTION ................................................................................. 4
PEOPLE COLLABORATE EFFECTIVELY WITH CLEARLY DEFINED ROLES
AND RESPONSIBILITIES.................................................................... 5
COLLABORATE WITH TWO DISTINCT GROUPS – DEVELOPMENT AND OPERATIONS.........5
COORDINATE KEY MEMBERS FROM BOTH DEVELOPMENT AND OPERATIONS ................5
CREATE A SEPARATE RELEASE MANAGEMENT TEAM............................................6
UNIQUE APPROACH FOR EVERY ORGANIZATION................................................6
PROCESSES CREATE EFFICIENCIES THROUGH REPEATABILITY AND
RELIABILITY ..................................................................................... 7
COBIT ..............................................................................................7
ITIL .................................................................................................8
ADOPT A METHODOLOGY FOR RELEASE MANAGEMENT IMPROVEMENT .......................9
COMMUNICATE WITH A CENTRAL REPOSITORY ............................................... 11
ROLLBACK TO A PREVIOUSLY TRUSTED APPLICATION STATE ............................... 11
SECURELY SEPARATE ROLES AND RESPONSIBILITIES ....................................... 12
RECORD CHANGE ACTIVITY ..................................................................... 12
AUTOMATE AND ENFORCE RELEASE PROCESSES ............................................. 13
LINK PEOPLE AND PROCESSES ................................................................. 14
INTRODUCTION
Communication and coordination are vital when introducing any change, but
choosing the right combination of three key elements - people, process and
technology – guarantees the success of application changes and release
management processes.
Today’s IT organizations are rapidly evolving. As they release business-
critical application changes into production environments, they face
additional pressures driven by a competitive business climate, IT must adapt
quickly in order to survive, often a challenging and painful task.
Many teams are instrumental in application release management. For
instance, development plans changes to business applications while
operations deploys the changes into production. Effective communication
between teams is essential for successful application change release. Poor
communication can result in files going to incorrect locations, property files
being wrongly configured or critical steps being missed in the release
process. One or all of these missteps can bring a production application down
and can lead to customer unhappiness, lost revenue and increased
organizational cost.
The Gartner Group estimates that 80% of application downtime is directly
attributed to a combination of operator errors and application failures.i The
inability to effectively manage frequent changes to business critical
applications not only results in lost revenue and increased cost, but also
reduces an organization’s competitive advantage in an ever changing
business world. A McKinsey survey found that “only 34 percent of IT
executives say that they are more effective at introducing new technologies
than their competitors are” 2 in a market of ubiquitous competition.
A single person, process, or technology will not result in consistent
application changes. Organizations need to find the right combination of all
three elements – with clearly defined roles and responsibilities – to better
influence a positive result. Processes need to be established and followed
with management support, and the right technology used to coordinate the
people and support the process. This paper describes how people, process,
and technology can work as a team to create release management success.

4
PEOPLE COLLABORATE EFFECTIVELY WITH
CLEARLY DEFINED ROLES AND
RESPONSIBILITIES
An increasing number of people involved in today’s release management
activities – from technical architects, developers, and operations managers to
business focused application owners, business managers, and auditors – are
driven by critical applications aligned directly with business objectives.
Adding the need for critical applications to the complexity of distributed
applications forces organizations to retain multiple individuals specializing in
different technologies and platforms to successfully manage the applications.
For example, an IT organization may run a Java application on a WebLogic
server with an Oracle database installed on a RedHat Linux operating system
directly communicating through web services with a .NET application running
on an IIS server with a SQL Server database installed on a Windows 2003
Server. Factor in other technologies such as xml schemas or integration
middleware and it’s easy to see there’s a lot to know when competently
managing this type of heterogeneous environment.
Successful coordination of application changes in complex environments
depends on clearly defining each individual’s role and responsibility. Defining
these roles means understanding the relationship between development and
operations.

Collaborate with two distinct groups – development

and operations
Most of today’s organizations place a strong boundary between development
and operations. Changes to an application are made and tested by the
development and testing teams and sent to the operations team for
implementation. Although the roles are defined, a successful result comes
only by pure chance – were the deployment instructions correct? If not, the
development team might think they provided all the necessary files and
instructions while the operations team believes they executed the
deployment based on the instructions and the existing environment.

Coordinate key members from both development and

operations
Another approach is to streamline release management roles by identifying
equal members from development and operations for coordination and
compromise on the process release stage. This adds more responsibility to
the respective development and operations leads, resulting in a streamlined
process with open lines of communication. However, this approach can
quickly overload the job responsibilities of the respective team members,
resulting in a lack of focus on many tasks. For example, a key development

5
manager will be less focused on providing technical guidance on the next
critical feature set while they are involved in the release management
process.

Create a separate release management team

What about creating a third separate group mediating the handoff of
applications between the development and operations teams? This approach,
which adds more people to the release management process, is often
handled by a quality assurance team or technical project lead. The advantage
of this concept is that a dedicated group can focus on the release process
and help coordinate and standardize application releases across the
organization. However, this third group may become a referee to two
completely capable teams already doing all the work, and the politics
introduced by the third party could potentially lead to more red tape when
the ultimate goal is to streamline the process. Finally, an independent role is
often unimaginable in small organizations with smaller budgets.

Unique approach for every organization

As with most things in business there is no clear right or wrong answer for all
situations. The right approach considers the unique complexities and
relationships within each organization, as well as the location of the
development and operations teams, the frequency of the deployments, and
the overall culture of the organizations involved. Regardless, no matter which
approach is taken, the roles and responsibilities of development and
operations must be clearly defined. The development team needs to be
responsible for turning requirements into functioning products and creating
documentation describing, in detail, how to install the product. The
operations team takes the functioning product and incorporates it into the
production infrastructure.
Clearly defined roles are critical for a few reasons:
• Development can continue to create new functionality and products
and not spend unnecessary time with deployment troubleshooting
• Operations will be able to handle the increasing frequency of
deployments that occur across multiple applications
• Customer roles are more clearly defined. In other words,
development’s customer is the operations group whose customer is
the business, whose customer is the customer

6
PROCESSES CREATE EFFICIENCIES THROUGH
REPEATABILITY AND RELIABILITY
It’s obvious a reliable and repeatable process is needed to successfully
manage the increased frequency of changes introduced into an already
complex environment. This becomes even more important in interdependent,
service-oriented architected environments where applications operate on a
plethora of technology and platforms. Without a solid process, deploying
changes become unnecessarily chaotic, introducing unnecessary risk into
environments. Analysts estimate that in the overall application lifecycle,
operations account for between 70% and 80% of the overall time and cost of
an application – meaning only a small portion is actually spent on developing
the application. If an IT organization can reduce the cost of operations over
the life of the application, it can improve the business investment return for
building that application.
Process methodologies are designed to cover different aspects of an
organization, but there are a few key methodologies to consider when
implementing application deployment processes into an IT organization.
Although many organizations use a combination of two or more process
methodologies, two of the more popular for IT organizations are COBiT and
ITIL.

COBiT
As IT services began to rely more on IT governance, the Information
Systems and Control Association (ISACA) and the IT Governance
Institute (ITGI) developed a set of metrics for IT management called
the Control Objectives for Information and related Technology
(COBiT). COBiT addresses a broad spectrum of duties in IT
management that aims to be generically complete, but not specific.
The goal of COBiT is to maximize benefits derived from using
information technology and development of IT governance controls.
This methodology primarily focuses on executive business owners and
has recently become popular due to the Sarbanes-Oxley Act. COBiT
was designed to help organizations better understand their IT systems
and enable them to decide on the right level of security and control to
protect their assets.
COBiT is comprised of four main domains, each with its own specific
process objectives. The Acquire and Implement domain addresses the
control objectives for a successful release management process. Many
of the COBit and business drivers are directly aligned for improving a
release management process, and these drivers include IT process
standardization and automation, structure audit approaches and IT
cost-cutting initiatives.

7
 Figure 1: COBiT Domains

ITIL
Complementing COBiT’s broad control and metric methodology, the
Information Technology Infrastructure Library (ITIL), originally
developed by the UK government, focuses on improving the IT delivery
and support processes. ITIL offers a common framework, independent
of any particular industry or business, and incorporates all activities
commonly found in an IT organization. ITIL’s goal is to make an
organization’s IT operations more mature. The framework identifies a
number of best practices used in different IT organizations and
suggests the optimal process, coordination between processes, and
formality to the process. ITIL was designed to serve as a common
point of reference, so a changing organization can always refer to ITIL
no matter the organization’s size, type, and complexity.
Analyst data indicates that of all the best practices available for IT
operations, most organizations are planning on ITIL best practices
only. Because of this, analysts and consultants predict a 40% adoption
rate by 2007 and as high as 80% in 2008!

8
 ITIL is made up of five main elements, each with a specific subject. IT
Service Support categorizes release management as a main subject.
According to ITIL, the goal of release management is to ensure a
successful rollout of releases into a live environment. By not including
release management processes in the overall IT operations plan and
budget, ITIL warns that organizations introduce the risks of major
interruptions, duplication of work, inefficient use of resources, and loss
of source files. By using the ITIL framework as a guide, implementing
a release management process can achieve process efficiency and help
control the increased frequency of change requests.

Figure 2: ITIL Elements

Adopt a methodology for release management

improvement
When selecting a methodology, consider how it’s different objectives
fulfill the IT organization’s goals and which combination meets the
organization’s needs. Some methodologies to consider are Six Sigma
(which focuses on repeatable processes) and the Capability Maturity
Model Integration (CMMI) (which focuses on improving technical and
managerial maturity). Combining these methodologies will help the IT
organization better align with the business. Since each methodology
has different strengths, an organization that only focuses on only ITIL
may gain improvement in operations, but continue to have poor
controls in other areas. Likewise, an organization pursuing other
methodologies without ITIL may experience a lack of operational
excellence that can’t support the maturity elsewhere in the
organization.
Adopting a methodology is critical for companies under scrutiny by
executive management who question the abilities of the IT

9
organization and prevent the acceptance of IT as a critical business
partner. Understanding the problem landscape will help avoid only
tactical fixes to the problem. Traditionally these methodologies have
been implemented at a more tactical project level, but a more long-
term approach is required as IT organizations move from a back-office
service to a strategic partner with the business.
Any of the aforementioned methodologies can be applied to an
organization’s release management process – albeit using a slightly
different approach – but it comes with a cost. Organizations should
expect to incur personnel and time costs if they hope to understand,
implement, and enforce the release management best practices.
However, these costs are minor in comparison to the potential costs
associated with no methodology, poor planning and the lack of control
over release management.

10
TECHNOLOGY COORDINATES PEOPLE AND
AUTOMATES PROCESSES
Once an IT organization clearly defines release management roles and
responsibilities and formally outlines the release management process, it can
use recent advances in technology to coordinate people and automate the
release management processes. Tools are key for successful release roles
and processes since they are defined independent of a complementary tool.

Communicate with a central repository

A release management solution fills the gap between development and
operations teams. A solution serves as a central location for
application releases and therefore becomes the common
communication point between development and operations. Using a
central repository for application releases, in combination with clearly
defined roles, enables a smooth and seamless transition of applications
through the application management lifecycle (using a collaborative
effort). The operations team accesses the tool to define how the
application should be deployed and the physical server environments
that are available for deployment. Then the release management team
accesses the tool to link together development’s deployment
instructions and operation’s physical environment, and then executes
the deployment.

Rollback to a previously trusted application state

A separation of the application deployment definition and the physical
environment definition enables further deployment flexibility – for
example, a rollback to a previously trusted state of the application in
the event of an error. When the development team defines the
application or deployment instructions, a release management tool
saves a snapshot of the application definition in its internal repository
prior to a deployment. The operations team then links the snapshot,
which is a version of the application definition, to the physical
environment when executing the deployment. Since a release
management tool is designed to ensure that the application definition
is versioned prior to deployment, if a critical defect is introduced into
the environment as a result of the change, then the operations team
can quickly and easily roll back to the previous version of the
application definition – minimizing downtime of the application and
ultimately reducing the impact to customers and any service level
agreements that may be in effect. Due to this, the development and
operations group have time to troubleshoot the change error while
customers continue to access the live application in its previous form.
This allows communication between the development and operations
team, since they have a baseline of information to use for proactive

11
discussions and they can figure out what went wrong in the application
change process.

Securely separate roles and responsibilities

The separation of application definition, physical environments, and
releases can occur only if a release management tool has the proper
role-based security. Since development and operations have clearly
defined roles and responsibilities, it is necessary to enforce the
separation of duties throughout the release management process. By
doing so, organizations can prevent unauthorized changes in all stages
of the release process. This is especially important when deployments
occur in a live production environment.
Often there is a subset of individuals in the operations group that have
access to the production servers. Securing those target servers is
necessary for release management success. Role-based security also
becomes important as multiple applications are managed in a release
management tool. In large organizations there are often multiple
development teams, each responsible for the definition of a few
applications. The ability to secure the modification or even visibility of
applications that a team is responsible for is critical to the release
management process. By appropriately securing across applications
the operations team is able to manage all applications through the
same release management tool, therefore making their release
process much more predictable and efficient. Properly securing a
release management process helps enforce the clearly defined roles
between development and operations and also allows both groups to
collaborate effectively and efficiently with the proper controls in place.

Record change activity

Another key aspect of technology is the ability to keep an audit trail of
all the changes that are made and all the activities that are conducted.
Keeping track of all the release management change activity serves a
variety of purposes and brings the greatest number of people together
in the release management process. A release management tool
brings together development and operations by recording all the
change history, enabling them to troubleshoot in infinite detail about
who, what, when, and where application changes were made. In
addition, using a release management tool to record change activity
provides added visibility to additional people that are not as intimately
involved in the release management process, but need to have a
higher level of knowledge of the process. These people include
application owners, development and operations managers, and
auditors. Development and operation managers will now be able to
track who from their respective teams implemented the application
changes and which files where changed. Application owners will now

12
be able to track which of the applications they are responsible for
incurred changes and when they were change. Also, auditors will now
be able to track all the changes that are introduced into a production
environment and be confident that deployments can be easily and
quickly reproducible to the respective environment. Finally, auditors
can be confident that the organization has intimate knowledge of all
the application files that are currently running in their production
environments.

Automate and enforce release processes

One of the obvious benefits of introducing technology to the release
management process is the efficiencies brought on by automation. A
release management tool serves as the automation engine for release
management activities, therefore bringing repeatability and reliability
to the deployment process. Automating deployments makes is easier
to move applications through the software development lifecycle to
various environments like testing, staging, and production. Due to the
increased complexity of applications and the environments they run
on, there are bound to be minor application configuration changes that
occur when deploying a change from staging to production. The key
solution for reliably managing these changes is found in a
parameterized substitution mechanism that only a release
management tool can provide. Using a tool that separates the
application definition from the physical environment, configuration files
can be defined using variable substitution for key definitions that
change depending on the environment being deployed to. When
linking an application definition to a physical environment, the release
management tool will require the release manager to enter the values
to the variables for the configuration file to be appropriately defined.
By managing configuration files with parameter substitution,
deployments to various environments are more reliable and operations
teams don’t have to spend extra time managing multiple versions of
the configuration files or rebuilding the application multiple times for
each separate deployment environment.
When figuring out how to automate the deployment process, release
teams should look at simple steps that are prone to human error such
as starting and stopping target servers, transferring files, and creating
new folder structures. Initially the deployment process will likely be a
combination of automated steps and manual processes. A release
management tool should allow organizations to determine the right
combination of automated and manual steps that an IT organization
feels comfortable with. Target server credentials, such as to a
database, may require the highest level of security such that
organizations may require a pause in the automated process to
execute the manual intervention and then continue with the rest of the
automated process. This practice is not uncommon.

13
By automating the simple steps, the release manager can now focus
on standardizing the release process across applications. Automating
the application release process increases a release manager’s
productivity. By standardizing the deployment process across
applications, teams can achieve efficiencies and cost reductions across
all applications involved.

Link people and processes

A release management tool is a powerful agent in defining release
management roles and responsibilities and enforcing release
management processes. Tools will allow organization to increase
communication and collaboration of all people involved in the release
process and help automate steps taken to perform a successful
release.

14
PEOPLE, PROCESS AND TECHNOLOGY – A
FORMULA FOR APPLICATION RELEASE SUCCESS

The total release management solution arrives with the harmonious

combination of people working together as a team, using tools, with one
standard process. Each team member needs to have clearly defined roles
and responsibilities, processes need to be established and enforced, and the
right technology needs to be implemented to coordinate the people and
support the process. Improved IT and business alignment means choosing
the right combination of people, process, and technology for an IT
organization for control over the changes to complex, distributed
applications. According to McKinsey, “IT organizations that have mastered
the art of business collaboration may be poised to move to a more advanced
form of strategic planning, a level at which they can truly show the business
how, where, and when to use IT as a competitive weapon.”ii Strategically
aligning the IT organization and business units through improved release
management can be an important competitive advantage that can translate
not only into uninterrupted application changes, but also increased revenues
and, ultimately, happy customers.

15
NOTES

i
“IT Operations’ Three Tenors: Change, Configuration and Release
Management” April 2007 The Gartner Group

“The next frontier in IT strategy: A McKinsey Survey” David Craig, Kishore

ii

Kanakamedala, Ranjit Tinaikar McKinsey on IT Spring 2007

16