Configuration Management (CM)

Definition of Configuration Management (CM)

Configuration Management (CM) is a continuous process of recording and maintaining consistent and reliable records pertaining to an organization's hardware and software composition, including software version control and hardware updates.[1]

Configuration Management is typically identified with managing the software configurations of network devices. It addresses the following kinds of practical questions: What features are to be enabled? What addressing and routing configurations will be supplied? How will the configuration be maintained? How will a configuration be restored? However, configuration management also covers several other topics. These include:

  • Inventory Management: Inventory Management consists of tracking network devices and their attributes (e.g. chassis, cards, interface types, serial numbers, hardware revisions, etc.).
  • Change Management: Change Management encompasses the tracking of changes to the network, its devices and services, from request through planning, engineering, approval, implementation and operational hand-off.
  • Provisioning Management: Provisioning management is the configuration of network devices to enable or disable network services. Provisioning can be as simple as network operators logging into network devices to modify configurations. Provisioning might also consist of implementing vendor, third-party, or homegrown applications capable of taking higher-level input.[2]

Configuration management (CM) is a governance and systems engineering process for ensuring consistency among physical and logical assets in an operational environment. The configuration management process seeks to identify and track individual configuration items (CIs), documenting functional capabilities and interdependencies. Administrators, technicians and software developers can use configuration management tools to verify the effect a change to one configuration item has on other systems. Configuration management is one of the operational processes identified in the IT Infrastructure Library (ITIL) service management framework, although an enterprise need not adopt the ITIL framework to perform configuration management. Configuration management is referred to as Service Asset and Configuration Management in ITIL V3. For a configuration management system to operate, it needs some form of mechanism in which to store the information it governs. Originally, this was called the configuration management database (CMDB); ITIL V3 introduced the concept of a configuration management system (CMS) to replace the CMDB. The CMDB promotes a concept of a singular monolithic repository, while the CMS provides a conceptualized system of CMDBs that act together to support the needs of this governance process. Both demonstrate advantages over a static configuration management spreadsheet or text file that requires significant manual upkeep and cannot integrate base workflows and best practices. Every service management tool is deployed with a supporting data repository. Without the governance process of configuration management validating its contents, the repository is simply an operational database with unverified data, not a CMDB or CMS. Automated configuration audit and verification components entitle a repository to be leveraged as an authorized gold source of assets. A manual audit is also possible. A configuration management process and its supporting repository, CMDB or CMS, face the challenge of overlapping and contradicting data from sources across the enterprise. The configuration management plan must include a way to merge and reconcile CIs to present a single point of reference or single source of truth.[3]

History of Configuration Management (CM)[4]

Configuration Management originated in the United States Department of Defense in the 1950s as a technical management discipline for hardware material items—and it is now a standard practice in virtually every industry. The CM process became its own technical discipline sometime in the late 1960s when the DoD developed a series of military standards called the "480 series" (i.e., MIL-STD-480, MIL-STD-481 and MIL-STD-483) that were subsequently issued in the 1970s. In 1991, the "480 series" was consolidated into a single standard known as the MIL–STD–973 that was then replaced by MIL–HDBK–61 pursuant to a general DoD goal that reduced the number of military standards in favor of industry technical standards supported by standards developing organizations (SDO). This marked the beginning of what has now evolved into the most widely distributed and accepted standard on CM, ANSI–EIA–649–1998. Now widely adopted by numerous organizations and agencies, the CM discipline's concepts include systems engineering (SE), Integrated Logistics Support (ILS), Capability Maturity Model Integration (CMMI), ISO 9000, Prince2 project management method, COBIT, Information Technology Infrastructure Library (ITIL), product lifecycle management, and Application Lifecycle Management. Many of these functions and models have redefined CM from its traditional holistic approach to technical management. Some treat CM as being similar to a librarian activity, and break out change control or change management as a separate or stand alone discipline.

Configuration Management Process[5]

