What is configuration management? A comprehensive guide

Why is configuration management important?

IT configuration is a broad idea that involves three principal layers:

1. What IT resources, services and applications are available?
2. How are those elements deployed and set up?
3. How do those elements relate to or interoperate with one another?

Consider a simple example. A data center can possess many servers, each providing compute, storage and physical networking resources. Those resources are provisioned to provide a clearly defined operating environment for services and applications, such as network firewalls, OSes, web portals and sites, databases, APIs, CRM and ERP programs and countless other business platforms. Every business platform deployed into those operating environments must be configured to use specific paths, storage volumes, VMs or containers and network segments. Most business platforms interoperate, such as CRM frameworks and databases, and each dependency must be carefully configured so resources, services and applications can work together.

All the details involved in provisioning, setup and dependencies comprise configuration, and a business can have many different configurations depending on the organization's size and IT needs.

A configuration is important because it establishes a known good environment. A business knows that when an environment -- resources, services and applications -- is configured a certain way, that environment and the elements operating in it will deliver the stability, performance and security the business expects. If the configuration deviates from the established norm, the environment and its constituent elements might also deviate from normal behavior. This can lead to security vulnerabilities, reduced performance, and disruptions and downtime in the production environment.

Consequently, the practice of configuration management serves to monitor the IT environment against an established baseline configuration. A process of configuration control will report on and alert administrators to any changes in the configuration and even prevent changes without proper authorization. Every change is recorded, creating an audit trail that details what was changed, when and by whom. Real-time alerting and reporting can identify precise changes, letting administrators or automatic systems locate and remediate changes to restore the established configuration, vastly simplifying any troubleshooting involved.

Configuration management doesn't prevent planned and authorized configuration changes. Configuration changes are typically handled through a well-defined change management process intended to test, validate, review and document any changes, often enabling successful changes to become the new baseline configuration.

How does configuration management work?

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. A CMDB promotes the 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 CM spreadsheet or a text file that requires significant manual upkeep and can't 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 used as an authorized gold source of assets. A manual audit is also possible.

A CM process and its supporting repository -- CMDB or CMS -- face the challenge of overlapping and contradicting data from sources across the enterprise. A configuration management plan must include a way to merge and reconcile CIs to present a single point of reference or sole source of truth.

As the CMDB grows and contains more configuration information, it becomes possible to predict the effect of configuration changes, a key role in change management. By tracking dependencies, for example, administrators can determine the effect that a hardware, software, network or other outage might have on other systems or resources. This makes it possible to predict potential problems before implementing configuration changes and quickly troubleshoot or correct configuration changes if problems occur.

Even when configurations are well documented and carefully enforced, configuration management must account for the reality of periodic changes, such as software upgrades and hardware refreshes. Infrastructure and architectural changes might be required to tighten security and enhance performance. This makes change requests and a comprehensive change management process integral to the CM practice. This might be as simple as opening a certain port on a firewall to accommodate an application's new feature or relocating one or more busy servers on the local network to improve performance of other applications on the subnet.

History of configuration management

In the broadest sense, configuration management traces its roots to the 1960s, when the U.S. Department of Defense instituted military standards for general hardware and configuration management. Standards evolved and consolidated into what became ANSI/EIA-649-1998.

The basic CM model was adapted and implemented for myriad technical disciplines, including systems engineering, product lifecycle management and application lifecycle management, as well as later standards such as ISO 9000, COBIT and Capability Maturity Model Integration. The ITIL framework, which emerged in the 1980s, introduced principles and practices for enterprises to select, plan, deliver and maintain IT services. These let IT function as a business service rather than simply a cost center -- a concept that continues to resonate today. ITIL has embraced configuration management as a central part of its framework through its ITIL v4 update.

IT and business leaders readily adopted configuration management with the explosion of enterprise computing in the 1970s and 1980s. Data center operators realized standardized practices were vital to the established functionality of servers and systems within a production environment. IT further refined the CM process to include specific activities, such as change control or change management, to ensure that changes were documented and validated.

