SACM and CMDB Tools – Some Planning Considerations – Part 2

In the previous post of the series, we discussed what initial considerations should be taken into account when deciding whether your organization needs a full CMDB solution. Let’s say you went through the analysis and decided that a more functional CMDB solution is needed. You need the solution to have a better ability to assess the impact of a change, incident or problem on a service because your current analysis capability is not meeting the business needs. What other considerations need to come into the planning of a CMDB solution? I would suggest the following…

  • Scope: What data need to be captured, stored, and processed? What processes and activities will make use of that information? At this point, you should have some pretty good ideas how to answer those two questions, at least with some degree of precision. If you need a better handle on managing the changes within the data center, what sort of hardware and configuration information will you need to capture from the servers and the networking gears in the data center? Do your needs for CMDB/asset management involve needing configuration information from the client devices? If so, how do you plan to reliably capture that very fluid information? What processes do you plan to target the CMDB information for in the near term, just change and incident or more? What services or processes will the CMDB enhance in the long run? I would recommend start with what you absolutely need right now to show improvements in service and gradually build it up over time.
  • Data Model: Talking about what data you need conceptually need is one consideration. Translating those concepts into actionable data model design is another. I am a believer that a CMDB is an information cornerstone to an organization’s IT service management activities. I often compare how an ITSM system relates to IT as how an ERP system relates to an organization. The CMDB is the foundational information store for that “ERP” system for IT. With that said, it pays to implement the data model well upfront because frequent structural changes to CMDB afterward will easily kill the productivity you gain from using CMDB.

There are some potential benefits and understanding that can be derived from the data model:

  • How all CIs within the scope of the process relate to IT services provided to the business
  • How various total cost of ownership components are related to an IT service
  • How individual availability or capacity figures can relate to groupings of CIs and overall availability or capacity targets
  • Which CIs facilitate or enable which IT services
  • Prioritization of CIs in relation to disaster recovery or continuity management

If your organization has one, now is the great time to get in touch with your Enterprise Architecture (EA) folks and work on the data model. They should be your organization’s information and data architecture expert, and designing (or assisting in design) an ERP data model for IT should be the very part of their charter. Design a data model with a long-term end in mind. Try to put into as much forethoughts into the design as possible. The data model should remain structurally stable for the most part, with an occasional addition or removal of fields or attributes. If you find yourself needing a brand new entity or object in the schema due to legitimate business needs, that is OK, too. In any case, my experience tells me data model design is something to be taken very serious of, because it frequently plays a big part in making or breaking a CMDB effort. Get some competent, professional help and start collaborating across the organization boundaries.

  • Roles and Responsibilities: Who is your configuration management process owner that has the overall accountability for governance matters with access to senior IT management team for escalating policy discussions, if necessary? A CMDB manager role should be named and responsible for managing the operational activities of the process and ensuring integration with the other service management processes. The process owner or its delegates need to work on developing the CMDB data model (with EA’s help), the core policies, maintenance processes and procedures, key performance indicators and producing ongoing management reports.

Also, another important topic to work out is the data ownership issue. Another word, who will own which portions of the data in CMDB? Naturally, I think it is most productive for the organization when the CMDB data repository structure is centralized. Does that also mean the CMDB care-taker team will also be able to own all data within CMDB? By owning I am referring to the acquisition, maintaining, validation, and reconciliation of the data. Will your CMDB team or the server admin folks manage the server device data in the CMDB by themselves, or will there be some kind of collaborative arrangement in place between the CMDB team and the server admins? How about the ownership for the networking device data in CMDB? How about the ownership for the application specific information in CMDB? The data modeling exercise may give us more insights into what data we need. I would strongly recommend the data ownership issue get thoroughly reviewed and agreed upon during the planning phase.

In the part 3 of the series, I will discuss more planning considerations such as Control and Verification, Key Performance Indicators, and Awareness Campaign, Communication & Training. Planning for a CMDB solution can be a complex but also a fun and educational exercise. You are doing the organization a great service by fulfilling its on-going need for great information and knowledge to carry out its mission. Do this value-add project well by planning ahead and think things through.

Links to other posts in the series