16.5 Operational Use

Operational use is, from the point of view of configuration management, the ultimate release for usage. What is considered operation in this connection is the packing, delivery, and installation of the product either at a customer's site or in an internal operation department, as well as the following ordinary use or running. Another kind of operational use is the packing and sale of off-the-shelf, or shrink-wrapped, products subsequently used privately by individuals or in companies.

New single configuration items are not created in this activity. Here, if not earlier, deliveries are defined that constitute the entire system to be released. Most often, such deliveries will be defined in integration, so final approval and any necessary changes can be performed immediately before the product is deployed. As the last part of the test, it's a good idea to test the delivery to be deployed, to be sure it's complete and can be installed and run. It may be useful to define a delivery consisting of the system in operation together with the operating and/or development environment. Special attention is required for variants of the product.

Configuration Management Considerations

In operation the configuration management system will stand its final test:

• Have the deliveries been composed and specified such that everything (and not too much) is included?

• Are the procedures for release in order, so everything required is generated and delivery takes place at the correct time, to the correct destination?

• Are the corresponding status reports adequate, so the operations staff or the customer can check up on the product and deploy it in operation?

• Is it possible to go back to an earlier operation version if a new operation startup goes wrong?

• Is it possible to register events for the product?

• Is it possible to extract information on running versions and existing event registrations?

All this must be planned and tested before the first operation starts and sustained throughout the product's lifetime. This is especially important if the start is complex and installations must be made on several platforms that must work together, such as client-server systems running on a mainframe, workstations, or Web systems.

Release

The operations staff themselves may take out the finished system for operation start, but most often it will be handed over more or less formally , assembled and packed for operation. This is especially true if operation takes place at a customer's site or from sale of off-the-shelf products.

Event Registration

The most important configuration management activity in operational use is registration of events, especially in the running-in period. This period can vary from product to product or user group to user group. Internal or external users (customers) as well as operations staff will presumably observe events and must be able to register and handle them. Ideally, they have access to the facility in which events for the product are registered, but this is not always the case. Access must allow both registration of new events and searching for events that are already registered.

Several levels of support functions may be placed between the ultimate user and the event registration itself. The first level might be with the customer himself and the second with the operations organization. The support function must never be performed directly by developers without event registration and a configuration control board. How events are registered and handled must be defined.

Status Reporting

The operations organization must know which configuration item the running system isits unique identification and composition. It must be possible to extract relevant information from the status reporting facility or facilities. It may also be important to extract information on which users (customers) are running which configuration items (systems) and which events are already registered for a given item

Organizational Considerations

Operation is usually placed elsewhere organizationally than development and testeven where operation is within the developing company. For this reason, it's important to define the interfaces between development/test and operation, so that it's clear when the responsibility for configuration management is transferred from one organizational unit to the other.

For off-the-shelf products, the responsibility remains in the companycertainly if the product must be maintained . When a product is transferred to a customer who is to be in charge of the operation or will involve a third party, it must be clear whether the configuration management responsibility is transferred and if not, who will carry which parts .

If the entire life of a product lies in an operations department, the responsibility is transferred to operations or may remain in development, so operations has only the responsibility for operation itself and possible event registration of observations. In such cases the operation environment should be isolated from other environments, such as development and test. Other reasons for isolating the operation may be security, reliability, and performance issues.

Backup

Backup of systems in production, including data, is a major responsibility for operations. This is not a configuration management task, though freezing the data contents, to be able to re-create it if necessary, resembles storage in configuration management. However, the two activities must be kept apart, since they require different procedures and information.