Neven Zitek On one side we have business operations, which rely on well-established processes, with little or no room for deviations. And on the other side is IT, which is supporting those operations as one of the fastest changing industries in the world. And within the IT, there are not only technology-based changes we have to consider, but the way we operate and consume IT services is changing as well; from the basic IT-as-a-tool model, to IT services (provided in-house or outsourced), and the latest novelty – the cloud-based service model. All of those have a great impact on business operations, especially when transitioning from one model to another.
But, we can examine the large impact changes present to the business operations even on a small scale, such as a single application version change. Such changes often get neglected, as on an operational level, application software is considered to be an asset, and as such, unchangeable. This might have been true some time ago when software was distributed via physical media, and major changes in software were presented as new software for which you had time to examine, train personnel, modify business processes if necessary, and at the end, easily implement it within your workplace. But today, with online software distribution and auto-updates, how do you prevent software changes that might bring business operations to a grinding halt?
Controlling the changes by preventing them from happening automatically over time
It’s good practice to keep all software installation media and files in their current form after the deployment. You might need them later for additional installation, or in case you need to reinstall / restore the whole workplace. By keeping the original files, you are ensuring the same user experience and functionality even if the software provider has made changes to the package in the meantime.
Figure 1 – Definitive Software Library (DSL)
Within ITIL, such practices are covered within the Service Transition part of the Service Lifecycle, or to be more precise, it’s under Release Management responsibilities to establish and manage the Definitive Software Library (DSL) – as a repository of all authorized versions of software currently in use within the organization.
With a strong connection to Change Management and the Change Management Data Base (CMDB), Release Management ensures that new changes implemented within the new software versions will not introduce unwanted effects that might jeopardize business operations. You can read the following articles to get more information about how to manage new releases: ITIL Release and Deployment Management Part I – General principles and service testing, and ITIL Release and Deployment Management Part 2 – deployment methods and early life support, or this one specifically written about: ITIL Application Management Lifecycle – within IT Service Lifecycle.
Hardware gets changed over time as well
If you also operate hardware equipment (servers, storage, network, computers, etc.), you’ll have to treat those assets in the same manner as described before, as hardware can be changed over time as well. Some changes in hardware may even lead to a situation where it’s not even compatible with the system you currently operate.
Therefore, an area should be set aside for the secure storage of definitive hardware spares. Such area is known as a Definitive Hardware Store (DHS) within ITIL, and this would contain spare components and assemblies that are maintained at the same level as the comparative systems within the live environment.
Details of these components and their respective builds and contents should be recorded comprehensively in the CMDB. These can then be used in a controlled manner, when needed, for additional systems or in the recovery from major Incidents. Once their (temporary) use has ended, they should be returned to the DHS or replacements obtained.
Can you cope with automatic changes in Cloud services?
When you use traditional software applications, even the most advanced auto-update service can be disabled, or prevented from installing a new software version that is untested in your environment. But with Cloud-based services, you are only using the front-end service, and everything behind it is completely obscured and out of your control.
A Cloud service provider may change anything: from application front-end, to the way they deliver a service, so how can you prevent and / or minimize the impact to the business operations?
This is a very complex topic, but in short – you can’t. By embracing Cloud services, you accept some downsides, and uncontrollable change & release is one of them. You can either design flexible business operations processes to mitigate any change imposed, or you can simply avoid transferring Vital Business Functions into such an environment. And this would be a great point to find out more about the Vital Business Function according to ITIL principles.
