Like any IT project, building a configuration management database (CMDB) requires time, money and resources for management and deployment. You just have to be strategic in justifying your business case.
As a CIO, you find yourself supporting an initiative for CMDB deployment or upgrade. You have a few constituent groups to satisfy -- your staff, your CFO or CEO, and your end users.
Your staff members will deploy and use a CMDB (or manage an external service group that will do so for you) so they can be more productive. Your end users, internal or external, are potentially the target of improved service with the foundation of the (new) CMDB. And your CFO/CEO either provides supplemental funds for the CMDB project or expects that it will be funded within the bounds of your existing budget expenses (or some combination of the two).
I'll assume that you are relatively knowledgeable of your company's needs for ITIL/ITSM-like capabilities, even if you are not an IT Infrastructure Library (ITIL) or IT Service Management (ITSM) expert. Thus, as a starting point, I'll simply define a CMDB as the following: a database describing the current, past, and "to-be" configuration of software and hardware for the IT network(s), or a set of time-referenced records in the database that define the management processes executed for the network(s).
Creating a business case
While a CMDB is central to most IT management processes, what really matters is how it is built. This can have a big influence on the successful justification of a CMDB. Here are some points to consider:
Shortsighted benefits. Many capital investment decisions for "operational" improvement are constrained to show short-term payback, but thinking of a CMDB as a one-time improvement is shortsighted. You need to consider the CMDB as the central part of a strategy for continuing to improve service, lowering per-service delivery costs and enabling an IT organiza
To continue reading for free, register below or login
To read more you must become a member of SearchCIO.com
tion to bring on new services that support competitive advantages. While many CXOs may have short payback periods (six to nine months), ongoing and growing benefits could drive a higher ROI argument.
Integration. The IT management landscape is complex and full of a wide variety of great product and service management offerings from many vendors. Building a CMDB is central to using these offerings. Understanding how to integrate and synchronize these systems to achieve a master CMDB is critical for success.
Appropriate scope. Have a clear understanding of the choices you face and the benefits you are targeting with a CMDB. A common mistake I see is when a CMDB deployment begins across a target of services that is too broad (PCs, office networks, interoffice Web servers, etc.). The assumption is that such a deployment will support all environments, including business-critical systems that cannot tolerate service disruption.
Business-critical environments tend to have a significant number of processes that use the CMDB and require strict adherence to maintain a reliable production state and regulatory compliance. Starting with too broad a scope that targets these bulk technology or low-value environments can lead to problems satisfying business-critical environment needs that have higher payback value.
Also, you can use different solutions for a CMDB capability for business-critical systems versus what you would use for higher-quantity, greatly dispersed and lower-business-value environments. For lower-business-value environments, consider outsourcing.
For business-critical environments, focus deployment on where the best value will be achieved at low-to-moderate risk. Achieve those results in the short term to support payback goals, and then eventually expand coverage to critical service environments.
Another mistake I see is when companies roll out one type of CMDB-related process, such as incident management, and then move on to another area, such as change management. This approach can lead to headaches for those maintaining the "master" CMDB data across differing IT management applications as they are deployed over a long period of time. It can also lead to missing the targeted value and payback period for a CMDB investment.
Take incident management across an enterprise, for example. Incident management is great, but without problem, change, configuration and release management processes, you cannot obtain real value. An alternative approach is to put the above processes in place across a small area to obtain IT staff acceptance and also demonstrate results and benefits.
Justifying CMDB costs
If you are a CIO of a large enterprise, you already recognize the underlying complexity of managing the integration, deployment and adoption of a CMDB project. But you have probably come to realize that without a core CMDB capability, change and growth of your IT service portfolio can't be planned, budgeted and managed.
Assuming you have achieved the above -- appropriate scope with achievable benefits coupled with a vision and plan for expanding coverage -- the following list has common justifications for many IT management projects, but here they are in the context of ITSM:
Some simple advice: For all of the justifications you note, be sure to provide two or three examples of problems that have occurred (or are at risk of occurring), the constraints that can occur and how the CMDB can address them. Use reasonable -- but not overly conservative -- estimates to balance the expense of deploying the CMDB.
In general, a CMDB is a core element for IT service management, but it works only in conjunction with consistent processes geared at quality service delivery with a bend on continuous improvement. This is what the ITIL community intended in version 3 -- an extended set of process disciplines with the emphasis on continuous improvement.
David Femia is a contributing writer and consultant who has worked in the IT industry for more than 20 years.
