If you have been keeping up with all the rhetoric about the latest Configuration Management technologies, you will find many vendors sharing their insights into how Configuration Management technologies should work. They typically start with ITIL’s definition of Configuration Management and then develop their white-paper argument of why their particular approach to the business problem fits best. Yes, the holy wars have begun. What should an IT professional do first to get his or her arms around the problem? Should the focus be on technology or process and data? Because there are no real standards for the technology, how does one know what is really needed to be successful? Here is what I recommend:

Get your arms around what is available in the marketplace by checking out the industry analysts’ latest evaluations. In addition to what we (Evergreen) are doing in this area, I have also found that Gartner and Forrester have some interesting opinions on this as well. See the following for more info:

Also, take a look at the “white papers” written by some of the vendors to get a sense for what they provide, but remember who is writing the paper. If you find a white paper that appears to be vendor neutral - be sure to read the fine print to see if there was a vendor sponsor.

Because this is such a new set of technologies and the industry doesn’t really have a broad set of implementations, I recommend starting with an RFI based on some very specific high-level questions. Ask the provider to demonstrate how the technology meets that requirement today and what their plans are in the next 18 to 24 months.

Here are four major considerations Gartner suggests (and I agree) should be taken into consideration when choosing a solution:

  1. Reconciliation - the ability to rationalize one or more instances of a CI that is discovered and determine that they are the same item. Determine that the relationships identified are accurate. Serve as the hub for discovered data prior to updating the CMDB
  2. Federation - enable multiple data sources to be brought together to represent a coalesced view of defined level of data and/or link data stores to the CMDB. KTS intends to view ?core? data from multiple data sources in the CMDB for ease of use in performing IT tasks (e.g., planned and unplanned outages). The configuration data in a specific IT domain will be managed in the appropriate repository to that domain, but a subset of data will be kept current in the CMDB or be easily linked to the CMDB so that a ‘Drill down’ into more detail can be performed. (e.g., past incidents recorded against a CI). These data repositories will be representative of multiple vendors: technologies.
  3. Mapping and Visualization - the ability to illustrate logically and physically the hierarchical and peer-to-peer relationships between CIs. The capabilities must go beyond parent-child relationships to multilevel and functional relationships. This should include reporting capability of various views and, eventually, ‘what-if’ capability to simulate the impact of a change on a specific service or system. Additional functional relationships that should be supported are:
    • Ownership - the owner of submitted by
    • Direction - governs, uses or runs on
    • Communications - creates a data feed to
    • Conditional - A activates B if C occurs
    • Connectivity - connected to, installed on
  4. Synchronization - the ability to update the CMDB with approved changes and to identify changes that were made and not authorized or did not meet the conditions of a change of a specific type or CI. Ability to alert the Change Management workflow engine of a discrepancy so that remediation can take place
  5. .

After receiving the answers to these questions and seeing the technology demonstrated, compare it to your current environment and work on your process and data requirements next. There is lots of work to do with your Configuration Management project that has little to do with the technologies, so you probably have more time then you think. Work on process and data models first before getting too committed to the technologies. Getting a good understanding of the technologies early in the game, however, may influence your design work and may provide a change lever for your thinking. At the end of the day, the technologies should enable your process and data model and not drive it.

Because there are no standards yet and the technologies premature, be sure to look at those players with a strategy but may not have all the components available.

Finally, after you have your process and data model well understood, develop a list of requirements based on your knowledge of the marketplace and your own environment. Then narrow your search down to two or three players and have them do the detailed response to your detailed requirements (RFP).

That’s what I think - now tell what you think. what have you seen and what are you doing to tackle this challenge in your organization? We’d like to hear from you!

Thanks

Tony

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

Technorati Tags:

—–


Posted in: Change Management , CMDB  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Add comment


(Will show your Gravatar icon)  

  Country flag

biuquote
  • Comment
  • Preview
Loading



Search

Calendar

«  March 2010  »
MoTuWeThFrSaSu
22232425262728
1234567
891011121314
15161718192021
22232425262728
2930311234
View posts in large calendar