Those who have implemented configuration management (CM) practice would agree that implementing a robust CM discipline with the accompanied tools is no trivial task. The assets we acquired and deployed in IT can be massive in number and sophisticated in complexity. Keeping track of things coming in and out plus all the on-going changes can be tedious and error-prone when doing it manually. That is one major reason why we look to a SACM/CMDB tool to reduce the complexity of managing those IT assets. At the same time, a lot of people I talked with have indicated that CM is also one discipline that is usually the least mature in many organizations, when compared to other ITSM processes. Intuitively most of us would agree CM is something we should do well, and properly implemented tools can only help. How should we approach this complex issue?
For the sake of simplicity, I am going to use the term CMDB as the general, overall reference to the SACM and CMDB terms and concepts in this post. In ITIL V3, SACM is much more comprehensive, and they are not the same as CMDB. That is fine. For many organizations, we are still struggling to get the basic CMDB stuff down, so that is what this series of blog posts will target.
I believe the first of two questions to ask is… “Do we know what a CMDB is?”
This question may sound basic, but it is worth asking because there are widely varies opinions on what a CMDB is. I believe a data repository, which tracks and manages the inventory in the IT infrastructure with key attributes such as asset tag, description, location, owner, user, etc., is a CMDB in itself. The inventory list may be rudimentary, but it nevertheless contains the configuration items (CI) that a full-fledge CMDB tool would keep track off. With that assertion in mind, we can see that many organizations have a lot of those inventory lists in our environment. Not surprisingly, everyone seems to keep a set of those inventory lists for the stuff they own or operate. For example, the server admin folks have a set of servers, physical or virtualized, that they manage with a bunch of details about those servers. The DBA folks have a similar list for the databases under their management. The application folks have something similar for their application portfolios.
Many organizations also have asset management tools installed for their finance department, and those tools track the financial lifecycle of those assets for depreciation or accounting purposes. Many of those assets such as computers, equipment, and software are also used in IT with location and ownership information. Sure they are not well connected with each other so that you can extract the relationships between various items, but they do exist. The truth is… every organization has a number of inventory lists or assets databases that contain, in reality, CMDB information.
Now we have some ideas on what CMDB information we have. The second question to ask is… “What do we need a CMDB for?” In addition to tracking the inventory and financial information about those IT assets, do you have a genuine need of…?
- Performing more informed impact assessments for incident and change management activities? The relationships documented between the items in CMDB can be a valuable tool for understanding what impacts a change or incident can have on a particular system or application. When one component changes or breaks in the IT environment, a good CM practice and system in place will highlight how the change in state affect the rest of IT environment. With the localized CMDB info, the relationships are sitting in each technology owner’s head, and that has always made assessing changes and incident a labor-intensive activity. The assessment can also be less than precise or accurate if you don’t have all the necessary people involved with the information you really need.
- Facilitating systems upgrade or platform retirement? A comprehensive CMDB, with the full view to all applications and correctly documented relationships, can easily facilitate the analysis when considering introduction of the new applications, retirement of the old applications, and even changes to the overall enterprise architecture.
- Optimizing financial and capital expenditure planning? By having the full financial information available for all CIs, it will be easier to plan or project the upcoming financial obligations in expected hardware leases, software license fees/renewal, and maintenance contracts.
- Contributing to service continuity or contingency planning? By having a comprehensive list of CIs and a full picture of the environment, it makes easier to identify the essential, needed components or systems quickly during a disaster recovery or business continuity scenario.
- Making changes more visible and accountable for the operations and service delivery functions? The change history attached to each CI can provide valuable insights or trigger the attention by IT Management into changes that might have data protection, regulatory compliance, or other operational implications.
- Facilitating compliance adherence or audit obligations? Your organization or environment may have special legal or reporting requirements beyond what the typical spreadsheets and inventory lists can provide.
Once you have identified the needs and understand what you have to work with, you can make a more informed decision on how to bridge the gap. After all, the CMDB information is useful and productive only if:
- The CMDB is the central data repository for all configuration items we want to track in the organization, plus
- The CMDB has the data we can reasonably store and manage well, and
- The CMDB is the TRUSTED source and is used by all IT disciplines
Buying and implementing a full-fledge CMDB tool is not the only way to plug the gap. The gap can also be filled by marrying various CMDB sources you have on-hand with some well-designed middleware mechanism that provides the integration between the CMDB sources. Of course, the gap can also be filled by strengthening what you have with more robust processes and solid discipline. It all depends on what your business really needs. In the next post, we will explore some planning considerations that can go into what does it take to build a CMDB if you find yourself really needing one.
Links to other posts in the series
- SACM and CMDB Tools – Initial Considerations – Part 2
- SACM and CMDB Tools – More Planning Considerations – Part 3
- SACM and CMDB Tools – Implementation Considerations – Part 4
You must be logged in to post a comment.