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
Got something to say?