Managing change at the IT level helps businesses move faster, provide responsiveness for business units and end users, and mitigate the risks of errors or omissions.
Changes need clear justification and business reasoning. The actions associated with the change must include unambiguous workflows, and any resulting changes must maintain the company's compliance posture.
Change management tools are readily available and more powerful than ever, but the task still poses challenges. Let's consider some change management issues that might arise in your organization.
Design your configuration management database to be business-facing
There are numerous configuration management database (CMDB) tools such as ManageEngine IT360, BMC Remedy, HP Configuration Management System, but change management is not a ubiquitous or universal need. Every business relies on a diverse mix of hardware and software, so it's up to each IT team to organize and set up the CMDB tools to reflect the company's specific needs. And this is where many CMDB projects get into trouble -- resulting databases do not always meet the needs of the business.
It's easy to overlook the business relevance of CMDB tools. But savvy IT professionals understand that IT components and services only exist to provide IT services to the business. Resulting change management projects must ultimately benefit the business and work to facilitate business projects. Ironically, the most troubled CMDBs are the ones that try to embrace high-levels of abstraction. Don't try to make the CMDB mimic the company's organizational chart. Instead, take a bottom-up approach and allow the CMDB to start with granular infrastructure like servers, network gear, appliances and storage subsystems.
Change management is the practice of identifying hardware and software components, maintaining the current (accurate) state of each component, auditing and verifying the state of each component, and then securing the information related to each component to prevent unauthorized adjustments. All of the vital details about the hardware and software deployed throughout an organization -- and the relationship between those components -- are retained in a configuration management database.
CMDBs don't just retain details; they also document how those details relate to each other and to the business. Automated discovery and dependency mapping tools help ensure that each component is captured properly. Once all of the low-level details are in place, administrators can then outline the relationships between those components in the CMDB to visualize which higher-level IT services the business consumes. Administrators can also construct dashboard-level reporting that focuses on services rather than on components, helping them to quickly identify services that may be impacted by changes. Beyond that, coupling automation, ticketing and workflow tools to the CMDB ensures that changes receive adequate attention throughout the change management project, minimizes process errors and guarantees that all stakeholders are informed.
Now the CMDB has far more value to the business. The database carries careful attention to granularity and all elements of the enterprise, provides well-documented relationships between those elements to form business services, supplies reporting that conveys the status of those services, and uses automation to speed responsiveness to change while reducing errors. All of these parts combined make the business more agile, support audits and ensure adherence to compliance requirements.
Can change management verify nothing changed during a migration?
Change is unavoidable and beneficial to the business -- bolstering existing IT services, adding new IT services or facilitating other important business growth. Changes may be routine, such as refreshing server technology, adding more disks to the storage array, upgrading an operating system or application version, or adding Ethernet links for clustering, failover or bandwidth aggregation. And changes can also be profound -- introducing a new enabling technology or moving a data center from one location to another.
But regardless of the magnitude or scope of change, any change presents risk, and risk causes anxiety for IT and business leaders -- especially when unexpected or unforeseen consequences occur. For example, changes can result in costly service disruptions or open security vulnerabilities. They can also create gaps in data protection or availability. Any of these issues can potentially compromise the business's compliance posture. Business leaders need assurance that important changes in IT services and the environment -- such as moves and migrations -- don't cause collateral changes that might leave the company and its data vulnerable.
CMDB tools can help with such assurances. For example, IT operations analytics tools like Evolven's Blended Analytics tool can deploy agents on each server to analyze the established configuration for possible changes against an existing benchmark. Although such tools don't prevent unanticipated changes, they allow any differences to be identified and rectified quickly.
What is the best way to document changes?
Clear and meaningful documentation is key to successful change management. CMDB tools capture, log and report granular changes that occur within the environment -- such as changing an IP address or associating an application with a new LUN.
But documentation needs to go further than an update of resources and configurations. Documentation must help current and future IT staff members understand why changes occurred, what business goals the changes were intended to accommodate and who implemented particular changes. The goal here is to apply context to the changes and raise accountability for the staff. If changes result in oversights or mistakes, IT managers can use the context of good documentation to rectify problems more effectively and better educate the responsible staffers. The entire IT staff benefits from such an effort.
The business and its technology projects also benefit from this effort. Detailed documentation efforts help to protect the company's compliance posture by providing auditors with additional clarity into the business's change management projects and personnel activities.
IT staff enter change comments and details into the CMDB tools or other IT orchestration/workflow platform, depending on what change management software the organization has deployed. In addition, some businesses have adopted tools that promote cross-silo social collaboration in a style similar to wikis. Common platforms such as SharePoint can support some of this social collaboration, but more specialized tools include change management functionality that could include dependency mapping, finding configuration drift, identifying errors in the configuration database and other capabilities. Thus, the entire IT staff sees changes that occur and can respond or comment on them. This creates a collective group dynamic in the business's change management process.
Have the right people involved in change management projects
This is a surprisingly complex issue and there are several angles that we can address, but it all comes down to a single question: How do I get change management right every time?
Unfortunately, there is no universal answer. Every business and IT infrastructure is unique; the change management practice that suits one organization may be totally inadequate or excessive for another. Some businesses adopt a series of formalized change management guidelines such as the IT Infrastructure Library. Many other organizations adopt CMDB tools from third parties. Ultimately, the benefit of formal processes and software tools is limited without the input of knowledgeable peers within the business.
As long as you lead the charge, more input is almost always good. First, formulate a detailed change plan. Identify what you plan to do and why, and then float a complete plan to your peers for review and suggestions. Don't be afraid of granularity. For example, if you plan to replace a hardware device, include steps such as logging into the administrator console afterward, changing the administrator password, verifying configuration and security settings, testing functions, and checking logs.
Peer review can help identify cracks in the plan, but your peers shouldn't need to fill in the blanks for you. Include the corporate compliance officer so you're able to address pressing compliance concerns, and keep business managers informed so they can expect potential disruptions.
Even with the very best preparations, precautions, products and peers, successful change management projects are never 100% guaranteed. Approach changes conservatively, change one thing at a time, verify and test changes thoroughly, have a fallback/rollback plan in place, always have a clear picture of how your changes will affect the business, and be ready to refine and improve your change management process over time as technologies and business needs evolve.
IT change is an unavoidable part of business -- and change can usher in a wide range of benefits to the business, its employees, partners and customers. But change poses serious challenges. Change management projects take a combination of CMDB tools, practices and peer support to meet these challenges, mitigate service disruptions, maintain security and ensure continued compliance across the organization.
About the author:
Stephen J. Bigelow, Senior Technology Editor in the Data Center and Virtualization media group at TechTarget, has more than 20 years of technical writing experience in the PC/technology industry. He holds a Bachelor of Science in electrical engineering, along with CompTIA A+, Network+, Security+ and Server+ certifications. Bigelow has written hundreds of articles and more than 15 feature books on computer troubleshooting, including Bigelow's PC Hardware Desk Reference and Bigelow's PC Hardware Annoyances. Follow Bigelow on Twitter (@Stephen_Bigelow) and LinkedIn.
Automated infrastructure management untangles cabling
Updating your configuration and change management plans
Five ways to justify a CMDB implementation