z/OS conventions:

One of the advantages of the mainframe is the very high availability that it offers; therefore, all change must therefore be carefully controlled and managed. A high proportion of any system programmer's time is involved in the planning and risk assessment of change. One of the most important aspects of change is how to reverse it and go back to the previous state.

The implementation of any change must be under the control of the Operations staff. When a change is introduced into a production environment that results in problems or instability, Operations staff are responsible for observing, reporting, and then managing the activities required to correct the problem or back out the change.

Although system programmers will normally originate and implement their own changes, sometimes changes are based on a request through the change management system. Any instructions for Operations or other groups would be in the change record, and the approval of each group is required.

Implementing business application changes would normally be handled by a production control analyst. Application changes will normally reside in test libraries, and an official request (with audit trail) would result in the programs in the test libraries being promoted to the production environment.

Procedures involved in the change must be circulated to all interested parties. When all parties consider the change description to be complete, then it is considered for implementation and either scheduled, deferred, or possibly rejected.

The factors that need to be considered when planning a change are:

The benefits that will result from the change
What will happen if the change is not done
The resources required to implement the change
The relative importance of the change request compared to others
Any interdependency of change requests

Risk assessment

It is common practice for data center management to have a weekly change control meeting to discuss, approve, or reject changes. These changes might be for applications, a system, a network, hardware, or power.

An important part of any change is risk assessment, in which the change is considered and evaluated from the point of view of risk to the system. Low risk changes may be permitted during the day, while higher risk changes would be scheduled for an outage slot.

It is also common practice for a data center to have periods of low and high risk, which will influence decisions. For example, if the system runs credit authorizations, then the periods around major public holidays are usually extremely busy and may cause a change freeze. Also, annual sales are extremely busy periods in retailing and may cause changes to be rejected.

IT organizations achieve their goals through disciplined change management processes and policy enforcement. These goals include:

High service availability
Increased security
Audit readiness
Cost savings

Change control record system

A change control record system is typically in place to allow for the requesting, tracking, and approval of changes. This is usually the partner of a problem management system. For example, if a production system has a serious problem on a Monday morning, then one of the first actions will be to examine the changes that were implemented over the weekend to determine if these have any bearing on the problem.

These records also show that the system is under control, which is often necessary to prove to auditors, especially in the heavily regulated financial services sector. The Sarbanes-Oxley Act of 2002 in the United States, which addresses corporate governance, has established the need for an effective internal control system. Demonstrating strong change management and problem management in IT services is part of compliance with this measure. Additionally, the 8th Directive on Company Law in the European Union addresses similar areas to Sarbanes-Oxley.

For these reasons, and at a bare minimum, before any change is implemented, there should be a set of controlled documents defined, which are known as change request forms. These should include the following:

Who is responsible for implementing the change, completing the successful test and responsible for backout if required. Also who will "sign off" the change as successful. This is usually a department, group or person that requires the change.
What are the affected systems or services (for example e-mail, file service, domain, and so on). Include as much detail as possible. Ideally, complete instructions should be included so that the change could be performed by someone else in an emergency.
The start date and time and estimated duration of the change. There are often three dates: requested, scheduled. and actual.
The scope of change, the business units, buildings, departments or groups affected or required to assist with the change.
The implementation plan and a plan for backing off the changes, if the need arises.
The priority of the change; that is, high, medium, low, business as usual, emergency, dated (for example clock change).
The risk, which is usually classified as high, medium, or low.
The impact if the change is implemented; what will happen if it is not; what other systems may be affected; what will happen if something unexpected occurs.

Production control

Production control usually involves a specialized staff to manage batch scheduling, using a tool such as Tivoli® Workload Scheduler to build and manage a complex batch schedule. This work might involve daily and weekly backups running at particular points within a complex sequence of application suites. Databases and online services might also be taken down and brought back up as part of the schedule. While making such changes, production control often needs to accommodate public holidays and other special events such as (in the case of a retail sales business) a winter sale.

Production control is also responsible for taking a programmer's latest program and releasing it to production. This task typically involves moving the source code to a secure production library, recompiling the code to produce a production load module, and placing that module in a production load library. JCL is copied and updated to production standards and placed in appropriate procedure libraries, and application suites added to the job scheduler.

There might also be an interaction with the system programmer if a new library needs to be added to the linklist, or authorized.