A configuration management maturity model

October 24, 2005 @ erp4it from alphasong

Vote This Post DownVote This Post Up (No Ratings Yet)
Loading ... Loading ...


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


This article is syndicated from erp4it . The original article is available here. Read more in Project Management News .

No tag for this post.
Reminder : PMToolbox has ZERO tolerance to copyright violation and agrees to follow strictly PMI's Professional Responsibility. That's why each post on this site includes a link to the original version at its source site.

Comments

Got something to say?