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

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 the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…