What is the difference between Release Management and Service Management?

Service management implies IT Service Management or ITSM while release management is a whole different set of roles and responsibilities and it is a term that is geared more toward a development-driven IT organization. Some organizations take an ITSM approach to release management, but many organizations are starting to decouple traditional ITSM from more agile approaches to release management.

You could think of service management and release management as referring to the same activities viewed from a different perspective, or you could view them as polar opposites. That being said the same organization often has different teams practicing both service management and release management. Both approaches are not in conflict; although, if you bring these teams together there will surely be disagreements about definitions. This post is an attempt to illustrate the nuanced differences between service management and release management for leaders looking to understand what these two terms mean, and, more importantly, how they are related to each other.

Defining Service Management (ITSM)

Service management or IT service management (ITSM) refers to a collection of activities, and it also implies a particular process. Here’s what Wikipedia has to say about IT service management:

ITSM often implies that an organization has adopted the Information Technology Infrastructure Library or the ITIL which is a set of standards and procedures used to support applications (or in the language of these standards IT “services”.) ITSM is related to other standards designed to provide organizations with processes to guarantee quality such as COBIT, ISO 9000, ISO/IEC 27000.

Almost impossible to describe in a brief blog post, ITSM and standards like ITIL bring along a process and a whole collection of standards for everything from architecture to change management to release and deployment to incident management and so on. If an IT department says they practice ITSM and individuals state that they are ITILv3 certified it is very likely that they share a very IT-centric and process-oriented view of standard IT functions.

Defining Release Management

Now take a look at the, much simpler, definition of release management on Wikipedia:

The term release management is more recent than service management and you should note the emphasis on developing and delivering software. Release management (and release managers) focus on moving software projects through stages or environments and are focused on iterative, regular releases.

When you say that you practice release management you are often implying that your organization has an emphasis on software development and you’ll be talking about applications instead of services.

What’s a “service”?

Depending on your perspective and context the term “service” may mean two very different things:

• When you practice ITSM a “service” is just about anything. It can be an Oracle database or some Peoplesoft system that supports accounting. It can be a DNS server, or it can be an application developed by in-house developers. In the world of ITSM, there’s no real distinction between software developed by in-house developers and software supplied by a vendor. Everything is a service and the goal is to maintain availability to react to changes using a process that guarantees quality.

• When you practice “release management” with everything else that implies, a “service” likely refers to an internal API or system that supports an application. If you are a developer or a release manager for an application the term service implies that you are using a “service oriented architecture.” This means that you likely have some REST endpoints or something more complex like a SOAP service. Example: a financial news website has an application that calls out to a stock quote service to retrieve the current price of a stock.

These are two very different definitions. If you are involved in software development you might not understand what ITSM professionals mean by the term “service.” Conversely, if you are working in an ITSM environment it is easy to be confused by developers talking about services. The term is abstract, and it has different definitions depending on your context.

Information Technology: Service Management

Developers seldom think of themselves as part of an “IT” organization and when a team describes themselves as working in “IT” it implies that they are supporting ongoing operations. They are part of an infrastructure group supporting an operating business. If it is a large enough business the “IT” group is responsible for a set of activities that guarantee availability. They are often the group responsible for keeping production systems up and running at all times, but they are also the group responsible for making sure that the copiers keep running, email keeps on getting delivered, laptops continue to operate on internal networks, and the accounting systems don’t stop working.

To IT everything is a service. Keeping production databases patched and up to date isn’t so different from making sure the company’s phone system continues to operate. IT provides services to customers and ITSM gives the IT department a unified process to track and guarantee uptime. Standards such as ITIL also bring with them a set of job roles and defined activities that IT departments can adopt instead of having to reinvent a new process for every new company. If there is a bug in a service or an interruption to availability call problem management and if someone needs to alter production you can fire up a software package that was built to support ITILv3 change management.

Application Development: Release Management

While ITSM is about IT, release management is about developers and application development and this focus area has been trending toward agile for more than a decade. Agile was created as a reaction to slower moving processes of the previous two decades that are often referred to as “waterfall” processes. When someone uses the term “waterfall” they are talking about long-running, slow-moving processes that involve several stages of application development.

Prior to Agile most projects took months to move through a process that had strict definitions of roles and responsibilities. Developers would never architect a system. That was left to the “application architects,” and they would certainly never deploy software to production, that was a task best left to an operations team (usually following strict procedures defined in ITIL.) With Agile teams have adopted a more fluid approach to development. Software isn’t transitioned through a series of lifecycle stages once, it is moved through an iterative cycle of state transitions over and over again. A web site might deliver features every few days, and in the process, this calls for a much lighter-weight process.

The False Paradox: Stability or Agility?

If you are familiar with the billion-dollar IT department at the center of a large bank or government agency you have an appreciation for ITSM and ITILv3. It may not be the most enjoyable process to follow, but when you have hundreds of projects each with a production commitment to 24/7 it helps to have a process and a standard in place. On the other hand, if you work for an innovative technology company or a large company with a DevOps initiative you appreciate that Agile and ITILv3 require some isolation. If every change to production has to run through a fifteen-step flowchart you’ll never get anything done.

This leads many to believe that there’s a choice between the stability and predictability of ITILv3 and the benefits of Agile. This is a false paradox – you can achieve different levels of both agility and stability by using tools and processes that are tailored to each individual project. You might want to apply “service management” processes to your Peoplesoft applications while supporting a more Agile “release management” for your customer-facing web site. In a large IT organization, you have to use the right tools for the right job.

Proactive vs. Passive: Services are Maintained, Software is Released

When viewed from the perspective of practitioners release management could be more different from service management, but depending on your organization approach to software development and IT you may be using both approaches to support different parts of your organization, and even though ITILv3 and Agile may seem diametrically opposed to one another, there is some overlap, and if you use tools like Plutora you can expose the same software “release” as a compliant ITSM service management process. The trick is in translating and adapting both worlds to one another.

With Plutora you can isolate release management from service management using API integrations and support for the various tools used by different groups. Here’s an example: groups practicing ITILv3-inspired ITSM often standardize on BMC Remedy or ServiceNow. These are ticket-based systems that can step a change request or a process through a lengthy, multi-actor process. If you look at some of the simpler examples of change management you’ll see that there’s a whole committee of people involved in making sure that production changes have been given the appropriate approvals either to preserve uptime or to comply with regulations such as Sarbanes-Oxley or PCI.

While ITSM groups use BMC Remedy, your application developers may be using Atlassian tools such as JIRA or other issue tracking tools such as FogBugz. Plutora can facilitate translation between these two tools automatically. This means that you can practice release management while exposing the output of the release management process as a series of ITSM-compliant inputs to a group that is more adept at service management.

Conclusion

Service management is focused on availability of services as a general concept making no differentiation between a “service” like a database or a custom application. Release management is more focused on development and developer output. Release management is essentially a reaction to what has been perceived as productivity-killing procedure of which ITSM and ITIL is an example.

While there is a disconnect between these two concepts both are appropriate for different tasks within your IT organization. You need ITSM and ITILv3 professionals to keep systems up and running, and you need your innovative developers to produce code quickly without many obstacles. The key to success in bridging the release management and service management divide is to use a tool like Plutora to manage the translation between these two paradigms.