The Value of Release Models

To understand the concept of “Release Models” one must first understand the clear distinction between the Change Management process and the process of Release and Deployment Management. At a high level you could say that the Change Management process activities assess, authorizes and control the change and that Release and Deployment Process will actually execute or implement the change. This helps to understand the difference between change and release but also to understand that there will be different skillsets and activities involved for each area. Although Change and Release management processes in and of themselves do have clearly defined objectives, roles and responsibilities these processes do not stand alone and must consistently work together for seamless integration with all of the Service Transition processes including Service Asset and Configuration Management and Validate and Testing processes. This is especially true when you set out to define “Release Models”.

Release Models

You might have already been exposed to the idea of having incident models or procedures that are followed based on type of incidents. You might also have many change models based on type of change. This idea of models is not unique to release management but is a theme that permeates all service lifecycle stages and processes for ITSM. A “Release Model” is a clearly defined set of procedures based on type of Release. It is important to note that there is one “Release and Deployment Management” process and that we will have many release models that run through that process.

The content of the release model includes such things as the roles and responsibilities required for a specific type of release. It will also contain workflow, escalation points, handoffs, deliverables, templates, documentation procedures, timelines and any detail required to effectively and efficiently deploy that specific type of release. Not all releases will require the same urgency, skillsets, and rigor. Having models will ensure that the appropriate detail and effort is applied.

We do this in practice but frequently these models are not document or formalized in such a way that allows us to optimize our productivity. One way to understand the concept of release models is to think about the different types of releases that you deploy in your organization that require very unique roles and responsibilities and well as activities to deploy.

Release Model Examples

Releases for virtualization - Cloud architecture may require the creation of release models or procedures that are very different from those that would be needed for the deploying physical servers in your environment. The ITIL Core Publication for Service Transition notes that “The tools, activities, authorities, roles and responsibilities for creating and managing virtual servers are unique. Often these activities will be carried out by different organizations or service units and the relationship between them will be managed by a contract.” With that in mind there should be no ambiguity in the organization about how this should be managed and deployed. This model will include all of the elements required to meet this unique type of deployment.

Software Deployment – Deployment of code into the production environment will be packaged and implemented in substantially different ways depending on your organizations policies. Certainly this is very different from other types of releases and will require a very special “Release Model”. Who, what, where, when how the software engineers deploy the code will be documented in the model with clearly defined roles and responsibilities, timelines, and more. What is required here and the skillset and governance is unique from other types of deployments.

Once you begin to brainstorm and come up with a list of different types of releases, it might be helpful to categorize these into higher level classifications. Begin by creating a few generic release models and design a framework conducive for ongoing improvement so that these models evolve to meet the dynamic nature of your business. Increase productivity, reduce cost and become awesome in the eyes of your business and customers through the optimization of “Release Models”.

Four Service Characteristics

Recently I came across several articles by researchers and experts that laid out definitions and characteristics of services. ITIL provides us with a definition that can help drive the creation of value-laden services: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. An area that ITIL is not so clear is in terms of service characteristics. Several researchers and experts put forth that services have four basic characteristics (IHIP): Intangibility—Services are the results of actions not things. They have no physical presence and represent a logical set of elements. One way to think of service is “work done for others.” Heterogeneity—Also known as “variability”; services are unique items because of the mechanisms used to deliver services, which is people. Because the people element adds variability, the service is variable. This holds true, especially for the value proposition—not eve...

What Is A Service Offering?

The ITIL 4 Best Practice Guidance defines a “Service Offering” as a description of one or more services designed to address the needs of a target customer or group. As a service provider, we can’t stop there! We must know what the contracts of our service offering are and be able to put them into context as required by the customer. Let’s explore the three elements that comprise a Service Offering. A “Service Offering” may include: Goods, Access to Resources, and Service Actions 1. Goods – When we think of “Goods” within a service offering these are the items where ownership is transferred to the consumer and the consumer takes responsibility for the future use of these goods. Example of goods that are being provided in the offering – If this is a hotel service then toiletries or chocolates are yours to take with you. You the consumer own these and they are yours to take with you. ...

What is the difference between Process Owner, Process Manager and Process Practitioner?

This article was originally published in 2015. With the Introduction of ITIL 4, some of this best practice has changed. See ITIL 4 and the Evolving Role of Roles . Updated Definitions in ITIL 4: Process Owner: In ITIL 4, the concept of 'processes' has expanded into broader 'practices.' Consequently, the Process Owner is now often referred to as the 'Practice Owner.' This individual is accountable for the overall design, performance, integration, and improvement of a specific practice within the organization. They ensure that the practice achieves its intended outcomes and aligns with the organization's objectives. Process Manager: Now commonly known as the 'Practice Manager' in ITIL 4, this role is responsible for the day-to-day management of the practice. The Practice Manager ensures that activities are carried out as intended, manages resources assigned to the practice, and oversees the practitioners performing the work. Process Practit...

Search