Change management is the process of controlling modifications to configuration items so as to minimize incidents that disrupt normal operations. The reason change management is so important is that one change can have ripple effects through multiple other assets (see Figure 5.4).
Ripple Effects of Change
Consider a change to a hypothetical management reporting system. Until now, managers have received static reports in Adobe PDF format once a week summarizing the business activity of their units. The IT department is deploying an interactive reporting system. Here are some of the changes related to the new system:
- Client software must be installed on power users' desktops and laptops; basic users will use a Web-based system to retrieve reports.
- The new client software for power users will have to be added to the patch management process to ensure clients receive all relevant security updates.
- Middleware software, including a downloadable applet, will have to be installed on Web servers.
- Firewall rules will be modified to allow traffic on a newly opened port to the Web component of the reporting system.
- New groups and roles will be added to the database access control system to allow managers to retrieve information using their network login ID.
- Additional database servers may be required to support the additional load of ad hoc querying.
- Failover servers may be added to ensure managers access to the database if a Web server should fail.
Clearly, what appears at first to be a software change can quickly propagate ripple effects to other software components, hardware devices, and network settings.
Formal change control procedures are one way to ensure that the effects of a change are understood before the change is implemented. Formal methods are often based on a standardized change request mechanism and a change review board.
Requests for Change
A request for change is a documented description of a change to the IT infrastructure. A change can be as simple as installing a new version of a word processor on a user's laptop to deploying a new application for hundreds of users. Regardless of the complexity, several characteristics of changes should be documented:
- Originator of request for change
- Configuration item to change
- Implementation plans
- Back out plans
- Type of change, such as a change in requirement, bug workaround, additional hardware for increased demand, and so on
- Reason for the change, such as compliance, policy change, defect, new business Requirement
- Priority, which can include emergency, urgent, or routine
- Detailed description of change
- Estimated time and resources required to implement
- Impact analysis for complex changes
Some of these items, such as the change description and the reason for change, are defined by the user or department making the request; others, such as the time and resource estimate and impact analysis, are determined by technical staff. The approvals required will depend on the priority and the complexity of the change. A relatively simple change, such as a desktop application installation, may require line manager approval, but a major software release will require approval from several managers, both on the business and technical sides of the organization.
Change Advisory Board
A change advisory board (CAB), sometimes called a change control board, is responsible for reviewing complex requests for changes. A CAB should include managers responsible for business operations as well as technical staff familiar with systems administration, network operations, security and software development and management. The purpose of the CAB is to provide visibility to changes before they are made -- not to slow the change process.
CABs are sometimes seen as bureaucratic road blocks to getting work done -- they should not be.
Their role is to provide a checkpoint to ensure that the implications of changes are thought through as completely as possible. Correcting a problem with a proposed change is much easier and less expensive when done at the planning stages than after the modification has been made.
In organizations with mature, functional IT operations, change is managed as a formal process. There is no avoiding change, but you can determine how we deal with it. After changes have been reviewed, revised and approved, the next step is implementation. This domain is addressed by release management practices.
Implementing System Management Services
Home: Deploying Service Support
Part 1: Elements of Service Support
Part 2: Incident Management
Part 3: Problem Management
Part 4: Configuration Management
Part 5: Change Management
Part 6: Release Management
The above tip is excerpted from Chapter 5, "Implementing System Management Services, Part 1: Deploying Service Support" of The Definitive Guide to Service-Oriented Systems Management by Dan Sullivan. Get a copy of this ebook at Realtime Publishers.
About the author: Chief Technology Officer of Redmont Corporation. Dan's 17 years of IT experience include engagements in enterprise content management, data warehousing, database design, natural language processing and artificial intelligence. Dan has developed significant expertise in all phases of the system development lifecycle and in a broad range of industries, including financial services, manufacturing, government, retail, gas and oil production, power generation, and education. In addition to authoring various books, articles and columns, Dan is the leader of The Realtime Messaging and Web Security Community where he posts to his Messaging and Web Security weblog and produces his expert podcast.