IT Focus Area: IT Operations Management
October 29, 2015
An Effective Configuration Management Database May Be More Attainable than You Think
A configuration management database (CMDB) has become a foundational component within the management of IT operations. Many organizations view it as the single source of truth for managing IT assets and vital to keeping the business running effectively.
When implemented successfully, a CMDB can: help reduce the risk of failed changes and releases; provide a vehicle to faster incident and problem resolution; facilitate the alignment of technical and business information with financial information; and, ultimately, assist with providing better overall customer support.
An organization could be interested in implementing a CMDB for a variety of reasons.
Imagine the following three scenarios:
Scenario #1: You recently completed a data center migration where a detailed inventory audit was just performed. Now, your organization would like to maintain a fresh list of all IT assets that were identified during the migration.
Scenario #2: Your organization conducted an IT service portfolio review. You’ve gained insight into significant dependencies of the IT assets being used to support a critical service to the business. Now, how can you sustain that knowledge?
Scenario #3: Or maybe you’d like a CMDB to be the natural extension spawned from a recently implemented discovery product tool that now places IT asset information at their fingertips.
With so many motivations for attaining a CMDB, deciding on the best method for implementing it is directly tied to how quickly the value can be realized. Selecting the right approach for your needs is important, as each one has different benefits, challenges, and intended objectives.
There are three common methods to be explored: the service approach, the application approach and the infrastructure approach. Each method has value; your selection should depend on your organization’s goals and expected use.
Three Methods for Implementing a CMDB
1. The Service Approach
The Rundown: While offering a high-value proposition, the service approach is not as commonly used as the other two approaches. This approach is usually undertaken within mature organizations that already have a proven track record implementing other service management initiatives, such as defining and documenting a service catalog.
In most cases, these organizations understand the merits of managing a service portfolio and making IT and business decisions according to a service's importance to their organization. Using this service-based knowledge can also lead organizations to making sound IT portfolio buy-hold-sell decisions based on the importance of their IT assets, as well as understanding the operational characteristics of knowing which configuration items (CIs) are needed to support each service within the portfolio. This includes being cognizant of CI categorization, relationships and dependency mappings to all pertinent business functions, IT systems, applications and infrastructure equipment.
Define a service portfolio to determine service importance to the organization
Define and document the business and technical services delivered to, or in support of, the business
Create a service catalog to document the services and service requests
Determine service relationships/compositions to be documented in the CMDB to assist with risk analysis
Use the service information to better align IT activities with the business
Pros: The most common benefit gained with the service approach is the ability to ensure that continued investment, in both budget and resources, are directed to the services that are most critical to the business and its ongoing success.
Besides the direct benefit of ensuring that money and resources are supporting critical services, this activity provides an indirect benefit of demonstrating that IT understands the business needs and has aligned its resources accordingly. The service approach also creates a mechanism to begin the process of managing customer and user expectations by laying the foundation for the creation and execution of service agreements, both within IT and the business.
Cons: This approach is complex and requires a fair amount of due diligence to define and document services, and to gain an understanding of all the service interdependences. Unfortunately many organizations find themselves in a position where they are unable to take advantage of any established baseline data due to undocumented applications and infrastructure information, thus preventing a full understanding of these relationships. In organizations where this is the case, the service approach can take additional time to complete.
2. The Application Approach
The Rundown: While the value proposition of this approach can be more challenging than others, this is the approach most IT personnel are already familiar with. The application approach is usually initiated when an organization makes an investment in an IT asset discovery and dependency mapping product. These products provide the ability to scan the network and identify IT addressable assets, their interdependencies, and in some cases even create CI categorization schemes. However, without proper planning, the information produced can easily overwhelm any team.
Map application dependencies to determine service and infrastructure relationships
Collect an inventory of applications and their relationships to use in the definition of services
Map applications to services to define the composition of each service
Create a service catalog using the application relationship information
Maintain the integrity of the data using change management
Pros: Because the application approach relies heavily on discovery and dependency and mapping tools to collect information, you have the ability to create a comprehensive list of applications and their relationships more quickly than in other approaches. This newly discovered data can be used in compiling groups of applications for the eventual creation of a service catalog, and usually includes the detailed technical information of application to application, and application to infrastructure relationships and dependencies.
Cons: The most overwhelming aspect of using the application approach is the complexity and volume of the information collected. Because the focus of the data collection is application-based, it may not be obvious how this new information can lead to service transformation. This approach also frequently leads to organizations to over-architect the CMDB, making it difficult to maintain going forward.
3. The Infrastructure Approach
The Rundown: This approach is usually undertaken because of an IT organizations’ inherent knowledge of the infrastructure, specifically the network layer. Almost every IT infrastructure support group maintains a spreadsheet or database with basic network device information required to provide efficient and effective support. In many cases, an organization will begin a CMDB implementation process due to a recent IT inventory audit that left them in possession of a complete list of IT asset inventory. However, inventory audit results, just like many locally maintained spreadsheets can sometimes include only limited CI relationship information.
Collect physical and logical infrastructure configurations
Build a CMDB with the foundational physical and logical infrastructure information
Establish a baseline of CIs that can be used to cascade relationships for application and service definitions
Maintain the integrity of the data with change management
Pros: An organization that has just completed an IT inventory audit is in a perfect position to use the newly collected information with the infrastructure approach. This readily available information tends to be less complex than information collected using application dependency discovery tools and usually provides a solid foundational model for implementing a CMDB. This approach also allows for cascading relationships for application and service mappings at a future time.
Cons: Using this approach, inventory audits do not initially capture service relationships, but do produce a foundation asset baseline. The CMDB design needs to be well thought out to allow for an eventual transition to service information. This can be time consuming when you’re attempting to gather information across IT silos (server, network, storage, applications, etc.).
Targeting the Right Strategy for CMDB
Understanding the key objectives and the pros and cons for each CMDB implementation method can help organizations choose an approach that aligns company's goals with CMDB usage, while eliminating some headaches. No one approach is the right approach for every organization, but realizing the value of CMDB might be quicker than you think.