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.
Hardware inventory, manually maintained through periodic inventory.
Software licenses manually maintained through periodic inventory.
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.
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.
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.”
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.”
The Guide to IT Service Management is an exhaustive compendium of much industry-leading thought on all aspects of large-scale IT management. This 800-page tome (somewhat hard to obtain in the U.S.) features over 50 in-depth articles and case studies on issues such as service lifecycle management, conceptual IT frameworks, organizational and process issues, and much more. It is one of the most comprehensive and concentrated collections of high quality IT management writings available, in a field somewhat diffuse and hard to research.
Good luck finding a copy...
Van Bon, J., The guide to IT service management 2002. 2002, London ; Boston: Addison Wesley, ISBN 0201737922.
Note that 1) Microsoft is a prominent member of SIM and 2) Microsoft's Bill Gates is on a big IT education push; could the two be related?
Thing with the national SIM is their membership criteria is elitist. (Just being objective - nothing wrong with elitism, but it by definition limits your base of support.)
The AITP is another organization to look at - also with Microsoft as a major sponsor. Looks like membership is more broadly based, but they don't appear to be as active as SIM lately. Both SIM and AITP have affiliates here in the U.S. Upper Midwest (NWAITP and SIMMN, along with DAMA-MN and MN-IPS. The Minnesota ITSMF chapter can be reached through the national ITSMF web page).
The University of Minnesota (my alma mater) has developed quite a strong ITIL offering through its College of Continuing Education. This resources page includes podcasts and white papers, including a good one on configuration management by a senior Carlson Company IT manager. (Carlson is headquartered in Minnesota.) Recommended; very well structured and written. There is also an excellent discussion on ITIL metrics with a Carlson School (U of MN business school) professor.
Those of you particularly concerned with data architecture may want to check out Dr. Arnon Rosenthal's work; I just re-visited his site tonight and was reminded of the uniformly high quality of this man's research and thought.
"DSAs are a specialization of service level agreements (SLA) between service providers and consumers [Wust02]. Typically, SLAs emphasize performance metrics about time (e.g., response or problem resolution time) or availability (e.g., maximum percentage of downtime). However, we are aware of no prior work on SLAs to address data obligations (e.g., the need to provide data of a certain quality at specified time intervals)."
As a service management approach, a DSA as he describes it might be more of an internal service (OLA) or underpinning contract, but (as he notes) there is really no other work in this area, so hats off to Dr. Rosenthal for starting a conversation here.