The broad shift from mainframes to server-based computing in the early 1990s multiplied the volume of hardware and devices in the data center. A centralized mainframe gave way to racks of individual servers, storage subsystems, networking gear and appliances, as well as full-featured endpoint systems such as desktop PCs.

Configuration management practices continue to evolve and now embrace remote resources and services. For example, cloud users employ these practices and tools to monitor the resources, services and workloads deployed within the public cloud.

In addition, configuration management has bifurcated into software development efforts, helping developers track software components, libraries, build versions and other software elements used in Agile or continuous development initiatives. This dovetails with DevOps, continuous integration and continuous delivery (CI/CD) practices and related areas, such as IaC and software-defined infrastructure.

As machine learning and AI continue to build capabilities, configuration management will systematically embrace more automatic features, letting CM perform more autonomously -- often able to make configuration changes dynamically with little, if any, human intervention.

Key benefits of configuration management

From its earliest implementations in IT, configuration management served four key purposes:

1. Consistency.
2. Security.
3. Service delivery.
4. Compliance, or business continuance.

Let's dig into each of these benefits.

Consistency. Consider a traditional data center filled with dozens or hundreds of physical servers, network switches and storage devices. It's vital that IT staff and business leaders understand precisely what is present in the environment and ensure every device, service, OS and application is configured in a known and acceptable way. They might even implement measures to enforce an established configuration. Consequently, configuration management provides an underlying consistency to the IT environment. When a device requires service or replacement, an established configuration provides a baseline that can be preserved and applied to replacement devices. Even when new and evolving technologies demand changes to the configuration, those proven changes become a new baseline. Similarly, configurations are often documented in ways akin to software version control, enabling a configuration to be quickly reverted or rolled back to a known good state if a change precipitates an unexpected error.

Security. Data centers have long relied on hardware and software configurations to help support enterprise security. Configurations affect security in countless ways: Login credentials are needed, APIs require authentication, periodic password changes are mandated, firewall ports open and close while blocking questionable traffic and network subnets are established. Documentation and consistency through configuration management help establish and maintain security.

Service delivery. Consistency also plays directly into quality of service and service delivery, and configuration management holds a core role here. Service delivery helps ensure the environment -- and the hardware and software therein -- operates in a known and validated manner. IT service management (ITSM) frameworks, such as ITIL, take the concept even further by outlining the processes, people and products involved in service delivery. IT administrators use configuration management and ITSM to enforce accepted approaches while guarding against prohibited approaches. The goal is to ensure that any services provided by IT are available, reliable and secure.

Compliance. Finally, configuration management is a major factor in business governance, business continuance and regulatory compliance. Compliance dictates adherence to guidelines, specifications or actions established by a governing authority, be it a recognized standards body such as ANSI or ISO, an industry organization or a government. Configuration management by itself doesn't demonstrate compliance, but the ability of an organization to show that a CM mechanism is in place to discover, preserve, enforce and audit a configuration across the infrastructure can support the organization's compliance efforts. Similarly, the presence of a CM mechanism to document and enforce an established configuration adds confidence to business operations, such as troubleshooting or recovering from disasters, and ensures the business can continue to function normally.

Although CM tools have become more sophisticated and best practices have expanded in scope, these four goals remain as important as ever.

There are also secondary benefits to configuration management, such as the following:

• Cost savings. CM avoids mistakes and alleviates time-consuming and costly troubleshooting. The ability to prevent problems is almost always greater than the cost of implementing and supporting CM.
• Documentation. Traditional configuration management involved a substantial amount of manual work, such as gathering data and organizing configuration information into spreadsheets. With the advent of powerful CM tools, organizations can automatically discover configuration information, prepare detailed reports on the configuration and offer assurance that the documented configuration is current and enforced.
• Less staff dependency. The availability of current and well-documented configuration information eliminates dependence on staff institutional knowledge. Any administrator can see the current and complete configuration without regard for who knows what.

Risks of configuration management

Although the benefits of configuration management can be compelling, the technology isn't perfect. CM platforms and practices pose challenges, starting with adoption and integration.

The traditional CM process requires an organization to identify each element in the IT environment, understand its specific configuration details, enter those details accurately into a documentation platform and then manage that data. Deciding which configuration data to collect and how to manage that data over time -- especially as hardware and software changes are required -- places a demand on IT staff.

