In terms of change management, ITIL lays out a foundation based on a CMDB (change management database). The CMDB can take any form, from a simple Microsoft Access database to a fully fleshed-out SQL-driven solution. A CMDB can also be sourced from a vendor, such as Troux Technologies’ Troux CMDB for ITIL product. There are also a few hosted CMDB services that are best suited to small businesses, such as myCMDB.com.
The CMDB database contains documentation on all the moving parts of any infrastructure and provides a framework for the modification of this data when changes are instituted.
The process of creating and maintaining a CMDB starts quite simply: define and document the critical infrastructures within your network. This can be a slippery slope and anyone with a stake in a particular application will claim that it is highly critical, so some discretion is required. Good examples of critical infrastructures would be security systems, payroll databases, shipping and inventory systems, and interfaces to external partners. These systems need to be documented from the ground up, with all the data residing in the CMDB.
One of the big concerns with the CMDB approach is determining a suitable level of detail, which is why identifying critical infrastructures is so important. It’s certainly feasible to document every aspect of the network in excruciating detail, but that may be counterproductive. Limiting the extent of data within the CMDB can prevent drowning under a sea of meaningless data while searching for the necessary elements that affect an existing problem. For instance, the network-management tools described above can participate in the CMDB, but it may not be necessary for device configurations to find their way to the CMDB. External resources may best handle such intricate low-level detail, with the CMDB providing detail on the overall function and purpose of that infrastructure.
Most configuration management vendors support the concept of change management. Although there is a distinction between the two, they are mutually inclusive. One aspect of configuration management that can clearly assist the change-management effort is policy management and adherence verification. Rendition Network’s TrueControl, for instance, can generate a report verifying that every Cisco 2950 switch on the network has an identical access list in place, and has TCP small servers disabled. Further, policies can be created and configuration changes pushed to like devices simply, reducing the chance of human error affecting network resources. Of course, this also introduces the potential for the amplification of a single mistake across the network.
Baby Steps First
Of course, best practices guidelines can only help if the infrastructure is stable; there’s no sense in erecting scaffolding on a burning building. Instituting a short freeze on any new projects is a good way to achieve stability. This tactic will undoubtedly cause some short-term problems, but the long-term ROI is well worth it. Once the staff is no longer tasked with rush implementations of new systems, stability will increase. Then begin the change-management process by identifying the critical infrastructures, developing the database, and investigating the tools that can automatically update the database. Most IT shops keep track of various network elements in small ways, such as an Excel spreadsheet of VLAN locations or external IP numbering assignments. Migrating this data to a central repository is a simple first step. As with any systemic change, starting small and gaining early victories will pave the way for success when the project becomes more challenging.