Configuration Management Tools

Definition: Webster defines a tool as "something regarded as necessary to the performance of one's occupation or professional task. [Words are the tools of my trade.]" Configuration Management (CM) tools come in several forms. For the systems engineers and their partners/sponsors/customers, these tools include best practice methodologies, standards, documentation, managed environments, manual tools, automated tools, and leadership skills. These require and enable discipline and rigor needed to plan, stand up, implement, and carry out CM successfully.

Keywords: automated tools, configuration management policy, program management plan, Statement of Work (SOW), tools

MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are expected to have a sound understanding of the principles of configuration management; how program management and project management view configuration management; how the development organization initiates configuration control; how the developer implements configuration management; and how the government sponsor or sustainment organization continues the configuration management following product delivery. MITRE systems engineers are generally involved in identifying requirements for automated tools to support the CM process. Rather than selecting specific automated CM tools, MITRE systems engineers need to begin with requirements that understand and address the roles of technical and non-technical elements of CM, to include documentation and the traditional software configuration management elements of hardware and software. To be successful, it is essential to understand CM. CM success is a function of leadership to insist on its implementation and use.

CM is defined in the Guide's Configuration Management topic. Within that context, it is important to note that CM is not all things to all people nor is it program management. It is a tool used by program management. It is not document management, but it is a partner tool used by document management. It is not requirements management nor engineering, but is a tool with important connections to requirements engineering activities and processes.

Automated CM tools can help:

  1. Record, control, and correlate Configuration Items (CIs), Configuration Units (CUs), and Configuration Components (CCs) within a number of individual baselines across the life cycle.
  2. Identify and control baselines.
  3. Track, control, manage, and report change requests for the baseline CIs, CCs, and CUs.
  4. Track requirements from specification to testing.
  5. Identify and control software versions.
  6. Track hardware parts.
  7. Enable rigorous compliance with a robust CM process.
  8. Conduct Physical Configuration Audits (PCAs).
  9. Facilitate conduct of Functional Configuration Audits.

Best Practices and Lessons Learned

Start at the Beginning: Get top down buy-in on the value of CM. A successful CM program is supported and enforced by leadership. Set or cite a CM policy/directive that authorizes a high level Configuration Control Board (CCB) (e.g., Executive CCB) at the highest authority with links to higher and lower boards. Coordinate CM planning with requirements development and management, quality assurance, process improvement, independent validation and verification, and existing enterprise processing centers to ensure engagement and integration of production stakeholders. Ensure the Program Management Plan contains a program level Configuration Management Plan. Coordinate with the acquisition organization (e.g., Contract Officer, Contract Officer Technical Representative Acquisition Advisor) to ensure adequate CM requirements are in the SOW. In addition to the standard CM requirements, the SOW should include formal CM audits of the contractors to measure compliance with the agency/customer CM policy, agency/customer regulations, etc.

Audit Early and Often: Set standards early, and audit for compliance. Identify or establish agency/government/enterprise policy, plan, practice, procedures, and standards, including naming and tagging conventions early. Audit internally to ensure the Program Management Office is following the policies and procedures. Consider an annual demonstration of contractor alignment with Software Engineering Institute Capability Maturity Model Integrated (CMMI) CM, Information Technology Infrastructure Library CM, uniform top-level CM processes—ISO-9001, and National Consensus Standard for Configuration Management (ANSI EIA 649). Consider using a CMMI Practice Implementation Indicator Description format, such as those used for CMMI assessments, and include conclusive evidence for the demonstration. Schedule it annually.

Considerations for Automated CM Tool Acquisition: First, ascertain the method of management that is most significant for your project or system, and ensure the tools serve that purpose. Next, define the requirements. Automated CM tool requirements need to be identified before acquisition decisions are made. It is critical to establish requirements for the automated CM tool by collecting available CM plans, policy, process, procedure, and instructions, and meeting with the relevant stakeholders. Be certain to include business, user, contractor, and operations and maintenance stakeholders to define the automated CM tool requirements.