Older CM platforms were little more than spreadsheets that required extensive manual effort to populate and manage. CM platforms later provided ever-greater levels of discovery and automation to help organizations fill in the blanks of each element's configuration and dependencies. But IT can't manage what they can't see, and elements that aren't discoverable by or suited for a specific CM tool might require additional tools, spreadsheets or other documentation. This effectively splits the CMDB and carries a significant risk of configuration management errors and oversights. While modern CM tools provide discovery and automation, don't assume that every element is perfectly represented.

Effective configuration management must be an all-or-nothing effort. Overlooked hardware and software narrow the view of CM processes, reducing the IT staff's ability to manage the environment. One forgotten desktop with an unpatched OS can expose the entire business to catastrophic security vulnerabilities.

Data sharing, integrity and protection are also vital. The configuration of an enterprise IT infrastructure involves sensitive details, such as a server's IP address. That information must be kept secure, yet it also must be available to other stakeholders, such as corporate compliance officers who perform audits. Deciding which stakeholders or staff can access and modify CM data is a delicate matter.

The evolution of data center technologies poses challenges for configuration management. Consider IaC pipelines, where fully virtualized data center resources are pooled, provisioned and managed as VMs, containers, cloud instances and other virtual constructs. Configuration management is essential to manage virtualized environments, but mistakes in defining virtual configurations can lead to new security risks and wasted resources -- also known as sprawl.

Consequently, any configuration management initiative must be approached with a high degree of testing, auditing and validation to ensure CM tools discover all elements in a reliable manner, generate meaningful documentation and reporting, provide adequate security and can adapt to inevitable changes in configurations over time.

Change and asset management

The discussion of configuration management typically involves the ideas of change management and asset management. These ideas complement configuration management, but it's important to understand the differences.

Change management. Change management is a process that directs the organization's approach to change. This applies to business goals and workflows, helping employees and customers accommodate and adapt to change within the workplace environment. But IT also employs change management to formalize the approach to change within the data center or enterprise computing environment. This can include protocols for how changes are requested and how to define procurement, deployment, setup/configuration, testing and even troubleshooting. A company will also want to organize change approvals and validations.

For instance, consider a workload running on a server. Application updates aren't applied to the environment indiscriminately; an unmanaged change will result in a configuration change that might affect the production environment. Change management is the process by which the new version might be identified, considered, tested, approved for deployment, deployed, configured and validated and even monitored on an ongoing basis. Changes must be registered in the CMS, though modern automation can usually help with discovery, evaluation, updates and reporting. Change management might also detail any training or guidelines needed for users to help smooth a transition or minimize disruption.

Consequently, change management is different than configuration management, but managing change -- recognizing the potential effects of change on a production environment -- is a vital part of configuration management. The detail and formality involved in a change management process can vary depending on the size and type of organization; a large and highly regulated business will typically use a detailed change management and reporting process.

Asset management. IT asset management shares the common use of data to identify the presence of hardware, software and other tangible assets across the business. Asset management is focused on business and accounting applications, but IT leaders recognize that the key to managing anything is knowing what's there in the first place -- if you don't see it, you can't manage it.

For example, asset management is aware of the servers, storage, networking gear, endpoint devices and other IT assets across the enterprise. Still, it is more concerned with the cost and validity of hardware and software licenses and service or maintenance agreements, the physical location and costs of each asset, and how those things are procured and ultimately disposed of. By comparison, configuration management is typically concerned only with an asset while it is in operation.

As another example, consider a server that is procured for a specific purpose. That server will be subject to both asset management and configuration management. If that server is repurposed at some point in its lifecycle, it will take on a new entry in configuration management because the server would be configured differently to do a different job. But its presence would remain the same business asset under asset management.

Software configuration management

Software configuration management has diversified into two separate issues: operational configuration and build (development) configuration.

In terms of operational configuration, software maintains many of the characteristics associated with hardware device configurations. For example, a software product might require extensive configuration during its deployment to define configurable issues, such as storage volumes and paths, user credentials, license authorizations and countless preferences or setup details.

