CMDBs and what it needs to contain
1. Should a CMDB contain specific application configurations?
2. Should it contain what is installed and what it requires (both other hardware/software/etc)?
I am under the impression that it should be answer number 2. Our Chief Architect thinks number 1. I can see how number 1 is important, but I think that number 2 is also easier to manage and helps you understand the basic systems, without getting into specifics. I also think that the deployment and configuration of software should not be controlled by the CMDB (although it can have a part in feeding its data into a build process).
Some of our developers want to build a APPDB which has these application specific items tracked in it, but it doesn't help to answer number 2 which is more important in my opinion.
All very interesting stuff. Either way we are very far off here, but we need to get our asses in gear.
1. Should a CMDB contain specific application configurations?
2. Should it contain what is installed and what it requires (both other hardware/software/etc)?
I am under the impression that it should be answer number 2. Our Chief Architect thinks number 1. I can see how number 1 is important, but I think that number 2 is also easier to manage and helps you understand the basic systems, without getting into specifics. I also think that the deployment and configuration of software should not be controlled by the CMDB (although it can have a part in feeding its data into a build process).
Some of our developers want to build a APPDB which has these application specific items tracked in it, but it doesn't help to answer number 2 which is more important in my opinion.
All very interesting stuff. Either way we are very far off here, but we need to get our asses in gear.
Comments