CWDS

Configuration Management Plan

Executive Summary

The purpose of the Configuration Management Plan is to document how the Project will identify State service assets (SA) and configuration items (CI) including internal deliverables and work products, and State owned software products. The Project will record all SA’s and CI’s, list their attributes and relationships, as well as protect them from unauthorized changes.

The term “Service Asset” refers to any resource or capability. Assets can be one of the following types: management, organization, process, knowledge, people, information, applications, and infrastructure.
The term “Configuration Item” refers to any component that needs to be managed in order to deliver an IT Service, and anything that needs to follow a formal change control process. Information about each CI is recorded in a configuration record within the Configuration Management Database (CMDB) and is maintained throughout its lifecycle. CIs are under the control of change management. Project CIs will include IT services, software, source code, and some formal documentation.

The following processes are in scope for this Configuration Management Plan:

Configuration Identification
1. Configuration Identification covers the recording of information about CI's including software versions, documentation, ownerships and other unique identifiers.
2. This includes defining the relationships of the CIs in the system.
Configuration Control
1. Verification of CIs will occur every six months by the Configuration Analyst with the exception of project documentation as it is covered under the Document Management Plan.
2. Decommissioning a Configuration Item requires a change request. Follow the Change Request Process and indicate the reason for retiring the asset.
Status Accounting and Reporting
1. Status accounting ensures that all configuration items are recorded as each CI progresses through its lifecycle.
2. It contains current and historical data for each CI which enables the tracking of changes to the CI.

Configuration Management utilizes the typical request, track, build, test, approve, implement, control and monitor approach in order to utilize the processes already in place.

Introduction

Purpose

This document describes the Configuration Management (CM) Plan (hereinafter referred to as the “plan”) for the Child Welfare Services – New System (CWS-NS) Project (hereinafter referred to as the “Project”). The purpose of this plan is to document how the Project will identify State service assets and configuration items (hereinafter referred to as “SA’s”, and “CI’s”) including internal deliverables and work products, and State owned software products. The Project will record all SA’s and CI’s, list their attributes and relationships, as well as protect them from unauthorized changes.

The term “Service Asset” refers to any resource or capability. Assets can be one of the following types: management, organization, process, knowledge, people, information, applications, and infrastructure.

The term “Configuration Item” refers to any component that needs to be managed in order to deliver an IT Service, and anything that needs to follow a formal change control process. Information about each CI is recorded in a configuration record within the Configuration Management Database (CMDB) and is maintained throughout its lifecycle. CIs are under the control of change management. Project CIs will include IT services, software, source code, and some formal documentation as detailed in table 3-4 below.

Scope