However, configuration management has also expanded into the realm of software development and deployment, where it's known as software configuration management (SCM) or unified configuration management. Although it's rooted in broader configuration management, SCM focuses on the management of the many artifacts and components involved in software development, including source code, modules, libraries, components and APIs, along with related elements such as documentation, change requests and trouble tickets.

SCM can be used across the entire software stack. It provides additional structure and standardization to the software development process, which can help organizations establish baselines, enhance and organize reporting, manage changes and oversee resources allocated to a development project. SCM is codified in standards such as IEEE 828-2012.

Organizations frequently undertake multiple projects, each involving myriad components and multiple developers or teams. Without some cohesive way to bring order to the process, software building and testing would devolve into chaos. When several developers work on the same source code at the same time, the various changes won't integrate well, and the software will break. To avoid that outcome, SCM creates multiple lines of development (branches) and reconciles each line (merges the tested branches) into a final source for a build, letting many developers work on the same code simultaneously.

Configuration management in DevOps

Configuration management is crucial to collaborative and rapid software development paradigms, such as DevOps. With CM, software developers can create, test and deploy builds to staging and production with minimal IT oversight.

Software components must be brought together and integrated into a build, and each resulting build also carries unique version designations before being tested and deployed. Configuration management tracks the components involved in the build and ensures that a desired build uses only certain components.

Moreover, each build must be thoroughly tested, and configuration management can be employed to specify the tools and test files needed to validate a given build. When paired with automation, CM techniques can accelerate testing and release processes.

On the operations side, configuration management enables developers to stipulate an appropriate deployment environment for a build. This might involve creating and configuring VMs, but it's also a powerful way to create and configure virtual containers using container management/orchestration tools, such as Kubernetes. Other operations issues might involve provisioning and configuring storage, networks, services -- such as firewalls and load balancers -- and other elements needed to achieve a suitable operational environment for the software.

Every step of the way, configuration management provides logging to help track changes, audit access, enforce established configurations -- such as specific version components -- and maintain security within the library of components and builds.

CI/CD and configuration management. CM is used throughout the CI/CD toolchain. With build automation and source code management, CM can establish and enforce version control and change tracking. It also assists with version control and change tracking to log any activity within the repository and enforce any version restrictions.

Application deployment and configuration management define and enforce the resources needed to run the build in a desired configuration. The final step is the actual deployment, where the build is delivered for signoff to deployment or automatically deployed to live servers and connected to running services as desired. CM tools, such as Ansible, Puppet and Chef, are generally geared toward the latter part of the CI/CD toolchain, where workloads are deployed into the data center's hardware environment.

Configuration management and infrastructure as code. IaC principles rely on extensive virtualization to discover and pool resources across the data center environment, then provision and manage those resources based on software-driven or software-defined actions. DevOps is a principal driver of IaC because the use of code to create and manage infrastructure for a build's deployment is a natural extension of the software development and testing processes. IaC carries code into the operations side and lets developers readily deploy builds without ever touching or configuring actual hardware.

In more practical terms, IaC lets a hardware environment be defined exclusively through software that adheres to the principles of SCM. IaC description files can be written, tested, validated, version controlled and deployed much like any other software. This also means various testing processes are essential for an IaC deployment. These include static tests, unit tests, system tests, integration tests and blue/green (or A/B) tests. IaC security also must be considered.

Configuration management relies on programmatic techniques such as instructions or code to create, test and deploy software builds and manage infrastructure. Writing the code to drive CM processes in DevOps can use either imperative or declarative programming techniques.

Imperative programming focuses on how something is done. It tends to be more literal and detailed; for example, if someone asks you for directions to a Best Buy store, the imperative response would include all of the specific turns and distances to reach the destination. By comparison, declarative programming focuses on what is being done. It is more focused on ultimate goals. To get to a Best Buy store, the declarative response would be to provide the store's address; it doesn't matter much which route a person takes to get there. Configuration management embraces declarative programming, which enables goals to be stated more clearly and concisely.

Configuration management tools

A wide array of tools is available to address CM tasks. Important CM tasks can include the following:

