Oct 23 ’08
Maintaining Critical Services in a Dynamic World
The pace and magnitude of change is accelerating as companies seek to capitalize on rapidly shifting global market conditions. To effectively support the business, IT must constantly change, too. These changes often include introducing new services, the incremental addition of service capacity, and the extension of services to new constituencies such as employees, customers, or partners.
IT change, however, can be quite dangerous, especially in today’s heterogeneous distributed environments. Even the simplest change can have unintended adverse consequences, causing service disruptions far beyond anything anyone anticipated. Some observers assert that as much as 80 percent of all service problems are the result of poorly executed change management.
Because it’s so important to minimize the risks associated with change, IT organizations are putting greater emphasis on the change management discipline. They’re seeking proven best-practice frameworks for defining and enforcing that discipline. Foremost among these frameworks is Information Technology Infrastructure Library (ITIL), which has the advantage of providing guidance for a wide range of core IT management disciplines. By embracing ITIL, organizations can optimize the responsiveness of IT to business change while eliminating the service outages and other problems associated with inadequately disciplined change management processes.
Platform-Based Change Management
Most mainframe managers find ITIL change management practices familiar. ITIL change management is a widely accepted best practice for mitigating the risk of change-related IT disasters. Like all other aspects of ITIL version 3, change management is defined in terms of IT services and the service lifecycle. ITIL defines service change as “the addition, modification, or removal of an authorized, planned, or supported service or service component and its associated documentation.” According to ITIL, the scope of change management covers changes to “base-lined service assets and configuration items across the whole service lifecycle.”
This broad definition requires some explanation. ITIL starts with the concept of an IT service, regardless of platform. It doesn’t make arbitrary distinctions between mainframe and distributed systems applications and processes. Instead, it describes services as a way of delegating the risks and costs of outcomes. A service provider delivers value and desirable results and frees the consumer of the risks and responsibilities of owning or delivering the service.
A credit report function is a good example of such a service. The IT department defines the scope of the service, such as a credit check with all three credit bureaus, along with a credit score, a comparison to historical creditworthiness, and acceptable service levels (i.e., availability and performance). Each business unit selecting this service pays for it—typically in the form of allocations from the enterprise budget—and expects to not have to worry about how it’s implemented, managed, or maintained. The IT department assumes all the risks and costs of procuring the assets necessary to provision the service.
In this way, the IT department has the resources to provide better, more reliable service at a lower overall cost than any individual business unit or department. In addition, the resources and capabilities of IT can be more effectively leveraged across the enterprise by sharing and reuse. In fact, Service-Oriented Architecture (SOA) itself is based on this idea of sharing and reuse, with customized capabilities layered on top of common services as needed.
This service concept is essential for a proper understanding of ITIL change management. Ultimately, the value of change management is derived from its ability to support the agreement between the IT department and its constituents regarding the delivery of services. ITIL change management helps reduce both the risk and cost associated with service delivery. Since the Service Level Agreement (SLA) explicitly sets terms for availability and performance, it’s a key element in change management. So a consistent change management discipline—and, by extension, mitigation of the business risks associated with IT change— is at least in part contingent on a standardized approach to defining services and SLAs per the larger ITIL schema.
Continuing the credit assurance example, a change in the information passed to a credit bureau, for example, might require modifications to a Web front-end, mainframe database server, and UNIX application. The business transaction encompasses all three tiers. Following the change management process, these changes can be managed to avoid adverse business impact and promote full compliance to required governance by involving all stakeholders.
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.