A configuration management maturity model

Just some quick thoughts on how configuration management might evolve. This is not a strict model; certain things can be leapfrogged (while others can't). Comments appreciated.

Level	Hardware	Software
Level 1	Hardware inventory, manually maintained through periodic inventory.	Software licenses manually maintained through periodic inventory.
Level 2	Hardware inventory maintained through procurement and change management process, supported by basic automated scanning. Hardware to installed commercial software dependency maintained through manual and/or automatic means.	Software licenses maintained through procurement and change management processes.
Level 3	Hardware characteristics and dependencies (e.g. network topology) discovered by automated scanning. Configuration scanning to enforce change control.	Enterprise application portfolio, including ownership/responsibility baselined and maintained through change management proceses. Automated release management provides software to hardware dependencies.
Level 4	Hardware to software product dependencies compiled and maintained through fingerprint-based scanning. Hardware to application portfolio dependencies compiled and maintained through manual and/or automated processes.	Database catalogs maintained as first class configuration items. Application to application and application to database dependencies captured and maintained: Sychronous and asynchronous app dependencies distinguished. Application to software product dependencies compiled and maintained. Change risk assessment is (at least partly) based on automated analysis of system dependencies. Security processes enforce CMDB accuracy: “if it’s not in the CMDB, you can’t have access to it.”
Level 5	Change control scanning integrated with asset and topology-oriented config.	Middleware dependencies fully mapped out at component level. Component level management possible for other areas if ROI is there. Software architecture gatewayed through release management are primary input into CMDB for application/business service dependencies (e.g. UML component/deployment diagrams). Enterprise architecture capability uses configuration management data for what-if modeling. Service management processes enforce CMDB accuracy: “if it’s not in the CMDB, we don’t support SLAs, availability, or capacity modeling.”

-ctb

Comments

[Matti M.]

Thanks for this model. It really was an eye-opener (yet another) on your site to register for commenting. So, some minor comments here:

On higher levels the enforcing of CMDB accuracy by integrating provisioning systems, i.e. the layer that carries out the changes to the configurations, need to be tightly integrated with CMDB. You have it there, in a way, but I would highlight it even more.

The other thing that somehow bothers me is the division to HW & SW. It works for me, but I have to think why they are separete. One implication is obviously that on lower levels of configuration management the main focus is in simple things, HW.

BR,
Matti