Skip to main content

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”.

 

Comments

Popular posts from this blog

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People:   Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products:   These are the technology managem

What Is A Service Offering?

The ITIL4 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 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 than toiletries or chocolates are yours to take with you.   You the consumer own these and they are yours to take with you.               Note: Goods may not always be provided for every Service

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

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables.  An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and th