These requirements should include considerations for the following:

  1. Requirements Management
  2. Document Management version control
  3. Controlled repositories
  4. Configuration Identification and control, including hardware, software, etc.
  5. Change Request processing and tracking
  6. Audit support
  7. Configuration Status Accounting Reporting (CSAR)
  8. Baseline management (software, documentation, requirements, design, product, production)
  9. Software development check-out/check-in
  10. CM of environments (development, test, product, production); may be multiples of each
  11. Multiplatform capabilities (personal computer, local area network, Web, mainframe, data centers, etc.)
  12. Release engineering of all types of Change Requests (CRs) (e.g., normal releases, routine releases such as operating system and security updates and patches, break fixes, emergency)
  13. Transition CM tools into the sustainment activities
  14. Automated CM tool within the approved technical reference model or fully justifiable for a waiver.

CM tool selection needs to include a discussion of the selection criteria based on the requirements, evaluation of tools, and selection of tools.

CM Lessons Learned and Pitfalls

  1. Depending on the level of support from the program leadership and stakeholders for CM, tools may not be included as part of the overall CM plan or planned for acquisition. If automated tools are acquired, ensure that program leadership is aware of the need for planning short-, mid-, and long-term needs for installation, establishing the baseline data, and training, updating, securing, and maintaining the tools and the associated process and procedures needed to use them effectively.
  2. Set expectations early. CM and configuration change control are all about CRs, regardless of what they are called, and the impact of change on scope, cost, and schedule.
  3. Keep informal and formal communication open with CM as an agenda topic in meetings and gate reviews. Do not shoot the messengers.
  4. Consider release management separate from CM. Do not assume that release management can be done by the CM organization.
  5. Everyone may know CM, but training will be needed to orient staff on how CM is done in your particular organization.
  6. Coordinate with those responsible for business continuity of operation and disaster recovery. Some will assume that CM will provide the capability to restore the entire system if the need arises. This is not a safe assumption, unless your CM tools are designed with this capability in mind.
  7. Identify, establish, maintain, and control the necessary development, test, and production environments, including the automated CM tools, hardware, software, operating system, security, access control, and supportive infrastructure.
  8. Contractors and periods of performance may come and go. It is recommended that the transition from one contractor to the next include an inventory of baselined hardware, software, documents, etc. PCAs on the departing contractor product should establish what the new contractor inherits. Gap analysis should be performed to determine the delta and provide input to the contract closure activity prior to making final payments to the departing contractor.

Conversely, if the above lessons are not applied, the consequences can lead to CM failure. Indications that things are not going well include: leadership support is not evident, formal CCBs are not chartered or recognized as change approval authorities or do not function, "lanes in the road" are not defined and chaos reigns, attendance at CM meetings (CCBs, engineering/technical review boards, and impact assessment boards/teams) declines or is non-existent, and cross program/project impacts are not identified by CM, but only when something breaks down.

Automated CM Tools Lessons Learned

  1. Buying a tool will not establish an appropriate CM program for your effort.
  2. It is unlikely that a single automated CM tool can be all things to all stakeholders by integrating all required elements across all platforms. So-called commercial off-the-shelf "suites" of tools may not contain integrated capabilities to suit the enterprise. When they have the potential for integration, often there may be a significant effort needed to adapt the products after they are taken out of the box. What may support software development with check-out/check-in features may be bundled within a "suite" of stand-alone automated tools without any integration. Tool administrators may only have the ability to export to a spreadsheet for reporting. Automated tools may control one area well, but not be suited for other areas.
  3. The automated CM tools used within the development and test environments may not be compatible with those in the production environments. This may require development of semi-automated or manual processes. In either event, security and firewall infrastructures may present additional challenges.
  4. Automated CM tools may offer flexible options, including the ability to design your own change request (CR) form and flow. This has inherent pros and cons. There is often an assumption by the acquirer that the tool will deliver a CR process out of the box such that no other development effort will be needed. It is important to understand that the capabilities delivered out of the box are directly impacted by the installation/customization of those tools. It is important to understand the need for development and administration of the automated tools, and set expectations early on.
  5. When planning the acquisition of the automated CM tool, consider the initial and longer term costs, including licenses, and labor cost to install and develop it so it is usable for your program. Plan for on-going system administration, security, maintenance, back up, and recovery as well as business continuity of operation and disaster recovery. Consider the ability of the tool, and data contained within the tool, to be transitioned from one contractor to another, which is sometimes the case when a program transitions from production to sustainment.
  6. Avoid an approach with tools that implies the tool will establish the standard and solve the problem. It is not best practice to say "Here is the solution. What is your problem?"

References & Resources

  1. MITRE Center for Connected Government, CM Toolbox
  2. MITRE Systems Engineering Practice Office, Configuration Management Toolkit


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team