• Discovery. The CM tool detects hardware and software present within the management scope, such as the data center. It collects relevant information about the CI and organizes that information into a database.
• Configuration states. The CM tool establishes and enforces desired configuration states for selected hardware or software CIs. This is usually accomplished using policies and automation. Deviations from a desired state -- the baseline -- are alerted and logged, letting administrators investigate and remediate unauthorized change attempts.
• Version control. CM tools ensure that specific software versions or components are deployed or built. In software development, version control ensures a given build is assembled from specific components -- different builds, or versions, might use different components.
• Change control. The CM tool controls the configuration and implements a process that coordinates, authorizes, documents, logs and reports authorized changes within the management scope. In some cases, the CM tool might be able to predict conflicts or generate warnings related to proposed changes, alerting administrators to potential problems before an authorized change is implemented.
• Auditing. The CM tool scans the environment, validates that current configurations are in place, identifies and reports any dependencies and ensures the overall environment is configured as expected. This can be an important feature for business governance and regulatory adherence.

Because CM tools are so different, selecting the right configuration management tool can make or break a CM initiative. The following are among the numerous features and attributes to consider:

• Flexibility. The tool should be easy to use, extensible and easily integrated with other tools, such as those used for systems management or the help desk. A tool that's flexible can discover and manage more than one that isn't. Ideally, only a single CM tool would be necessary. Multiple CM tools are usually undesirable and can cause oversights and unnecessary CM mistakes.
• Comprehensive reporting. Activity logging and reporting enables administrators and auditors to gather a complete picture of the environment and any changes made to it over time, such as what was done, when and by whom.
• Collaboration and communication. The tool should bring configuration management together with other management functions so administrators are notified of change requests, change attempts and completed changes -- especially changes affecting security or compliance.
• Scalability and extensibility. Simple CM tools should be adequate for small to midsize organizations. Larger organizations, however, will need sophisticated tools that support complex and expanding environments, as well as a larger number of integrations with other tools within the business.
• Cloud support. The management scope of the CM process is growing. Environments can be heterogeneous or homogeneous. Single data centers are now often complemented by secondary data centers, colocation, SaaS providers, private cloud deployments and public cloud infrastructures. Tools must be able to operate across multiple environments.
• Cost. CM tools can be expensive, but the cost is readily justified by the risks that a tool mitigates.

Leading configuration management tools vary in their scope and purpose. General tools, such as SolarWinds Server Configuration Monitor, CFEngine, Puppet, Chef Infra, Ansible, Juju, Octopus Deploy and Rudder, can handle data center hardware and SCM with some degree of automation. Cloud users can take advantage of provider-based services, such as AWS Config and AWS OpsWorks. Note that there is active industry consolidation around CM vendors, which complicates product availability and roadmaps.

Software developers can use many of these tools for SCM tasks but will also employ other tools, such as Atlassian Bamboo for continuous delivery and release management; JetBrains TeamCity, Jenkins, Vagrant and Apache Maven for configuration management and continuous integration; Git, Bazaar, Apache Subversion and Mercurial for source code management; simple Wikis for documentation; and JFrog Artifactory, Cloudsmith, MyGet, Yarn, Sonatype Nexus and Apache Archiva for artifact repositories used in version control.

Configuration management process

Configuration management is a core part of any IT organization, but getting started can be challenging. It takes careful planning and ongoing effort to successfully deploy it across an enterprise. The distinct steps to a CM deployment can vary but should include these six phases:

