What is a Configuration Management OPS document?

(1)

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

(2)

– –

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.

(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

cross-jurisdictional service management. This document is organized as follows:

(5)

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 sub-processes are expected to flow into and depend on one another. The sub-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

(6)

– –

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

(7)

1.2.2 Scope of Configuration Management

The following table illustrates what IS and IS NOT in scope of Configuration Management process:

IS IS NOT

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)

Maintaining a document management database. The physical documents are stored and maintained by their owners

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

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

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”

Depreciation accounting (Covered in Asset Management under accounting practice). Tracking the costs, contracts and financial status of during the lifecycle

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

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.

(8)

– – 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.

(9)

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

(10)

– –

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

(11)

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 [email protected] [email protected]

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

(12)

– –

1.7 Acknowledgements

1.7.1 Development Team

Name Cluster/Ministry Branch

Norm Watt MBS Infrastructure Development and

Deployment Branch

Lorrie MacKinnon MBS ITS & Change Management

Branch

Ali Ajellu MBS ITS & Change Management

Branch

Binh Lu MBS ITS & Change Management

Branch

Selena Leung MBS Infrastructure Development and

Deployment Branch Mohamed El-Deeb MBS Consultant to Infrastructure

Ryan Rossman MBS Infrastructure Development and

Deployment Branch

Rick Guyatt MBS 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

(13)

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

(14)

– –

Configuration Management

2 Common Process Principles

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:

(15)

 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:

(16)

– –

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

(17)

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

(18)

– – 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

(19)

 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).

 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.

 Properly identifies and accurately registers Cis

 Maintain the integrity of the relationships of their CIs

(20)

– –

4 Process Flow

4.1 Configuration Management Portable Process Flow

Configuration Management Process Overview

Change Coordinator Configuration Coordinator Configuration Manager 4.2 Monitor and Verify CMDB 4.3 Control and Maintain CMDB 4.4 Audit CMDB 4.1 Identify Configuration Items Other ITSM Process Roles CMDB Query CI Update Information Configuration Management Plan

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

CMDB Updated by new / modified CIs, Defunct CIs

(21)

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.

(22)

– –

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

(23)

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.

(24)

– –

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.

(25)

Document Numbering

Document No: GO-ITS 36

Title: Configuration Management OPS Portable Process Guide

Month Year: September 2004

Doc. Type: Microsoft Document

(26)

– –

Copyright

(27)

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) Sa m e M od ifi e d New Rem ov e d 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.

(28)

Table 2 - Configuration Management Roles

Portable Process Guide (2004)

OPS Standard Process Guide (2001) Sa m e M od ifi e d New Rem ov e d _Explanation

Role Section No. Role

Configuration Management Process Owner

3.1.4 Process

Owner X

Added to clearly reflect the responsibilities around process definition, support and evolution

Configuration Manager 4.3 Configuration Manager - Enterprise Level X

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;

4.4 Configuration Manager - CI Level Configuration Coordinator / Administrator 4.6 Configuration Co-ordinator (Optional) X

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 4.8 Business Unit

Manager X

Removed as not a role specific to Configuration Management

CI Owner 4.9 Service

Providers X

CI Owner fulfills the role of Service Providers

4.10 Operations / Production Control Function X

(29)

Table 3 - Configuration Management Process

Portable Process Guide (2004)

OPS Standard Process Guide (2001) Sa m e M od ifi e d New Rem ov e d Explanation Process Section No. Process (4.1) Identify Configuration Items 4.2.1.1 Identification of Enterprise Configuration Items X

- 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

4.2.2.1 Identification of CI Level Configuration Items (4.2) Monitor and Verify CMDB 4.2.1.2 Monitor and Verify the CMDB X

- Process flow now involves Configuration Coordinator as well as Configuration Manager. 4.2.2.2 Monitor and Verify the CI Level CMS (4.3) Control and Maintain CMDB 4.2.1.3 Control and Maintain the CMDB X

- Process flow now involves Configuration Coordinator as well as Configuration Manager. - Change Coordinator provides the interface to other Processes

4.2.2.3

Control and 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

(4.4) Audit CMDB

4.2.1.5 Verification Process

X

- Process flow now involves Configuration Coordinator as well as Configuration Manager. 4.2.2.5 Verification

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

(30)

– –

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 Description

Planned 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.

Production The CI exists and is functional within the production I&IT

infrastructure. This is the “normal” state for most CI’s in the CMDB.

Out-of-Service 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

(31)

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)

(32)

– –

Glossary

A glossary of terms used in this guide is provided below:

Term Description