The general CM process, graphically demonstrated below, is made up of the following elements:

  • Configuration Identification – process of documenting and labeling the items in the system, by providing a unique identifier to track changes and identify item location.
  • Change Management – process of assessing impacts of a possible change to a system, determining the fate of the proposed change, executing the approved changes, and ensuring that the change is properly documented.
  • Configuration Status Accounting – process of ensuring that all of the relevant information about an item is up to date and as detailed as necessary.
  • Configuration Audits – process of analyzing Configuration Items and their respective documentation to ensure that it reflects the current situation.

Configuration Management Process
source: DOT

Overview of Configuration Management Tools[6]

Even though each CM tool has its own terms, philosophy and ecosystem, they typically share many characteristics and have similar concepts. Most configuration management tools use a controller/master and node/agent model. Essentially, the controller directs the configuration of the nodes, based on a series of instructions or tasks defined in your provisioning scripts. Below you can find the most common features present in most configuration management tools for servers:

  • Automation Framework: Each CM tool provides a specific syntax and a set of features that you can use to write provisioning scripts. Most tools will have features that make their language similar to conventional programming languages, but in a simplified way. Variables, loops, and conditionals are common features provided to facilitate the creation of more versatile provisioning scripts.
  • Idempotent Behavior: Configuration management tools keep track of the state of resources in order to avoid repeating tasks that were executed before. If a package was already installed, the tool won’t try to install it again. The objective is that after each provisioning run the system reaches (or keeps) the desired state, even if you run it multiple times. This is what characterizes these tools as having an idempotent behavior. This behavior is not necessarily enforced in all cases, though.
  • System Facts: Configuration management tools usually provide detailed information about the system being provisioned. This data is available through global variables, known as facts. They include things like network interfaces, IP addresses, operating system, and distribution. Each tool will provide a different set of facts. They can be used to make provisioning scripts and templates more adaptive for multiple systems.
  • Templating System: Most CM tools will provide a built-in templating system that can be used to facilitate setting up configuration files and services. Templates usually support variables, loops, and conditionals that can be used to maximise versatility. For instance, you can use a template to easily set up a new virtual host within Apache, while reusing the same template for multiple server installations. Instead of having only hard-coded, static values, a template should contain placeholders for values that can change from host to host, such as NameServer and DocumentRoot.
  • Extensibility: Even though provisioning scripts can be very specialized for the needs and demands of a particular server, there are many cases when you have similar server setups or parts of a setup that could be shared between multiple servers. Most provisioning tools will provide ways in which you can easily reuse and share smaller chunks of your provisioning setup as modules or plugins. Third-party modules and plugins are often easy to find on the Internet, specially for common server setups like installing a PHP web server. CM tools tend to have a strong community built around them and users are encouraged to share their custom extensions. Using extensions provided by other users can save you a lot of time, while also serving as an excellent way of learning how other users solved common problems using your tool of choice.

Choosing a Configuration Management Tool

There are many CM tools available in the market, each one with a different set of features and different complexity levels. Popular choices include Chef, Ansible, and Puppet. The first challenge is to choose a tool that is a good fit for your needs. There are a few things you should take into consideration before making a choice:

  • Infrastructure Complexity: Most configuration management tools require a minimum hierarchy consisting of a controller machine and a node that will be managed by it. Puppet, for example, requires an agent application to be installed on each node, and a master application to be installed on the controller machine. Ansible, on the other hand, has a decentralized structure that doesn’t require installation of additional software on the nodes, but relies on SSH to execute the provisioning tasks. For smaller projects, a simplified infrastructure might seem like a better fit, however it is important to take into consideration aspects like scalability and security, which may not be enforced by the tool. Some tools can have more components and moving parts, which might increase the complexity of your infrastructure, impacting on the learning curve and possibly increasing the overall cost of implementation.
  • Learning Curve: CM tools provide a custom syntax, sometimes using a Domain Specific Language (DSL), and a set of features that comprise their framework for automation. As with conventional programming languages, some tools will demand a higher learning curve to be mastered. The infrastructure requirements might also influence the complexity of the tool and how quickly you will be able to see a return of investment.
  • Cost: Most CM tools offer free or open source versions, with paid subscriptions for advanced features and services. Some tools will have more limitations than others, so depending on your specific needs and how your infrastructure grows, you might end up having to pay for these services. Training should also be considered a potential extra cost, not only in monetary terms, but also regarding the time that will be necessary to get your team up to speed with the tool you end up choosing.
  • Advanced Tooling: Most tools offer paid services that can include support, extensions, and advanced tooling. It’s important to analyse your specific needs, the size of your infrastructure and whether or not there is a need for using these services. Management panels, for instance, are a common service offered by these tools, and they can greatly facilitate the process of managing and monitoring all your servers from a central point.
  • Community and Support: A strong and welcoming community can be extremely resourceful for support and for documentation, since users are typically happy to share their knowledge and their extensions (modules, plugins, and provisioning scripts) with other users. This can be helpful to speed up your learning curve and avoid extra costs with paid support or training.

