CMDB - It needs some serious love - what do others think?

CMDB - It needs some serious love - what do others think?

Guys,

According to my opinion there is some additional work needed to make the CMDB really usefull. My critical view upon it, along with the suggestions:

  1. Too many default CI types

    There are a staggering 64 default CI types implemented, all of them cannot be hidden nor deleted. 

    Make sure these can be hidden or deleted. The user should be in charge of what CI's he/she uses. Licensing should work independent of this. 

  2. Default fields in custom made CI's

    When you create a custom CI without any additional fields there still are 'asset details' added to with fields: Vendor name, asset tag, serial number, etc...

    The scenario is that i am creating:

    - A list of web services i am running internally
    - A list of database schema's that i am running on our database servers

    These kind of items do not need the 'Asset Details' nor the deprecation details. 
    I want a simple list with fields i have chosen, nothing more, nothing less. 

  3. Deleting custom made CI's doesn't work

    And the forums show. 

    Create a custom CI without a parent. Add a CI item in it, and delete it. Now try to delete the CI Type itself. An error pops up "The CIType(s) cannnot be deleted as it is being refered by other modules. ". And euh, no nitpicking but: 3 errors in one sentence?

    The deletion of custom made CI Type's should work as it should. As an example watch iTop's handling of references and deletions. 
    The above remarks show how sloppy it sometimes becomes...


  4. Inconsistencies in default CI Types

    Two examples (but there are more): CI Type Switch and Firewall

    Firewall has 2 custom default fields: IP Address and Firmware Revision
    Switch has 15 custom default fields: Subnet Mask, Mac Address, Estimated Bandwith, etc...

    Please tell us: What (logical) use is there to incorporate fields like this within the Switch CI: Estimated Bandwidth, CPU (in MB) (??), Config Register, Processor BoardID (??), Flash Size (in MB), IOS, NVRAM Size (in KB), CPU Type, DRAM Size, etc..

    Remove all these default fields and let the user decide what fields they actually wants to incorporate and use.

  5. Add extra field types in custom CI Types

    Currently there are only a few field types that can be utilized: 

    - Some system attributes with Technician, Department, etc..
    - A single line, multi line, pick list, numeric and date field

    Many times over the following has been asked: a Hyperlink field, a Image field, set default value for pick list, ...


In my opinion the CMDB needs this attention to remove a lot of unwanted clutter and sloppiness. There is way to much balast and inconsistencies for me to use it properly currently. 

                  New to ADSelfService Plus?