{ Service Asset and Configuration Management Design Package }

29 September 2014

version 1

• Ensure that assets under the control of the IT organization are identified, controlled and properly cared for throughout their lifecycle.
• Identify, control, record, report, audit and verify services and other configuration items (CIs), including versions, baselines, constituent components, their attributes and relationships.
• Account for, manage and protect the access to and integrity of CIs through the service lifecycle by working with change management to ensure that only authorized components are used and only authorized changes are made.
• Ensure the integrity of CIs and configurations required to control the services by establishing and maintaining an accurate and complete configuration management system (CMS).
• Maintain accurate configuration information on the historical, planned and current state of services and other CIs.
• Support efficient and effective service management processes by providing accurate configuration information to enable people to make decisions at the right time

{ Process Objectives }

1. Identify CIs at the level at which it is appropriate to determine that something is a CI and what to manage/record/capture within any individual CI type or category
2. Control and properly care for assets throughout their lifecycle
3. Store the data about each CI in an easy to use, efficient and effective manner
4. Obtain information about the current run state of production services
5. Account for, manage and protect the access to and integrity of CIs throughout the service lifecycle
6. Maintain an accurate and complete configuration management system (CMS)
7. Maintain accurate configuration information on historical, planned and current state of services and other CIs.
8. Provide accurate configuration information to enable people to make decisions at the right time

{ Critical Success Factors }

{ Key Performance Indicators 1/3}

{ Key Performance Indicators 2/3}

{ Key Performance Indicators 3/3}

• Setting the scope too wide, causing excessive cost and effort for insufficient benefit
• Setting the scope too narrow, so that the process has little to no benefit
• Maintaining accurate information recorded by the process by letting it stagnate, not auditing enough, or not doing anything with results of audits
• Storing data in the cloud and losing access to it
• Setting the wrong focus. The temptation to consider service asset and configuration management from a technically view and ignoring the service and business perspective.

{ Risks }

• Achieving organizational change and buy-in for Service Asset and Configuration Management by convincing everyone that the process has value to expend some effort throughout daily, operational activities
• Agreeing on a definition of a service asset versus a configuration item
• Agreeing on what information should be managed for each CI type/category
• Integration and/or replacement of current toolsets

{ Challenges }

{ Recommended Process Owner }

Bob Dein

Advantages

• Overlap with Enterprise Architecture. EA repository refreshed and partially derived from the CMS
• Near-term goal alignment to document current state architecture
• Major stakeholder in seeing that configuration management is done well

Disadvantages

• EA Only interested in changes and CIs that have architectural relevance
• Concern about time commitment

{ Process Policies }

• When possible, use automated or forced discovery to ensure the accurate collection of configuration management information that is free from human errors
• Prefer as few configuration management data sources as possible
• Limit duplication of configuration information across multiple repositories as much as possible. Configuration and asset information stored outside the Configuration Management System should be reviewed and approved in collaboration with the configuration management and change management process owners
• All configuration items must have a unique identifier, type, single owner, and name that follows a naming convention for each type.
• Take a regular configuration snapshot of the configuration management system(s) for Business Continuity purposes
• Only authorized individuals may view or change configuration items
• Take regular configuration snapshots and performance snapshots for important configuration items.

{ Process }

* Information contained in the CMS is managed via the change management process

{ Configuration Management System }

Integrated CMS (TeamDynamix)

CI Types

Source CMDB

NOC-IT

TSC

Filemaker

Oracle Enterprise Manager

Wiki

Process

IT Staff

Server

App

Contract

Storage�System

Database

Network Device

ETC

{ Configuration Item Type Topology }

Facility/�Cloud

Facility Hardware

End Point Device

IT Service

IT System

IT Process

Contracts

IT Staff

(See next slide)

{ Configuration Item Type Topology }

IT System

Server

Server Cluster

Storage

System

Database

Database Instance

Application/�Software

VLAN

Network Device

{ Configuration Item Shared Attributes }

• Name
• Unique Identifier
• Description
• CI Type
• Format (cloud, physical, etc)
• Which CMBD is authoritative/master source
• Owner (change authority)
• Relationship with other CIs
• Relationship type (runs on, plugs into, etc)

• Lifecycle status (production, dev, etc)
• Status (live, up/down, retired)
• Date added
• Last audited
• Who audited
• Last modified
• Who last modified
• Primary support unit

Full dictionary of Configuration Item Attributes available

{ Where to Start? }

1. Team has identified source CMDBs for each CI type
2. Rated along 5 dimensions
1. Number of Source CMDBs
2. Reliability of source CMDBs
3. Frequency of changes
4. Desire to manage
5. Feasibility of managing in integrated CMDB
3. Force Rank among team
• TSC top priority
• Others TBD

{ Acceptance Criteria }

{ Acceptance Criteria }

{ Acceptance Criteria }

{ Acceptance Criteria }