Making Good Decisions with CMDB

Consider, for example, the many decisions that are made around the cost of support. Should we outsource our IT support? Perhaps we can move some of the support off shore to leverage lower labor rates. How much longer should we support those old dot-matrix printers? Is the value of the redundancy really worth the cost of supporting the load balancer? These are just a few of the many questions that come up around support costs in IT shops every day. In an era of global economic competition, making wise decisions can be a matter of survival. But wise decisions are fueled by adequate information. Having an accurate CMDB allows the IT manager to understand which components of the infrastructure fail most often, how much change activity is occurring to antiquated equipment, and when to drop support of certain applications or types of equipment.

Although configuration management should never be confused with IT asset management, there is certainly value to having more information as part of the IT purchase cycle. The CMDB can help determine when it’s appropriate to refresh hardware sooner than expected, or when it is acceptable to let the refresh cycle lag behind the original schedule. If a server is hosting businesscritical applications and has had a whole series of minor incidents reported against it, it might be time to escalate the refresh time of that server, or perhaps swap it into a less critical part of the environment. But rather than simply deciding based on the annoyance of the most recent incident, you can have concrete information from the CMDB on which to base this kind of decision.

On the other hand, if a router has been running perfectly for four years, and it supports only a handful of user networks, it probably doesn’t make sense to replace it with a newer model just because policy says that four years is long enough for routers. Of course, none of these decisions can be made without good data on the environment, including relationships of components to applications and users, and a good track of the incidents and changes by component. Without configuration management information, you won’t have solid information on when to shift your IT policies, and you will have to rely on instinct or emotion.

If your organization has adopted grid computing to any extent, you already understand the significant decisions around this utility-based computing model. Because the basic tenet of grid computing is massively parallel computing, you must have an easy way to understand the configurations available for use. Accurate configuration information will allow for rapid decisions about how much work can be directed to the overall grid, and which potential hosts can support the additional workload. Without having adequate information about the configurations involved, it would be virtually impossible to make workload decisions for the entire grid.

Another kind of decision that is enabled by configuration management data is investment decisions. By looking at the data available, and particularly at the relationships between IT components as captured in the CMDB, it’s possible to isolate single points of failure and see redundancies. Examining the number and criticality of applications related to a server can show potentially under- or overutilized servers. Seeing the links between routers can show where additional firewalls might improve IT security. This type of information helps to determine which projects are worthy of funding and which projects can safely be delayed until the following year. In this way, the CMDB and discipline helps to support the decision making around your IT investments.
[Implementing ITIL Configuration Management, Larry Klosterboer, IBM 2008]