back ⇧

2 Potential hardware operating life

To what extent are hardware replacement cycles decoupled from software replacement cycles?1

Software imposes requirements on the hardware on which it is executed. The faster these requirements increase as the software product is developed further, and the more specific they are, the more they limit the use of hardware products already in existence. If existing hardware products cannot be used, or can no longer be used, to execute the given software product, then this shortens the operating life of the hardware.

The ideal is a software product whose development dynamics permit operators to manage their hardware products independently of these dynamics, i.e., decouple hardware management from software management. 

Does the manufacturer of the software product guarantee that the current release can be executed on a reference system that is n years old?*

Indicators:

a) Initially use the specification by the manufacturer (hardware, older operating systems, older frameworks), since no standard configurations have been defined for previous years

b) When this criterion has been applied for a long enough time periode, so that the standard usage scenario can also be executed on earlier standard configurations as well: Can the standard usage scenario still be executed with the current release of the software product on a configurations that was the standard configuration n years ago?


* Thus, the software product can be executed on a standard hardware configuration that has already been in operation for n years.

Can the software product be executed on different currently prevalent productive system environments (hardware and software), and can users switch between them without disadvantages?*

Indicators:

a) Manufacturer specifications (compatible with various operating systems, runtime environments)

b) Execute standard usage scenario on various currently prevalent productive system environments and check for portability of data and software settings


* We recommend that this criterion should not be considered one of the minimum requirements because in principle, there could be very resource-efficient software that runs on just one platform. Nonetheless, platform independence is to be considered beneficial since it gives users more freedom when optimizing procurement of hardware and system software.

Does the amount of hardware capacity used remain constant over time as the software product is developed further and additional functions are added?

This criterion rewards software manufacturers who make it easy for their customers to continue to use their existing hardware. It intentionally does not take into account whether functionality is expanded. Sufficiency means that the amount of resources required will not increase even if the utility they provide increases (which is possible, after all, because of increasing efficiency).

The ideal is a software product that fulfills more and more requirements from one version to the next, but nonetheless does not increase its hardware requirements.

This criterion can be applied only when products have already been assessed several times, i.e., when at least one previous result is available.

Indicators:

a) intertemporal comparisons with the following imaginable results:

  1. “very good”: To date, new versions have resulted in a decrease in the hardware capacities required.
  2. “good”: To date, new versions have resulted in no increase in the amount of hardware capacities required.
  3. “sufficient”: Although to date, new versions have increased the amount of hardware capacities required, the increases have not overcompensated for the efficiency improvements due to technical factors as exhibited by the succession of reference systems over time.
  4. “insufficient”: Because of new versions, the required hardware capacities have increased faster than technical efficiency.

[1] Decoupling software and hardware replacement cycles amounts to long potential hardware operating life. Basic assumption: Every software product requires a system environment as the platform on which it is executed. The system environment is defined as the sum of the hardware and software components of the ICT system that are required for executing the software product. The software product itself can be part of the system environment of other software products. Example: A web browser requires an operating system, additional system software, and hardware as a system environment, and at the same time it constitutes the system environment for a web application. From the perspective of a given software product, the following question is crucial to understand its influence on hardware operating life: when the software product is replaced by a newer version, which requirements to the lowest level—the hardware—does this generate via the intermediate levels of the system environment?