Recently, a question was raised by a client regarding whether it would be better to create a method to manage technical information in support of the IT disaster recovery planning effort, acquire and implement a commercial Configuration Management Database (CMDB) solution, or customize its existing business continuity software solution. The short answer is, “it depends”. This perspective discusses this commonly asked question, which by the way, is very important given the need to understand the relationship between IT infrastructure, applications, data, and business continuity requirements.
Typically, business continuity software supports various analyses, plan development efforts, and continual improvement activities. Often, functionality enables planning at the department or business processes level, with a focus on resource requirements, time sensitivities, and dependencies related to the recovery of critical products and services. As an extension of the planning effort, business continuity planning software not only becomes a repository for plans and related documentation, but it evolves into a repository of resource and configuration information – the details necessary to plan for the loss of resources following a disruptive incident. One such resource that the organization collects considerable information on is information technology assets, including infrastructure, telephony, applications, networks, and data. This information is necessary to identify appropriate recovery strategies, implement the recovery strategy, and execute the recovery strategy when faced with an IT disruption.
As noted in the introduction to this perspective, business continuity software is not the only approach to enable IT disaster recovery planning.
So what are the options to address the need to identify, collect, and manage information technology resource information, with the information not only supporting business continuity and IT disaster recovery, but also other IT processes and services, such as project management, asset management, configuration management, and change management (to name just a few):
- A Commercial CMDB Solution
A CMDB is typically an IT-centric product that focuses on “configuration items”, designed to track IT information by asset and provide a systematic view of all IT assets and their relationships. The type of information collected and maintained by asset may include model number, vendor, storage size and type, operating location, date of commission, memory, operating system, service owner, business customer, and much more, including operating and troubleshooting documentation. Comprehensive CMDBs usually include asset-based agents that monitor the assets and provide automated updates of detailed information to a central repository. Less sophisticated systems rely on manual updates of information to maintain information that is not discoverable through automation. Of note, despite the many advantages of a commercial CMDB (especially one that takes advantage of automation), the adoption rate and the mature use of these solutions is surprisingly not where it needs to be. In many cases, configuration management is manual or reliant on other solutions.
- A Homegrown Solution
Many organizations, particularly small to mid-tier organizations, build and maintain IT asset-specific information in homegrown solutions, with many relying on MS SharePoint lists, MS Access databases, or even spreadsheets. Although easier to implement and maintain, homegrown solutions are manual and require update discipline as the IT environment changes over time.
- Business Continuity Software
Because of the need to understand IT asset information in order to plan for disruptive incidents, business continuity planning software has emerged as a solution to manage or maintain IT asset configuration information. Although manually updated and maintained (like a homegrown solution), business continuity planning software is often centrally maintained and can be made available to those who manage IT assets. The value of using business continuity planning software for this purpose – especially when another solution doesn’t already exist – is that the software fills an IT process need as well as a need to enable IT disaster recovery strategy design.
Overall, attempting to use a single product in support of day-to-day IT process/service management and business continuity/IT disaster recovery will require compromises and is dependent on the organization’s individual circumstances. Potential questions that should be considered include:
- What is the size and complexity of the organization – now and in the foreseeable future?
- This is the most basic question. In small organizations with limited IT assets and resources, it may be possible to utilize manual processes to overcome system or other limitations. As organizations and IT environments grow, manual processes will likely break down, especially without strong governance mechanisms.
- How mature is the IT organization?
- If the IT organization does not have the maturity level associated with strong controls and monitoring, the implementation of a CMDB is unlikely to yield the desired results and deliver the ROI the organization needs to justify such a solution.
- How is the organization structured? Are business continuity and IT disaster recovery both under the same leadership and able to share the responsibilities and benefits?
- Unless the two groups are closely aligned, issues are likely to arise from IT responsibility for data in a business continuity system or business continuity information in an IT owned CMDB.
- Additionally, without close alignment, the drivers and goals are likely to diverge, increasing the risk that any system, either a CMDB or business continuity software, will no longer meet the needs of the organization.
- What are the drivers of business continuity and what outputs of any system are critical?
- If the goal is business continuity compliance to regulatory requirements or potentially certification to a standard, a comprehensive business continuity software system that aligns to requirements, especially in the areas of risk assessment, business impact analysis, and continuous improvement, will likely be needed.
- If the goal is efficient tracking of changes in the IT environment to maintain currency of an internal disaster recovery solution, managing external disaster recovery contracts, or managing the production IT environment, attempting to track and control them in a business continuity system without automated feeds from a CMDB could be ineffective.
Additional Resource: How, When, and If to Implement Business Continuity Software
Your answers to the questions above should provide a preliminary guide to the direction your organization should consider taking. For a small organization with a simple IT environment, either a commercial CMDB, homegrown solution, or a business continuity software approach could be effective. In a larger organization, the ability to effectively use manual processes diminishes rapidly and the chances that parts of the process will report to multiple areas of the organization increase greatly. Additionally, management reporting and regulatory or other compliance often become a more important driver. In this environment, the drawbacks of either tool as a sole solution are quickly seen. Modifying configuration items in a CMDB to facilitate a business impact analysis or reporting to provide management information and metrics would likely entail more cost and effort than purchasing a purpose built system. Also, key business continuity activities and tools such as risk assessments and notification would have to be conducted and maintained separately. Similarly, attempting to maintain a reliable database of IT configuration items in a business continuity tool without a real CMDB that provides automated discovery and bulk upload capability would quickly become a problem.
Overall, in a small organization either direction, or just everything manually, will work as long as the gaps are recognized and compensated for with manual processes. As organizations grow the natural separation of duties and responsibilities that evolves, as well as the sheer volume of information, should be a guide to the separation of tools.
Avalution Consulting: Business Continuity Consulting