Comparasion of Popular CM Tools

The table below should give you a quick overview of the main differences between three of the most popular configuration management tools available in the market today: Ansible, Puppet, and Chef.

Comparison of Configuration Management Tools
source: Digital Ocean

The Need for Configuration Management (CM)[7]

Almost everyone in an organization plays a role in effective and efficient configuration management. Problems arise because too many do not understand their roles. Configuration management processes, like the conductor of an orchestra, are there to ensure everyone is working to the same sheet of music. Without some form of configuration management, there would be chaos. CM protects organizations from Murphy’s Law – "anything that can go wrong, will go wrong". When errors occur that need correcting, it is imperative that organizations are able to quickly locate and utilize the latest and most accurate information. If any of the following is happening in your organization, it is an indication your CM related processes are in need of improvement:

  • Products are produced and parts are purchased to the wrong configurations.
  • Individuals spend hours searching for up-to-date information, then more time trying to figure out what it says in order to make a ten minute decision.
  • It takes too long to make changes to documentation and product.
  • Unauthorized changes are being made to product, documentation, special tooling, test equipment, etc.
  • Audits are feared instead of welcomed.
  • Communication between departments is poor.
  • Product documentation and changes to that documentation are not calculated as part of a true cost.
  • Bad ideas and costly mistakes are discovered after the fact.
  • There is a lack of accountability when things go wrong.
  • It takes days to figure out the configuration of a problem product.
  • The level of customer dissatisfaction is unacceptable.
  • Non-conformances, scrap, re-work, or repair rates are too high.
  • Product development takes too long - it is over budget and behind schedule.
  • Production goals (such as cost, schedule, performance, quality, etc.) are not being met.
  • In-service products are changed but few records exist.
  • Individuals leave the company citing "frustration" as a reason.
  • Integrity of supplier CM abilities is in doubt.
  • And more…

ROI of Configuration Management[8]

Some of the financial benefits contributing to positive ROI results found in leveraging configuration management include:

  • IT staff productivity increase. Optimization of IT staff activities through automation reduced IT staff time spent "keeping the lights on", freeing up valuable staff resources for business-related initiatives.
  • User productivity increase. Reduction of downtime caused by system outages, cyber attacks, security intrusions, and change and configuration activities.
  • IT cost reduction. Optimization of IT operations reduces costs in multiple areas, including infrastructure, outsourced services and management software.
  • Continuous delivery of IT services. Ensuring that the software can be reliably released at any time.

There are plenty of ROI calculations that you can apply for your business. The metric is cost avoidance in areas such as:

  • The number of devices/nodes monitored by a configuration management system.
  • The effort (try $35/hour conservatively) it takes a system/network engineer to handle configuration management processes manually.
  • When (not if) a system outage occurs with no backup configuration.
  • When you inevitably need to apply a bulk configuration update to many systems, or a new rollout needs to happen.
  • When your business has to comply with a configuration audit request, or pass a technology risk assessment.

The benefits of configuration management flow into all these activities. These activities take time, and time is money.

See Also


  1. Defining Configuration Management (CM)
  2. What is Configuration Management (CM) Tobias International
  3. Understanding Configuration Management Techtarget
  4. History of Configuration Management (CM) Wikipedia
  5. Configuration Management Process FHWA
  6. Overview of Configuration Management Tools Digital Ocean
  7. Why Do We Need CM? CMPIC
  8. What is the ROI for Using Configuration Management? UpGuard

Further Reading