Asset Management _{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.

Availability _{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.

Availability Management _{A process that focuses on understanding and managing} availability requirement of the business.

Change Advisory Board (CAB) An advisory committee that provides expert advice to the change manager on change issues

Change Advisory Board Emergency Committee (CAB/EC)

A subset of the CAB that is always available to be called upon to address urgent change issues

Capacity Management _{A process that aims at ensuring that the capacity of the IT} infrastructure matches current and future requirements of the business.

Category _{Classification - possibly based on nature of event.}

Change _{Any modification – addition or removal of approved, supported} or base lined hardware, network, software, application, environment, system, desktop build or associated documentation.

Change Management _{Process of implementing Changes to the infrastructure or any} aspect of services, in a controlled manner, enabling approved Changes with minimum disruption to service.

CI (Configuration Item) _{Component of IT infrastructure or a related item under the} control of Configuration Management.

Configuration Baseline _{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.

Configuration Management _{A process for identifying, recording, auditing and reporting on} the CIs for accuracy and completeness.

Configuration Management

(33)

Term Description Configuration Management

Plan Document describing the organization and procedures for the _{Configuration Management of a specific project, product,} system, support group or service.

Contingency Planning _{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.

Continuity Management _{A process that supports the Business Continuity process to} ensure that IT Services are recovered within agreed time scale. Crises Management _{An occurrence and / or perception that threatens the}

operations, staff, shareholder value, stakeholders, brand, reputation, trust and / or strategic / business goals of an organization.

Customer _{Recipient of a service, responsible for funding the service} against business requirements.

Customer Management _{Customer Management process establishes and maintains} links between executive business managers and the IT services organization.

Definitive Hardware Store

(DHS) Definitive Hardware Store. An area that is aside for the secure _{storage of definitive hardware spares.} Definitive Software Library

(DSL) Definitive Software Library. A secure software library where all _{versions of accepted software configuration items (CIs) are} held in their definitive, quality-controlled form.

Disaster recovery planning _{Set of processes that focus only on the recovery processes,} mainly in response to the physical disasters, which are contained within BCM.

End User (or User) _{The individual who uses the service on a day-to-day basis.}

Forward Change Schedule _{A schedule of all approved changes and their planned} implementation dates for a pre-specified period. Impact (For Incident) _{Measure of scope and criticality to business.}

Incident _{An event that negatively impacts the standard delivery of a} service, or a service request

Incident Management _{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 _{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.

KDB _{Knowledge database. A database of solutions and}

workarounds that is used by front line support staff to restore normal Service operation.

Known Error _{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.

Maintainability _{Describes the ability of the Internal IT groups to maintain the} services via the management of IT infrastructure components

(34)

– –

Term Description

Mean Time Between Failures

(MTBF) 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).

Mean Time To Repair

(MTTR) 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.

Metric _{A measurable element of the service process or function.} Operational Level Agreement _{An internal agreement covering the delivery of services, which}

support the IT organization in their delivery of services. Operational Test Environment _{A test environment that is directly used by customers or}

end-users as part of the IT services they receive.

Operations Management _{A process that consists of all activities and measures} necessary to enable and maintain the intended use of IT services and production environment.

Post Implementation Review _{A review for verification of correct implementation of change by} authorized personnel.

Priority _{Relative order in which a given event needs to be addressed.} This usually depends on Impact and Urgency.

Problem _{An unknown underlying cause which could or has caused} disruption of service.

Problem Management _{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. Procedure _{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.

Process _{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.

Process Owner _{The Process Owner is the person involved in the project with} regard to process design and / or re-engineering efforts. Production environment _{A subset of IT infrastructure that participates in delivery of}

Service.

RACI Matrix _{RACI diagrams are tools used to map activities to roles and} define how roles contribute to an activity.

Release _{A collection of new or changed CIs.}

Release to Production _{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.

Reliability _{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.

(35)

Term Description

Request for Change (RFC) _{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.

Resilience _{Degree redundancy of a CI with the intent of eliminating single} points of failure in the infrastructure.

Security Incidents _{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 _{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. Service achievement _{The actual service levels delivered by the IT organization to a}

customer within a defined life span.

Service Build and Test _{Service Build & Test process develops, tests and documents} new Services and enhancements & fixes to an existing Service. Service Catalogue _{Written statement of IT services, default levels and options.}

Service Delivery _{Processes that address Service Management from a design} and management perspective.

Service Desk _{Single point of contact between Service Provider and the users} of the Service.

Service Improvement Program A formal project undertaken within an organization to identify and introduce measurable improvements within a specified work area or work process.

Service Level Agreement

(SLA) 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.

Service Level Management _{A process that defines Service levels agreed with customer and} subsequently manages at an acceptable cost.

Service Level Objective (SLO) A defined target for a service metric, usually specified in an SLA.

Service Management _{Management of Services to meet the Customer's requirements.}

Service Planning _{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”.

Service provider _{Third-party organization supplying services or products to} customers.

Service quality plan _{The written plan and specification of internal targets designed} to guarantee the agreed service levels.

Service Request _{Every Incident not being a failure in the IT Infrastructure, such} as requesting information or moving equipment.

(36)

– –

Term Description

service.

Services _{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.

Underpinning contract _{A contract with an external supplier covering delivery of} services that support the IT organization in their delivery of services.

Urgency _{Measures how quickly an event needs to be addressed.}

User _{Person who uses services on a day-to-day basis.}

Workaround _{Restoring service by application of temporary fix or routing} service to the customer via another channel.

Workgroup _{An organizational or logical unit of individuals with similar} specialization and responsibilities

(37)

References

 OPS Standard Change & Configuration Management Process Guide version 2.3 (last

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

Foreword

Table Of Contents

Introduction

1 Introduction to the Portable Process Guides

1.1 Purpose of the Standard

1.1.1 Scope of Standard

1.2 Process Definition

1.2.1 Process Focus & Goals

1.2.2 Scope of Configuration Management

1.2.3 Value to Organization

1.2.4 Basic Concepts

1.3 Recommended Versioning and/or Change Management

1.3.1 ITSM Process Governance and Ownership

1.4 Contact Information

1.5 Type of Standard

1.6 Publication

1.7 Acknowledgements

1.7.1 Development Team

1.7.2 Reviewers

Configuration Management

2 Common Process Principles

3 Portable Process Roles

3.1 Configuration Management Process Owner

3.2 Configuration Manager

3.3 Configuration Coordinator / Administrator

3.4 Configuration Item Owner

4 Process Flow

4.1 Configuration Management Portable Process Flow

4.2 Configuration Management Process Quality Control

5 Common Process Metrics

6 Standard Process Parameters

Errata

Document Numbering

Copyright

Appendix

A. Process Variances from OPS V2.3 Process Guides

B. Standard Parameter Allowable Values

C. Process Localization Guidelines

Glossary

References