To those who deal with IT quality management, the questions „what is IT quality, actually, where and how is it measured, and where is it created?" very quickly arise.

According to the IEC 2371 standard, quality is the correspondence between the observed properties and the previously defined requirements of an observation unit. In the case of IT quality, the observation unit typically either is an IT component (server, switch, router, etc.) or an IT service.

Very often, in case of IT quality, agreed upon KPIs (Key Performance Indicators) in IT operations are reviewed. These operative KPIs are, on a regular basis, indicators that indicate the availability of a server system, the load on a file service, or also the degree of network utilisation. What is taken under review here are also operative servers and network components and/or the interaction of infrastructure components through which a service is defined. This is completely okay with respect to the agreed upon quality of a service to be provided because, ultimately, the contractually agreed upon provision of operative services can actually only be assessed in operations.

The quality of hardware and software ultimately only proves itself in practical use

The catch with respect to quality, though, is that the characteristics inherent in the systems are not implemented once in operation in the systems, but rather much earlier than that. If, for instance, network cards that are outside the manufacturing tolerances are installed in a server system, this may only show up much later during operations. The same applies to the implementation and maintenance of software. If insufficiently tested software is put into operation, the software errors often only show upon intense utilisation by the users, wrong results are produced, or – worst case – complete systems fail and a complete service is disrupted.

Here, release management as a component targetedly contributes towards increasing and/or ensuring the stability and thereby also the quality of the operations. And this in multiple ways:

 

1. Through bundling of pending software changes

With the bundling of pending changes in one release, the necessary interruptions of a operative service are minimised.

The old rule of thumb applies: „Never touch a running system". But when changes must be applied to an operative system, it is far more efficient to carry out these changes in one release than to disrupt, or even interupt operations time and again in order to carry out the next individual change.

 

2. Through monitoring of development and test activities

The release management monitors the development activities with respect to adherence to the schedule of development activities and tests to be carried out. It is only once it has been ensured that all changes ordered have been developed successfully and have been tested in accordance with the release requirements that release management grants the release for assembling the release.

 

3. Through comparison of the results from functional tests to the specialised requirements

As part of the release management, it is ensured that the requested functional changes have also been successfully tested in a functional test/user acceptance test.

 

4. Through the monitoring of the roll-out of the software components to be installed

Once all pending software changes have been put together, a final verification is performed to determine whether all changes have also been combined in the software delivery. If this is the case, the final release for delivery and installation is granted for the release.

Release management increases the quality and spares the budget

The implementation of a release management as described in IT service frameworks such as ITIL encompasses many more aspects in the operative implementation. In this, it follows the tried and tested principles of an individual situation analysis as well as subsequent process implementation. However, even the implementation of the aforementioned topics can also achieve a definite increase in IT quality.