Mitigating the Top 4 Risks to CMDB Success

Transcription

1 Mitigating the Top 4 Risks to CMDB Success Configuration Management Databases are IT s White Whale; massive efforts have been undertaken with success largely slipping through most organizations grasps. Even decades after the concept s origination, and massive technological revolutions, CMDBs are still considered a four-letter word at most enterprises. After extensive customer implementations at Fortune 1000 enterprises, FireScope has identified 4 key risk factors common to every CMDB project that effectively kills any chance for success before they even begin. These are: 1. The Starting Point 2. Project Scope 3. Data Quality 4. Maintaining Accuracy With effective mitigation strategies leveraging automated discovery with dependency mapping, these four risk factors can be eliminated and ensure that CMDB projects are properly equipped for success. This document will explore each of these risks in detail and describe methods of abatement. 1

2 1. The Starting Point First and foremost, the focus for CMDB documentation should be on capturing how technology is supporting the business, in terms of services or user experiences being delivered. This is substantially different from Asset Management, where the focus is on capturing every depreciable or licensable asset within the infrastructure. Therefore, it does not always make sense for every server or device to be included within the scope of a CMDB, and organizations should have a clear delineation between Asset Management and the CMDB. While discovery will be an essential resource to aid in the population and maintenance of a CMDB, it is important to avoid what is described as a Bottom-Up approach. In this approach, mass discovery identifies every element within an environment and creates appropriate entities in the CMDB for each discovered element. In subsequent stages, IT Services are defined and various methods are used to associated these infrastructure Configuration Items (CIs) to IT Services. The challenge with this approach is that not every device within a network may be supporting a Service. This leaves potentially thousands of orphaned CIs in the system, cluttering the overall picture and adding maintenance work (e.g. updating the configuration documentation of systems that don t support any services). The ideal method for avoiding this risk is to take a Top-Down approach. This approach starts with the end points of services (e.g. urls, service role controllers) and leverages dependency discovery methodologies to only map the infrastructure assets that contribute to these services. This results in a smaller CI foot print in the CMDB, which provides clearer visibility as well as lower ongoing data maintenance work. 2

3 2. Project Scope (or Boiling the Ocean) The breadth and depth of your CMDB project may well be the biggest risk to success. All too often, we see organizations that want phase 1 of their CMDB project to include every IT service, and to be as granular as capturing serial numbers on hard drives, patch levels and maintenance contracts. This not only makes success virtually impossible, but sets the bar of expectations across the organization so high that it can never be achieved. We have found that organizations that have found success with their CMDBs consistently: 1. Start small, focusing on a single IT service or functional silo (e.g. application servers) in order to rapidly fulfill project requirements and get users to start leveraging the system as quickly as possible. 2. Keep the initial user base small, based on the initial scope and also selected based on their willingness to actively adapt their processes to leverage the CMDB. We are looking for early success, as nothing builds on success more than success itself. If the initial user base is hostile towards the project from the beginning, these will not make good champions moving forward. 3. Build on the success of the initial project to seek out subsequent stages, with each mirrored on the first in terms of narrow scope and rapid implementation possibilities. Avoid the urge to quickly expand the scope to encompass the entire IT organization. 3

4 3. Data Quality If users don t trust the quality of the data in the CMDB, they will simply stop using it. This has been the fate of the vast majority of CMDB implementations. For every data point included within the scope of your CMDB project, you must have answers to these five questions: 1. How will I source this data? 2. Does the scope of the data source span all relevant CIs within the CMDB, or will additional sources be required to complete population? 3. How accurate is this data source? How did the source initially collect this information? By manual data entry, or by automated methods? 4. How old is this data? 5. Is the data in a usable format, or will it require modeification prior to ingestion into the CMDB? There will always be the potential for data points that are not machine discoverable, such as support contract details, contact information or geographical details. Whenever possible, these should be kept to a minimum. All manually entered data should be treated as suspect, and the more frequently this is required, the more suspect the reliability of the CMDB as a whole. Far more valuable data lies in systems that either discover or originate the data. In some cases, utilization of APIs can be invaluable, such as VMware s API, Amazon AWS APIs and others. 4

5 4. Maintaining Accuracy A CMDB requires a long term strategy. No environment is static, and therefore no CMDB project truly ends after initial population. Therefore, an important consideration for each data point should be how will you maintain accuracy in 6 months, 18 or 24? In cases of virtualized environments, where VMs can migrate between physical hosts automatically, this becomes even more complicated. This is where automated discovery and dependency mapping are absolutely essential to any CMDB project. New projects and firefighting will inevitably take priority over taking the time to update the CMDB by hand. It is also important to evaluate the capabilities any discovery engines being used to maintain the CMDB. Do they have the ability to discover the relationships between Configuration Items, in terms of service dependency as well as virtual, physical and storage dependencies? Are they able to collect all configuration attributes required to maintain CMDB accuracy? How frequently are discovery scans scheduled, or is discovery a continual process? 5

6 Conclusion Configuration Management Databases are among the most challenging projects to get right, as evidenced by the thousands of failed projects across organizations world-wide. Accuracy and up to date data is critical for success, if users begin to doubt the data within the CMDB usage will begin a death spiral and the organization will fail to realize any of the many benefits of having a centralized repository of configuration knowledge. Manual data entry cannot be a primary source of inputs into the CMDB, other projects and priorities will quickly erode the time spent updating the solution. Furthermore, modern technologies such as virtualization, cloud computing, automation and orchestration have enabled a pace of configuration change that humans cannot keep up with. Automated discovery with dependency mapping is therefore absolutely essential to the initial population and ongoing data maintenance of any CMDB. FireScope Discovery and Dependency Mapping (DDM) gives organizations a clear and timely view of IT Service configuration, automatically identifying the IT services that users are consuming, their infrastructure dependencies from applications down to the network, and continually refining this picture as infrastructure changes take place. All of this information is then synchronized with the CMDB on a real time basis to ensure that users have access to an accurate picture of service configuration, while also eliminating thousands of man-hours required to manually maintain configuration data. Learn more today by visiting where you can also watch product demonstrations or schedule a meeting to learn more. 6