In-Depth
Is CMDB the Key to IT Service Management?
Looking to embrace configuration management database (CMDB) technology? We offer two best practices for defining your CMDB strategy.
Our increasingly competitive business environment leads companies to continually pursuing strategies to achieve and maintain competitive advantage. As part of this ongoing quest, many organizations adopt best practices within their IT organizations, evolving from managing IT “silos” to managing IT services. As a result, the IT Infrastructure Library (ITIL), developed in the late 1980s by the United Kingdom’s Office of Government Commerce, is gaining widespread acceptance as an integrated framework of best practices for companies seeking IT process improvements that better align IT services with the current and future business needs.
ITIL best practices dictate that companies need to have the core foundation of people, process, and technology in place to achieve rapid, positive results when implementing IT service-management processes. Closely related (and highly integrated) processes that comprise IT service management rely on accurate configuration information, and ITIL specifies that this information will be provided by the configuration management process and, more specifically, the configuration management database (CMDB).
Leading IT analyst firm Gartner, Inc. defines configuration management as the process of discovering and tracking relationships among IT components and enabling changes to configuration settings. Gartner views configuration management as the keystone to effective IT management.
CMDB is a repository for storing information about the attributes of configuration items (CIs), changes to these items, and their corresponding relationships and dependencies. In essence, the notion of a CMDB is nothing new. For years, IT teams have made painstaking efforts to discover, inventory, and document information about specific technology domains—for example, servers, desktops, and network devices. However, the concept is garnering significant interest because of the growing popularity of ITIL and the desire of companies to understand how disparate technology elements depend on one another and collectively comprise an IT service.
While nearly all industry experts agree on CMDB's importance for companies evolving to IT service management, there's still debate about whether to use a monolithic, enterprise CMDB (containing every type of CI imaginable) or take a federated approach (where a centralized database links to other data stores that share a common data model for sharing and exchanging information). The pendulum is swinging toward the federated approach, in part because of technology limitations and a reluctance to abandon investments in existing data sources.
- Technology limitations: A centralized enterprise CMDB requires the ability to store a multitude of CIs, ranging from details on infrastructure components to information on asset, financial, and contract details. A CMDB must also represent relationships to applications and services. According to Forrester Research, no such solution exists; the firm is highly skeptical of the ability of any vendor to deliver a single database capable of capturing and storing relevant information in a common format. Gartner agrees, citing doubt that a single enterprise CMDB will be able to scale to include the depth of configuration items an organization wants or needs.
- Current investments: Many IT teams have made painstaking efforts to discover, inventory, and document information about specific technology domains. Rather than abandon these efforts, for most it makes far more sense to use their established information sources to feed a CMDB via a federated approach that presents a consistent view of data received from a variety of sources. Further, while the CMDB will ultimately become the central information point for all IT domains, each domain will need to continue to maintain detailed information specific to its element or service, and needs are likely to vary across domains. With a federated approach, IT teams can construct different views of the data for different purposes while simultaneously storing and updating the data in local data stores.
Regardless of the approach selected, consider two key best practices when defining your CMDB strategy.
Best Practice #1: Don’t try to “boil the ocean.”
Building a CMDB is a lengthy process that can take many years. IT teams must deliver value throughout the process. Begin with a focused, bounded project that addresses an area of pain specific to your business, such as a critical IT service or an element-specific technology domain (such as server-based applications). Consider and plan the integration points that feed information into a federated repository. With a well-defined starting point, your IT department can move from managing systems to services in a gradual fashion that supports the needs of your company’s business, and demonstrate success along the way.
Best Practice #2: Don’t underestimate the importance of accurate, up-to-date data feeds into the CMDB.
As Gartner stated in a recent research report, “Having accurate configuration data is extremely valuable, but having inaccurate configuration data will be extremely damaging.” IT service quality can suffer dramatically when an IT organization lacks up-to-date, accurate configuration information. Imagine the service quality problems that might ensue if you rely on incorrect relationship information for impact analysis before you make changes to key business applications. Similarly, realize that delays in problem resolution arise because accurate configuration information is not available to support root-cause analysis.
Historically, companies have performed configuration management by maintaining multiple rudimentary data stores (such as spreadsheets, Visio diagrams, or Microsoft Access databases) containing data gathered manually. However, a manual approach simply cannot provide sufficient information due to the size, complexity, and number of changes occurring within IT environments. Fully accurate information is imperative to both maintaining and improving service management processes and quality levels. Consider that trying to map out a single significant business application typically takes three to five people a few weeks. Because environments are dynamic, data is out of date the day after the project is completed.
To address this challenge, many companies leverage automated technologies such as automated application and server-dependency mapping solutions that provide information about hierarchical and peer-to-peer relationships among infrastructure components. Some of these tools eliminate the manual effort traditionally associated with the configuration-management process and can be used to auto-populate the CMDB and maintain synchronization between "live" configurations and records stored in the CMDB. Whether used to improve configuration-management processes or specifically to feed a CMDB, Gartner believes these dependency-mapping solutions enable improved change planning and risk analysis, as well as faster problem isolation and root-cause analysis.
Summary
When automated and populated with fully accurate information, a CMDB represents each element within the context of other elements in an IT service, creating a topology and dependency map of the infrastructure that results in higher service levels, reduced downtime, and the ability to effect change more efficiently. In the end, a CMDB allows IT to become more business-focused by delivering a holistic view of how business services are defined and supported by an interrelated collection of infrastructure components. All of these benefits are key to companies seeking to achieve and maintain competitive advantage within their industry.