The third group of errors that often occurs in my practice is the lack of availability of the technical solution. In less abstract terms: The existing software suffers a total crash (case group 3a) or the software required to operate the technical system is not delivered or is delivered late (case group 3b).
Description of the case group
From a technical point of view, this group of cases can only apply to situations in which the software has already been delivered, installed and accepted. It works and one day it stops working in part or at all. In contrast to other technical systems, the failure of availability is often due to incompatibilities with other software systems. Non-disabled "auto-update" functions for peripheral systems have often caused errors. In the case of machines, it can happen that the machine is operated beyond the estimated running times and therefore wear and tear occurs more quickly than planned. This is impossible with software. The zeros and ones do not wear out. What can happen, however, is that the environment systems are changed and an error occurs due to incompatibility or that the load behavior of the software changes because the software was not designed for this application.
Technical solution
The technical solution for such groups of cases is to create redundancies. Either by creating workarounds or new software or by importing a data backup.
Data backups
Data backups are inspiring. They are the simplest way to ensure redundancy. The fact that this efficient form of creating redundancy does not actually work is clearly due to the fact that customers often do not back up their data or the quality of the data backup is not checked or the customer is simply not aware of the time it takes to restore redundancy when choosing a particular method of data backup. Legal considerations begin with the consultation prior to delivery. As an IT specialist, it is easy to stand up and say that data backup is the customer's responsibility. Anyone who thinks this way does not know the case law. In a case decided by the courts (OLG Hamm 13 U 133/03), a customer had ordered the removal of a virus from his system. The technician who arrived asked whether a data backup was available and the customer said yes. The technician then formatted the hard disks and reinstalled the system. Then came what was bound to happen: the data had not been backed up at all for a long period of time. Now they were arguing in court about compensation. The court ruled: Of course the customer should have made data backups every time. But - according to the court - an IT specialist who formats hard disks or intervenes in a technical system that destroys data should have checked the existing data backups beforehand, so our tip to IT specialists is: Before you touch a system, check a.) whether there is a data backup at all and b.) whether it works.
From the IT specialist's point of view, it can only be a matter of advising the customer that a data backup does not necessarily mean that he will be able to work with the system again immediately. The various data backup options must be presented and it must be made clear to the customer that this is also about the period of time until a system is available again. And secondly: The quality of the data backup must be checked several times a year.
Necessary adjustments are not delivered or are delivered late
Group 3b describes the case where the technical solution required to operate the system was not delivered, installed, tested and put into production on time. In practice, there is no reasonable remedy for this. Under the blog for software maintenance and support contracts, I will explain the topic of delay and maintenance of functionality.
stefan kramer
