Element versus enterprise configuration management

The term "configuration management" continues to be a badly overloaded phrase, with almost as many meanings as "service." One distinction I am making recently is between

1. Enterprise configuration management

2. Element configuration management

Enterprise configuration management is the inventories of, and dependencies between, Configuration Items.

Element configuration management concerns the internal states of particular CIs.

Enterprise configuration management questions include:

• What is the enterprise inventory of servers? Databases? Applications?
• What applications use this database?
• What software, databases, and servers comprise this service?
• What depends on this message queue?
• What business processes use this application?

Element configuration management questions include:

• Did parameter X change on this server in the past 24 hours?
• What is the current CPU and RAM for this server?
• What is the patch level for this operating system?
• What version of the application server software are we running?
• What is "high queue depth" for this queue? Has it changed recently?
• What is the definition of this ETL job?

Enterprise configuration management overlaps with enterprise architecture, portfolio management, and metadata management. It requires a central repository of some sort, and as an industry we are not very mature in managing the logical dependency data such repositories target. Dependency mapping tools enable enterprise configuration management.

Element configuration management is distinct from simply element management. Element configuration management is the concern for a repeatable or duplicable state for a given CI, or the detection of changes to that state from a given baseline. Element management is the broader set of activities concerned with the entire lifecycle for that CI. 

What is an element management system? The definition I use in my book is that element management is the most sophisticated non-programming work the IT shop undertakes. Here are some examples:

• Server systems administration tools
• Network management consoles
• Middleware management consoles
• DBA enterprise management tools
• BPM, ETL, rules engines, and the like

Element configuration management is related to provisioning, discovery, and monitoring systems, as well as element management systems.

I've been applying the enterprise/element config distinction with some success in my daily activities, discussions with vendors, and so forth. It's also represented in my book. Like any distinction there are gray areas, but generally it's added value for me in architecting an ERP for IT solution.

In particular, the distinction has sparked in me a caution towards all-purpose discovery tools. I am skeptical of tools that are trying to discover both dependencies as well as element configurations, because element configurations in particular are extremely varied. I might very well want to baseline the configuration for an ETL hub and detect any changes to it - talk about a super critical Configuration Item for some shops! But I am not seeing any mainstream CMDB or discovery tools that cover things like ETL, BPM, batch schedulers, and the like. Most just do servers and some of the more prevalent middleware. This is one reason to decouple the two kinds of configuration management.

Thoughts?

Charlie

Comments

[Joe Pearson]

I wonder. The distinction is useful and should help to maintain attention on both levels. - Perhaps also to help recognise situations where a tool or method claims to do "Configuration Management" but addresses only one of the levels.

But when you say "decouple the two kinds" my distrust kicks in. Perhaps they should be decoupled at the discovery tool level, or at the vendor selection level; but somebody is going to interpret that as decoupling the information ownership and decoupling the information model between the two kinds, and that's not going to be helpful. There's still gotta be "one CMDB".