It’s counterproductive to distinguish between mainframe and distributed systems when implementing ITIL change management. The service itself, the SLA, and the service contract are relevant—not the specific infrastructure used to implement the service. Centralizing change management minimizes the risk of change being applied only to one tier. The business customer should have no concern about how their service is provided; their only concern is that the terms of the agreement are met.
Centralizing the change management function brings diverse groups back together. During the ’90s, when business units created their own data centers and brought in their own servers, the communication broke down. Many organizations established a tradition of distributed authority over distributed systems. ITIL is an opportunity to regain the tight relationship between business and IT that such partnerships fostered, and establish centralized server management processes that reduce costs and risk.
Practical Advice in a World of Change
The ITIL change management process is straightforward. After a change is proposed, it’s assessed, authorized, executed, reviewed, and closed (see Figure 1).
Assessment is the foundation of this process. The authorization, implementation, and prioritization of the change depend on the assessment results. The goal of the assessment is to gather all the information necessary to decide whether the change should be made and the best way to do it. The ITIL Service Transition publication characterizes change assessment succinctly in the form of the “Seven R’s of Change Impact Assessment” (see Figure 2).
Assessment includes the identification of all stakeholders in the process. It’s important that both mainframe and distributed system experts and managers participate so the interrelationship between mainframe and distributed systems is accounted for in determining the technical scope and business impact of the change.
The appropriate level of authorization also is determined during assessment; this can widely range. Some change proposals, such as those that enable a new line of business or substantial restructuring of existing lines of business, have wide enough impact to require approval from an organization’s directors. At the other extreme, a minor change to a workstation configuration may not require any specific authorization. The cross-platform credit assurance application example falls in the middle: It would require approval from the stakeholders, but probably wouldn’t need to go to the board. By carefully determining appropriate levels of authorization, the ITIL change management process avoids overwhelming the system with minutiae that can waste resources and slow down IT’s ability to respond to business needs. Simultaneously, it ensures that appropriate caution is exercised.
Intermediate-level changes are usually authorized by a Change Advisory Board (CAB). An example of an intermediate-level change might be a significant capacity change to the environment. Though it wouldn’t require the same oversight as launching a new application, these changes must be carefully considered so those responsible for each affected platform can ensure adequate capacity to meet service levels. This is particularly important when financial constraints require that existing servers run at close to their effective capacity. Each line of business and application developer might be consulted to ensure that business capacity projections are considered in application code changes to accommodate possible increases in demand per business transaction.
Wide participation is typically required for an effective CAB. This board may be comprised of the following representatives:
• Change Manager Chair
• Finance Manager
• Release Manager
• Problem Manager
• Senior Business Representative
• Service Level Manager
• Application Manager
• Others as required.
ITIL suggests several concrete indicators of a poor change management process, all of which are related to the goal of efficient, uninterrupted delivery of services. They include unplanned outages and delayed projects (see Figure 3). Every IT organization should monitor these indicators, but organizations where mainframes and distributed systems coexist and are intertwined should pay special attention when availability and performance problems are related to the interactions between those platforms. Often, these problems arise because systems experts have an exceptional grasp on their own environments but little or no knowledge of the way another platform works or integrates with other platforms or the overall environment. Full understanding requires the collaboration of all stakeholders, and of network as well as distributed and mainframe administrators. ITIL best practices address this issue by specifying a core group of enterprise specialists who focus on interoperability issues.
Since ITIL has enjoyed widespread acceptance, change management solutions that support the ITIL change management process are available from several software vendors. There also are a substantial number of skilled ITIL trainers and service organizations that are ready to help IT organizations implement an ITIL change management process that supports mixed mainframe and distributed systems environments. With this support—along with topdown commitment to change management excellence—any organization can avoid the risks from unmanaged change and reap the benefits of a disciplined ITIL change management process.