Posted by: buzina | April 15, 2009

CMDB autodiscovery and other fairy tales

As I promised in an earlier post, here is the slide deck of my noventum day presentation

CMDB autodiscovery and other fairy tales

I hope you enjoy seeing it, even if it lacks the voice stream.


  1. Love the slide deck! great stuff.

    Couldn’t agree more about the overselling of autodiscovery. Of course as you know I’m more skeptical about the whole CMDB thing🙂

    Also agree about not trying to fix with technical solutions.

    • In the audio (not available here), I stressed a few times the need to ensure that everything you put into configuration management is worthwhile the effort. I remember someone asking to include hard disk serial numbers in case the manufacturer would call back a range of disks!

      But against your public opinon, I still believe that configuration management can be worthwhile. You need some one who is checking data quality and this is the job of configuration management. How you call result, CMDB, CMS or just “My IT Management System(s)”, is not important. If you look at manufacturing, they created quite some standard catalogs of components that are re-used and they do create databases with CMDB information. Mercedes does know the serial number of the navigation system installed in every car they produce (unless you change it at an unauthorized dealer!). Sounds CMDB to me…

      ** EDIT ** forgot to say: thanks!

      • People will soon start calling me the IT Pedant, but I must defend the term “CMDB”. A CMDB is not a bucket of config info. I’m a big fan of good configuration management process and data (especially asset data).

        but that aint a CMDB. A CMDB stores all CIs under change management and their relationships, including and especially the relationship to the conceptual entity Service.

        • OK, is still available, so go for it.

          So what you are saying is that in may example Mercedes does not have the link to the conceptual entity service? You may be right in part, since Mercedes is linking it to the conceptual entity product.

          I have just checked the definitions, but I could not find the requirement that a CMDB needs to have every CI that is under CM and their relationships. I checked the ITIL v3 glossary and the v2 documentation (and quickly scanned the v3 docs) but I found no requirement of that sort. Which definition of CMDB are you using?

          Obviously I trying to beat you to the rights to

  2. It is true that Service Transition slipped in the word “selected” (ST 4.3.2) in order to keep Juan Jiminez and I arguing for the next few years.

    nevertheless ST 4.2.1 p42 “All changes to …CIs are recorded in the CMS”

    ST 4.3.1 p65 “Ensure integrity of …configs required to control the services

    Simple logic dictates:
    If all CIs involved in a service are not in the database and related to service, one cannot assess impact on service of a change to a non-recorded CI.
    If not all CIs that support a service are under change control one cannot protect the integrity of the service, and one does not know if a service impact is due to a change to that CI.

    the idealised CMDB is one that stores all CIs that contribute to all services. I don’t understand how there can be debate over that.

    While it is perfectly reasonable and sensible to take a phased approach and only record some data in early phases, I argue that one does not have a CMDB, one is only on the path to a CMDB, with some interim configuration data.

    if we start calling every step along the journey a CMDB, then the term will come to mean “any old bucket we put configuration data in”, in which case the term adds nothing.

    In recent debate on Linkedin, one person argued that I was wrong to suggest CMDB is too hard becuase we can control how much we put in it through scope; and then I was told by another that i was wrong to suggest we can do without CMDB because there are typically 100,000 CIs in a CMDB.

    • OK, so let us first take the references:
      4.2.1 (in my Copy on P 43) states “All changes to service assets and configuration items are recorded in the CMS”. Since Config Management defines what a CI should be for your organisation, this is not implying a full coverage of all possible CIs in order for the CMS to be a CMS (or CMDB to be a CMDB). If you have a look at the CMS architecture diagram, it is shown to contain Change Request Status (upper left in the presentation layer). So the CMS needs a connection to the change records and so they are in there, even if they have no CI representation.
      4.3.1 This is the purpose of configuration management, not of the CMS / CMDB. So this does not tell us, if the CMDB is required to have all CIs under change control.

      Your simple dictated logic is the logic of the CMDB vendors (this is a first😉. There is a way to do impact analysis of a service that is not fully recorded in a CMDB. This is the method of the brains. Since a CMDB will never be perfect your change process should be fault tolerant. CMDB Data will aid the change process, but it will not automate it (fully).

      Your idealised CMDB is the vision that people have in their mind when talking about CMDBs. I believe this vision to be wrong, since it is not achievable. Even with seemingly “simple” Asset Management you will have quite a high fault rate (if you have > 90% accuracy you are really good).

      So the whole debate is about “when is a CMDB a CMDB”? In my opinion the term CMDB is misleading anyway. CMS is better if we can avoid that it will mean 100% accurate data on the whole world of IT and it’s business connectivity. This is why I prefer to talk about configuration management and not about CMDBs, CMSs or SKMSs.

      Whe do talk about the incident management process, not about the incident workflow tool, so why should we talk about the CMDB and not about the configuration management process?

      I like the LinkedIn discussions you mention. Of course the 100,000 argument is pure nonsense, but the first one has at least some relevance. If the target of a CMDB is not to solve all data issues about the IT environment, but to be an aid in many situations it is a usefull tool. I personally do not give a s***t about it’s name, so lets go ahead and name it ITEIS (IT Environment Information System). It provides inmformation and does not do decisions.

      ** Edited to include the CMS architecture reference **

  3. […] is a CMDB a CMDB or what to call our Configuration Management Data containers In my post on CMDB autodiscovery and other fairy talesthe ITSkeptic raised the question of: “when does any old bag of configuration management data […]

  4. So we agree then.

    ‘idealised CMDB is the vision that people have in their mind when talking about CMDBs. I believe this vision to be wrong, since it is not achievable.” That is precisely my argument. the idealised CMDB is not achievable.

    I’m a big fan of ITAM. I like network discovery and PC inventory.

    Of course the important thing is configuration mangement not some underlying technology – CMDB and CMS and SKMS are terrible distractions. The other processes don’t get all hung up on underlying technology or data stores.

    “There is a way to do impact analysis of a service that is not fully recorded in a CMDB. This is the method of the brains.” Precisely what I argued with “On-demand CMDB”.

    yes we are in perfect agreement.

    • Good. I probably just fell for your striktness in using the term CMDB (as in “idealised CMDB”).

      But one thing I would still like to have your opinion on. Is the strive towards a better documentation of the services and their underlying components (some call this Enterprise Architecture Management) the way to go or should we leave the design of the services to be dormant in visio graphics, power point slides and the odd UML definition?

      You say you like ITAM, NW discovery, PC inventory (also Systems discovery?), so what is your opinion on the less discovery orientated configuration management data containers?

  5. Is “better documentation” a code for one unified central repository? Because my fundamental issue with CMDBN is the same for all “one ring to rule them all” solutions: they are an anal perfectionist response to an imperfect world.

    Anything that can automatically display a complete view of the current state is a Good Thing. Anything that needs to be manually maintained to do that is a Bad Thing: it can’t keep up and it falls into disrepeair and then disuse. YAFR (Yet Another Repository). Better to live with isalnds of data and potential inconsistencies and let the brain do the unification on demand.

    I’m sure there are exceptions but I’m equally sure it is a good principle.

    • Not unified, but yes, one place (a place called configuration management process) that holds more of the available information on the IT landscape.

      When someone comes in and makes a shift to a new email system, they make a lot of archtectural decisions. They document this in Word, Excel, Visio and a lot of other data dumps. Then they are forgotten. The original designer of the environment is gone (probably was an external guy) and noone knows anymore what happens when I push a button.

      If your notation of Good and Bad Things would be true, than why the heck should anything be documented? Let us all just be creative and build intersting (but failing) systems? Lets make sure that IT is and stays an art form, far away from business and mundane things as risks.

      In SW development, 20% (approx.) of the efforts is development. The rest is testing, documenting & designing. Why do you say? Because the SW development industry found out that no matter how perfect your code analysis tools are, they will never tell you the intent of the original developer (every now and then they are again trying to this, but fail). The move to aid here is modelling. And my opinion is, save these models in a “CMDB” like environment.

      Another example: The whole of the supply chain management. They had a large number of seperate systems managing their supply. There was no way in finding out what would happen if one supplier failed to deliver on time. Right now in large manufacturing companies they do know what parts the next models of products will need, they are in talks with the suppliers even while the new products (and their manufacturing process) is designed. Yes, this is what IT service management talks about. And what do they use to propel the process? A central system that stores the required configuration data.

      I guess your Good and Bad are not so strict as you posed them in this comment.

  6. What you are diuescribing is SKMS. CMDB holds CIs and their relationships.

    • Yep, a CMDB holds CIs & their relationships.

      It has a Service CI, which is related to it’s components. The components show the relationships between them and then you have your SKMS.

      As stated before, the naming of these data repositories is not in my interest. For the handover to production the service designers build diagrams that show how the service works for the operations manuals. For every release they have to produce an update to that. So the idea is to use a more or less central version of these diagrams elektronically, since a diagram is just one form of representing CIs & their relationships.

      You may be right about this vision to be very far away indeed. If we are bickering over names, then the SW companies will again succeed.

      **sigh** you just took away my optimism for the day…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: