What is a Configuration Management OPS document?

Configuration Management OPS Portable Process Guide Government of Ontario IT Standards (GO-ITS) Document No. 36 Version 1.1 Status: Approved OCCIO/OCCTO MANAGEMENT BOARD SECRETARIAT CORPORATE ARCHITECTURE BRANCH TECHNICAL STANDARDS SECTION Last Review Date: April 1, 2005

Foreword Government of Ontario Information & Technology Standards are the official publications on the standards, guidelines, technical reports and preferred practices adopted by the Information Technology Standards Council under delegated authority of the Management Board of Cabinet. These publications support the Management Board Secretariat's responsibilities for coordinating standardization of Information and Technology in the Government of Ontario. Publications that set new or revised standards provide policy guidance and administrative information for their implementation. In particular, they describe where the application of a standard is mandatory and specify any qualifications governing its implementation. 2

Table Of Contents INTRODUCTION... 4 1 INTRODUCTION TO THE PORTABLE PROCESS GUIDES... 4 Mandatory Sections of Standard:... 5 Suggested Only Sections of Standard... 5 Appendices... 5 1.1 Purpose of the Standard... 5 1.1.1 Scope of Standard... 6 1.2 Process Definition... 6 1.2.1 Process Focus & Goals... 6 1.2.2 Scope of Configuration Management... 7 1.2.3 Value to Organization... 7 1.2.4 Basic Concepts... 8 1.3 Recommended Versioning and/or Change Management... 10 1.3.1 ITSM Process Governance and Ownership... 10 1.4 Contact Information... 11 1.5 Type of Standard... 11 1.6 Publication... 11 1.7 Acknowledgements... 12 1.7.1 Development Team... 12 1.7.2 Reviewers... 12 CONFIGURATION MANAGEMENT... 14 2 COMMON PROCESS PRINCIPLES... 14 3 PORTABLE PROCESS ROLES... 17 3.1 Configuration Management Process Owner... 17 3.2 Configuration Manager... 18 3.3 Configuration Coordinator / Administrator... 19 3.4 Configuration Item Owner... 19 4 PROCESS FLOW... 20 4.1 Configuration Management Portable Process Flow... 20 4.2 Configuration Management Process Quality Control... 21 5 COMMON PROCESS METRICS... 22 6 STANDARD PROCESS PARAMETERS... 23 ERRATA... 24 DOCUMENT NUMBERING... 25 COPYRIGHT... 26 APPENDIX... 27 A. Process Variances from OPS V2.3 Process Guides... 27 B. Standard Parameter Allowable Values... 30 C. Process Localization Guidelines... 31 Glossary... 32 References... 37 3

Introduction 1 Introduction to the Portable Process Guides This standard process guide is part of a portable set of ITSM process documentation intended for use as a reference across the OPS. This documentation establishes the required OPS baseline for ITSM process adoption and describes what needs to be done. A Key objective identified during an OPS ITSM Planning workshop held in December 2003 was to Define Standard Portable Elements for All ITSM Processes. Hence, these guides are designed to be portable across all IT Clusters as well as any parties in the end-to-end supply chain and only include the necessary process components that should be common across the OPS. Further details may be defined at the local level as required. This documentation uses the OPS Standard Change & Configuration Management Process Guide version 2.3 (last updated in March, 2001) as its starting point. Changes have been made for three reasons: 1. Principles, Roles, Responsibilities and Processes that do not need to be specified OPS-wide have been removed or streamlined. 2. The guides have been updated to reflect a maturing of the OPS in its implementation of Configuration Management Processes. 3. The guides have been updated to reflect the evolution of ITIL best practices. Appendix A outlines the key variances between the Standard ITSM Process Guide V2.3 and this OPS Portable Process Guide. This document establishes common standard Configuration Management principles, roles and processes for use across the OPS. These portable elements provide a frame of reference for localization of the guide for use by Clusters. Use of a common process and underlying information will also enable OPS-wide monitoring and reporting using common data/metrics. It is expected that each enterprise will develop a localized process guide that will address specific requirements for implementation of Configuration Management in its environment. This local guide will identify specific principles and procedures as well as address specific organizational mapping considerations. The more detailed information included in Version 2.3 may still be referenced as an archived resource (with noted updates and changes) for use in the development of these local guides. GO-ITS 44 ITSM Terminology Reference Model Portable Guide provides a common information model for key process parameters that require standardization across the OPS to ensure consistency, reliable business intelligence and to support end-to-end crossjurisdictional service management. This document is organized as follows: 4

Mandatory Sections of Standard: Section 2 presents the Common Process Principles, which represent founding principles meant to guide the design and delivery of services to customers or users. The principles are meant to provide direction and guidance to areas of the process that may be ambiguous, unclear or contentious. Section 3 presents the Portable Process Roles, which should be viewed as a minimum required set of roles and responsibilities needed for the smooth functioning of the associated process. Section 4 presents the Portable Process Flow as a high-level view of how the various subprocesses are expected to flow into and depend on one another. The sub-processes are also described in brief along with their expected output and/or completion criteria. Appendix C offers guidelines for Process Localization in the use of this standard. Localization is mandatory to provide the level of detail required to implement this standard. Suggested Only Sections of Standard Section 5 presents suggested Common Process Metrics, which are intended to provide useful measurement of process effectiveness and efficiency, as well as aid in strategic decision support. Section 6 presents suggested Standard Process Parameters, which are important for aiding in classification, categorization and prioritization of process objects, states and procedures. Appendix B provides suggested Standard Parameter Allowable Values that align with the suggested process parameters from section 6. Appendices Appendix A outlines the Process Variances from the previous OPS Process Guides. 1.1 Purpose of the Standard The purpose of these new standard guides is to define a baseline for ITSM process adoption across the OPS, which establishes the key areas where there must be alignment and consistency of adoption. In addition, it is expected that streamlined processes will facilitate and accelerate their adoption. The existing "OPS ITSM Process Guides" which were developed in 1999 with some revision in 2001, were used as the starting point for developing the portable guides. With the government's increased priority on horizontality and inter-jurisdictional service delivery, organizations need to be quicker and more agile. Ensuring repeatable, consistent processes for end-to-end service delivery and support is an essential goal for I & IT contributing to the overall goals of innovation, effectiveness and efficiency. The continued expansion of common infrastructure services as well as service partners in the supply chain reinforces the need for consistency. The degree of adoption as well as localization of the existing process guides across the OPS have been varied as determined by the readiness assessment conducted through the Service Desk initiative. There is a recognition that the level at which the processes need to be consistent is not necessarily at the level of detail offered in the 2001 guides, but at a higher, "portable" level. 5

1.1.1 Scope of Standard The mandatory sections of this standard are as follows: Section 2: Common Process Principles Section 3: Portable Process Roles Section 4: Process Flow Appendix C: Process Localization Guidelines With the exception of Component Category as defined in the Terminology Reference Model, Section 5 and 6 (and related appendix B) are suggested only at this time. The Standard Process Parameters for Component Category are described in detail in the GO-ITS 44 ITSM Terminology Reference Model Portable Guide. Any Information related to tools that support or implement the standard is considered outside the scope of this standard. 1.2 Process Definition Configuration Management is a process that underpins and enhances the effectiveness of other ITSM processes. It is used to identify and control Configuration Items (CIs) in the IT infrastructure, to record and report the status and relationship information of CIs as well as to conduct periodic audits to verify accuracy and completeness of CI data. 1.2.1 Process Focus & Goals The purpose of Configuration Management is to provide accurate information about CIs to other ITSM processes, implement configuration control on CIs, and facilitate adherence to legal obligations and organization security, as well as aid Financial Management and Continuity Management. This contributes to efficiency and effectiveness in IT Support. The goals of this process are: Account for all IT service delivery assets (CIs) and attributes that exist within the organization Verification of CIs with respect to how they are recorded in CMDB via Audits Provide accurate CI information including dependencies and relationships to other ITSM processes 6

1.2.2 Scope of Configuration Management The following table illustrates what IS and IS NOT in scope of Configuration Management process: IS Identification: Select and identify the configuration structures for all managed CIs, including their owner, their interrelationships and configuration documentation. This includes allocating identifiers and version numbers for CIs, labeling each item, and entering it on the Configuration Management Database (CMDB) Control: Ensuring that only authorized and identifiable CIs are accepted and recorded, from receipt to disposal. It ensures that no CI is added, modified, replaced or removed without appropriate controlling documentation, e.g. an approved Change request, and an updated specification Status accounting: The reporting of all the current and historical data concerned with each CI throughout its life cycle. This enables Changes to CIs and their records to be traceable, e.g. tracking the status of a CI as it changes from one state to another for instance under development, being tested, live, or withdrawn Verification and audit: A series of reviews and audits that verify the physical existence of CIs and check that they are correctly recorded in the Configuration Management system IS NOT Maintaining a document management database. The physical documents are stored and maintained by their owners Control of components that are under development and CIs the organization has elected not to control. These are not under the control of the ITSM Change Management process Depreciation accounting (Covered in Asset Management under accounting practice). Tracking the costs, contracts and financial status of during the lifecycle 1.2.3 Value to Organization Benefits Risk Reduction Decisions based on accurate information provided by Configuration Management reduce unanticipated downtime. Appropriate authorization requirement to make changes to the IT infrastructure / CMDB increases security and reduces the risk of uncontrolled environment changes. Cost Reduction Faster, simpler, more thorough identification of CIs, their attributes and their relationships by other processes. Multiple ITSM processes depend on information provided by Configuration Management duplication of this effort is avoided in these processes. Configuration Management also facilitates adherence to legal obligations and aids budgeting and financial planning. CMDB provides a platform to initiate CI standardization which leads to substantial reduction in support costs. Service Agility Improvement A clear understanding of how CIs participate in provisioning IT Services enables IT organizations to react quickly to changing business needs and a lesser time to market. This reduces the time to enhance range of Services offered as well as the time to market. 7

Service Quality Improvement Providing a facility for storage and retrieval of documented customer expectations makes it easy to compare and improve actual service delivery. Quality improvement also results from support provided to Incident and Service Request, Problem, Continuity, Change, Release and Security Management. Improved information management enables IT organizations to monitor SLAs and maintenance contracts with greater precision. Retrieved data can be sorted, summarized, and reported in whatever manner makes sense. Following up on reported data ( drill down ) is facilitated. 1.2.4 Basic Concepts The Configuration Management process ensures that only authorized CIs are released to production and manages and controls the revision of all managed components of the IT infrastructure. CIs managed by this process include hardware items, software components and object code, network items, selected documentation and any other elements within the IT infrastructure that an organization needs to control. Data is stored in a logical entity (CMDB) that typically consists of multiple distinct databases. The Configuration Management Process identifies components as CIs before they are released to production when still under development or planning. A pre-production status is used to identify these CIs. When the time comes for releasing these CIs to production, an RFC is raised against these CIs. Once these CIs are released to production, their status is updated to reflect the new in-production status. Configuration Management begins with the development of a Configuration Management Plan that addresses the definition of the scope and depth of the IT infrastructure that needs to be covered. There is a critical balance that needs to be struck - since these parameters set limits on what level of information is made available to related processes on the one hand and impact the effort and resources required to consistently maintain the CMDB to an acceptable level of quality, on the other. This planning is followed up with the identification, labeling, naming of individual configuration items and their attributes and relationships with other CIs. Configuration Management maintains the status of a CI (i.e. functional / administrative status, relationships, etc.) It includes links to documentation related to that CI. It creates, maintains, tracks, controls and reports on information that enhances the ability of other supporting processes to be effective, especially the Change, Problem and Release Management process. Configuration Management includes Verification and audit which may be executed using discovery tools to automatically scan specific infrastructure components and to produce CI discrepancy reports based on a match against the data in the CMDB. An organization that has implemented Configuration Management would use this to complete the verification activity. Organizations that have not implemented a Configuration Management process may choose to use the reactive process of configuration monitoring to populate the CMDB with infrastructure changes that occur on a daily basis. The management and control of CIs may be executed at different organizational levels (e.g., 8

the Enterprise Level, the Workgroup Level, etc.). This enables the autonomy of CIs at the Workgroup level while still providing for consistency of CIs at an Enterprise level in the CMDB. For instance, if too many CIs are controlled at the Enterprise level, the process will quickly become unmanageable and an unacceptable amount of bureaucracy may develop. Alternatively, if too much control is pushed to the Workgroup level, this may result in a loss of completeness and integrity required at the Enterprise level. Hence, there is a need to separate those CIs that must be managed at an Enterprise level from those that can be managed at a Workgroup level. Input to the Configuration Management process may include: Change Records & Work Orders Component Usage & Performance data CI Status data Cost data Service data Incident and Problem Records Outputs from this process include: Up to date CI information & relationship data Configuration baselines Management information Configuration Management performance reports 9

1.3 Recommended Versioning and/or Change Management 1.3.1 ITSM Process Governance and Ownership On-going ownership and responsibility for maintenance and evolution of the OPS portable guides resides with the Office of the Corporate Chief Technology Officer OCCTO, IT Services and Change Management Branch. For further information, please contact: Head of ITSM Strategies and Change Management Branch Office of the Chief Technology Officer 77 Wellesley Street West, 8th floor (416) 325-4240 10

1.4 Contact Information Contact 1 Contact 2 Name Head Manager, ITSM Organization/ Ministry MBS MBS Division OCCTO OCCTO Branch ITSM Strategies and Change Management ITSM Strategies and Change Management Section/ Unit ITSM Office Phone (416) 325-4240 (416) 212-0856 E-mail go-its@gov.on.ca go-its@gov.on.ca 1.5 Type of Standard Check One Type of Standard Implementation or Process Standards requirements or specifications, which may include best practices and guidance, for the implementation of a technology or the performance of an activity related to the use of technology, applicable throughout the provincial government. (e.g. mandatory O/S configuration requirements, security procedures, change management procedures, web page design requirements etc.). Information Standard specifications for a data format (e.g. XML schema, metadata, and/or related data models) Technical Standard - networking and communications specifications, protocols, interfaces (API s) (e.g. standards adopted from recognized standards development organizations such as W3C, OASIS or IETF such as TCP/IP, XML, SOAP, etc.) Architecture Standard application patterns, architecture and standards principles governing the design and technology decisions for the development of major enterprise applications Product Standard an enterprise-wide product which is mandatory for use such as a single corporate-wide application, which all ministries and agencies use to record and access their HR information. 1.6 Publication Please indicate if this standard should be restricted to publishing on the Internal (Intranet) IT Standards web site or whether it is intended for publishing on the public (Internet) Government of Ontario IT Standards web site. Check One Publish as Internal or External Internal Standard External Standard 11

1.7 Acknowledgements 1.7.1 Development Team Name Cluster/Ministry Branch Norm Watt Lorrie MacKinnon Ali Ajellu Binh Lu Selena Leung MBS MBS MBS MBS MBS Infrastructure Development and Deployment Branch ITS & Change Management Branch ITS & Change Management Branch ITS & Change Management Branch Infrastructure Development and Deployment Branch Mohamed El-Deeb MBS Consultant to Infrastructure Ryan Rossman Rick Guyatt MBS MBS Infrastructure Development and Deployment Branch Infrastructure Development and Deployment Branch 1.7.2 Reviewers Check Area Date: (month/year) Technical Standards Unit, Corporate Architecture Branch, OCCTO July 2004 Corporate Architecture Branch (CAB Architects), OCCTO Infrastructure Development Branch & iserv, OCCSD April 2004 Corporate Security Branch, OCCS Strategy, Policy, Planning and Management Branch (SPPM, OCCS) Corporate ACT and Domain Working Groups Sept 2004 Information Architecture Domain (IADWG) Technology Architecture Domain (TADWG) Application Architecture Domain (AADWG) Security Architecture Working Group (SAWG) Cluster ACT/ARB (for cluster standards promoted to corporate standards) ITSC members July/Aug 04 Others (named below) 12

Name Cluster/Ministry Branch Maria Ritchie IJ Infrastructure Support Branch Michael Oas IJ Consultant to IJ Darrell Bengert CAC Enterprise Technology Solutions Tony Condello HSC Technology Management Branch Wynann Rose TC IT Service Management Rick Morasch CSC Information Technology and Services Ron Brittain EBC Information & Technology Management Branch Jerry Sanford LRC Client Services Jim MacPherson EBC Consultant to ESDI 13

2 Common Process Principles Configuration Management IT organizations define principles to guide the design and delivery of services to customers or users. Principles can be common that is they apply to all functions and groups - or local and apply specifically to a specific function or group. The absence of well-defined common principles may result in processes that are neither aligned with customer expectations nor with the standards set for delivery of service. Common principles for the OPS are listed below. Principle 1: The Configuration Management Database (CMDB) represents the current known-state of the IT environment. Rationale: Ensures all authorized CIs are under Configuration Management control Enables the Change Management Process to determine the impact to the IT environment for each proposed change Supports and enhances the Incident, Problem, Change, Configuration, Operations and Release Management processes via the use of the CMDB Implications: The level of detail of the Configuration Management Database will need to be determined by business needs and the cost (efforts) of maintaining the information Without effective automated discovery tools, certain aspects of building and maintaining the Configuration Management Database(s) become very difficult CI relationship matrices need to be developed and maintained Different types and levels of training will be required for ITSM process roles, especially around CMDB usage Principle 2: Each CI has an owner who is responsible for keeping the CI information accurate and current. Rationale: Accurate and current CI information is made available 14

Ensures that only authorized changes can be made to the CMDB Clear accountability Implications: The CI Owner needs to be notified of all changes made to the owned CIs All CI owners, including external service providers, will adhere to the Configuration Management process Access policies are required for the CMDB to control what can be changed and who can change it Principle 3: Each component (CI in the CMDB) is identifiable by its location, name and relationships to enable the proper management of the environment as a whole. Rationale: All CIs will be easily identified and located and the environment is better controlled Verification and audits are facilitated Unsupported CIs can be readily identified Implications: Standard CI naming convention needs to be developed, implemented and adhered to CIs need to be labeled Relationship information, such as parent/child, needs to be recorded and tracked For software items and associated documentation, a Definitive Software Library (DSL) needs to be developed and managed by the Release Management process Principle 4: A formal CMDB audit is conducted at least once a year. Rationale: Ensures that the CMDB matches closely to the IT environment Ensures high level of process compliance Implications: Resources are required to perform the audits Automated audit tools are needed to enable checks to be made at regular intervals 15

since manual operation is likely to be error prone especially when the volume of CIs is high Physical audits require travel and physical access to the equipment Principle 5: All Service Providers will fulfill their roles in compliance with the OPS Configuration Management process. Rationale: Ensures consistency Service providers can play key roles in the process Service providers own configuration items Implications: Process provisions will apply to internal and external service providers Contracts with service providers must reflect the Configuration Management activities, tasks and linkages associated with their role Principle 6: Any changes to CIs tracked in the CMDB must adhere to the Change Management Process. Rationale: Ensures control of all CIs in scope Ensures currency and accuracy of CMDB data Implications: Required integration with the Change Management & Release Management Processes Significant analysis and planning are required to reach an informed decision on the scope & depth of tracked CI data 16

3 Portable Process Roles Each process has specific roles with defined responsibilities for process design, development, execution and management. In an organization, one person can take on multiple roles as per the requirements specific to the organization. This person may choose to delegate these responsibilities to those lower in the hierarchy. Additionally, responsibilities of one role could be mapped to multiple individuals. Regardless of specific organizational mapping, specific portable roles are necessary for the proper operation & management of the process. These roles are required at the Enterprise level and may also be applied at local levels of Configuration Management. This section lists these roles and their responsibilities. In addition to process roles, service-specific roles may be defined as part of the management and governance structure for a specific service. Other roles will also be involved in the Configuration Management process activities, including other ITSM process roles, operations, and service providers. One role is accountable for each process activity. The role may assign one or more people who are responsible to carry out the task. However, it is ultimately the job of the person who is accountable to ensure that the job gets done. Legend: Responsible, Accountable, Consult Before, Inform After Sub-Process Configuration Manager Configuration Coordinator CI Owner 4.1 - Identify Configuration Items A R R 4.2 - Monitor & Verify CMDB A R I 4.3 - Control & Maintain CMDB A R I 4.4 - Audit CMDB A R C / I 3.1 Configuration Management Process Owner The Process Owner owns the process and the supporting documentation for the process. The Process Owner provides process leadership to the IT organization by overseeing the process and ensuring that the process is followed by the organization. When the process isn't being followed or isn't working well, the Process Owner is responsible for identifying why and ensuring that required actions are taken to correct the situation. In addition, the Process Owner is responsible for the approval of all proposed changes to the process, and development of process improvement plans. If the organization does not require the separation of roles (Process Owner and Process Manager), responsibilities listed below should be merged with that of the Configuration Manager role that follows. 17

Responsibilities Ensures that the process is defined, documented, maintained & communicated at a Enterprise and local level Reviews effectiveness and efficiency of the Configuration Management process and Identify opportunities for process improvement Is responsible for the success or failure of the process and has the authority to represent management on common process definition decisions Defines and develops Configuration Management process common metrics and reporting requirements Ensures Configuration Management processes and tools integrate with other ITSM processes Is responsible for the requirement and guidelines of the Configuration Management tool usage Ensures organizational adherence to the process Ensures adequate process training is available for the organization Manages changes to the process within a defined governance framework. This includes reviewing and approving all proposed changes and communicating changes to all the participants and affected areas 3.2 Configuration Manager The Configuration Manager is directly responsible for core process deliverables. In the situation where the activities have been split among a Configuration Manager and Configuration Management Process Owner, the Configuration Manager takes on direct accountability for the day-to-day management of the process and acts as the escalation point for the business users. Responsibilities Ensures that unauthorized CI changes are identified and acted upon Escalates to Change Management on unauthorized CI changes or alterations to environment not reflected in CMDB Ensures integrity, accuracy and completeness of the CMDB Supports effective use of CMDB for other groups and processes Requests Change Management report metrics in support of the Configuration Management process Produces Configuration Management process metric reports 18

Participates in Change Management process evaluation Approves structural changes to the CMDB Defines access privileges to CMDB Monitors Configuration Management process activities and ensures that audits are performed Develops, owns and manages the Configuration Management Plan 3.3 Configuration Coordinator / Administrator The Configuration Coordinator is focused on managing and maintaining the Configuration Management System and the Configuration Management Database (CMDB). Responsibilities Properly identifies and accurately registers CIs Identifies unauthorized CI changes, escalates non-compliance issues to Configuration Management Creates reports and analyses the CMDB when requested by the Configuration Manager Ensures authorized procedures and work practices are followed Supports the effective use of the Configuration Management System & database Maintains and recommends improvements to facilitate effective use and integrity of the CMDB Monitors, verifies and participates in auditing CMDB data Participates in the evaluation of the Configuration Management process 3.4 Configuration Item Owner The Configuration Item Owner is anyone who owns (develops, supplies or supports) a configuration item that will be included in the Computing Environment. This includes Application Development, Database and Infrastructure projects. The CI Owners are the owners of the CI in the CMDB and are measured on the reliability, availability and performance of the CI. Responsibilities Properly identifies and accurately registers Cis Maintain the integrity of the relationships of their CIs Provides additional information regarding the change when requested by the Configuration Manager/Coordinator 19

4 Process Flow 4.1 Configuration Management Portable Process Flow Configuration Management Process Overview Change Coordinator CI Update Information Configuration Coordinator Configuration Manager Configuration Management Plan 4.1 Identify Configuration Items 4.2 Monitor and Verify CMDB 4.3 Control and Maintain CMDB 4.4 Audit CMDB Other ITSM Process Roles CMDB Query Figure 1: Configuration Management Process Overview No. Sub-Process Input / Trigger Description Output / Completion criteria 4.1 Identify Configuration Items Input: Configuration Management Plan, CI Requirements Discovery Tools Identification and labeling of CIs to the granularity required often to the extent of an independently manageable change Identification & recording of CI relationships CI Owners Identified and Assigned to Each CI, New CIs registered, Updated Configuration Management Plan 4.2 Monitor and Verify CMDB Input: Auto-discovery Tools, List of CIs to be monitored Recording of authorized and identifiable CIs in the CMDB upon receipt. Updating of administrative and functional status and relationship information of CIs Ongoing verification of CMDB data. Warning to Offender, Actions to be taken to ensure Process compliance, Corrective Action Plan to Reconcile CI, Updated CMDB 4.3 Control and Maintain CMDB Trigger: Notification of Approved RFCs CMDB Data, List of Completed RFCs and Associated CIs, Input: Verified Discrepancies Control on individual CIs through Change Management Interface 20 CMDB Updated by new / modified CIs, Defunct CIs removed

No. Sub-Process Input / Trigger Description Output / Completion criteria 4.4 Audit CMDB Trigger: Audit Schedule Input: Configuration Management Plan, CMDB Data, Auto- Discovery Tools, Assigned Actions on corrective measures (from Change Management) Verification of CI with that recorded in the CMDB Final Configuration Management audit Report distributed within organization, Updated configuration Management Plan 4.2 Configuration Management Process Quality Control In parallel to the execution of the Configuration Management process, there are activities related to the management of the process to control quality as well as to ensure that the process is both effective and efficient. Monitoring of the service delivered by the Configuration Management team is performed regularly by the Configuration Manager. This allows the Configuration Manager to answer any questions about service quality as well as ensure that the Configuration Management process is not running into resource or ownership issues. The Configuration Manager is responsible to take corrective actions if bottlenecks are identified in the process. Reporting involves measuring the process via metrics and recording how well it behaves with respect to its metrics. It provides the Configuration Management personnel with feedback on the process. It provides the Configuration Management Process Owner with the necessary information to review the process performance and initiate required improvements. Evaluating the process involves regular reviews of the performance of the process and identification of possible improvements or actions to address performance gaps. Every process is only as good as its last improvement; hence, the feedback loop of continuous improvement is inherent in every process. 21

5 Common Process Metrics Metrics are intended to provide a useful measurement of a process effectiveness and efficiency. Metrics are also required for strategic decision support. The following need careful consideration: Reporting metrics should be readily measurable (preferably automated collection and presentation of data) Metrics need to be chosen to reflect process activity (how much work is done?), process quality (how well was it done?) and process operation (to review and plan job on hand). Depending upon the needs of the organization, metrics can be classified as hard (must have) or soft (desirable) Hard metrics will be common across an organization The following common metrics are suggested for the Configuration Management process: Number and percentage of CI discrepancies Number and percentage of CIs tracked within the CMDB Number and percentage of CIs added/deleted by category Percentage of CI s with stale audit dates Total configuration management effort in person-hours 22

6 Standard Process Parameters Parameters used for the categorization and definitions of CIs require a certain level of standardization across OPS. Special attention needs to be given to parameters related to consistency of reporting. This is particularly important for the provision of reliable business intelligence. Component Category (formerly Product Category) is a parameter used across Incident, Problem, Change and Configuration Management. To ensure consistency of meaning and usage it has been defined in the Terminology Reference Model. Please refer to the Classification Model section of the GO-ITS 44 ITSM Terminology Reference Model Portable Guide for standard process parameters and allowable values for Component Category. See Appendix B for draft Standard Process Parameter Allowable Values. 23

Errata Created: February 27, 2004 Updated: August 9, 2004 Updated: September 21, 2004 Approved by the Architecture Review Board (ARB) as a Government of Ontario Information Technology Standard (GO-ITS). Version number reset to 1.0 for approved this approved version. 24

Document Numbering Document No: GO-ITS 36 Title: Configuration Management OPS Portable Process Guide Month Year: September 2004 Doc. Type: Microsoft Document File Name: GO-ITS 36 Configuration Management Portable Guide V1.0.doc 25

Copyright Queen's Printer for Ontario 2004. 26

Same Modified New Removed GO-ITS 36 Status: Approved Version 1.1 Appendix A. Process Variances from OPS V2.3 Process Guides The following tables provide the detail of the specific variances from the previous OPS guides with respect to principles, roles and responsibilities, and process flow. As noted in the introduction, the purpose of these new guides is to provide the portable elements needed to be common across the OPS. As such, some principles, responsibilities, and aspects of the process flow were too specific to apply across the OPS. Table 1 - Configuration Management Principles Portable Process Guide (2004) OPS Standard Process Guide (2001) Explanation Principle No. Section No. Policy No. 1 5.2 1 X Refers to IT environment instead of Production environment 2 X Added for clarity 3 5.10 1 X Made more concise with respect to CI requirements 4 X ITSM best practice 5 5.15 1,2 X This Principle replaces all External Contractor & Service Provider policies 6 5.14 1,2,3 X This Principle replaces all release and version control policies 5.2 2 X Not required: The environment, as a whole, exists at the Enterprise Level (Federal level) of Policy. 5.3 1 X Part of Roles and Responsibilities: Release to Production is controlled by the Change / Config Manager(s), who are responsible for the reliability of the computing environment and who will enforce the Change and Configuration Management Process. 5.3 3 X Not required: The Configuration Management Process is controlled by the Configuration Manager. 5.4 1 X Procedural: Projects create, enhance or maintain a CI within the context of the environment, where a CI is a line item on the CMDB. 5.5 1 X Part of Release Management: CIs (Applications and Infrastructure Systems) will be developed or purchased and released in accordance with an agreed upon Standard Systems Development Lifecycle. 5.10 2 X Procedural: CIs (Applications) must be stored in a Corporate secured system, not on personal storage devices. 5.12 1 X Not required: All Releases will be activated in the Definitive Software Library, until there is no longer any possibility of a Business Unit needing to recreate the old release. 5.13 1 X Not required: All Platform Development will use the same configuration 5.15 1 X Part of Release Management: All External Contractors will supply versioned documentation that will conform to the requirements as specified in the organization System Development Lifecycle Document. 5.15 3 X Unenforceable: All External Contractors who own CIs will have an organizational resource also assigned to the CI to ensure the contractor follows the process. * PLEASE NOTE: In the OPS Standard Process Guides (2001), policies were not originally numbered. To identify them for comparison, they have been assigned numbers here according to the order in which they appear in their section of the Guide.

Same Modified New Removed GO-ITS 36 Status: Approved Version 1.1 Table 2 - Configuration Management Roles Portable Process Guide (2004) OPS Standard Process Guide (2001) Explanation Role Section No. Role Configuration Management Process Owner Configuration Manager Configuration Coordinator / Administrator 3.1.4 4.3 4.4 4.6 4.8 CI Owner 4.9 4.10 Process Owner Configuration Manager - Enterprise Level Configuration Manager - CI Level Configuration Co-ordinator (Optional) Business Unit Manager Service Providers Operations / Production Control Function X X X X X X Added to clearly reflect the responsibilities around process definition, support and evolution Previously roles at Enterprise and CI level were identified separately Additional responsibilities: - Ensure that (annual) audits are performed Removed responsibilities: - Authorizes move of CI to the Definitive Software Library for Release to Production; - Ensures all components relative to IT Service Levels are registered; No longer an optional role. Additional responsibilities: - Identify unauthorized CI changes, escalate non-compliance issues to Configuration Management - Maintain and recommend improvements to facilitate effective use and integrity of the CMDB - Participate in auditing CMDB data Removed responsibilities: - Maintain the Enterprise configuration CI dependency matrix database - Ensure Service Providers maintain adequate Config Mgmt Process disciplines and systems for their CIs - Review all test results against the Quality Plan Removed as not a role specific to Configuration Management CI Owner fulfills the role of Service Providers Removed as not a role specific to Configuration Management

Same Modified New Removed GO-ITS 36 Status: Approved Version 1.1 Table 3 - Configuration Management Process Portable Process Guide (2004) OPS Standard Process Guide (2001) Explanation Process (4.1) Identify Configuration Items (4.2) Monitor and Verify CMDB (4.3) Control and Maintain CMDB (4.4) Audit CMDB Section No. Process Identification of 4.2.1.1 Enterprise Configuration Items Identification of X 4.2.2.1 CI Level Configuration Items 4.2.1.2 Monitor and Verify the CMDB Monitor and X 4.2.2.2 Verify the CI Level CMS Control and 4.2.1.3 Maintain the CMDB Control and X 4.2.2.3 Maintain the CI Level CMS 4.2.1.4 Report Metrics X Removed as not required for portable guide 4.2.2.4 Report Metrics X Removed as not required for portable guide Verification 4.2.1.5 Process X Verification 4.2.2.5 Process 4.2.1.6 Evaluate Process X Removed as not required for portable guide 4.2.2.6 Evaluate Process X Removed as not required for portable guide - Process has been generalized to eliminate distinction between enterprise level CMDB and CI level CMS. - Process flow now involves Configuration Coordinator as well as Configuration Manager. - Change Coordinator provides the interface to other Processes - Process has been generalized to eliminate distinction between enterprise level CMDB and CI level CMS. - Process flow now involves Configuration Coordinator as well as Configuration Manager. - Process has been generalized to eliminate distinction between enterprise level CMDB and CI level CMS. - Process flow now involves Configuration Coordinator as well as Configuration Manager. - Change Coordinator provides the interface to other Processes - Process has been generalized to eliminate distinction between enterprise level CMDB and CI level CMS. - Process flow now involves Configuration Coordinator as well as Configuration Manager. 29

B. Standard Parameter Allowable Values Component Category It is recommended that a multi-level tree be used with the top two levels standardized across OPS and the lower levels subject to localization. Because the top level is used across Incident, Problem, Change and Configuration Management standard definitions have been defined in the Terminology Reference Model. Please refer to the Classification Model section of the GO-ITS 44 ITSM Terminology Reference Model Portable Guide for standard process parameters and allowable values for Component Category. The following are the values for the top level as per the Terminology Reference Model: Application Data Documentation Support Software Hardware Network Non-Production Environment Process Standards Facilities CI Status The following are the recommended values: Status Planned Production Out-of-Service Description The CI (or this version of it) is currently being procured, built, and/or developed and is planned to be put into the production state in the future. The CI exists and is functional within the production I&IT infrastructure. This is the normal state for most CI s in the CMDB. The CI is not working or unavailable for a prolonged period of time. (Note it is not the intention to modify the CI status for short-term service outages). Decommissioned The CI (or this version of it) is no longer supported within the production IT infrastructure. 30

C. Process Localization Guidelines Portable guide content applies to all organizations and groups within OPS. Localization involves adding group-specific information that applies to a particular organization or group. For every group, local content will focus on what s important for the particular environment. Local content is expected to evolve significantly as the processes are adopted and as more detailed requirements emerge. The Portable guide content will always apply to all localizations; the local guides are expected to be more granular and organization specific. Localization Principles ITIL & ITSM represent our reference frameworks for guidance on best practices Current practices will be considered to the extent that this does not jeopardize the long-term vision of an integrated set of ITSM processes and tools Deployment will focus on the short term but design on the long term Interrelationships with other ITSM processes will always be considered Local Process Guide Content All Portable guide content plus: Local Operational Principles, Guidelines & Standards (if required) Local Process Roles and Responsibilities Local RACI Charts Local Process Activities (such as Escalation) Local Reporting Metrics 31

Glossary A glossary of terms used in this guide is provided below: Term Asset Management Availability Availability Management Change Advisory Board (CAB) Change Advisory Board Emergency Committee (CAB/EC) Capacity Management Category Change Change Management CI (Configuration Item) Configuration Baseline Configuration Management Configuration Management Database (CMDB) Description A standard accounting process concerned with maintaining the details of assets above a specified value, including depreciation, lease agreement information, expected life, etc. Asset management does not track the relationship between assets and may not track each individual item purchased or leased as part of a bundle purchase. (For example, asset management would track the fact that 100 personal computers were purchased, but would not track the individual units.) Configuration Management would typically track the individual PCs. Ability of a component or service to perform its required function at a stated instant or over a stated period of time. Generally, availability is expressed as the availability ratio, which is the proportion of time that the service is actually available for use by the Customers within the agreed service hours. A process that focuses on understanding and managing availability requirement of the business. An advisory committee that provides expert advice to the change manager on change issues A subset of the CAB that is always available to be called upon to address urgent change issues A process that aims at ensuring that the capacity of the IT infrastructure matches current and future requirements of the business. Classification - possibly based on nature of event. Any modification addition or removal of approved, supported or base lined hardware, network, software, application, environment, system, desktop build or associated documentation. Process of implementing Changes to the infrastructure or any aspect of services, in a controlled manner, enabling approved Changes with minimum disruption to service. Component of IT infrastructure or a related item under the control of Configuration Management. A snapshot of the IT Infrastructure as recorded in the CMDB. Although the snapshot may be updated later, as changes are applied to CIs, the baseline remains unchanged and available as a reference of the original state and as a comparison against the current state. A process for identifying, recording, auditing and reporting on the CIs for accuracy and completeness. A database containing the relevant details of each CI and details of the important relationships between CIs. 32

Term Configuration Management Plan Contingency Planning Continuity Management Crises Management Customer Customer Management Definitive Hardware Store (DHS) Definitive Software Library (DSL) Disaster recovery planning End User (or User) Forward Change Schedule Impact (For Incident) Incident Incident Management IT Service Delivery KDB Known Error Maintainability Description Document describing the organization and procedures for the Configuration Management of a specific project, product, system, support group or service. The preparation to address unwanted occurrences that may happen at a later time. Usually, the term has been used to refer to planning for the recovery of IT systems rather than entire business processes. A process that supports the Business Continuity process to ensure that IT Services are recovered within agreed time scale. An occurrence and / or perception that threatens the operations, staff, shareholder value, stakeholders, brand, reputation, trust and / or strategic / business goals of an organization. Recipient of a service, responsible for funding the service against business requirements. Customer Management process establishes and maintains links between executive business managers and the IT services organization. Definitive Hardware Store. An area that is aside for the secure storage of definitive hardware spares. Definitive Software Library. A secure software library where all versions of accepted software configuration items (CIs) are held in their definitive, quality-controlled form. Set of processes that focus only on the recovery processes, mainly in response to the physical disasters, which are contained within BCM. The individual who uses the service on a day-to-day basis. A schedule of all approved changes and their planned implementation dates for a pre-specified period. Measure of scope and criticality to business. An event that negatively impacts the standard delivery of a service, or a service request A process that is committed to restoring normal service operations as documented in Service Level Agreements as well as processing service requests. IT Service Delivery processes (Availability Management, Capacity Management, Continuity Management, Financial Management and Service Level Management) address from a design and management perspective the service that business requires of the provider. Knowledge database. A database of solutions and workarounds that is used by front line support staff to restore normal Service operation. An incident or Problem for which the root cause is known and for which a temporary Work-around or a permanent alternative has been identified. If a business case exists, an RFC will be raised, but, in any event, it remains a known error unless it is permanently fixed by a change. Describes the ability of the Internal IT groups to maintain the services via the management of IT infrastructure components or services. Managed through OLAs. 33

Term Mean Time Between Failures (MTBF) Mean Time To Repair (MTTR) Metric Operational Level Agreement Operational Test Environment Operations Management Post Implementation Review Priority Problem Problem Management Procedure Process Process Owner Production environment RACI Matrix Release Release to Production Reliability Description Expected future performance based on the actual past performance of a population of units. Calculated as: (MTBF = total actual operating time / total number of failures). Average amount of time it takes to repair a component. MTTR typically includes time from when the unit failed until replaced, thus including hardware unavailability, response time, travel time, and on-site repair time. A measurable element of the service process or function. An internal agreement covering the delivery of services, which support the IT organization in their delivery of services. A test environment that is directly used by customers or endusers as part of the IT services they receive. A process that consists of all activities and measures necessary to enable and maintain the intended use of IT services and production environment. A review for verification of correct implementation of change by authorized personnel. Relative order in which a given event needs to be addressed. This usually depends on Impact and Urgency. An unknown underlying cause which could or has caused disruption of service. A process that minimizes the effect of errors in infrastructure / services and external events on the customers. It is a process focused on diagnosing and rectifying faults in the IT infrastructure to obtain the highest possible IT service stability. A set of specific steps that describe how an activity should be carried out, and by whom. Procedures may be supported by more detailed Work Instructions. A Process defines what is to be achieved; Procedures define how the objectives are to be achieved. A series of related activities aimed at achieving a set of objectives (or Principles) in a measurable, usually repeatable, manner. It will have defined information inputs and outputs, will consume resources and will be subject to Management controls over time, cost and quality. It will also balance benefits against risks. The Process Owner is the person involved in the project with regard to process design and / or re-engineering efforts. A subset of IT infrastructure that participates in delivery of Service. RACI diagrams are tools used to map activities to roles and define how roles contribute to an activity. A collection of new or changed CIs. The HP ITSM process, which controls the release of changes in the production IT Infrastructure. It is a component of the ITIL Release Management Process. The service or IT infrastructure Configuration Item (CI) is available when expected / as defined in the SLA. It can also be described as freedom from failure. It is expressed in terms of MTBF - average uptime. 34

Term Request for Change (RFC) Resilience Security Incidents Security Management Service achievement Service Build and Test Service Catalogue Service Delivery Service Desk Service Improvement Program Service Level Agreement (SLA) Service Level Management Service Level Objective (SLO) Service Management Service Planning Service provider Service quality plan Service Request Serviceability Description Form, or screen, used to record details of a request for a change to any CI within an infrastructure or to procedures and items associated with the infrastructure. Degree redundancy of a CI with the intent of eliminating single points of failure in the infrastructure. Security incidents are those events that cause damage to confidentiality, integrity or availability of information or information processing and materialize as accidents or deliberate acts. Security Management is the process of managing a defined level of security on information and IT services, in addition to managing the response and effect of security incidents. The actual service levels delivered by the IT organization to a customer within a defined life span. Service Build & Test process develops, tests and documents new Services and enhancements & fixes to an existing Service. Written statement of IT services, default levels and options. Processes that address Service Management from a design and management perspective. Single point of contact between Service Provider and the users of the Service. A formal project undertaken within an organization to identify and introduce measurable improvements within a specified work area or work process. Written agreement between a service provider and the Customer(s), that documents agreed Service Levels for a Service. The scope of an SLA covers the target environment to be serviced, specific IT service deliverables, service functionality, service coverage (e.g., level, hours, availability, responsiveness, restrictions, authorizations, etc.), security policies, and cost of the services being provided. A process that defines Service levels agreed with customer and subsequently manages at an acceptable cost. A defined target for a service metric, usually specified in an SLA. Management of Services to meet the Customer's requirements. The Service Planning process designs, develops and controls Service Plan required for service development. This plan will describe scope, functional requirements and required components for service implementation that aids in determination of service ROI along with decisions like Buy Vs Build. Third-party organization supplying services or products to customers. The written plan and specification of internal targets designed to guarantee the agreed service levels. Every Incident not being a failure in the IT Infrastructure, such as requesting information or moving equipment. Describes the external contracts or Underpinning Contracts (UCs) that exist with suppliers that are required to deliver 35

Term service. Description Services Underpinning contract Urgency User Workaround Workgroup The deliverables of the IT Services organization as perceived by the Customers; the services do not consist merely of making computer resources available for customers to use. A contract with an external supplier covering delivery of services that support the IT organization in their delivery of services. Measures how quickly an event needs to be addressed. Person who uses services on a day-to-day basis. Restoring service by application of temporary fix or routing service to the customer via another channel. An organizational or logical unit of individuals with similar specialization and responsibilities 36

References OPS Standard Change & Configuration Management Process Guide version 2.3 (last updated in March, 2001). 37