1. Select a suitable CM tool. This first step is often the hardest because the choice of CM tooling will be a costly investment that will be highly disruptive to change once implemented and established. Understand the specific CM needs for the business, as well as the nuances of the environments -- local and cloud -- where the tool must operate. Pick a tool that can handle the entire extended environment, offers flexibility and scalability, and supports high degrees of automation, enforcement and detailed alerting and reporting. Test several candidates in proof-of-principle projects, and select a final choice based on detailed feedback from staff. The tool should check all the boxes for the business. This might demand input from operations, DevOps, legal and business leaders.
2. Establish a baseline. In the discovery phase of configuration management, a tool or platform examines the IT environment, queries and discovers the hardware, software, services and other elements of the environment. This process establishes a current baseline of the elements, along with the configurations and dependencies of the elements. An organization will then know what is present and how everything works together. The baseline is the foundation for future change and change management. Consequently, a tool must see the entire environment, including physical, virtual and sometimes even cloud elements. Tools rarely identify every detail about every element, so IT staff must fill in any gaps or uncertainties in the baseline. This CM phase can take considerable time. Some level of staff institutional knowledge might be needed here.
3. Build a CM process or workflow. Consider the steps or process required to support configuration and change management, as well as the staff and managers involved. Appropriate CM tools must be selected, deployed and maintained. A regular system of discovery, recording, auditing and reporting must be established. Automation and orchestration are important parts of that process and should be used wherever possible, but they should never replace or assume the best outcomes for the specific business and its needs.
4. Maintain that baseline. Once a baseline is established, it must be actively maintained. The tool will typically detect, log and report changes -- all of which must be approved, validated and documented. Change and change management should follow clearly defined policies and practices to prevent accidental, unapproved or ad hoc changes. Tools with strong CM enforcement features can actively prevent changes until approval and validation steps are completed. Changes that do take place must be carefully documented to keep the CM tool current. Many CM initiatives fail when the environment deviates from the baseline without adequate control or reporting.
5. Audit the database. Even with active maintenance and comprehensive policies to govern CM processes, the tool and the environment must still be subjected to periodic auditing to validate the configuration and ensure the current environment matches the currently established baseline. Any differences must be corrected, and the reasons behind any differences must be understood and remediated. For example, if a certain server or particular application remains undetected, it might need an updated CM agent or other fix. Auditing is a central part of any business governance or regulatory compliance process.
6. Test to ensure your tool performs as intended. Finally, it's important to use the CM tool productively. For example, direct the CM tool to implement an OS patch or driver upgrade across a subset of the environment. Validate that the tool can accomplish such tasks within change management guidelines. Provide a means of rolling back undesired changes. Ensure that any reporting and CMDB updates behave as expected.

Configuration management heavily depends on policy, process and automation, which must be integrated into the CM tool or platform. But these three factors are not single steps. Just as a configuration must be regularly revisited, audited and tested, so must the surrounding CM policy, process and automation elements be reviewed and updated on a regular basis to ensure that the tool -- and its usage -- remains consistent with IT and business goals.

The future of configuration management

One of the greatest drivers for tomorrow's CM model lies in software-defined environments. More of the enterprise IT environment uses virtualization, automation and management to provision, deploy and manage resources and services through software. With the rise of data center technologies, such as software-defined storage, software-defined networking, SDDC and IaC, future CM tools and practices must be able to discover and interoperate with flexible and virtual software environments.

Consider the effect of IaC, which is also called configuration as code. Resources are typically virtualized and pooled, and a predefined set of instructions is used to provision those resources, configure the instance, deploy a workload into the instance, connect associated services such as load balancers or storage, configure the workload and manage the deployment over time. Configuration management must be able to discover new deployments as they appear, integrate those new instances into reporting and change management oversight. This means CM tools must be able to add, remove and manage instances ad hoc.

Another emerging technology to consider is GitOps, which enables a data center team to deploy container clusters using the Git code management and version control system. This effectively merges the use of containers, software development paradigms and SDDC capabilities to ensure that a container can be deployed using the desired software components in a suitable software-defined environment.

Future CM tools must also be able to handle the software-driven aspects of such an ephemeral environment, in which containers usually exist for only minutes or even seconds. This puts a particular emphasis on container orchestration tools for configuration management.

Cloud adoption continues for many types of businesses, and CM tools and practices must adapt to provide more cloud control and oversight, as well as better support for mixed environments where clouds must increasingly work together -- such as multi-cloud environments -- and offer stronger support for traditional physical data center infrastructures.

Finally, expect to see a broader use of machine learning and AI in configuration management. The primary purpose is to enhance automation in the CM process, enabling better prediction of change effects and more dynamic real-time responses to change requirements as they occur.

Stephen J. Bigelow, senior technology editor at TechTarget, has more than 30 years of technical writing experience in the PC and technology industry.