The scope of this plan covers SAs that the State shall manage – including internal deliverables and work products, State owned hardware and software products – across the whole service lifecycle from initiation through operations. (All CIs are considered service assets, but not all service assets are considered CIs.) The lifecycle management of a CI/SA is from the point of acquisition through to disposal.
S
ervice Assets (version control, change notificaice Assets (version control, change notificati

In-Scope

The scope of configuration management includes:

Configuration Identification

Selecting, grouping, and classifying SAs and CIs
Identifying SAs and CIs
Naming convention for SAs and CIs
Labeling SAs
CI relationships

Configuration Control

Change Management
Version Control
Baseline
Repository and Access Control
Software Licensing

Status Accounting and Reporting

Status Accounting
Reporting

Out of Scope

Please refer to table 3-4 below to see all documentation that is no longer being classified as a CI
Project IT Hardware Asset Management is not in scope for this plan, an Asset Management process needs to be established.

Legacy System (CWS/CMS) processes are out of scope for configuration management:

IBM is responsible for configuration management of software, hardware, licenses and source code for CWS/CMS.
IBM provides source code to the repository (change occurs as a result of the release process).
The CWDS organization won’t be changing the way that IBM performs configuration management – we need to define our processes for the project.
The State manages the contract for IBM but IBM manages all of the configuration. The CWS-NS project will have a separate CM process than the current IBM process.

Assumptions and Constraints

Assumptions	Constraints
The project will implement a new configuration management tool by the end of Q3, 2016. Excel is the current tool and will be used up until the new tool is ready.	Configuration management tools are still being evaluated for selection

Integration with other CWDS Plans

This plan integrates with Change Management, Contract Management, and Document Management.

Change Management Plan

The Change Management Plan (Note: This link is temporarily for OSI internal use only) is the process of managing changes to project artifacts, application code, deliverables, or baselines at a strategic, tactical, and operational level. The purpose of this Change Management Plan is to establish a standard approach for the approval and tracking of proposed changes for the project.

Contract Management Plan

The purpose of the Contract Management Plan (Note: This link is temporarily for OSI internal use only)is to provide the processes and procedures to ensure the project meets all contractual obligations.

Document Management Plan

The purpose of the Document Management Plan (Note: This link is temporarily for OSI internal use only) is to capture how document management is defined for the project, as well as how internal Project documentation is developed and reviewed. Document Management is the process of organizing, storing, protecting, and sharing documents. This plan describes how to manage the hard copy and electronic repositories of documents, historical information, and provides a consistent approach to the creation, update, and format of documents.

Document Maintenance

The CWDS Configuration Management plan will be updated as processes and procedures change.

During development of the plan, the guidelines and standards provided through the Project Quality Management Plan will apply; specifically all peer review requirements must be met.

Transition to Agile

As a result of the transition from a pure SDLC, waterfall change management approach to a more agile approach, the CWDS project has incorporated the following agile-like principles into the new changes in this document:

Project Documentation (Project Management Plans and Processes) are no longer considered configuration items. They are considered service assets.
Removing redundancy and complexity from all aspects of development: from designs, from requests and requirements, and even from and processes and tools.
Question what really is needed and remove the things we don't really need. Avoid overly complex or laborious tools and processes. These extraneous elements add complexity and/or redundancy that can create more friction than forward motion on development projects. The result is that they add little if any value to the main goal of developing quality software.
Agile Configuration Management is more about accepting and embracing change than preventing or controlling it. Agile methods acknowledge that too much "control" can harm development efforts of both software and business teams.

Roles and Responsibilities

The following tables describe the roles and responsibilities of the CWS-NS Project stakeholders in the Configuration Management arena.

Roles	Responsibilities
Configuration Management Analyst	Sponsor, design and manage the configuration process and its metrics Define the service assets that will be treated as configuration items Communicate process information or changes to ensure awareness. Provide process resources to support activities required throughout the service lifecycle Updates the CMDB as needed Address issues with the configuration process operation Work with Project Librarians to plan and coordinate all process activities Plan and manage support for CM tools and processes Coordinate Interfaces between CM and other processes, especially change management, release and deployment management, and knowledge management Periodically review the process strategy to ensure that it is still appropriate Work with service owners and other process managers to ensure the smooth running of services Monitor and report on process performance. Propose scope of the configuration management plan Define the structure of the configuration management system, including CI types, naming conventions, required and optional attributes and relationships Train staff in CM principles, process and procedures Perform configuration audits Respond to quality audit findings and work with the Quality Manager for process improvements/corrective action responsible for disposal of software
Project Librarian (Can be performed by Configuration Analyst)	Control the receipt, identification, storage, and withdrawal of all supported CIs Maintain status information on CIs and providing this as appropriate Archive superseded CIs Assist in conducting configuration audits Identify, record, store and distribute issues relating to service asset and configuration management Work with the Quality manager to conduct and report on Configuration Audits.
Application Development, Data, Technical Architecture Teams	Follow the processes to identify and change Configuration Items. Use the Configuration Management tools in the course of development, enhancements, and addressing defects in the CWS-NS project. Indicate when changes are ready for a build.
Quality Manager	Review the work of the CM process owner and other project teams as defined in Quality Management Plan to ensure compliance with this plan. Conduct quality audits of the CM process and tool.
Change Initiator	Fill out Change Request (CR) for a New/Changed/Retired CI
Change Developer	Develop planned change (includes implementation, verification, back-out plan if required)
Change Manager (Can be performed by Configuration Analyst)	Evaluate impact of resources required for implementation, costs and schedule Assess CR to consider business impact, technical impact, options, recommendations and (as needed) cost. Records CR updates, facilitates CCB meeting Perform post implementation review to verify that change does what the request stated it would do
Change Implementer (Can be performed by Change Manager)	Implements change Validates that change is successful

Plan Approach

Approach and Methodology

Configuration Management utilizes the typical request, track, build, test, approve, implement, control and monitor approach in order to utilize the processes already in place.

Table 3-1 CM Process Overview

The high-level steps to the CM process are listed in table 3-2.

Step #	Description	Role
1.	Request: Analyze if a change is needed. Follow Change Management Process by creating a Change Request (CR) for adding, changing, or retiring/archiving a CI.	Change Initiator for CR CCB for Approval
2.	Track in the Configuration Management Database (CMDB): Configuration Analyst updates the CI with status from CR if tool does not automatically do so and ensures there is a back-up/snapshot prior to Change Control Board (CCB) approval.	Configuration Analyst or Project Librarian
3	Build: Build or implement changes	Change Developer
4.	Testing and Validation: Test process and validate assumptions and constraints	Change Developer
5.	Approve: Approve the change for release after successful completion of testing and validation	Change Manager
6.	Release & Implementation: Train, roll-out, and support	Change Implementer
7.	Control & Monitor: Update CI, update status, put back under change control, monitor any issues or unauthorized changes, and report.	Configuration Analyst

Table 3-2 SACM Process Overview Steps

Configuration Identification

Configuration Identification covers the recording of information about CI's including software versions, documentation, ownership and other unique identifiers. This includes defining the relationships of the CIs in the system. The section will be updated with more information as the CWDS agile adoption matures and makes decisions in relation to configuration identification.

Selection and Classification

The criteria for selecting configuration items, service assets, and the components that compose them are listed in the tables below:

Table 3-3 Service Assets Overview

Service Assets (requires version control, not change control)
Category	Method and/or Situation
Project Documentation (Project Management Plans and Processes)	The Project Management Office (PMO) has decided that project documentation would not be considered a CI under change control. Project documentation is a service asset. The authority for making changes to project documentation is at the subject matter expertise (SME) level and does not require going through a CCB to approve changes.
User Documentation (user manuals, user guides, cheat sheets, help or FAQs)	Each service team is responsible for the development, revision, management, approval and storage of user documentation.
Vendor Documentation (Sprint Status Report)	Contract Management will handle the approval of the status reports in comparison to contractual obligations.
Technical Documentation produced by the State (architecture roadmap, data roadmap, infrastructure roadmap)	Technical teams are responsible for the development, revision, management, approval and storage of technical documentation.
Enterprise-wide Hardware/Software/Licenses purchased by the State	Goes through a workflow approval process for installation and configuration.
Standard Hardware/Software/Licenses purchased by the Vendor	Vendors are expected to bring their own laptops and set up their own development environments. If they bring software, the State needs a plan to transfer the software and licenses to the State.
Role Based Access	Role based access is a service asset that does not require change control but goes through a formal workflow approval process.
Stakeholder Communications	Press releases Conferences, events, vendor forums Public-facing informational web pages that detail time, budget, and procurement details Social Media Posts CWDS.ca.gov Homepage DNN Homepage

Table 3-4 Configuration Items Overview

Configuration Items (requires change and version control)
Category	Method and/or Situation
Cost	Requires additional cost to implement change
Digital Service Standards	Adverse impact to planned standards / compliance
Business Process and System Functionality	Requires modification to system functionality or business process
Schedule	Requires extension of scheduled deliverable dates
Bidders’ Library	All documentation within the bidders’ library
Source Code	IBM manages source code for the CWS/CMS independently. CWS-NS source code will be deposited into GitHub with appropriate version control. Becomes a CI when the source code is moved into the State’s environment(s). The GitHub repositories will have the mechanism to control who has access to the code and note who has checked the code in and out. Control of software code varies depending on environment, action, and responsible party.
Systems Development	Test Automation Scripts Ansible scripts Anything that affects the system, application, or infrastructure. Patch - A patch is a specific fix that addresses a single problem or a change resulting from a legislative or policy/program change Minor Release - A minor release is a release for system fixes (inclusive of all previous fixes and patches), system enhancements, and new functionality. Minor releases occur between major releases. Major Release - A major release includes new as well as improved features and functionalities.
Non-Standard Hardware/Software/Licenses purchased by the Vendor	If a vendor brings non-standard HW/SW that they want to install in a State environment, the State must allow for a formal change control process.
Configuration Baseline	A configuration baseline of CIs must be taken before performing an implementation/release (into system, acceptance test and production) in a manner that can be used for subsequent checking against actual deployment.
Snapshots	Snapshots will be taken of the production environment prior to being rolled out. In the progress of identify anomalies, a final snapshot is created and compared with the target baseline to verify any discrepancies. Snapshots will be taken before every release or major / minor upgrade, update, bulk update, schema changes and database migration and with a retention period of 90 days.

Grouping

The CIs identified will be grouped in the following manner:

Organization CI - Documentation that is required internally and not by a vendor.
Service Lifecycle CI - CIs that provide a picture of vendor services, how these services will be delivered, what benefits are expected at what cost. (I.e. Business case).
Supporting CI – CIs that are needed by vendors such as bidders’ library documents and infrastructure.

Naming Configuration Items

Each CI will have a unique CI/SA number assigned to it by the Configuration Analyst. The Analyst will assign the next sequential number available. When the configuration tool is ready, the unique id will be generated by the tool so that each entry into the CMDB reflects an individual asset or configuration item. The Configuration Documents should have file names that identify their origin, ease search and retrieval, and accurately reflect their content. Adherence to the CWDS Document Management_100_Naming Conventions Procedure helps maintain consistency in naming documents.

Here is the link to the procedure: https://osicagov.sharepoint.com/sites/projects/CWS-NS/PMO/_layouts/15/DocIdRedir.aspx?ID=PROJ-31-55 (Note: This link is temporarily for OSI internal use only)

Decommissioning Assets and Configuration Items

Decommissioning a Configuration Item requires a change request. Follow the Change Request Process and indicate the reason for retiring the asset.
All software that is no longer to be used in state service shall be disposed of in an appropriate manner. (See here for details.)
The Configuration Analyst is responsible for disposal of software (organization/classification).
Documentation will be retained per the retention policy and by utilizing the CWDS Document Management Process.

Status Accounting & Reporting

Status accounting ensures that all configuration items are recorded as each CI progresses through its lifecycle (see Figure 3-1, steps 2 and 6). It contains current and historical data for each CI which enables the tracking of changes to the CI.

Each asset or CI will have one or more discrete states through which it can progress through various statuses. The significance of each state is defined in terms of what use can be made of the asset or CI in that state. There will be a range of states relevant to the individual asset or CIs as listed below:

Service Assets & CI	Service Assets & CI	Service Assets & CI
Purchased	Live (CI may be used)	In Build/Dev.
Received	Retired/Withdrawn	In Test
Awaiting approval of CR	Disposed
Spare	Under Repair

Figure 4-3 - SACM Statuses

The CMDB should be updated with the reason, date time stamp and person that did the status change.

Verification and Audits

Verification of CIs will occur every six months by the Configuration Analyst with the exception of project documentation as it is covered under the Document Management Plan. All discrepancies will be documented and presented to management. Verification of all CIs will also be done as part of the release and deployment process.

The reviews and audits are performed in order to verify the physical existence of CIs, and checks that they are correctly recorded in the CMDB. Verification of CIs will also be done as a part of the release and deployment process before changes are made to the live environment.

The activities include a series of reviews or audits to:

Ensure there is conformity between the documented baselines and the actual business environment to which they refer
Verify the physical existence of CIs in the organization or in the DML and the locked site, the functional and operational characteristics of CIs, and to check that the records in the CMS match the physical infrastructure
Check that release and configuration documentation is present before making a release
Review the version control structures in active use

Verification and audit will be carried out:

Before a release to ensure the environment is as expected
Following recovery from a “disaster” and after “return to normal”
Shortly after changes to the CMDB (addition of fields), as well as changes to database itself
Before and after changes to the CIs
At planned and random intervals
In response to the detection of unauthorized CIs.

Unregistered and unauthorized items that are discovered during configuration audits will be investigated and corrective action taken to address possible issues with procedures and the behavior of personnel. All exceptions are logged and reported to the CM Analyst and Quality Manager.

If there is a high incidence of unauthorized CIs detected, the frequency of configuration audits will be increased.

Procedural Steps

Please refer to the CWDS Change Management Plan for the procedural steps on how configurable items and service assets are managed.

Tools

The project will implement a new configuration management tool by the end of Q3, 2016. Excel is the current tool and will be used up until the new tool is ready.
These requirements are for an integrated tool set, not for a single tool. The tool shall:

provide security controls to limit access to CWS records on a need-to-know basis
allow CI attributes fields; such as unique identifier, type, name, description, version, location, supply date, license details, owner, status and others depending on the type of CI
produce management reports from any of the data fields that are held within the CMS without the need to purchase additional products or consultancy services
facilitate the production of management reports from historical records
provide an audit trail for record information and updates; i.e., IDs of individuals or groups opening, updating and closing records; dates and times of status and activities updates, types of activities
automate notification and escalation to keep IT and users informed of potential issues or progress
allow old CI records to be deleted or archived
support CIs with different formats for model numbers, version numbers and copy numbers, such as for hardware (e.g., serial no. for Dell, HP & IBM) MS Office software and documentation such as ISBN number on books or an edition number on an SLA)
automatically validate input data to ensure that all CI record details are unique
support the addition of the relationship with other CIs at the time of entering the record
show the current status of any CI, such as 'live' or 'withdrawn'
support the control of software through all stages of its lifecycle, from design stage through to live operational running
support the management and use of baselines that can be used for reverting to trusted versions
verify that correct and authorized versions of CIs exist
support linking definitive media libraries to the CMS/CMDB
allow CI inventory reports to be produced to facilitate configuration audits
maintain the historic details of all CIs, such as installation date, records of changes and locations
display data in the form of models and maps relationships between CIs
support the hierarchic and networked relationships between CIs; i.e, a capability that is needed for management reporting, managing incidents, problems and changes (impact analysis)
automatically identify other CIs affected when any CI is the subject of an incident, problem, known error record and RFC
automatically update the version number of a CI if the version number of any component CI is changed
provide a documented procedure and checklist for manual updates to configuration data, which are also recorded in a change log
prevent CI records being updated without appropriate change approvals and procedures being followed, including documentation
produce a report showing unauthorized additions