HP Configuration Management System

Best Practices Library

CMS Strategy Guide

Revision 2, June 3, 2010

Planning and Design Guides

2

Documentation Updates

Table 1 Document Changes

Chapter Version Changes

All Initial JR - Initial document for rev2

3

Table of Contents

Introduction ............................................................................ 6

Purpose of This Document ...................................................................................................................... 6

Approach to Presenting a Strategy .......................................................................................................... 6

Plain and Simple Terms first ............................................................................................................. 6

Challenges and Barriers .................................................................................................................... 6

Expanded Key Definitions ................................................................................................................. 6

Desired Outcomes ................................................................................................................................... 7

How to Provide Feedback ........................................................................................................................ 7

Audience .................................................................................................................................................. 8

Prerequisites ............................................................................................................................................ 8

Related Documents ................................................................................................................................. 8

What is a CMS and Why Do We Care ...................................................................................................... 9

ITIL Gaps ........................................................................................................................................... 9

Functions of a CMS ........................................................................................................................... 9

Practical Definitions of CMS ........................................................................................................... 10

Why Does a CMS Exist .................................................................................................................... 10

Evolution of CMDB and CMS .......................................................................................................... 11

ITIL and CMS ................................................................................................................................... 11

CMDB and CMS............................................................................................................................... 12

A CMS is More Than Technology .................................................................................................... 13

The CMS Value Chain ...................................................................................................................... 14

What is a Service?........................................................................................................................... 14

Investment in the CMS Based on the Value Chain ......................................................................... 17

SACM and CMS Demystified ...................................................... 18

What is SACM ........................................................................................................................................ 18

SACM Process Activities ................................................................................................................. 19

SACM and ITAM .............................................................................................................................. 20

Domain and Lifecycle Overlaps ...................................................................................................... 21

SACM and ITAM Lifecycle Intersection ........................................................................................... 22

Service Asset and CI Intersection ................................................................................................... 23

Implementing a CMS with SACM ........................................................................................................... 25

High-Level Requirement ................................................................................................................. 25

Scope .............................................................................................................................................. 26

Policies ............................................................................................................................................ 26

Organizational Responsibilities ...................................................................................................... 26

Individual Processes and Procedures ............................................................................................. 26

Identify Configurations ................................................................................................................... 26

Proactive Use Cases ........................................................................................................................ 27

4

CMS Process Governance .......................................................... 28

The Consumer/Owner/Provider Model ......................................................................................... 28

Tenets ............................................................................................................................................. 28

The Consumer / Owner / Provider model tenets ........................................................................... 29

Data Model and Conduit Independent ........................................................................................... 30

COP Model / SACM Intersection .................................................................................................... 30

Component Relationships .............................................................................................................. 31

Differences between the Owner and Provider ............................................................................... 32

Every Attribute must have a Consumer ................................................................................................. 33

Rationale ......................................................................................................................................... 33

Implementation .............................................................................................................................. 34

Every attribute must have an Owner .................................................................................................... 35

Rationale ......................................................................................................................................... 35

Implementation .............................................................................................................................. 35

Each Attribute has Preferably One Provider .......................................................................................... 36

Rationale ......................................................................................................................................... 36

Implementation .............................................................................................................................. 38

Provider Authority Must be Rationalized .............................................................................................. 39

Rationale ......................................................................................................................................... 39

Implementation .............................................................................................................................. 39

Examples of Authoritative and Non-authoritative Provider Candidates: ....................................... 41

Providers are Transparent to Consumers .............................................................................................. 43

Rationale ......................................................................................................................................... 43

Implementation .............................................................................................................................. 43

Onboarding Processes must be followed to Protect Data Integrity ...................................................... 44

Rationale ......................................................................................................................................... 44

CMS Design and Planning .......................................................... 45

High-Level Recommendations ............................................................................................................... 45

Multiple data Repositories in a CMS in Practice .................................................................................... 46

Data Model Mapping and Reconciliation ....................................................................................... 47

Using Automated Discovery Supporting Verification and Audit .................................................... 47

Practical Limitations ....................................................................................................................... 48

Maturation and Migration Strategies .................................................................................................... 49

Change Management Interaction with the CMS ............................................................................ 53

Operations Monitoring Interaction with the CMS .......................................................................... 53

Operational Monitoring Feeds Incident and Problem Management ............................................. 54

Change Management Feeds Release Management ....................................................................... 55

Advantage, Inc. Change Management Case Study ................................................................................ 55

Case Study Analysis ............................................................................................................................... 58

Design and Planning Approach .............................................................................................................. 60

5

Implementation ..................................................................................................................................... 63

CMS Deployment ...................................................................... 68

Example #1: CMS Project Release Phases ............................................................................................. 68

Example #2: CMS Road Map ................................................................................................................. 69

Small Scope Pilot Project ....................................................................................................................... 70

Choosing an Achievable Scope for the Pilot ................................................................................... 70

Functional Testing .......................................................................................................................... 70

Populating the Configuration Baseline ........................................................................................... 71

Implementation Challenges ................................................................................................................... 71

Deployment Planning and Implementation Challenges ........................................................................ 71

Glossary ................................................................................... 73

Index ....................................................................................... 77

6

Introduction

Purpose of This Document

Welcome to the HP CMS Best Practices Library Strategy Guide. This guide will help you understand:

- What are a Configuration Management System (CMS) and Configuration Management Database (CMDB)

- Why a CMS and CMDB are important to the business and service management and improvement

- How a CMS and CMDB relate to each other, and to other IT services and applications

- How to make sense of the confusing and overlapping standards bodies of ITIL, ITAM, and SACM

- Why CI and asset lifecycles are important and how to use them in practice

- How to get and keep the highest quality of data in your CMS

- Workable approaches for CMS design and planning

- How to successfully deploy and grow a CMS from the beginning to fully operational

Approach to Presenting a Strategy

Plain and Simple Terms first

We’ll try to frame the many particulars of a CMS in practical terms, and explain the basis of recommendations as

we go. The simplest explanation is presented first and advances in detail, starting with why a CMS exists and the

context for talking about CMS and CMDB. We have tried very hard to demystify some of the confusion around

SACM, CMS, and ITAM.

Challenges and Barriers

Immediately after learning a way to solve a problem, it’s normal to immediately want to go solve the problem.

Not so fast! Experience shows it is easy to make major mistakes. We’ve tried to impart an appreciation of the

practical usage and limitations of technologies involved, and how to design an achievable solution and avoid

common mistakes. Anywhere a particularly powerful practice is discussed, or where it is easy to make a mistake

or let good intentions lead you astray, it will be marked with a caution symbol like the one shown to the left of

this paragraph.

Expanded Key Definitions

To break through the layers of confusion around CMS, some key terms and definitions need to be expanded and

refined, especially the terms “asset”, “service”, “CI”, and combinations of these. We provided a glossary near

the end of the document using these expanded concepts. While they may be rooted in ITIL or SACM, the

presented definitions are intended (and liberally used throughout this document) to empower you to think

about how your organization should manage the configuration of its collective services. Rather than trying to

7

piece together a strategy from the many sources of advice, we would rather you be able to decide what’s best

for your organization based on the needs and problems you’re trying to address.

Running Exemplar

To illustrate the critical decisions points in a more understandable context and

demonstrate the concepts in this strategy guide, we have set up a running case study of a

fictitious company called Advantage, Inc. Advantage, Inc. serves as a baseline reference

implementation, and used as a reference model to provide a context to discuss how an

organization might choose the right or wrong path when faced with difficult or unclear

choices. The Advantage, Inc. “story” is visually highlighted in a green-shaded box, as

shown here.

For the full description of Advantage, Inc., refer to the Advantage Inc., Running Exemplar

document in the CMS Best Practices library.

Desired Outcomes

Foremostly, we want you to learn some new ways to use knowledge you already have about your organization.

We want to give you a way to think about configuration management in a way that can become beneficial to

your business and your IT organization. We want to give you a solid foundation where you can stand on your

own wisdom amidst the many voices and choices facing a stakeholder of a major IT initiative like CMS. This

document does not address best practices like “what is the best practice for reconciling attribute a from MDR x

to attribute b of MDR y”. These types of issues are addressed in other documents in the CMS best practices

library.

It is also our hope that you gain a greater appreciation for the complexity and challenges of planning for and

designing a successful CMS. Most, but not all, of the best practices are presented with an explanation of why

the practice is best – perhaps a short history of what problems existed, and why and how a best practice

addresses the problem. We also tried to indicate how important the practice is: is it an improvement over

“normal”, or is it a dangerous unmarked hairpin turn where a small error could result in disaster? The latter

type is typically accompanied by an Advantage, Inc., sidebar. If you would like to see additional usage or

examples for other material in the CMS Best Practices Library, please let us know by providing feedback as

shown below.

How to Provide Feedback

Please let us know what we got right, what we missed, and if you believe we were wrong or misleading on any

of the material covered in this guide. We’d like to know if any material helped you make a better decision or

helped you avoid any key risks. We are also very interested in any discussion you wish to have on the principles,

premises, or concepts discussed. We have active, working communities of HP CMS customers who exchange

knowledge and technical and strategic information on a regular basis.

We are also happy to get objective feedback on how we could improve the structure, grammar, or flow of this

document. Corrections are requested and appreciated.

8

Please provide feedback to HP with your circumstances and comments to this email address:

CMSbestpractices@hp.com In addition you may want to pass on certain comments to your local HP Software

contacts.

Audience

This document is for:

- Sponsors, stakeholders, and program managers responsible for configuration management initiatives.

- Service Owners and other owners of IT assets, infrastructure, applications, and services

- CMS architects and implementers who need to understand, create, modify, or document processes related to onboarding new consumers and use cases to the CMS

- Planners and managers of CMDB and equivalent-role technology who need to understand how to prepare for and “upgrade” a CMDB within/for a CMS strategy

Prerequisites

The reader should be familiar with IT and ITIL basic concepts and terminology. Additional background with

configuration management, IT service management, asset management, and change management would be

helpful but not required.

Related Documents

The CMS Best Practices Library, published by HP Software and Solutions, authored by many, surrounds and

enables this document. The library contains documents for planning, designing, deploying, and operating a

CMS, based on the strategies in this document.

The CMDB Imperative, published by Prentice Hall and authored by Glenn O’Donnell and Carlos Casanova, is

highly-recommended reading for anyone involved with a CMDB or CMS initiative. Their insight and experience

greatly increase the approachability of the subject to those who do not have a technical or ITIL background.

HP SACM Guide v1.1, published by HP Software and Solutions, authored by many, provides a prescriptive

approach to configuration management using HP Software and Solutions technology. For a by-the-book, ITIL-

based implementation of configuration management, this is the reference guide to use.

ITIL Library, Service Transitions, published by the UK’s Office of Government and Commerce (OGC) and authored by many industry leading experts, is a foundational set of best practices for organizing and creating IT services.

ITIL Library, Service Operations, also published by the UK’s Office of Government and Commerce (OGC) and

authored by many industry leading experts, is a foundational set of best practices for operating and monitoring

IT services.

9

What is a CMS and Why Do We Care

Fundamentally, A CMS is one or more Managed Data Repositories (MDRs) and the tools and analytics which

enable the process of configuration management. Configuration management is defined within the context of

managing IT Services. IT service management (ITSM) is a model for understanding IT’s purpose and relationship

to the business it serves.

CMDB, CMS, and ITSM are definitions introduced by ITIL (IT Information Library), a body of best practices for IT,

first developed in 1989 by the UK’s OGC and currently in revision 3. ITIL can be generally thought of as a loose

set of guidelines for managing and operating IT. ITIL v3’s model emphasizes services and processes and the

interactions and transitions between them. Service operations are the set of interacting processes that

culminate in the provision and availability of a service. Services may consist of a composite of fundamental

processes as well as other services. ITSM is the set of processes that manage service operations, for example

the maintenance, update, and repair of service components.

ITIL Gaps

ITIL is not prescriptive and leaves most of the decisions regarding technology and implementation to the IT

organization. ITIL, for example, calls for a change management process and policies to be implemented, but

only describes at a high level what the processes and policies should accomplish, not how. This leaves a gap

many details across for IT organizations desiring to implement ITIL/ITSM-based solutions.

HP Best practices pick up where ITIL leaves off. HP extends and solidifies the ITIL concepts into actionable

solutions that fit seamlessly onto HP software, but also work with other technology you may already have in

place.

This strategy guide, along with the CMS best practices library, HP Software and Solutions, and service delivery

organizations form the foundational support for customers implementing ITL-based processes and solutions,

including CMDB and CMS.

Functions of a CMS

A CMS provides element and service configuration, and federation and other integration services.

10

- Element configuration – Enables identification and control of configuration items

- Service Configuration – Enables collections of CIs to be a model of a service and enable control and configuration of the service as a whole

- Federation – Data integration, mapping, modeling, discovery, and APIs to provide and consume configuration data among the providers and consumers

Practical Definitions of CMS

The primary purpose of a CMS is to enable IT to support and improve IT and business services.

A CMS can be defined as:

1. A set of

o Tools

o Analytics

o Bases of information (primarily but not limited to, databases)

o Systems (which help ITSM applications work together, to support IT and Business services)

An easy way to remember this is the first letter of these items spell out the word “TABS” – a CMS helps you “keep TABS” on your service configurations.

2. An operational model for executing the configuration management process as defined by ITIL (IT Information Library).

3. An operational CMS consists of all the consumers, owners, and providers of configuration data in an IT organization, wrapped by process and governance layers.

Why Does a CMS Exist

IT organizations typically deploy a CMDB and/or a CMS for:

- Supporting Specific ITSM processes: The CMDB/CMS follows other ITSM initiatives for their support

and integration. ITSM use cases include change management, release management, and incident

and problem management. IT organizations pursuing these initiatives will need their parts to work

together, to have a common view of services, and to exchange information as part of their

operation. A CMS does these things. Therefore, these initiatives typically call for some type of

configuration management to be implemented along with the primary initiative.

In this case, other use cases “pull” the CMS along with it to support their operation and interaction.

- Establishing a Configuration Management foundation: The need for additional or more formal

configuration management is realized after either 1) vision for the value of a CMS is realized or 2)

experiencing problems caused by traditional, informal, or non-scalable approaches typically used by

smaller organizations, or after having used an application whose primary function is something

besides configuration management e.g. a service desk or asset manager application.

In these cases, the CMS “pushes” to other use cases based on risk-avoidance or benefit-seeking.

11

In any case, the CMS is used by ITIL processes to hold and provide configuration items and relationships between them, as shown here:

The CMS, containing configuration items and relationships between them, is used by other ITIL processes to exchange

configuration data about services and service components, represented by the graph in the center.

Evolution of CMDB and CMS

Dedicated configuration management processes and technologies have only recently (since the early 2000’s)

evolved from a variety of disparate and heterogeneous roots, including asset management, application

mapping, service desk, inventory management, and other applications, all of which did some part of what we

call configuration management today. The concept of a CMS grew out of experiences using a configuration

management database (CMDB) and the difficulties associated with the replicative, warehouse-type approach,

for example, data latency, network bandwidth, and the resulting degradation of data quality and

trustworthiness.

ITIL and CMS

ITIL defines CMS, but only broadly. The concept of a CMDB and CMS is defined by ITIL, along with the processes

and services that make up IT. ITIL introduced the CMS as an expanded concept of the CMDB, in particular,

where CIs (configuration items) are called to reside. In 2006, the release of ITIL v3 deprecated the v2

“monolithic” CMDB to an ecosystem of multiple providers of configuration data. Configuration management

data naturally resides throughout the applications themselves that implement and support IT Services. Most of

the actual configuration data is left in its native application, rather than replicated to a central CMDB. Discovery

data is still populated via integration or auto-discovery for various purposes. The applications provide and

12

consume each other’s data under the workflows and processes executed by ITSM. Examples of this kind of

“external” configuration data:

- Financial and ownership data, and other fiscally relevant information, owned and provided by the asset management system. Essentially, actionable information needed by a process to support or enhance decision-making within that process.

- The real-time operational or security statuses of an application CI which would be owned and provided by the operations monitoring applications. This information is typically used to make change decisions and coordinate operational activities.

- The change status of the CI, owned and provided by the change management application.

Infrastructure CIs, such as those representing servers or application components, are generally populated to a

CMDB, or other MDR such as an asset management or service management application, depending on your past

and future strategy (more on this later). This data is related to itself and also to the configuration data residing

externally to the CMDB, that is, the data managed and residing among the ITSM applications themselves, such

as the service desk (incident/problem/change management) or the asset management system.

CMDB and CMS

In ITIL v3 terms, the CMDB is deprecated to one of many MDRs (The “CM” part is deleted, leaving more or less

the “DB” part). However, the v3 definition omits a critical layer of functionality from the CMDB definition which

is still not defined in the “CM” part, e.g. SACM. A CMDB is still more than an MDR. Viable CMS solutions will

continue to have “CMDB-like” components in order to provide this extra, expected, functionality:

- A data integration hub, providing the conduits for consumers and providers to exchange configuration data. These conduits are implemented as federation adapters, APIs, UIs, web services, and other methods of I/O

- Analytical functions such as impact analysis, gold master comparison, audit and compliance, and other forms of reporting

- A CI type model capable of representing business and IT services and components, such as infrastructure, applications, networks, databases, business processes and business services, and the relationships and dependencies between these.

- Service modeling and topology visualization

- Discovery and dependency mapping

CMDB is maturing and the technology, data, and governance layers are better understood today. CMDB is

technology that can be obtained to serve as the foundation for a CMS.

However, today, a CMS cannot be bought, only built. The components of a CMS are a core CMDB, all the

consumers, all the providers, and the process and governance surrounding all activity. This configuration will be

specific and unique to every IT organization. Common characteristics and trends will certainly accelerate

adaption and lower costs of implementation, but as of today, the general approach is to start with the use cases,

implement the CMDB, then begin onboarding providers, then consumers, building up the governance process

layers around them throughout the deployment and starting with the earliest stages of design planning.

13

Generally, you should plan to implement in phases, starting with one of the less complex use cases (more on this

later). It is easy to take on too much too early when everyone wants the CMS to be everything they were ever

told it could be. You will probably have to make decision on prioritizing competing use cases.

A CMS is More Than Technology

Although many features and functions are necessary to provide these primary capabilities, the CMS as a

deployed solution consists of much more than software. A CMS is built on technology, data, processes, and

governance, which can be visualized as follows:

How the Layers of a CMS support Services

The business is represented by the eye, surrounded by services, and sits on top of the CMS via the IT and

business services it supports as designated by the grouping bracket indicators to the right of the “stack”.

Technology - the foundational layer and includes components like CMDB, discovery, federation, and

reconciliation. Additional analytics such as reporting, serviced modeling, and impact analysis are commonly

included to enable the technology to function in practical terms.

HP CMS technology is based on three foundational concepts:

- Cloud-aware, Service Driven IT – HP CMS provides the shared service context that IT needs to effectively manage the physical, virtual, and cloud-based services. Shared service context is the key to effective prioritization for both proactive as well as reactive activity. Our goal is to enable the transition to cloud-based services that support new as well as existing business models.

- Greater visibility and control over your IT infrastructure – Increased visibility into business service impact, timely and accurate visibility into your IT operations, and reduced costs of audit and compliance and similar reporting. The goal is to improve your decision-making ability based on greater insight into your IT environment, specifically with end-to-end service visibility and quality monitoring.

- Delivering Information Sharing and Process Collaboration and automation – Unlocking authoritative yet siloed information and creating a unified foundation for information sharing across your IT environment. The goal is to increase speed of deployment through automation, and lower TCO through lower-cost deployment and increased accuracy of data (through shared context).

Data - Built in and around the technology layer, the data layer is responsible for understanding and translating

the many disparate providers and consumers with a common data model and the capabilities to transform,

14

reconcile, and map differing data models. There is no one model shared by any mix of ITSM applications -- even

from a single vendor. Although HP is approaching this with BDM, the BTO Data Model, a “Grand Unified Model”

is still not a reality today.

For a CMS, the technology and data layers are implemented as the enabling foundational layer of the CMDB

(being more than just a data provider, the CMDB can also be considered the “core” MDR for the reasons

mentioned earlier).

Process – Many processes surround the design, deployment, and operation of a CMS. Many processes are well-

defined and have broad examples. Other processes are much less formal yet are critically important to success,

such as the processes for onboarding consumers and providers to the CMS, and measuring CMS data quality.

This guide attempts to fill a few of these gaps.

Governance – The best practices and strategies used to ensure the design, architecture, and deployment

produce the desired result. What the desired result itself should look like, specifically in terms of ensuring data

quality, security, and integrity, and avoiding hidden cost and risk.

The CMS Value Chain

Why should organizations invest in a CMS and CMDB? The use cases for configuration management receive only

rudimentary and somewhat unfocused treatment in ITIL and SACM (Service Asset and Configuration

Management). Understanding the use case is not the same thing as understanding why and how the CMS adds

value from a business perspective. We see the CMS is not directly visible to business-level KPIs which measure

the availability and quality of business service information. The CMS only indirectly affects these.

The ITIL official introduction to the ITIL service lifecycle states it succinctly:

”The business value of SACM is often not recognized until the use of the CMS is used with other service

management processes within the Service Lifecycle.”

What is a Service?

To understand the value of a CMS, we must first understand what the business views as a service, as well as

what IT is doing from the perspective of the business. The term “service” is prolific throughout the ITIL books as

well as throughout the IT management industry.

If you ask different people throughout a business (including IT) what a service is, you are likely to get widely

varying answers. Fundamentally, the business itself is either the provider of a product (manufacturing) or a

service (anything that is not material). Even manufacturing businesses still have to provide services such as

customer support, ordering, and so on. Ultimately, the services that keep you in business are the only services

that are true services, that is, those that result in customer financial transactions. Every other “service” is a

composite of these business functions, and carries a cost rather than a value.

This is not to say that these functions are not valuable to the business; it is to say that IT traditionally views the

“services” it provides to the business as having value, when in fact, unless these services are paid for by an

external customer, they are not: they are simply components of the service the business provides to its

customers.

15

For example, IT hosts infrastructure and applications used by the HR department, and considers this a business

service; after all, HR is a business function. Not quite. HR is an internal function, just like IT. Unless your

business IS the HR business, HR is not really a business service; it is simply another internal department that

incurs a necessary cost to the business.

Advantage, Inc. Discusses Value Chains

Let’s listen in on an Advantage, Inc., conversation about how to socialize business awareness to the IT staff

without being oppressive or unnatural.

CTO to the VP of Ops: “This is the bridge we must cross to really understand corporate’s perspective of us:

Nothing matters until sales are made! Everybody needs to understand that, even if they are a few layers in.”

VP: “I agree, but this is not to say that we are recommending one of those silly initiatives with slogans like

‘everyone is a salesman’, or that our very technical staff should get sales training or be made to wear suits.”

CTO: “Yes, but it does mean that everyone in IT, even our most technical techies, or the guy who moves

hardware around all day, must not lose sight of the fact that they and IT serve AI’s business. They should know

their value in business terms.”

VP: “Look - many of our IT people are in precisely because they like working with things rather than people. We

shouldn’t try to change that. Let’s socialize the awareness, not challenge ideologies. People should be proud of

being a resource or capability that makes AI work. We should track service value for them as well.”

CTO: “I agree - they deserve to know how they’re making a difference. They can only get that if we can get it – if

we can trace an individual’s or any resource or capability of a service, to the bottom line. We get better visibility

and better control over TCO, and our people get the credit. Everybody wins.”

As Advantage, Inc. realized, if IT adopts this business-oriented perspective of its own function, IT can take a big

step forward in adding value to the business. CMS value should be connected not only to IT services, but to the

business’s services, including people. Meaning, unless the CMS can be measured and shown to improve the

business’s ability to compete or increase its sales, true value is not really being created.

However, this may be a radical departure from traditional IT thinking. To help, the CMS value chain below

illustrates the path of qualitative and quantitative improvement from the CMS to the business:

16

How the Business sees the value of the CMS:

The CMS Value Chain is built on the processes surrounding Managing Configuration Data.

Each tier builds on the one below it. The CMS value chain consists primarily of the benefits of aggregated and

unified views of services, and increased accuracy and reliability of fewer places to go to get configuration data.

As seen here, these combine to ultimately improve the business services on which the business directly relies,

and if truly successful, give the business a competitive advantage at a lower cost.

CMS (bottom) Tier: As shown earlier, the CMS is composed of element configuration, service configuration,

federation and other integration, and key analytics. Together, they enable consumers to benefit from a shared

service context and more actionable information.

Second Tier: The fundamental functions of the CMS combine to provide two major benefit tiers: Increased data

reliability, and shared context. The reliability increase is due to two things: having one place to go vs. many

places and the related uncertainty and decision-making around it, and by federation, enabling the data to

transparently be as accurate and as timely as it is in the native MDR. The shared context allows not only a

common view of services, but a more granular view of them.

Third and Fourth Tiers: These tiers enable value to be realized and monitored in the third tier) by traditional and

proven KPIs such as MTBF (Mean Time Between Failures) and MTTR (Mean Time To Resolution). A correlation

between the CMS and improvement in these KPIs could arguably be considered a success. However, the true

measure of success is the improvement to the business services (and therefore the business itself).

17

Top Tier: By reducing change-related problems and collaborating more efficiently, the ITSM processes support

the business services better and at a lower cost. This ultimately should help the business compete better and at

a lower cost of IT. If this can be detected and visualized, the value chain is complete.

Caution: Each box covers a lot of territory. Avoid assumptively embracing this value chain without meaningful

investigative research. Each value tier should be a goal unto itself and manifest demonstrable actionability

before taking on the tiers above it.

Investment in the CMS Based on the Value Chain

Configuration management requires investment to enable the value chain. Configuration management may be

a manual process, using no technology, or may rely on non-specific tools such as spreadsheets. Customers must

understand the value chain to rationalize the investment in configuration management. This investment may be

justified as an enabling technology, supporting another use case such as CLIP (closed-loop incident/problem

management) or CCRM (change control and release management). Alternatively, vision-driven enterprises may

invest in configuration management directly as a strategic foundation on which to fulfill general ITSM and SACM

use cases.

In either case, it is important to realize that not every customer has a need to mature every discipline out to the

maximum degree. The CMS should support the customer’s use cases and needs, but no more unless it is clearly

a future investment in ITSM infrastructure and sponsored as such.

18

SACM and CMS Demystified

What is SACM

ITIL v3 describes the CMS as a supporting enablement to the SACM process. The SACM processes is responsible

for delivering configuration management control for those Service Assets that have the characteristic of being

configurable and are therefore CIs.

SACM begins with 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 CMS 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, relationships with other

CIs.

The SACM process manages and controls the revision of all managed components of the IT infrastructure that

have been released to production. CIs managed by this process include hardware items, software components

and object code, network items, documentation and any other elements within the IT infrastructure that an

organization needs to control. Data is stored in a logical entity (CMS) that typically consists of multiple distinct

databases.

SACM maintains the status of a CI (i.e. functional / administrative status, relationships, etc.) in the IT

Infrastructure. It includes all documentation related to that CI. It creates, maintains, tracks and reports on

information that enhances the ability of other supporting processes to be effective, especially the change,

problem and release management process.

SACM 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., the enterprise level,

the workgroup Level, etc.). This enables the autonomy of CIs at the local 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. In contrast, if too much control is pushed to the Local Workgroup level, this may result in a loss of

integration of the highest-level enterprise objectives and the elements of redundancy and inconsistency become

potential issues at these local workgroup levels. Hence, there is a need to separate those CIs that must be

managed at an Enterprise level and those that can be managed at a Local Workgroup level.

19

SACM Process Activities

ITIL defines five basic activities required to perform the configuration management process. HP adds the activity

of population, assuming an IT organization large enough to need a CMS will have enough assets and change

activity to warrant auto-discovery.

1. Planning - Planning and defining the purpose, scope, objectives, policies and procedures, and the

organizational and technical context for configuration management.

2. Identification

- Selecting and identifying the configuration structures for all infrastructure components,

including their “owner,” their interrelationships and associated configuration documentation. It

includes allocating identifiers and version numbers for CIs, labeling each item, and entering it in

the configuration management database.

3. Population - HP adds population to the list, for two purposes: 1) service discovery 2) actual state discovery.

Under process control, the introduction of CIs into the CMS – not necessarily the CMDB.

Population is traditionally regarded as discovery. Replicating or federating CIs into the CMDB in

any form is considered population.

4. Control

- Making sure that only authorized and identifiable CIs are accepted and recorded, from receipt to

disposal. No configuration items should be added, modified, replaced or removed without

appropriate controlling documentation, e.g. an approved Change request, and an updated

specification.

5. Status Accounting - The reporting of all 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.”

6. Verification and Audit - A series of periodic reviews and audits that verify the physical existence of CIs and checks to

make sure they are correctly recorded in the CMS.

20

SACM and ITAM

Asset management covers service assets across the entire service lifecycle. It provides a complete inventory of

assets and who is responsible for their control. It includes full lifecycle management of IT and service assets,

from the point of fiscal significance (when money or resources are spent), through disposal. Asset management

also provides maintenance of the asset inventory.

Assets vs. assets vs. assets - The SACM process is often confused with the corporate financial process called,

“Asset Management.” The dictionary describes assets as “items on a balance sheet showing the book value of

property owned”. It follows that asset management is a business process that manages an asset throughout its

financial lifecycle. The asset management process includes activities such as contract management, cost

depreciation, total cost of ownership (TCO), total value of ownership and obsolescence for each asset. Although

there are key links between asset management and configuration management, it must always be remembered

that they are in fact distinct from each other, and each process has its own unique activities.

ITAM assets - ITIL defines asset management as “a recognized accountancy process that includes depreciation

accounting”. This is a nod to the non-IT definition of accounting – debits, credits, balance sheets, etc. and is not

a particularly useful definition. IT asset management infers some connection with IT and therefore a direct or

indirect association with a service. Asset management systems typically maintain details on assets above a

certain value, their business unit and their location. Relationships between assets are not usually recorded by

asset management tools. In some cases, organizations start with the implementation of asset management or IT

asset management and then move on to the activation of a formal SACM process.

Service assets aren’t necessarily ITAM assets - A corporate asset can be purchased, received and placed in stock

within the organization without being moved into the production IT environment. It is important to note that

CIs defined by SACM may or may not technically be corporate assets, since SACM allows for the control and

tracking of “resources” and “capabilities” or any number of “things,” some of which might not be classified as

typical corporate IT assets (e.g., people, knowledge, training, etc.).

CIs vs. Service assets - Conversely, some CIs may carry no fiscal relevance, yet have the characteristic of simply

being configurable, for example, a TCP/IP port. It did not have a purchase price, it has no fiscal relevance, it

occupies no disk space, the cost of knowing its presence and purpose is negligible and not specifically charged

for, yet it is configurable and part of a service, therefore it is a CI.

ITAM using CMS - Corporate asset management is interested in ALL of the corporation’s assets, not just what is

managed by IT. What this means is that all but small organizations most often require both an asset

management solution as well as CMS. Also, an asset management system must be capable of delivering

application functionality such as cost depreciation and/or total cost of ownership calculations and reports –

issues not necessarily relevant to a CMS. Managers of the corporate asset management system might be very

interested in the CMS/CMDB and linking to it in some form or fashion. This can be a potential benefit to the

CMS/CMDB IT initiative as additional use cases and potential value to the company can generate additional

funding and sponsorship.

ITAM as part of the SACM lifecycle - When an infrastructure component (IT asset) is identified and stored in a

CMDB, the SACM process activity called, “Status Accounting and Reporting,” will report on the relevant status

codes associated with a CI throughout its lifecycle. When the asset is ready to be moved into the production

environment, a request for change (RFC) is prepared and submitted to the change management process.

Following the “Release and Deployment” and “Service Validation and Testing” process activities, the asset is

21

eventually released into the production IT environment and the status of the CI record is changed to the

organization’s defined production status.

SACM leveraging ITAM - If your organization already has an asset management database, specific financial

information about assets will be stored in this database as part of a fully functional asset management system.

The asset management system will manage data input and validation, field structures, standard financial and

asset lifecycle (i.e. depreciation values) and provide specific asset management reporting capabilities. Some of

this information may be of interest to IT and a connection between the CMDB and the corporate asset

management system may warrant investigation as a use case. So in this case the asset management system may

be a provider. Conversely, you may also find that there is a need to expose or export data from the CMS into

your corporate asset management system, for purpose such as base-lining, compliance and audit, or

investigating anomalies. The asset management system would be a consumer.

Domain and Lifecycle Overlaps

The broad definitions of technology, data, and process governance are composites of many specific features and

functions, as described in detail by several bodies of standards, including ITSM and ITAM. As the previous

section is intended to indicate, the scope and boundaries of these domains is poorly understood and are often

steeped in different personal perspectives, adding to the confusion rather than the understanding. At best ITSM

and ITAM give us definitions that depend on the values of undefined variables, and at worst they are somewhat

tautological definitions.

The Venn diagram illustrates the separation and overlap of three specific domains, asset, service, and

configuration management. Each domain contains both overlapping and non-overlapping scope with the

others. The key point is of this diagram is to show that both SACM and ITAM have a governance responsibility

22

for service assets. This becomes important when we examine the lifecycle of configurable service assets. It is

important that the organization makes a conscious decision what to bring under configuration management.

Essentially there are overlapping lifecycles between ITAM that SACM that must be recognized in order to

effectively carryout SACM within the enterprise. The fact that both ITAM processes and SACM responsibility for

different aspects associated with the management of service assets influences how you design your CMS to

effectively support SACM and all related ITIL/ITSM processes that rely on the SACM process.

SACM and ITAM Lifecycle Intersection

Overlapping Asset and Configuration Management (SACM) lifecycles

Here are the relationships of the SACM and the ITAM lifecycles. The two lifecycles overlap within the

“production” space, that is, when an asset becomes part of a “live” service. What can be clearly seen is that the

ITAM lifecycle begins before a service asset is brought under management and continues beyond the point

when an asset is no longer providing value to a service and is thus no longer a service asset. Understanding this

relationship has implications for the design of your CMS to support SACM. Essentially because both SACM and

ITAM have responsibility for different aspects of the management of service assets you can leverage ITAM as a

data source when first bringing service assets under configuration management and you can also leverage ITAM

as a source for data when carrying out the verification and audit step of SACM.

However, SACM does not have to necessarily be ITAM-aware, nor does ITAM need to be SACM-aware. But due

to the high degree of overlap, it can be advantageous for each of them to be aware of each other in terms of

solution architecture.

23

Service Asset and CI Intersection

Service assets that are configurable are CIs. In addition to service assets that are CIs there may also be CIs that

by themselves are not service assets but rather are components of service assets. Since service assets are

defined by the organization that must manage them, there exist shades of grey between what is a service asset

and what are simply components of the service asset that are being managed as CIs. From a SACM perspective,

this makes little difference since they will be subject to the same governance process. The key thing to

remember here is that the organization must make informed decisions as to what is a service asset and what

service assets are subject to in terms of configuration management. This decision must be made on the basis of

a cost benefit analysis. Meaning, the question must be asked, and a conscious decision made, for each CI: Is

this CI worth it? The only worth relevant here is whether the CI will add value as described by the CMS value

chain, shown earlier: Will it improve data integrity? Help provide a common shared context, etc.? Improve

service delivery? Is the cost of populating, managing, owning, maintaining, and consuming the CI comparable

against the intended ROI? If not, then do not put that CI in the CMS.

The CI lifecycle begins when a CI is created and brought under configuration management. For service anssets

such as a server, the CI lifecycle begins when the server is deployed as part of a service, commonly referred to as

“Production”, and ends when the server is taken out of “Production” service. Likewise, an application is “born”

from business demand, and is eventually decommissioned upon replacement with a newer, better application.

The CMS is concerned with the lifecycle of CIs, not necessarily the assets for which the CIs exist. The lifecycle of

the CI is not the same as the lifecycle of the underlying asset. For example, a server physically exists as an IT

asset both before and after it is a CI in the CMS. A successful IT organization will balance the best practices and

standards with what works in practice and with their particular mix of requirements, constraints, and resources.

Beyond providing support for SACM the CMS is also concerned with the specific processes of onboarding

providers and consumers, once the scope of the SACM process is defined, that is, what is going to be managed.

Note that the CMS processes associated with onboarding do not “care” what decisions were made in SACM.

These processes are intended to “care” that the data that is to be managed is properly rationalized and

authorized before consumption. This is described in detail in the section on CMS Process Governance. Meaning,

SACM calls for particular owners and providers, CMS does not – only that whatever providers are chosen are

properly rationalized before becoming an approved provider.

The asset management lifecycle by contrast is responsible for accounting for everything that becomes an asset,

when it becomes an asset, through when it ceases to be an asset. The SACM lifecycle controls CIs starting when

a service asset becomes part of a service, and exits when the asset ceases to be part of a service i.e.

decommissioned.

The special case of non-service Asset CIs is easily accounted for by simply allowing the CMS to contain the

required CIs. The previous example of a TCP/IP port is relevant here: The port itself carries no fiscal relevance,

has no license, negligible cost, nor is it listed in the asset management system. Yet, it is part of a service and has

the characteristic of being configurable. Therefore the port is validly represented as a CI in the CMS.

Now that the basic principles/definitions have been described, how would this translate into a structure that

allows IT organizations to effectively manage the lifecycle?

24

First, a CMS has become the CI data hub for CIs and attributes, including its relationships and metadata about

CIs or their types (classes). Meta data helps consumers of CI data to find additional data about a CI in other data

sources.

Let’s take a look at our running exemplar, Advantage, Inc.:

Advantage, Inc.’s Asset and CI Lifecycles

Advantage, Inc.’s initial approach was to map the specific interaction between the CMS and their

asset management application (AssetCenter at the time) as shown here. The transition point

from the status of “accepted” caused the CI to become available in the CMS. The CI was

baselined into an authorized state before it is made available for general consumption.

Throughout the CIs production life, Asset Center “followed” the authorized status as changes

were made under the control of change management. At the end of the CIs production life,

AssetCenter once again took the “lead” and implemented the SACM control function of taking the

CI out of production and retiring it, making it unavailable for further consumption from the CMS.

Advantage, Inc.’s Asset and CI lifecycles and their specific transition points

As shown in this example, lifecycles are defined by states and transitions between the states, and the control

and usage of these states and transitions. For example, the CMS is concerned with differences between the

“actual” state as discovered by an auto-discovery system, and the “authorized” state, as approved via process

trusted by the IT organization. Such a difference would indicate that changes have occurred to the real asset.

The processes surrounding change and release management would use and manipulate the CIs and their states

25

to reflect change control, such as verifying a successful change, or detecting an unauthorized change or non-

compliant condition.

Caution: A CI has states, which are not the same as their lifecycle stages. CI states are actual (discovered),

authorized (managed) and future (planned). These states can be managed inside the CMS, by definition. If a

configuration management tool is used to control configuration compliance, it becomes a consumer and

provider of configuration data - it consumes CI activity, e.g. changes and updates, and makes decision against

policies for compliance. It generates and makes available this state of compliance, which itself is part of the

CMS.

Advantage, Inc.

Advantage, Inc. decides that when a CI is procured, it starts its life in Asset Center (AC). At this

moment the CI, although not yet present in the CMDB, is already discoverable in the trusted data

source. In this case HP Asset Center is the MDR (Managed Data Repository) for procured CIs. AC,

used under SACM, will govern a variety of steps in the lifecycle of a CI, but not all steps will be

relevant enough to be reconciled with the UCMDB. Neither will all CI data be reconciled between

the two tools. This is not necessary, because the federation capabilities of the CMDB will allow

you to get additional data on request of a consumer of the CI data. A consumer in this case could

be the person requesting the delivery date (stored in AC) of a CI to a service desk agent.

Implementing a CMS with SACM

First, create a plan for SACM-that provides a clear vision of what you want to achieve. Define and communicate

the goals and objectives, as well as the deliverables, of your SACM process. Communicating these points is

crucial for maintaining project momentum. Document expected benefits in order to build a business case to

support your ITSM program and gain full stakeholder backing. This step includes the following phases:

- High-level requirements

- Scope

- Policies

- Organizational responsibilities

- Individual processes and procedures

- Identify Configurations

High-Level Requirement

Some past SACM projects have been considered overly onerous process because organizations did not properly

communicate the key benefits that it will achieve. List the business goals and any necessary deliverables and in

what order, your SACM process will address. Identify key stakeholders and create a communications plan to

ensure that those involved understand their roles.

26

Scope

Determine the graduations of breadth and depth you plan to cover, including the level of granularity you wish to

achieve, which should provide insight into total project costs. Your scope should include a level of depth that

provides control while supporting agility. Here, a top-down approach seems to work best. If you cannot

immediately identify a need to control the next level, error on the conservative side — you can always add extra

layers later.

Policies

Outline the policies and internal and external standards to which the SACM process must conform — from

guidelines governing naming conventions and the classification of CIs to how the CMS will be updated. Once

these are defined the roles and responsibilities to continue the process management and design must be

published.

Organizational Responsibilities

Establish the organizational roles responsible for carrying out the policies you just outlined. This requires

creating and filling the necessary positions and giving individuals the correct level of authority to carry out their

responsibilities.

Individual Processes and Procedures

Identify the procedures for the SACM project and determine any intersections with complementary processes.

The HP SACM guide provides more detail on specific SACM processes.

Identify Configurations

After defining the high-level requirements, scope, policies, responsibilities, processes and procedures, the next

actions should define in detail the classifications for service assets (SAs) and CIs to ensure they adhere to a firm

standard that eliminates the possibility of duplication or redundancy. The sections preceding this point provide

the kind of thinking and approach to arrive at a solution plan that works for your organization.

Identify Class Model Requirements - Start by determining the classification types of a relatively small group of

service assets, and from this, determine the CI types and groups of CIs (assets) you plan to use. HP provides best

practices as well as a fully functional class model, which does most of this work for you. For more information,

refer to the Data Modeling Guidelines document in the CMS best practices library and the HP SACM Guidelines.

Focus on understanding the classes and attributes, and the hierarchy of CI types and relationships.

Avoid Hasty Judgment on Class Models - Caution: Do not try to immediately apply all your preconceived ideas

of what a class model should look like to the HP (or any other) “out of the box” class model. Doing so will make

any class model appear tremendously deficient, such that any implementation would require major

modifications. It is possible to derive a “pure” class model in a vacuum and want to compare all other models to

it, very likely with major differences in approach and design structure. While the model may be provable, it

must be implemented with technology and implementable in a practical timeframe. Building your own model

from scratch rarely does either of these.

27

CI Type Modeling Best Practice #1: Take some time to understand where a product “is coming from” before

making sweeping judgments on the quality of the class model or the intelligence of the designers. Often, with a

little thinking and deeper understanding, the class model that didn’t make sense last week will begin to make

sense today, given a bit of introspection and by speaking with a domain expert who is able to articulate the

design principles and how the model works with the entire solution vs. for any single use case. If you are in the

process of a PoC (Proof of Concept) or a series of competitive trials to evaluate vendor solutions, you should

remain objective and allow time for each vendor not only to explain and cover their class model in 10 minutes of

a presentation, but also to understand how the class model works within the entire integrated solution.

Take time to evaluate the class model down to the attribute level - After arriving at your preferred

classification scheme, you can establish the important attributes that need to be recorded for each service asset,

asset grouping, and CI.

Start small and grow - Keep the list relatively small to start, so you can easily manage it at the outset and then

grow it once you gain experience. Once you have created classification types, you need to think about the

unique naming conventions for your individual service assets and CIs. Your organization probably has existing

documentation in place to aid this step in the process. In addition to classification types, you must also consider

the types of relationships that make sense for your organization.

Caution: Extremes are problematic: don’t be tempted to define too many or too few relationship types. Don’t

make relationships, CI types, or attributes that you will never populate.

Do things as simply as possible, but no simpler - Just as you did with classification types, start by selecting a

relatively small number of relationship types and build from there as necessity dictates. Follow the “Occam’s

Razor” principle: The simplest explanation that adequately accommodates the circumstances is usually the

correct explanation.

Proactive Use Cases

Today, without several proactive use cases, much of the real value of SACM is in the verification and audit

activities. Taking affirmative action to verify actual state matches authorized state may still find large numbers

of differences.

Hypothetically, if we continue on this path and as we gain further knowledge and control, and improve the

configuration management processes, after a while we wouldn’t need actual state anymore because we have

control of the environment to the point where we can guarantee the result in advance – we don’t need to

validate the result anymore. This of course isn’t auditable – but that is what the data does for you; verify your

process is being effective. It’s an ideal to strive for. Future best practices will focus more on the proactive use of

a CMS, to prevent problems and reduce risk before making decision.

These types of use cases may seem prolific. However, those use cases at the top of the value/benefit curve are

more elusive. Customer research is necessary to find out how they have extended out-of-the-box functionality

(the use case having been worth it) to proactively consume CMS data for continual service improvement.

28

CMS Process Governance

While ITIL v3 is useful, it lacks sufficient granularity be used as a reference to create a functional CMS with the

real-world requirements expected from a modern CMDB. CMDB-oriented content has provided product-specific

practices and content, discovery, and service modeling best practices. A disconnect has remained to show IT

organizations not only what a CMS should look like, but how to envision, plan for, and build a configuration

management system.

Configuration data is often low-level and provided and consumed within processes without direct visibility to the

owning business. However, decisions made using configuration data can affect the owning business in many

ways. This chain of consumers depends on the data consumed from the CMS to be accurate, complete, and up-

to-date. Within the established ITIL, SACM, and ITAM configuration management processes, additional process

is necessary to ensure that inaccurate, incomplete, or outdated configuration elements are not delivered to

consumers.

Experience shows that even when all the ITIL standards are followed it is still possible and even likely to

compromise the data integrity as it moves through the CMS. Errors can also be introduced by onboarding the

wrong data providers, not properly rationalizing the authoritative nature of the data, or selecting the wrong

provider at consumption time. These are mistakes which can be very difficult to undo, especially for a new

project just getting underway.

The Consumer/Owner/Provider Model

HP has developed a CMS-specific model which is useful for constructing the right processes around the CMS to

ensure the highest-quality data is delivered to the consumer. This model, called the Consumer/Owner/Provider

model, or simply the COP model, provides governance for constructing processes that control the selection of

providers of configuration data, the flow of data through the CMS, and consumption of that data. The COP

model works with and around the other standards so standard knowledge and techniques can be used to create

a CMS technical design optimized for a consumer.

The COP model fills the gap between use case fulfillment and the technology and data layers (and fills in gaps

left by ITIL). Unless the CMS is constructed from the beginning with the proper attention paid to the

fundamentals, data integrity will likely be compromised and consumers will suffer from increased risk and

decreased confidence in acting on the data exchanged through the CMS. An approach is required that can

always result in the correct CMS, from design to operation, regardless of variables like the customer’s mix of use

cases, consumers, authoritative sources of configuration data, and organizational and technical capabilities.

A CMS must be designed with the consumer in mind from the beginning. Consumers, who are in reality the

ITSM processes that form the CI lifecycle, must all have a common view of business services and work together

to instantiate, own, provide, and consume configuration data throughout each CIs life.

Tenets

The CMS’s value is the optimization of sharing (providing) and consuming configuration data. The optimization

part reflects timeliness, operational resource efficiency, and increased data integrity to the processes which

consume the configuration data.

29

To achieve this optimization, a consistently high standard must be maintained for onboarding both consumers

as well as providers. The tenets described below provide the foundation for maintaining high data integrity and

performance of an efficient CMS:

1. Consumers drive Providers: Every CI and attribute in the CMS has fore mostly a consumer. An initiative and a use case drive requirements for consumption of configuration data. These elements for all consumers of a CMS form the CMS’s consumership. Despite the best-laid plans and intentions, CIs without a consumer, present for “possible” or “future” use cases, are always more problematic than is worth their existence. Don’t onboard CIs unless they already have a consumer.

2. All CIs Must Be Owned: Every CI and attribute that exists in the CMS has an owner. An ownerless attribute is an un-authoritative attribute. Ownership is specifically established at the attribute, not the CI type level. The owner is responsible for the information layer of configuration data and contracts to provide the data to the CMS from the provider.

3. Avoid Provider Conflict: Every attribute required by a Consumer and having an Owner will be supplied by preferably one provider. Most apparent conflicts are resolvable architecturally and should not require operational conflict resolution. Business logic and accountability are the preferred tools to resolve provider conflict, not reconciliation engines. Reconciliation engines should be used to establish multi-source identity of CIs, and should not be made the “traffic cop” to sort out “backup” or “alternate” duplicate providers after the fact. The business logic of choosing which actionable, accountable, authoritative information is used for decision-making should be done by plan and not operationally.

4. Rationalize all Providers: Providers must be authoritative; that means, only providers who are responsible for maintaining the data should be considered authoritative – replicated copies are not authoritative unless specifically authorized by the owner of the original data (allowing for non-real-time use cases such as replicating to an offline data warehouse, stabilization, or performance reasons.) Providers who have been properly rationalized through a provider onboarding process are called a Managed Data Repository (MDR).

5. Providers are Transparent to Consumers: Consumers are insulated from providers in terms of location, platform, or type of integration. Consumers requiring knowledge of specific providers should be a red flag to the configuration manager because it indicates other problems.

6. Pervasive Data Integrity: Both consumers and Providers must be onboarded with a CAB-approved and management-supported process to ensure non-authoritative providers cannot degrade the quality or confidence of the data in the system, also to ensure consumers are entitled to consume specific configuration data. Ensuring a high standard of entry into the CMS will help increase the quality of decisions made using that data.

The Consumer / Owner / Provider model tenets

These tenets call for specific processes to be created but may not describe all the details of the processes that

would differ from case to case. They are at once best practices and the model for planning, deploying, and

operating a CMS. Where supplemental information is provided, it is done so with the best of intentions that it

will help the architect and practitioner to better understand the intent and overall approach. The goal is to

promote self-sufficiency and drive continual service improvement. These tenets are a starting point for looking

at configuration management in a quality- and consumer- oriented way.

30

Data Model and Conduit Independent

The COP model calls for neither specific providers nor a specific class model. These are the responsibility of

other best practices. The COP model basically says, regardless of what data is provided and consumed, that data

must be authoritative and treated as any mission-critical data, and the CMS must be held accountable to

business standards for maintaining the quality of the data while in the CMS.

The COP model does not require any given CI type to be internal or external to a CMDB. For example, this is

particularly important when considering auto-discovery as a provider. SACM and ITAM best practices call for the

asset management system to be the MDR for all assets, including infrastructure such as servers.

If you are already using an auto-discovered repository as an MDR, you may or may not choose to transition

ownership to the asset management System. Depending on your organization’s specific priorities, needs and

resources, it may or may not be worth making this transition at any given point. The COP model will work

regardless of these types of choices. For more details see the Consumer Onboarding Guide and the Provider

Onboarding Guide in this CMS Best Practice library.

The remainder of the COP Model chapter assumes you may be using auto-discovery into the CMDB. This may be

as the authoritative state, or as actual state, depending on your use cases and capabilities. Either state’s

population must still reflect proper onboarding and rationalization; meaning, even what is discovered/onboard

for actual state must accurately reflect the authorized state of the CMS providership.

COP Model / SACM Intersection

Generally, the COP model provides governance of the processes for CMS provision and consumption. For SACM,

the consumer is the validation and audit activities – that is, validation and audit of the authorized state. This is

done by comparing the authorized state with the actual state. The actual state is provided by the CMS.

Actual state is more than what is provided by discovery. The consumer is not limited by discovered CIs; the

entire scope of the CMS comprises the actual state of a CI. A CI may be composed of attributes which came

directly or indirectly from an autodiscovery tool, as well as attributes from other providers such as various

operational statuses or other authoritative information required by an ITSM consumer.

Control extensions reflect lifecycles. Just as SACM extends ITAM for assets that are also part of a service, the

COP model extends SACM for service assets that are also CIs. The following diagram illustrates how embedded

lifecycles add layers of control.

The ITAM lifecycle “leads” at first, then “follows” the SACM lifecycle within its “in use” state. The SACM lifecycle

continues to “lead” the control function throughout the change management process, while the COP model

follows temporally – meaning, the COP model has already been followed, to properly onboard the CMS

providers and consumers. At consumption time, the COP model only calls for monitoring and creating a record

of the consumption for continual service improvement. As the data is onboarded properly, SACM and other

consumers may then benefit from the superior data quality provided by the CMS because the data is more

trusted – SACM is still “in control”.

31

Embedded Lifecycles: The COP Model extends SACM control function to the providers of actual state.

With SACM as the consumer, the COP model works to provide as accurate and timely actual state as is possible

with the current providers.

Component Relationships

Here is an illustration of how the consumer, owner, and provider fit together. Provision and consumption are

implemented via conduits. A conduit is defined as a mechanism used to provide data to the CMDB or retrieve

data from the CMDB. Consumers and providers are part of one of the ITIL ITSM processes. The CMS is the

bridge between providers and consumers as a single point of provision and consumption, reducing the need for

point-to-point integrations, lowering the cost of managing configuration data, and making the processes

consistent for all providers and consumers.

The CMDB in the center forms the hub for the conduits for the CMS’ providers and consumers.

32

Consumer/Owner/Provider relationships with each other and within Service Context

Providers create and maintain data, some of which is configuration data. Consumers typically consume data as

part of a larger process, and often are passed other configuration data from upstream processes, and pass data

to downstream processes. For example, the many processes a server goes through from inception to

decommissioning.

Differences between the Owner and Provider

The owner and provider differ by perspective, as the table below shows:

Perspective Owner Provider

Entity Person or Group Application

CMS Authoritative Source MDR

Consumer Business Accountability Provider should be transparent to consumer

Quality Accuracy, Currency Performance, Availability

Data Logical, Query, Model Physical, Database, Schema

Security Integrity, Audit Access, History

CMDB Contract to expose the data Responsible for the data itself

Asset fiscal relevance Asset Management Process

Differences in Owner and Provider Perspectives

33

For example, from a quality perspective, the owner is concerned about how closely the configuration data

matches the actual state of the business or ITSM, while the provider’s perspective of quality is around servicing

queries quickly and uptime of the application.

Every Attribute must have a Consumer

Rationale

Despite the name, this best practice is more about provider onboarding than consumer onboarding. The

following sections explain the rationale of requiring every attribute provided to have a consumer, use case, and

initiative before beginning the provider onboarding process.

Efficiency

Requiring a consumer for every attribute avoids discovery-induced clutter and implies a redo at the Move To

Production to clean the production CMDB from testing/PoC remnants and other superfluous content.

Consumerless attributes serve no purpose, consume resources and incur cost.

Exceptions

“Out of the box” attributes. This best practice applies to added or customized attributes. In practice,

system or other internal or hidden processes may “touch” or unknowingly consume out of the box

attributes. Meaning, do not remove an attribute from any attribute of the CMDB class model because there

is no business consumer.

Driving Discovery Strategy

This best practice is particularly useful in discovery planning. Typically, discovery is done in groups of

attributes or CIs. If a unit of discovery work discovers, for example, a server, many commonly-used

attributes are discovered at once. It is acceptable practice for not all these attributes to have a direct

consumer, although it is expected in more capable organizations that technical support teams will want to

lay claim to the consumership of these types of attributes for the purposes of operational problem

resolutions and similar “comprehensive” use cases. Discovery is generally well-rationalized at this level with

today’s technology. HP’s Universal CMDB’s integrated DDM (Discovery and Dependency Mapping) provides

granular control over discovery content generated.

The best practice here is in deciding what discovery not to run. Don’t activate any discovery unless it

discovers attributes required by a consumer. Do not activate all discoveries by default in production.

Testing and Discover-Everything Use Cases

It is important to note that some use cases imply a comprehensive discovery plan. For examples:

- Data center transformations (relocations, virtualizations, DR, consolidations)

- Asset and inventory management systems call for a configuration item for each server and all their

hardware components, application, database, etc.

Even with these use cases, the required depth should be understood and require a consumer before

activating all discovery. By all means, do activate all discoveries in a test environment – performance and

34

stress-testing should be done to the customer’s satisfaction. But do not keep this data when the move to

production is made unless all the discovered data is valuable and still has a consumer.

In summary, approach CMS population from the consumer’s point of view, not a provider point of view. In

other words, don’t start with “What do I need to put into the CMS”. Think “what do I need to get out of the

CMS”.

Security

Consumerless configuration data may not be tracked as closely as consumed data, and may present a

security risk of not knowing if configuration data was consumed under questionable circumstances. For

example; a stale conduit usurped by an individual who “discovered” the still-open access to the CMS.

Data Integrity

Ensuring consumership promotes self-policing of data and speedy resolution of data errors, contributing in

turn to the continual service improvement process for configuration management.

Without firm requirements of consumership, the deployment and operational CMS processes tend to

balloon and become difficult to control.

Implementation

Processes for consumer onboarding must be established, followed, and enforced. The general process does

not need to be more complex than that which ensures that no provider is onboarded without a documented

consumer. Here are the best practices for discovery and federation providers. The same general guidelines

apply for other mechanisms such as API-based providers.

Discovery:

- Unused out of the box attributes may be left as-is, but unused out of the box CI types must not be

allowed to populate

- A discovery unit must have at least one consumer for at least one attribute discovered by that

pattern, or it is not activated

- Integrations which use discovery technology should follow the same practices as for discovery itself

- Discovery overlap between discovery jobs must be eliminated. This applies in several situations,

including:

o When an attribute is discoverable via multiple protocols. For example given an IP address, a

server name could be obtained via SNMP or via DNS. The SNMP host name may differ from

the DNS reported host name, for example an FQDN vs. a short host name. Protocol overlap

creates “flip-flop” false changes and wastes change and history-recording resources.

o Where add-on integration supplants a shallower out of the box capability. For example, a

network manager application (or its database, depending on the instrumentation of the

conduit) is the MDR for network device CI types. These CIs are integrated to the central

CMDB using discovery technology. The network management group are themselves

consumers of the data (consuming additional business context in addition to the

configuration data provided by the network management application) as well as operational

35

and service management groups. The attributes provided by the network management

application are deactivated by the equivalent discovery patterns. This example shows all

four requirements in effect and being met.

Federation, Replication, ETL, and similar provider conduits:

- For existing conduits, out of the box attributes are ok to leave as-is

- If developing a new federation adapter, “out of the box” attributes are defined as those provided by

default for reconciliation or key-matching purposes, but not “sample” attributes which may or may

not apply to a particular federation adapter. In other words, don’t allow “sample” remnants in the

final implementation.

- A provider must have at least one consumer for that adapter to be activated

- New adapters should only provide data which will be consumed. Avoid adding more data for future

use cases until those use cases are properly validated, as this data will be difficult to authorize and

own.

- Attributes not directly consumed but which are necessary for reconciliation, key-matching or key-

building, etc. are exempt from consumership requirements.

Every attribute must have an Owner

Rationale

Ownership is critical to the model because it is the point of common coupling to the authority of the

provider data. Ownership ensures the state of the configuration data is maintained, as well as

accountability and chain of command for data accuracy and error handling.

Implementation

An approved use case calls for a new attribute to be onboarded and the attribute does not yet exist in the

system. If the attribute is available from an existing provider, only minimal process is necessary beyond the

normal change control to approve the consumer and new data to be provided, and add the attribute to the

provider and consumer technology.

If ownership cannot be established for an attribute, there are two possible choices:

1. The attribute cannot be considered authoritative and cannot be onboarded to the CMS 2. The attribute is new or does not currently have an owner, yet nevertheless is valuable. An owner

must be designated and the authority of the data rationalized.

Choice #1 implies a remediation or application development project. Choice #2 implies owner onboarding in

concert with provider onboarding. Here are the high-level guidelines for establishing ownership of an

attribute:

- Ownership must be identifiable for any CI at any time

- The owner of the data is responsible for the accuracy and integrity of the data

36

- The owner of the data must be empowered to make corrections and otherwise manage, create,

delete, or otherwise manipulate their configuration dat.

- The owner of the data may or may not be the same as the data provider (application manager of the

provider). For example, the owner of the data may be the configuration management group, and

the provider of the data may be the service desk application owner.

- Ownership may change as the capabilities of an organization grow. A CMS implementation implies

changes of this kind. For example, ownership of configuration data in the past was synonymous

with ownership of asset inventory data. However, modern CMDB systems typically operate with

asset/inventory providers only owning the tracking and sometimes financial elements of assets

while the inventory scope and content itself is owned by infrastructure management groups (the

“server owners”).

This ownership transition must be accounted for by process to ensure consumers are properly redirected

both in operation and for change management, problem resolution, etc.

Each Attribute has Preferably One Provider

Rationale

When provider overlap exists, conflicts arise during consumption which must be resolved. This operational

conflict resolution is costly both architecturally and operationally. While earlier approaches called for using a

reconciliation “engine” which employed heuristics or weights to resolve conflicts, this approach is problematic in

scale. Ideally, the reconciliation engine exists to simply act as an identity broker to find the same CIs in multiple

sources (but not the same attributes used for consumption, except for the identity-establishing attributes).

The solution is not as simple as designing a more efficient algorithm. The decision to choose between one or

more providers of the same attribute cannot be bought off with automation – business logic must still be

reflected in the choice of provider.

This problem brings us to the premise; the best conflict is no conflict. Rather than allow multiple providers into

the CMS in the first place, a policy of conflict avoidance allows an incumbent attribute’s provider to remain

authoritative and to effectively negate the need for any other provider to provide that attribute.

The Mythical Second-Tier Provider: There is an argument which has been overused to defend multiple-provider

operational conflict. This is the “what if a provider ‘goes down’?” scenario. What if the provider of an attribute

becomes unavailable for some reason? Wouldn’t we want to have a ‘backup’ provider? In theory, this sounds

good. However, in practice, one must realize who these providers are – they are the service desk, the asset

manager, the operations monitoring system, the security management system. These are mainstream

applications, warranting immediate action if they ‘go down’. This author cannot imagine an IT environment

where the highest priority would not be restoration of one of these type applications. Any application holding

authoritative configuration data that suffers an outage will create much bigger problems than availability to the

CMS. These types of highly-available applications have backup and recovery and failover systems unto

themselves, for reasons beyond configuration management: IT depends on them; therefore, there is no

‘second-tier provider’.

37

When an attribute is sourced by multiple providers who do not overlap in scope, there is no conflict. For

example, two different authoritative applications both contain the same or similar network management data,

but for different devices, perhaps in two different data centers.

Ideally there is one application for the entire scope of configuration data, but in reality this is not the case.

However, the practice of conflict avoidance is still sound, and if followed from the beginning of the CMS

deployment, will effectively eliminate the need to handle unforeseen operational conflict, and render

manageable the few outlier cases which may arise. Either way, the bulk of the resources required to otherwise

manage this now-unnecessary operational conflict is still avoided, with the resulting ROI gain.

What Causes Provider Conflict?

The COP model is designed to minimize provider conflict. If a provider is truly authoritative for its scope and

type of configuration data, why would the business require an additional provider? The reality is – it

happens, for understandable reasons. Remediation can be an application consolidation project, an

acceptable-risk amendment, time-window based, or primary-secondary provider. Otherwise, subsequent

“candidate” providers are simply not onboarded.

Understanding how these apparent conflicts arise gives insight into understanding how to avoid, rather than

engage, operational conflict:

The Waste-Anything-But-Time Scenario

Periods of rapid business growth (for example, through business success and/or mergers and acquisitions)

often compress silo decisions in the haste to provide services without regard to efficiency, or TCO.

For example; two different groups are conducting auto discovery. Both are considered authoritative by their

consumers and by the CAB. Which source is federated to the CMS? A: Whoever reports the data to

business management. It will invariably be one or the other – in essence, the CTO doesn’t have time to read

two reports that have the same data gathered from the same place. That source is federated to the CMS

and the other is not.

The Integrate-Now-Ask-Questions-Later scenario

In an effort to provide early value, production pilot projects and re-used PoC CMDBs may onboard non-

authoritative “low-hanging fruit” in an order to “show something”.

Often, this non-authoritative source is difficult to decommission because of the loss of investment and the

tendency to accept a lesser authority, lower-quality provider in exchange for no additional onboarding work.

This is usually a mistake, unless it is understood by the owner and there is a transition plan in place to

decommission the non-authoritative source in lieu of an authoritative one, or authorize the non-

authoritative source (unlikely, rare). In one instance, conflicting provider data was intentionally introduced

into a PoC by a vendor in order to demonstrate the conflict resolution capabilities of their configuration

management software.

For configuration management providers, less is more. Identify the one true authority of each attribute and

enforce this.

The Depends-on-Who-You-Ask scenario

38

Data may appear to be authoritative when it in fact is not. It is important for the CMS solution architects to

ensure they are rationalizing authoritative sources from a business accountability perspective, not

necessarily the end-consumer perspective.

Implementation

Process

The process for onboarding providers must avoid conflicts between providers from a business perspective.

Meaning, if one provider can provide an attribute, and is accountable to the business for the accuracy of

that attribute, then that provider is the authoritative source.

Any potential conflict which cannot be resolved architecturally must have a predefined plan to resolve any

conflicts expected to occur. There should never be an attribute whose authoritative source is unclear or

unknown.

Security

Security should also be enforced for updating configuration data. Owners, groups, roles and rules in the

CMS Security model should account for explicit or implicit access depending on the customer’s security

needs, extending down to who can update which attribute , based on ownership of the attribute and the

authority of the consumer.

Exceptions

Any attributes necessary for reconciliation, key fields, and other internal or system attributes.

Replication is not a conflict

It is NOT a conflict if an MDR is replicated to a secondary physical data store, provided

- The chain of ownership and authority is maintained

- The “switch” remains transparent to the consumer (the consumer setup will obviously be different,

but the consumer, once set up, will not need to care any more than before about conflicts)

- The consumer can tolerate any latency introduced by the replication conduit. This is reality and is

done for a number of reasons, including insulating users from the MDR or the MDR from users, for

performance, stability, security, or data warehousing. Here, “latency” refers to an available service

for routine consumership. Technical problems such as Exception-handling, timeouts, etc. must be

handled but is not in the scope of this document.

Backup Availability is not the same as Provider Conflict

Replication is often done to increase availability, or to isolate critical online systems from bulk

consumership, e.g. data warehousing. Availability of both direct and indirect providers should be

architected according to the needs of its consumers, including the CMS. If a provider goes offline, this is

not a reason to disregard the unique provider rule! Switching to a DR or backup system is just that; an

availability and operational issue, not a provider conflict issue. In this situation, the conduit, logically, would

remain the same and the COP tenets are not breached. See The Mythical Second-Tier Provider earlier in this

section.

39

Provider Authority Must be Rationalized

Rationale

Maintain Maximum Data Integrity

In order to maintain a high quality and integrity of data exposed to consumers by CMS, the points of entry

and exit must be tightly controlled. This means, defining processes which are achievable by the IT

organization, not deviating from them, and most importantly, avoiding certain common scenarios during

deployment which can create problems and decrease data integrity.

Conflict Avoidance Enabled/Occurs Naturally

If provider onboarding processes are followed, most multiple-provider conflicts are identified during

planning, not operationally, and can be resolved architecturally as well.

Replication

As discussed elsewhere, a workable model must account for MDR replication, where it is desirable for

authoritative data to be consumed indirectly. The following conditions must be accounted for:

- The consumer must be able to tolerate latency introduced by the replication conduit

- The owner of the replicated data must be the same owner as the MDR, or, a directly designated

authority

- The chain of authority must be maintained. Except for any time-based devaluation of the data, the

replicated data shall hold the same authority as the MDR.

Implementation

Rationalizing Provider authority is realized by the following practices:

- Provider is authoritative from a business accountability perspective and ideally no other. There are

many perspectives which will misidentify the authority of a provider and lead to conflict, such as the

end-user perspective (the end users will always state that whatever data they consume, from

whatever existing source they consume today, is authoritative).

- CMS practitioners should be prepared for many questions on this point. Ultimately, the case rests

on a single premise, that from a business perspective, one cannot have two authorities for a single

attribute at the same time. Any argument otherwise must be analyzed and the chain of business

accountability is revealed. If new data is being introduced, business accountability must be

established. If data is changing owners, business accountability must also reflect the transition.

- Outcomes: The rationalizing effect of this chain of reasoning will lead to either

1) an agreement in general or specifically that a single provider should be chosen,

2) a conclusion that neither provider is authoritative, and whether more work needs to be done to

provide the required data,

40

3) an as-yet-unencountered scenario which will add to the exception list or cause the process to be

modifed in some way.

- Requiring ownership of any/all onboarded attributes

- Verifying provider is part of the ITSM platform and therefore authorized to manage part of the

CI/Service lifecycle. Consumers may depart from this, but not providers.

- This item is specifically intended to exclude “opportunistic” provider/consumer pairs who would be

better served with an application but not the CMS. Consumers’ use cases should be configuration-

related, or ITSM-related, e.g., incident/problem/change/release management, operations

monitoring etc.

- For example, the following table of providers shows some sources which should and should not be

authorized to provide configuration data to the CMS:

41

Examples of Authoritative and Non-authoritative Provider Candidates:

Source Candidate

CI Types

Business

Responsible

Primary

Consumer

ITIL Process

Domain

Authorit

ative?

If not,

who?

Service Desk incident

problem

Yes Operations Incident/Problem Y

Chg. Mgr. RFC Yes IT Change Mgt. Y

Server Admin Group’s internal database

computer Entire list - No

+++

Server Admin Group

Release and Ops Mgt. No* Asset Mgr

Network Node Manager

network device

Yes Infrastructure Mgt.

Asset Mgt Y

Auto-discovery

network devices with

NNM above **

No Config Mgt Config Mgt N

NNM

Auto-discovery

windows and UNIX servers

Yes IT Config Mgt. Y

Bob’s XLS all UNIX servers

No Network Group

Non-infrastructure N Asset Mgr.

Bill’s Access DB

contract No Finance Asset Mgt N Asset Mgr.

Auto-discovery + fiscal input

Asset Manager

Yes IT Asset Mgt Y

SAP*** Servers No Asset dept. Asset Mgt N Asset Mgr.

Data warehouse (replicated)

Any No CAB Change Mgt verification

N

Actual State Discovery

Service Desk incident

problem

Yes Operations Incident/Problem Y

Chg. M

RFC Yes IT Change Mgt. Y

42

gr.

Server Admin Group’s internal database

computer Entire list - No

+++

Server Admin Group

Release and Ops Mgt. No* Asset Mgr

Network Node Manager

network device

Yes Infrastructure Mgt.

Asset Mgt Y

Auto-discovery

network devices with

NNM above **

No Config Mgt Config Mgt N

NNM

Auto-discovery

windows and UNIX servers

Yes IT Config Mgt. Y

Bob’s XLS all UNIX servers

No Network Group

Non-infrastructure N Asset Mgr.

Bill’s Access DB

contract No Finance Asset Mgt N Asset Mgr.

Auto-discovery + fiscal input

Asset Manager

Yes IT Asset Mgt Y

SAP*** Servers No Asset dept. Asset Mgt N Asset Mgr.

Data warehouse (replicated)

Any No CAB Change Mgt verification

N Actual State Discovery

* Silo applications are a prime source of miss-authoritative data. Typically they are internal in scope, not accountable to the

business, and a duplicate discovery with their “preferred” tool. To the users, this is the ONLY source, but to everyone else,

it’s a copy. This is a common trap to fall into, especially if the server admin group has a lot of political power or is even

driving the configuration management initiative.

+++ However, if the server admin group creates a business-accountable attribute for the server – for example, “current state

of deployment” or “Rack/Cabinet/U# space”, then that attribute, and that attribute only, would be authoritative – but not

the entire list itself. The server names etc. would be used to reconcile the authoritative attribute with the CMS, and

continue to be used by the server admin group without a violation of any of the COP tenets.

**This source could be authoritative if NNM or other network management system is present, but is not authoritative

because network devices discovered by other patterns are superseded by for example NNM data which would be

authoritative and provides additional information for network devices.

***This source is not authoritative because SAP gets its server list from the Asset system. SAP users may say SAP is

authoritative when it in fact is not. This is a dangerous and important trap to avoid when onboarding providers.

43

Providers are Transparent to Consumers

Rationale

If consumers have to “know” who is providing data, in order to decide which configuration data to use, this is

additional overhead the consumer should not be burdened with. If providers are properly rationalized,

authorized, and onboarded, the consumer will not need to know about the provider in order to confidently

consume the data. More strongly, a consumer should not be allowed to ask for a specific provider due to the

possible detrimental effect to the CMS. Provider-specific consumer requests risk setting a poor precedent which

could be difficult to isolate or undo for future use cases.

Implementation

- Implement a No-conflicts policy from the consumer perspective

o Never make the consumer need to know who or where the provider is.

If this is happening, it is probably because the provider must resolve conflicts.

- Make it the Owner and Provider’s responsibility to expose the right data in the right way.

o This is not to say that new consumers may need to comply with certain data format or

model conventions. It means, when there is a choice for either the provider or the

consumer to manipulate the data, and the need is common to all consumers of that data,

the provider should do this once vs. each consumer doing the same thing but with slight

variations. The thinking is to optimize the work required to prepare and present

configuration data. The best way to do this is to eliminate 1-offs and supply reasonable

standards for consumers, but to recognize truly unique needs if the business value is worth

creating a new consumer process.

- For specific formats and recommendations for consistency, refer to the Data Modeling Guide

document in this library.

- Applies to any provider and any provider technology (federation, discovery, integration, etc.)

Replication is not an exception: If a consumer is to consume data indirectly from one or more MDRs, the

changes in the consumer onboarding to “point” to an indirect data source, and the mechanism to replicate

and store the data, is not considered a breach of transparency. As mentioned elsewhere, provided the

consumer can tolerate any introduced latency, and the indirect data is owned and as authoritative as the

original data, the consumption itself is still considered transparent.

Questions of Authority: If a consumer questions or doubts the authority of the configuration data

provided, the configuration manager is responsible for settling the question. It is the obligation of the

configuration manager to satisfy the consumer’s question and as much as possible, instill confidence in the

integrity of the CMS. However, the configuration manager holds the choice of action to take, except for a

management override as described below. The configuration manager may, at their discretion, exercise

options such as the following:

- If the question is not about the provided data, but the process of provision itself, that is, questioning

the conduit or the owner, then the configuration manager may provide documentation or

44

explanation to the consumer which may satisfactorily demonstrate the process followed to

rationalize the provider. As recourse, the consumer may revise their requirements, ask further

questions, or refuse consumership until the requirements are met or questions answered. The

configuration manager may then initiate processes to:

o Satisfactorily further rationalize or authorize the existing provider

o Replace the existing provider (this is not to be taken lightly!)

o Decline to provide the data to the consumer

o Answer by demonstrating or showing the consumer who the provider is

- If the question is related to the configuration data itself, put the consumer in touch with the Owner

or provider manager or administrator. Also, the configuration manager may demonstrate the

integrity of the data by directly showing the consumer how the data is populated, collected,

secured, etc.

- Decline to further questioning, upon which the consumer may escalate the situation or withdraw

the question.

Note: These practices are not absolute and must be adapted for each IT organization. The strong tone of

language used here is a verbiage example, representative of the authority and dedication to uncompromising

integrity of the CMS needed to make your CMS work best. To concede to lower standards, especially for a single

consumer, is a dangerous precedent and could compromise the integrity of the CMS to other consumers, and

should be avoided unless the consumer holds sufficient executive authority to change the rules, who then

assumes all accountability of the risk of doing so. Clear, stringent processes are especially important when

problems arise and difficult compromises made.

Onboarding Processes must be followed to Protect Data Integrity

Provider onboarding refers to the processes and workflow around adding scope to the CMS.

Consumer onboarding refers to the processes and workflow around setting up new consumers, or adding

content scope to an existing consumer.

Rationale

The purpose of CMS is more than to manage and expose configuration data to consumers when and where it is

needed. The processes of setting up the CMS providers and consumers must result in a high quality of data.

Within CMS, “quality” is defined as, sufficient trust in the accuracy and timeliness of configuration data as to be

able to make reliable decisions with it.

45

CMS Design and Planning

High-Level Recommendations

By now, you should have a clear understanding that designing and implementing a CMS is complex but possible,

and involves significant planning and effort but can be very rewarding to your IT organization. A summarization

of the design and planning recommendations mentioned earlier in this strategy guide is presented here.

- Use the Value Chain - To link the value to the CMS, start from the business services rather than the IT

services. Document the value chain for your organization that demonstrates how the CMS will help your

business be more profitable or competitive, using the value chain method as shown earlier.

- Focus on process before technology – Do not substitute technology for process. You must create

processes that protect the integrity of the CMS. Ensure process is present that meets your needs and

works best for your organization.

- Measure Value from a Business Perspective - Ensure the planning and design team is clear on the

expectations of the value chain. Supporting infrastructure services will probably be necessary at first,

but the CMS must ultimately be tied to how it supports the business (money-making) services.

- Protect the Integrity of the CMS from the beginning - Plan for the highest possible data integrity from

the beginning. Don’t spread on the data integrity layer after the “important” work is done or as an

afterthought or with whatever remaining budget you have left.

- Put the use cases before the providers - Do not assume you’ll have a use case in order to give your

implementation consultants some work to do. Think about your consumers from beginning, and think

about your providers second.

- Start small - Many failed projects are due to taking on too much too early. Start with a valuable but

limited, achievable deployment and expand as your experience grows. There is no substitute for the

kind of experience you gain from implementing a CMS so do not fall into the trap of making too many

assumptions about the future based on others’ past experiments or experience – proof the

implementation for your IT environment for everything.

- Use the COP model - Rationalize and implement each consumer and provider without exception, even

in the face of using billable consulting time, impatient executives, looming deadlines, etc. Any breach of

the rationalization processes for both consumers and providers will reduce the trustworthiness of the

CMS and can be very difficult to correct later on.

- Get professional help - If possible, use experienced planners and implementers to reduce risk and

accelerate value realization. Implement as quickly as possible – but no quicker. HP offers several

alternatives for customers seeking design, planning, implementation, and operational help.

- Understand the similarities and differences in your organization – it has often been said that customers

believe they are more different from their competitors than they really are, and vendors think

customers are more similar to other customers than they really are. The reality is somewhere in

between. Because the IT management industry, and configuration management in particular, is still

46

maturing – behind, say, asset or service management - A CMS must be your CMS. No one can make this

journey “up the mountain”, but you can get some advice. Do not buy in too much to any one vendor,

analyst, white paper, etc.

Multiple data Repositories in a CMS in Practice

Now that some of the concepts of a CMS has been explained (and hopefully clarified and understood, if we did

our jobs), you may have questions about how to use your new understanding. Implementing a complex system

based only on understanding is unwise. In this section we try to supplement your understanding of the concepts

with precedent and practice of implementing a CMS, in terms of sorting through the multiple MDRs of which

your CMS consists. In your final CMS, configuration data will most likely exist in more than one repository. For

example:

- Incidents, problems, change requests, and SLAs exist in the service management application

- Assets and other fiscally relevant information exists in the asset management application

- The operational state of a server exists in the operations monitoring application

- The real-time security state of a router exists in the security management application

These different data stores naturally use several methods of keying data

For all these repositories to share data, that data must have common identifiers to allow comparisons to

establish identity. These comparisons need to tie to IT processes (like configuration and change management)

to control the transition between the states. This way, unplanned or unauthorized changes (not in the change

management system) can be trapped and handled accordingly. See more details in the section below titled

“Data Model Mapping and Reconciliation”, as well as the document titled “Data Reconciliation and

Normalization Reference” in the CMS Best Practices Library.

A CMS usually contains data from multiple MDRs, depending on the stage it is in its lifecycle (early stages by an

asset management solution such as HP Asset Manager) or the class of CIs (e.g. Network components from HP

Network Node Manager). On top of this a CMS supporting tool as HP Universal CMDB can leverage its native

discovery tools like DDM.

There will in some cases be an overlap. This overlap must be analyzed and rationalized according to business

rules, and preferably eliminated (except for the special case of identity reconciliation) during the solution

architecture phase. It is considered poor form to allow operational conflicting provider data to enter the CMS.

This strategy guide describes a process by which overlap can (and should be) eliminated. As a benefit, the

quality and trustworthiness of the data is increased. In short – do not fall into the trap of assuming there will be

or should be multiple providers.

It is not uncommon that a CMS implementation will use a combination of the above. This leads to the following

requirement: a CMDB MUST HAVE the capability to reconcile CIs from various data sources. There should be

only one trusted data source for a certain CI in a particular phase of its life.

A CMS can have multiple data sources that can act as an MDR. Those MDRs will usually hold CI data for the

purpose of supporting another process, not relevant to configuration management.

47

Data Model Mapping and Reconciliation

MDRs contain data which must map to the CI type model in the CMDB. A group or person implementing a CMDB

may want to go through an exercise of defining naming conventions for the CI classes, CI attributes and

relations. Although this is possible, it is not practical. A mature CMDB will already have a CI type model and

have proper names for the majority of all needed classes, attributes and relationships, which can be extended

where needed.

Now a mapping can be created between the CMDB classes/ attributes and the MDR. These mappings are

defined and used by conduits, such as federation adapters, ETL tools like HP’s Connect-IT or in HP’s DDM

(Discovery and Dependency Mapping). The mapping must accomplish at least two things:

- Identity equivalence – Reconciliation establishes identity equivalence. There must be enough

common data so that the identity of the data in the MDR and the CMS can be established. This can

be done with whatever data is available. Preferably, only the minimum amount of attributes

required to establish identity is used.

o Identity-purposed data - Preferably this is one attribute, such as a serial number, asset tag,

“Universal ID” or other data which is specifically intended to carry identity.

o Data which also carries identity – If necessary, data which is intended for another purpose

but which also carries identity. Often used as a composite of other attributes which

together establish identity. For example, the host name + IP address, or, a location + rack +

mount + U number.

- Data equivalence – Mapping different data models together. Transformations establish data

equivalence. Transformations must account for:

o Data type casting – For example, translating a string representation of “42” into the integer

value 42.

o Formulaic conversions – For example, English to SI units, C to F conversion, and other

transformations which are programmatic or formulaic in nature.

o Attribute splitting – Dividing an attribute in one model into several attributes in another

model, for example, one attribute containing a person’s name in the format “L, F, M(s)” to

another model that stores F, L, and M(s) names in separate attributes.

o Attribute aggregation – Taking data from multiple attributes and concatenating them

together, possibly with some additional space and place holder characters such as commas

or spaces, and according to some business rule. For example, taking a person’s name as

stored in three attributes named F, L, and M, into a single attribute called “name”, in the

format “F, L, M(s)”.

The nature of the conduit will determine further characteristics of the mapping such as the frequency of

execution, how key reconciliation is to occur, where the keys come from, etc.

Using Automated Discovery Supporting Verification and Audit

One of the activities performed within the configuration management process as defined by ITIL is “Verification

and Audit.” Given the technology available today, many organizations rightfully attempt to verify the integrity

48

of their CMDB through the use of tools that are capable of monitoring configuration items. Being able to

automatically monitor CIs as they change states is therefore, critical to a formal implementation of a

configuration management process.

Some organizations have, in the past, thought that monitoring their CIs would suffice in place of fully

implementing a configuration management process. This has proven to be an incorrect and potentially costly or

damaging approach.

Tools, such as HP Release Control, certain modules of HP Service Manager, and HP Universal CMDB are

examples of the types of solutions available for monitoring various configuration items. Software agents or

probes (agent-less monitoring) need to be deployed to managed CIs (based on the requirements of the specific

tools) and the resulting scanned data can then be used to automatically populate a CMDB or produce

discrepancy reports, based on a comparison between what was discovered in the CMDB and the real production

IT environment.

When differences are found, they should be addressed immediately, as the CMS is only as reliable as the data it

contains. Typically, this is done through a remediation sub-process. This means differences between the CMS

and the real world environment need to match against the authorized state of a CI as stored in the CMS. The

planned state is created as part of the change management process.

Practical Limitations

Caution: Discovery technology can but should not reach into every file, every element, because such a discovery

would result in many millions, if not billions, of CIs. Therefore, today, the “planned” state refers in practice to a

CI associated with a change request.

If no match can be made, it is a possible that an unauthorized change has occurred, indicating changes are being

made to the production environment without going through the change management process, or that there is

some kind of break-down of the change management process.

Some organizations may choose to use their monitoring tools to populate a CMDB or inventory system (Asset

Management) on a daily basis instead of a formal configuration management process. But, to do so is a mistake.

Consider the following example:

49

Advantage, Inc.’s “Discovery” Plan Changes Rapidly

Initially, Advantage, Inc allowed their discovery tools to replicate MDR data into the CMS daily

such that their CI info was at most one day old. Initially they thought this would be sufficient for

most use cases. However, detailed discussions between the configuration manager and the

business owners began to reveal a disturbing pattern.

Both teams quickly realized that the use case’s tolerance for latent data was in fact unacceptable.

In order not to be denied the data, the consumers had assumed there was no way around the

latency even though it would produce less-than-trustworthy results. Investigations revealed that

for change analysis and operational use cases, data that was one day old was not acceptable.

Unless the data was provided that was as current as was stored in the owning MDR, the business

analysts stated they could not use the data for much more than service modeling, and in the past

for this reason they stopped looking at the data altogether.

Having learned of federation, they began working to integrate their configuration management

process with the change management process, to proactively detect incorrect CI information and

correct it as quickly as possible, ideally in less than 24 hours to regain their analyst’s confidence.

If the analyst has visibility to the actual state information then they can count on that information

to resolve an incident, plan correctly for change, and much more.

Author’s note: This is an example of a conscious decision to federate versus replicate from MDRs

in the CMS, based on the use cases. If replication somehow is the best decision, replicate.

However, federation is more efficient (no bulk data moved, only what is queried) and the data is

as current as it is in the owning MDR.

Maturation and Migration Strategies

As mentioned earlier, not every IT organization needs to “mature” or “evolve” from where they are now. Have

you optimized all IT services? Are your service levels of availability and support acceptable? Has the business

suffered no financial impact from any IT issues? Is the business growing, leveraging IT to a competitive

advantage, or at least fulfilling its mission unimpeded by any lack of IT service or resource? If so, you may be

“OK” may not need to change further. Otherwise, there is room for improvement.

If the room lies in any IT Service, and you do not have a formal configuration management process, it is likely

your IT organization can benefit from implementing a CMDB and CMS. But the question remains, how do I get

there from here? Depending on your existing model, you may have more or less work to do.

This is a commonly used model. Discovery acts as both discovery as well as an integration framework for other

providers. Discovery and /or the populated CMDB are often considered authoritative for infrastructure,

applications, dependencies, and/or services. Auto discovery is the primary or only means of populating the

CMDB. Federation, APIS or other “conduits” may not be present. The class model is defined by what needs to

be discovered.

50

Consider Advantage, Inc.’s scenario of a CMDB with discovery. It depicts Advantage, Inc., at an

earlier time in their company history:

Advantage, Inc.’s Original CMDB Solution Architecture

It is important to note that this scenario may or may not have much to do with actual configuration

management. Configuration management may still be “fragmented”, in the stages of being parts of other

processes, or as a function of asset management. A fully functional CMS will unite configuration management

into a single process which is much more efficient and delivers higher-quality information than the fragmented

model. However, this will not happen immediately, and should for that matter happen only with a conscious

decision to change it. In other words, if you are realizing value from this model and there isn’t a compelling

reason to change it, then you should not change it because ITIL or ITAM or SACM or any other vendor or analyst

says you should.

Use cases can range from application mapping, asset/inventory and data center transformations (DR planning,

migrations, relocation, consolidation, etc.) The IT organization may or may not have a formal change

management process, is probably not detecting unauthorized changes, and discovery may be serving a single

use case. For example, discovery may be placing CIs only in the service desk, operations monitoring, or the

network management applications. Multiple discovery technologies may be present and reflect a silo

organization.

This scenario is depicted here expressly to emphasize that no standards body can replace a clear use case

fulfilled by existing technology which produces clear value and fills a clear need. If this resembles your situation,

and you can positively answer the questions near the beginning of this section, then you may not need another

strategy, even one “more aligned with ITIL” or similar initiative.

However, if you are doing this and still having problems related to configuration management (or lack thereof,

such as unsatisfactory SLAs related to change-related outages), perhaps consideration of advancing this model is

warranted.

Many HP customers are moving towards a CMS from this perspective. While not a fully implemented CMS in

terms of configuration management, the introduction of federation establishes an ecosystem of consumers and

providers of configuration data.

51

Here is Advantage, Inc.’s updated model following their original scenario:

Advantage, Inc.’s Solution Architecture adding Federation

Originally, Advantage, Inc., considered this updated architecture as simply adding another choice

of provider conduit. However, the effect was profound. Federation enabled AI’s CMS to provide

real-time status and states from their providers. But process-wise, it began to enable the ITSM

processes to share each others’ data in a more meaningful context. Consumers could ask the

CMS for CIs without regard to where the individual attributes resided. Federation paved the way

for the providers and consumers to take shape as a CMS and move toward a more governable

position using SACM.

Federation also reduces the latency associated with replicated data – the data is left in the MDR and queried at

consumption time rather than periodically. This potentially enables other use cases which require real-time

data which could not be fulfilled with replicated data. The data is as accurate and current as it is in its native

MDR.

For SACM-based CMS deployments, discovery of infrastructure and applications is moved to the asset

management System, and federated to the CMS. The CMS may still have discovery of services going directly into

it.

In practical terms, “Service Discovery” is distinguished from “Asset Discovery” by two things:

1) Relationship and dependency discovery which serves to identify the structure of services

2) Non-service asset CIs such as our aforementioned file containing configuration data.

52

For Advantage, Inc., this yielded a SACM-based architecture basically similar to the following:

Advantage, Inc., –SACM-based Solution Architecture

Considering the previous diagram, in terms of generic providers and consumers, Advantage, Inc.,

found it difficult to know whether or not they were actually “doing” configuration management.

For example, auto-discovery populated the CMDB with CIs, which were arranged into service

models (application maps) and were used by application owners to validate application

architecture, and other business purposes. The consensus of AI’s CAB was that no configuration

management per se was occurring.

However, one consumer was a user creating an RFC (Request For Change), and consumed the

exact same service model to make a decision about the details of the RFC. AI realized after

analyzing this that configuration management was in fact involved, because the consumption was

part of the change management process. Change management was the consumer and discovery

was the provider – under SACM control.

So if you apply a domain layer, the domain of configuration management, you now have both sides of the

equation: The enabling technology, and what to do with it.

This domain layer is the documented configuration management process. As previously mentioned, SACM is the

control function of the CMS. Configuration management is what places CIs themselves under the Change

control process. This domain layer calls for specific providers and consumers and specifies the type of CIs

exchanged.

Providers and Consumers may be the same group, process, or application: Previously, consumers have been

depicted separately from providers. However, in practice, the consuming processes and the provider data

sources are really parts of the same thing. It is easy to imagine Application “A” providing Consumer X with some

CIs which X goes off and uses for a defined business purpose. However, in ITSM reality, the provider and

consumer may be highly interactive with each other, up to and including residing in the same application. Each

process has defined interactions with the other processes, under defined use cases, with defined data types, as

called for by SACM.

For example, here is how the change management process interacts with the CMS:

53

Change Management Interaction with the CMS

Change Management Process CMS Interaction drill-down

This diagram shows the workflow tasks within the change management process and how each one interacts

with the CMS. For example, when an RFC is created, the CI representing the asset to be changed is updated to a

status of “planned”. When the change is implemented, the CI is updated to reflect the change.

Operations Monitoring Interaction with the CMS

The Operations Monitoring Process Interaction with CMS

54

Downstream of the release management process, operations begins (or continues) monitoring services and

service assets. The operations monitoring process is responsible for and owns the Operational status of each

element and service. This status may be federated to the CMS for other consumers to use and make decisions

on, for example, whether a change should or could be performed on an application based on its operational

status.

If / when the operational health of a service changes, a process is initiated to evaluate and if necessary restore

the status back to the desired state. The operational monitoring process is said to be “upstream” of the incident

process, as changes to the operational health ‘feed” the Incident process.

Operational Monitoring Feeds Incident and Problem Management

Incident and Problem Management CMS Interaction

When an incident is created, the Service Desk now owns a relevant piece of configuration data – the fact of any

incidents being open on a configurable element or service. This fact may change decision being made in other

processes, for example, a change request which is unrelated to the operational health change in the previous

example. Unless that change request process “knows” about this incident, it is possible that the change request

could be created and implemented at the same time changes to restore the operational health are being

applied, creating a “collision”.

Collisions of this and similar types are a leading cause of service unavailability. This is one of the key values of a

CMS: shared context.

55

Change Management Feeds Release Management

The Release Management Process Interaction with CMS

Likewise, the change management process is upstream of the release management process and feeds the

release management process with data required to deploy the changes.

Downstream of the incident and problem processes is the change process. Incident and problem data are used

to create a change request to correct and prevent the problem that affected the operational health of the

service.

Advantage, Inc. Change Management Case Study

Now, we will explore a case study using our running exemplar, Advantage, Inc. The case study is meant to show

you how a CMS is leveraged as an enabler of organizational change required to implement new processes. The

idea is to show you something closer to a “finished product”. Once you establish an operational CMS, the

problems and variables change from implementing technology to implementing a hierarchy of processes that

leverage the CMS. The processes create and amplify CMS value through implementing and improving ITSM

processes such as change management. Since change management is one of the most important and early

processes, we review the “end game” of Advantage, Inc. ‘s change management process implementation. You’ll

see how the CMS providers and consumers evolve, and how both IT and the business evolve their understanding

of each other and of how to manage change. We start with the moment AI has created the CMS and is ready to

fulfill their use case of reducing change-related impact to MTBF. As an aid to understanding, text that

references the CMS are highlighted in blue bold text like this.

56

Advantage, Inc. Case Study – Reducing Change-related Outages

Advantage, Inc., implemented their CMS in part to reduce change-related outages. Specifically, they wanted to evolve their change management process to include the following policies and activities that could leverage their new CMS and configuration management process. AI amended their change management process to include the following requirements.

- Impact analysis must be done for each change, to determine any potential impact to business services. Any potential impact was considered a risk, proportional to the business criticality of the potentially affected application.

- Risk analysis must be done for each change, to identify any factor which could individually or combine to cause problems with the implementation of the change. The following factors were identified as the most critical factors:

o Historical record of changes of the same type

o Historical record of changes to the specific target of change

o Historical record of the success record of the implementing team or person

o Historical record of incidents and problems of involved infrastructure

o Expected state of the target of the change at the time of the change

o Schedule of any other changes for any CIs related to the change at the same time

o Length of time required to implement the change

o Scope of the change, if the change affects multiple CIs. For example, a release to all laptops in the company was considered a higher risk than a change to a test server.

HP CCRM was deployed to consume from the CMS and HP Service Manager for impact and risk analysis.

- For critical changes, an operational checklist must be completed before the change is implemented. AI described this as a “flight plan” analogous to the RFC, and the “preflight checklist” at the time of implementation of the change. So if the change was scheduled to a server at 2am on Sunday, the initial checklist of implementing the change would be, at 2am: 1) Final Impact Analysis

2) Final Status check

3) Final State check

4) Final FSC (Forward Schedule of Change) check The record of the checklist would be a key audit component in the event of a failed change, and the person implementing the change was without exception responsible for the completion of the checklist. Data would be meticulously collected for each change, for two reasons 1) to monitor and measure success and goals being achieved 2) in the case of a failed change, the data would be used for audit analysis and remediation “post-mortem”.

57

To allow the IT organization to embrace the changes to the policies as positive, AI implemented a “breaking in period” where all change implementers were expected to follow the new process. However, in the event of a failed change, the implementers would not be subjected to disciplinary action. Instead, they would be required to report on the problems that occurred, and meet with key persons involved in the change, including CAB members, owners of the data consumed to plan the change, and the impacted business users and owners. The documentation generated would be used either to modify the specific change process at the appropriate level of detail (specific to the type of patch being applied, for example, or, a more general type of policy of another type of check). The breaking-in period started small in scope, beginning with four services, and expanded. After the breaking-in period included the entire IT environment, the “go-live” date was announced, socialized, and discussed among management, technical staff, and the business. It was given a name, “Better Change for Better Business.” Users, IT, and management all agreed that the new change policies were designed to make their jobs easier, not more difficult, and shielded the change implementers as much as possible from the risk of having directly impacted the business.

All service owners were given access to a real-time dashboard of the availability plan for their applications and business services, both those dependent on and depended on by the owners’ scope. The dashboard would consume operational and service-related data from the CMS and let the owners know if there was any risk of unplanned outage.

Even before the go-live date, the data quality collection processes began to show that the number of failed changes was beginning to go down. But with so little data it was not possible to definitively point out a trend. It was decided that the go-live date should proceed. Shortly after the go-live date, an emergency change was implemented on a Thursday night at 3:30am because an operational alert indicated a change to a database must be completed to continue availability of several mission-critical applications. Because of the delicate and advanced type of change that needed to be done to repair the problem, the most senior technician was called to implement the change. Because the technician felt the most important factor was to maintain the application’s availability, they created no emergency RFC and did not follow the correct process before implementing the change. No Impact or risk analysis was conducted, nor was the application owner consulted. The change to the database required a short outage to the online retail application using the database. During the temporary outage, several users were unable to complete their online orders, resulting in a business cost of approximately $12,000. The technician explained the next day they knew how to fix the database so they did, and that the new change policy was all well and good but was unnecessary for the type of change performed, and that he had performed the change many times, and they outage to the online system was unavoidable anyway, and that he had planned to create the RFC and “fill out the forms” the next day when he came to work. The VP of Operations and his peers decided that all these reasons, while not untrue, were still not an acceptable reason not to follow the new policy, especially since everyone in the company had been trained in the new policy, which was explicit on this point and had

58

had ample opportunity to ask questions. Furthermore, since the technician held a senior position and was expected to be a role model for other newer technical staff, they had set a bad example, the VP said. The technician’s actions had risked the success of the ongoing project. The technician was subjected to disciplinary action, but was not terminated, with a warning that the next outage caused by a change that was not implemented according to the process would be subject to more severe disciplinary action, no matter who the person was. This case was advertised within the business and the IT organization, but protected as much as possible the identity of the technician who had made the change. The next week’s CAB meeting was tense, but was conducted successfully. Another social advertising campaign was conducted throughout the IT organization, with two primary messages: 1) the new policy was working (MTBF began increasing) and 2) implications of the consequences of not following the change policy. “Protect the process and the process will protect you” was the theme of the new campaign. The CAB meeting using the dashboard to review and discuss important changes. HP CCRM, which consumed from the CMS and HP Service Manager.

AI still experienced occasional outages due to change, but none due to the policy not being followed, except for a few new employees who did not properly execute the checklists for the first time. Each time a change caused an outage, the documentation checklists and other circumstances were investigated as to how the process failed to protect the integrity of the changes. The CAB team formed sub-committees to investigate failed changes. A new policy was established that every failed change must produce, if possible, a way to prevent the same problem from recurring. Additional risk analysis data was onboarded to the CMS. MTBF continued to improve.

Today, AI’s unauthorized and improper changes account for zero percent of change-related outages. New technology and unique situations make change-related outages a matter of time, but they are few and far between (the MTBF is exactly the measure of how few and how far between).

Case Study Analysis

The AI case study is intended to be as much introducing organizational change as it is how to build a CMS. The case study is intended to provide a picture of how an organization touches the CMS, through process, not just in IT operations or as part of a SACM configuration management process, but pervasively, via change management and other process interaction.

Other material in the CMS best practices library address the processes discussed in the case study, including provider and consumer onboarding (The Provider Onboarding Guide and Consumer Onboarding Guide documents), data quality measurement and monitoring (

As an aid to thinking about the case study, you may want to ask yourself some questions:

1. Using the data provided in this example case study, how many times during AI’s change planning process did the change management process consume from the CMS?

59

2. Who were the providers of each piece of information? Who were the owners? Did the authoritative provider or ownership of any configuration data change through the life of the project? Who was the original owner, and who was the new owner?

3. What changes would you make to AI’s change management policies?

4. What parts of AI’s process would you consider unnecessary, or are missing or incomplete?

5. What parts of AI’s process do you see are missing or incomplete?

6. How important do you consider the social advertising campaigns to AI’s success?

7. How important was the quality of the consumed data to the change process? What risks could be introduced to the process if the data were unreliable? Even if the change process was followed exactly, could a change still fail and impact a business service?

8. Do you see your organization following (or already having followed) a similar path? What mistakes did you see AI make that could have reduced cost, risk, or delays?

9. Does this case study help you make any better decisions now about how to build your CMS? Are you able to make the connection from building a CMS and the COP model to leveraging your IT and business services for the business?

10. What other ITIL processes would follow similar evolution paths to the change management process? How would you leverage process engineering done previously for other processes?

Ultimately, you must decide what is right for your organization. You may want to create your own similar scenarios for implementing organizational process change.

60

Design and Planning Approach

At a high level, a CMS/CMDB project can be generalized as follows:

- Identify the problems/pain points. For example, too much downtime, too much cost, too much risk,

for a certain area. Collect as much quantitative data as possible.

- Derive the use case that addresses the problems. Note that this step is not solving all the problems,

just a more formal definition of requirements based on addressing the problems identified in step 1.

- Asses your IT organization’s executional and technical capabilities

- Every IT organization has similarity and uniqueness compared to any other. The uniqueness is a

given IT organization’s specific mix of technology and technical capabilities, constraints, budget,

regulatory requirements, style of management and the ability of the organization to execute

projects e.g. “get things done”. These types of facts can be visualized with a quadrant for each

investigated domain:

Sample Organizational vs. Technological Executional Capabilities Assessment Grid

61

As populated, the graph might look something like this:

Sample populated capabilities grid for ITSM Processes

This high-level structure can only be created based on a detailed analysis and understanding of the IT

organization. HP offers a service which can create such a graph.

At this point, you can now plot two points on a line: 1) where you are, and 2) where you want to be. This

defines the gap that must be closed to fulfill the use cases.

Based on the gap, create a technical and organizational “road map” which identifies the steps taken to close the

gap based on implementing the ITSM processes and what technology and organizational changes are required.

Here is an example of such a “road map”:

62

Overlaid with specific product action items:

Sample customer-specific technology road map

63

Implementation

ALWAYS protect the integrity of the CMS – Never take on ‘junk’ data from any system, no matter how strong

the pressure is from outside. Once this boundary is crossed – and the business gets a reason to distrust your

data integrity – the CMS immediately loses credibility, the CMS is in danger of falling into disuse and CMS

becomes another failed project.

Although simply defined, in practice the goal of maintaining data integrity has been difficult to realize. Many IT

organizations lack sufficient capabilities to effect the changes required to support the required data integrity.

Simply complying with the audit requirements as defined by the ITIL books may not result in a satisfactorily high-

quality CMS.

Determining the Ability to Maintain Data Quality

To determine if the required data quality is achievable, a maturity and capabilities assessment of IT’s

technical and executional capabilities should be conducted.

Capabilities Assessment

Designed to quantitatively measure an IT organization’s maturity in terms of both organizational and

executional, and technical capabilities. These should be expressed on a continuum. A good example is the

CMS Evolution Path itself, which is itself relevant for any discussion about improving data integrity:

This or a suitable measurement is made against a number of ITIL and ITSM process/activity vectors such as

change, asset, and configuration management. The final list depends on the size and nature, security needs,

64

etc. of the IT organization and the business it services. An example is the evolution and capabilities path for

Change Management:

Desired End State

As the capability assessment proceeds, the IT organization’s goals and initiatives will be revealed. The

cumulative set of services and consumers that make up IT will be defined in utopic terms to act as a

bookend to the capability assessment and reveal the gaps between current and desired end state. These

gaps are then documented as the solution blueprint and deployment plan.

Solution Blueprint:

The desired end state is documented as a set of new and changed processes and technical capabilities. The

solution blueprint describes the system as would be ideally consumed by all currently documented use

cases. Dependencies will drive what must be done first, for example, one cannot effect closed-loop change

management without effective configuration management first in place.

Deployment Plan:

The solution blueprint is implemented by executing one or more deployment plans. A reputable service

delivery organization will greatly expedite a successful initial CMS onboarding and is highly recommended.

The Maturity/Capability assessment, the desired end state, and the solution blueprint combine to form a

road map for the IT organization. As with many large projects, it is assumed that multiple phases will be

used to deliver incremental value, ostensibly addressing the critical issues first, and then optimizing to

improve service. The chart below shows how these documents form the framework for achieving the

desired end state:

65

IT management should have a clear understanding of the expectations of the business initiatives, derived

from either ongoing activities or as a study conducted as part of the CMS planning, to granularly describe

and document the desired end state. With the maturity assessment and desired end-state compared side

by side, the gaps become visible between where we are now and where we need to be. These gaps are

transformed into initiatives which drive the CMS solution blueprint and deployment plan.

Provider Onboarding:

The provider onboarding process should start once a consumer identifies a need for configuration data

which does not yet exist in the CMS. At this point the consumer and owner should be validated and

documented and have clear requirements for the data to be onboarded.

The first step is identifying which provider will supply the data. Each attribute must follow process to be

properly authorized. Normally, there would be exactly one provider for any given attribute. However, if

multiple providers are available for valid reasons, the correct provider and conditions must be documented.

For example, provider A provides an attribute during one time range, and provider B provides the same

attribute during all other times. Or, if primary provider A is offline, alternate Provider B is used

Next steps are documented in more detail in the Provider Onboarding document, another document in the

CMS Best Practices Library. Provider Onboarding has a Data Modeling component and a Process Model

component.

Data Modeling Component:

The Data Modeling component covers how to approach the details of identifying the data and its location,

defining the interactions between the data models, including reconciliation, key matching, and data

transformations and conversions.

Process Modeling Component:

The Process Modeling component describes an approach to onboarding new provider data. This process will

be refined and repeated many times in the initial deployment phase, producing a mature process for

ongoing operation. The process modeling components include identifying and documenting provider

details, and the type of provider conduit to be used, for example, federation adapter, discovery, third-party

integration, or a combination of these.

Consumer Onboarding:

New consumers or adding scope to existing consumers is primarily a function of the following practices.

- Rationalizing the Consumership

- Documenting the Use Case

- Documenting the details of the consumer

66

A separate document exists for more details, the Consumer Onboarding Guide in the CMS Best Practices

Library.

Rationalizing Consumership:

The consumer must be authorized and validated, provide a necessary service using the consumed data, and

control the consumed data securely. The consumer’s ITSM role and its accountability to the business must

be articulated.

(In separate document)

- Authority of the consumer to consume the data

o Describe the authorizing business need

o Describe specific data to be consumed

o Describe the limitations of the consumables

o Document specific persons and applications to have access

- Process Interactions and Transitions:

o Whether this consumer is a provider as well

o Document which Processes consumer is involved in

o Document Process transitions to other consumers or providers

Document Consumer Use Cases:

Use Case documentation has robust processes already defined. The important thing is to treat a use case

as a Service or part of a Service. This way, the use case benefits from a defined structure for services

(provided by ITIL), and generates optimization of consumer onboarding (via the Continual Service

Improvement process). The use case can be defined as a set of Service Inputs and Outputs, data and process

flow, and task workflow such as integration and automations, and process transitions.

Document Consumption Details

Such as the expected volume and pattern of usage, the type of conduit used, for example, Java or Web

Services API, GUI, etc.

Document the consumership and providership, which could be similar to the following:

67

The “X”s get expanded into CI types and specific consumption use cases

68

CMS Deployment

Deploying and initially operating a CMS can be as challenging as the design. As new design limits are continually

tested and change is constantly occurring to the CMS itself, many assumptions will be put to the test. Some will

turn out to be incorrect. Plan for correction and continual improvement. Do not plan the project so tight as to

preclude a couple of false starts and a redo or two. A CMS is a complex, uniquely-crafted piece of machinery

which will take time to get operational.

To help you address this challenge, HP Software Professional Services has developed a customizable solution

package that provides specific guidance on how to effectively size, deploy and operate robust CMS. A part of

this solution package is described below around how to effectively deploy a CMS solution.

As described earlier, a CMS is really a system or systems with often several data providers and consumers each

with their own inherit complexity. It is best practice to implement such a system in stages or releases.

For example, we could say that the Release 0 stage should identify what the business goals, objectives and use

cases are for the CMS system. Building on this example further, Release 1 of a project may involve identifying

consumers and providers and building an actual state UCMDB with some population of CIs via discovery, while

Release 2 may involve integrating a service desk application such as HP Service Manager and identifying other

consumers and/or providers to the UCMDB, such as HP Release Control or other managed data repositories.

Example #1: CMS Project Release Phases

Preparation This stage is about preparing information that is required to kick off the project and start

Release 1. It can be thought of as a preparation for kick off and identify the overall business

case, goals, objectives and use-cases of the project.

Release 0

Configuration

Management

Foundation – Actual

State

This stage will focus on delivering a light configuration management process and a standalone CMDB tool to only manage the “actual” state of the Configuration Items without integration to other products. This stream will involve automatic discovery by such tools as HP Discovery and Dependency Mapping, development of a data model etc.

Release 1

CMDB Enrichment –

Actual State / Managed

State

This stage will cover the integration between the CMDB, a service desk application such as HP Service Manager and other data sources and tools to create a CMS. The data sources and tools are defined either as data consumers and/or providers and can be thought of as enriching the current actual data. These data sources are authoritative for particular CIs or CI attributes and this data will be made available via the CMS.

Release 2

69

Asset/Change/Release

and Configuration

Management – Managed

State

This stream will focus on delivering an integrated Asset/Change/Release and

Configuration management process in order to manage the “managed” state of CIs and

the discrepancies between “actual” and “managed” state. Usually involves integrating

asset or release management software such as HP Asset Manager or HP Release Control.

Release 3

Set of example releases for a CMS deployment

The business drivers for such a project may vary slightly for each IT organization and change depending on

where you are in terms of maturity. Therefore elaborating on this implementation is difficult until we have first

established (among many other things) the goals, objectives, as-is state and to-be state.

Often the next step is the need to visualize these phases and the overall deployment in a roadmap or

implementation format approach. Such a high level roadmap shows an overall approach, without having

considered feasibility of realization yet. It also allows you to see the project positioning in terms of your overall

initiatives roadmap. An example based on the releases mentioned earlier is shown below.

Example #2: CMS Road Map CMS approach Use Case Driven!

CMS requirements + use cases workshopsCMS requirements + use cases workshops

Application mapping + rollout

Application / Service mapping

Data enrichment

Data enrichment

CMS Architecture Blueprint

Define data model

Implement data modelImplement data model

Consumer / Provider ob-boarding+ federation interfaces

Process Extensions

Integration + unit testing

Reporting, Training

Release 1

Business case + CMS strategyBusiness case + CMS strategy

Release 2

Implement data modelImplement Discovery

Integration / Deployment Service Manager

Integration / Deployment BTO Products

Release 3

70

An example CMS implementation approach

As discussed, it is generally recommended to follow a best practice approach to the sizing, deployment and

operation of your CMS.

Small Scope Pilot Project

The sample CMS implementation chart above is able to vary with scope. If you follow the chart with a small

scope, this could be considered a “pilot” project. You could use the release phases or the road map examples

above, or use your own. The focus is on creating a repeatable process for onboarding that works for you, and

then re-use that process to expand the scope of the CMS pilot into the desired scope incrementally.

Assuming that you have already designed your configuration management process, principles, policies, defined

roles & responsibilities and identified the business logic necessary to customize the technology to enable this

process, and have made your decision about the scope of your initial CMDB, some care and thought must go

into determining a formal test of your decision.

First, you will need to do some kind of functional test, where your CMDB structure (main CI categories,

subcategories, CIs, attributes and relationships, etc.) is built, populated or federated with test data and

customized with the required business logic. Use Scenarios will have to be used to test each key aspect of your

process and tool. With this functional test successfully carried out, (and only after it is successful), you are ready

to do a pilot test.

The pilot test is different from the functional test in that it uses live production data and when it is completed

successfully, it can be used for production. Therefore, the pilot test must involve careful planning. What will be

the first target IT infrastructure you seek to put under configuration management?

Choosing an Achievable Scope for the Pilot

Choose the initial scope carefully. There may be strong influence to add too much scope initially. Focus on a

scope which could limit complexity but will also add meaningful value. Think about the ways in which you might

limit a specific set of CIs “naturally”. For example, by platform, or by geography, such as selecting one or more

specific production IT sites as the first targets for adding to the CMS. Or, if you have defined your IT services,

you could target a specific service and limit your first pass at building the CMS just to the CIs and categories that

make up this one service.

Functional Testing

Your configuration management pilot is not only testing the structure of your CMDB - it is also testing your

process. The roles and responsibilities you’ve defined will need to have been implemented prior to your pilot

test; principles and policies will have to have been approved by management. Expect to perform some

modifications to these things after both your functional test and your pilot test, as well as to the business logic

and customizations you’ve implemented in your tool.

71

Populating the Configuration Baseline

It is imperative that your pilot test be successful. Remembering this fact should help you to reign in your desire

to “do it all” in one huge test. For your target IT infrastructure, select a grouping of infrastructure components

that will not only be easy to manage and provide some immediate value, but also possible to halt changes for

the discovery period. It is critical that during the initial load of your target IT infrastructure into the CMDB, there

can be NO changes made to those infrastructure components! This is what is meant by “freezing” your target

infrastructure.

This time frame will vary depending on the discovery required to fulfill your pilot use case. It need not be long;

potentially on the scale of hours or possible a few days. Longer than this means either your pilot scope is too

large, or you have not yet done sufficient testing before implementing the pilot, or your processes for discovery

are not fully sponsored, for example, you are having trouble gathering discovery credentials. Ensure you have

none of these problems before beginning your pilot.

ITIL refers to this as a “configuration baseline.” According to ITIL, a baseline is “the configuration of a product or

system established at a specific point in time, which captures both the structure and details of a configuration.”

Taking a snapshot of your IT infrastructure is indeed important; as this becomes the reference point for future

determinations as to what has changed. If you can’t trust your baseline, you’ll never be sure you fully

understand what changed and what didn’t.

Your CMS is only as valid and useful as the data it contains. If you have changes being made to components

while you are loading them, you will start out with an invalid CMDB (one that doesn’t reflect reality) and the

value you are seeking from configuration management will be dramatically lessened, possibly to the point where

it is unusable.

Therefore, the target infrastructure you select will also need to be completely under the control ofchange

management.

After your pilot, given the best practice mentioned previously, only items under change control should be

exposed to the CMS. These are both considerations that can help you decide what your initial target

infrastructure should be.

Implementation Challenges

While you are planning your configuration management pilot, you must keep one eye looking towards the

future. Your pilot test should allow you to continue building your CMDB in a logical, step-by-step manner. After

you have identified the target infrastructure for your pilot, which components will you do next? After these,

what is next? And so on. Your configuration management pilot plan and implementation plan are two parts of

one whole that must fit together.

Deployment Planning and Implementation Challenges

Implementing a configuration management process, like many IT projects, always poses some risk when moving

your organization forward in a new direction. Listed below are some common barriers associated with

implementing a formal configuration management process. Each of these is based on experience and research

of both failed and successful projects.

72

- The discussion around the definition of CMS scope, breadth, depth and overall structure could

prevent the organization from moving forward as this can become overwhelming as organizations

attempt to create the “perfect solution.” This is sometimes called “Analysis Paralysis” and is

suffered under the illusion that 100% of the information needed to plan for a project can somehow

be obtained.

- Trying to substitute technology for missing or dysfunctional processes.

- Leaving out the process governance layer in between the CMS/CMDB technology and ITSM and

business services.

- Not defining the value chain past support of internal services.

- Within smaller IT organizations, one supporting tool may be able to meet the requirements of the

configuration management process; however, larger IT organizations may be sidetracked looking

for, or designing the “one tool” solution which may not be the most practical.

- Some solutions such as a service desk or asset management system may be providing some measure

of CMDB or CMS provider function. Political resistance to change may need to be overcome.

- Not paying attention to quality of the data from the beginning.

- Lack of management commitment to sustain the initial process development and/or to enforce

configuration management policies and procedures on an ongoing basis.

- Lack of clear responsibilities and adequate authority.

- Confusion around the basic terminology of configuration management. Refer to the early sections

of this document that attempt to clarify the scopes of assets, service assets, IT assets, CIs, services,

etc.

- Taking on too much scope too early on or allowing scope to “creep” after an initial agreement.

- An inability to manage “willing compliance” of the staff with respect to the configuration

management process procedures and policies.

- Challenges around the definition and assignment of key process roles.

- An inability or unwillingness to implement a configuration management process together with a

formal change management process – some organizations may not have an existing change

management process in place.

- The size and scope of defining standards and naming conventions and the subsequent component

labeling activity may cause staff to resist at implementation time or late in the project.

- The complexity involved with defining an audit and verification process.

- Accounting for the cost of populating a CI but not accounting for the cost of maintaining, using, and

managing it operationally.

- The lack of usable automatic data collection and filtering tools to populate and maintain the CMDB.

- The inability to achieve the right balance between manual population, updating and housekeeping

of CIs within the CMDB.

73

Glossary These definitions are a mix of expansion and refinement of existing definitions. Some are new to CMS best

practices, others are rooted in the ITIL or SACM definitions. In all cases, the definition has some special meaning

to CMS best practices in that it shifts the meanings to work better together and to give you a better foundation

from which to make your own CMS decisions.

Business Service

ITIL defines a business service as “An IT Service that directly supports a Business Process, as opposed to an

Infrastructure Service which is used internally by the IT Service Provider and is not usually visible to the

Business.” Many persons in IT confuse infrastructure services with business services. This is not to

disparage IT: IT’s value has traditionally been understood to end with fulfillment of use cases regardless of

the type of consumer. However, the business makes a clear distinction between internal (infrastructure

services) and business services.

For example, a coffee machine in a coffee shop is an asset, and provides a service, but not a business service

because the value is only indirectly provided to the customer. The coffee machine is used by the barista (a

capability, i.e. the knowledge and ability to make the coffee), and uses coffee, electricity, and water

(resources) under the control of the barista, and the barista (or their clerk) delivers the cup of coffee to the

customer. In other words, the process of preparing coffee and the coffee machine’s involvement in the

preparation process is of no concern to the customer and therefore provides an infrastructure service rather

than a business service.

Capability

The ability of an organization, person, process, application, configuration Item or IT service to carry out an

activity. Capabilities are intangible assets of an organization. Knowledge can be considered a capability.

Also see “Resource”

Configuration

1. Sometimes called “asset”, specifically, a group of Configurable elements that work together to deliver

an IT Service, or a recognizable part of an IT Service.

2. Certain parameter settings for one or more CIs.

Configuration Item (CI)

Any component, that needs to be managed in order to deliver an IT Service. Information about each CI

resides in one or more locations within the CMS and is maintained throughout its lifecycle by configuration

management. CIs are under the control of change management. CIs typically include IT services,

applications, infrastructure such as hardware, software, and key relationships between these.

To “specify a CI,” means to:

- Identify it by name and description - Describe its attributes (e.g., location, company name, hardware and software configuration

parameter values, etc.)

- Associate versions with it - Record its status (e.g., new, released, down, secure, etc.)

74

- Define its owner (i.e., the individual who can make decisions about the item)

- Detail relationships between it and other CIs (e.g., a LAN could be related, as an intermediary, to both a client and server; a component could be contained in a single service or used by several services; etc.)

To “track a CI” means to:

Maintain and update information about a CI as it changes (e.g., location of hardware, distribution of documents, version of software, etc.), thus providing information useful to service management (e.g., incidents associated with a specific CI, change projects and work orders affecting it, performance data, delivery costs, etc.) and preserving historical data for reporting. Tracking also connotes periodic audits to verify data integrity.

To “report on a CI” means to:

- Respond to specific requests for information from the CMDB.

Configuration Management

The organized set of processes, workflows and policies that track, store, manage, and provide configuration

information to consumers for the purpose of ITSM. It is the process responsible for relationships. This

information is managed throughout the Lifecycle of the CI. Configuration management is part of an overall

Service Asset and Configuration Management Process.

Configuration Management Database (CMDB)

Initially, a CMDB as database used to store CIs throughout their Lifecycle. The CMS maintains one or more

CMDBs, and each CMDB may store data including CI attributes and relationships, or provide other

capabilities such as reporting or analytics. A CMDB is also more than an MDR.

Although ITIL deprecated the idea of an integrated CMDB, reality did not, and many configuration

management solutions today are built around a CMDB as described in the sterile data terms, plus additional

features such as topology visualization, auto-discovery, impact analysis, and more.

Configuration Management System (CMS)

- A system of tools and databases that are used to manage configuration data, including a CMDB, a CI type model, various conduits and APIs for providing and consuming CIs and relationships.

- The collective set of consumers and providers of configuration data.

The CMS also includes information about incidents, problems, known errors, changes and releases; and may

contain data about employees, suppliers, locations, business units, customers or users. The CMS includes

tools for collecting, storing, managing, updating, and presenting data about all Configuration Items and their

relationships. The CMS is maintained by configuration management and is used by all IT service

management processes.

Providership

Everything available for consumption in the CMS at a given point. All instantiated CI and relationship types.

75

The providership (also called the “Configuration Model”) is essentially the entire graph contained in the

CMS. Sub-graphs provide meaningful subset of the applications and infrastructure, such as applications or

system services.

The Configuration Model enables other processes to access business context and other valuable

information, such as:

- To assess the impact and cause of incidents and problems

- To assess eligibility of proposed changes. For example, a CI in a compromised operational state

cannot be the candidate of a proposed change, unless the change is directly related to resolving the

reason why the CI is not eligible.

- To assess the impact of proposed changes

- To plan and design new or changed services

- To plan technology refresh and software upgrades

- To plan release and deployment packages and migrate service assets to different locations and

service centers

- Maintaining information about Configuration Items required to deliver an IT Service

- To optimize asset utilization and costs, e.g. consolidate data centers, reduce variations and re-use assets.

Consumership

All the consumers of the providership.

MDR

Managed Data Repository. A place where configuration data is stored and exposed to the CMS. In order for

a repository to become an MDR and part of the CMS, it must go through a trusted process of rationalization

whereby the authority and value of the data is asserted and formally onboarded to the CMS. The rev1 of

the CMS best practices library defined an “ASOR”, Authoritative Source of Record, to mean, a properly

rationalized and onboarded MDR. However, the MDR designation should not be conferred until the proper

onboarding process has been followed in the first place; therefore the term ASOR was superfluous and

omitted in favor of a simple reinforcement of MDR.

Resource

A supply of materials or capacity that is used to provide a service. For example, a bag of coffee beans, some

of which are used in a coffee machine (an asset) to make a cup of coffee. An IT example would be the

storage and computing capacities of a server for use in providing a paying service to a customer of the

business.

A generic ITIL term that includes IT infrastructure, people, money or anything else that might help deliver an

IT Service. Resources are tangible. Many resources are considered to be assets of an organization.

Service

ITIL defines a service as “A means of delivering value to customers by facilitating outcomes customers want

to achieve without the ownership of specific costs and risks.”

76

A service is fulfilling the need of a consumer, provided to a consumer without the consumer’s need to

understand everything that had to be done to meet the need. For example, a consumer buys a cup of coffee

from a coffee shop. The consumer does not need to know how to make the coffee or where the coffee

beans are; only to pay for the finished cup. An IT example would be a web site which is paid for to provide a

service of storing data or communicating with others.

Service Asset

Any asset, capability or resource of a service provider, that is part of a service. Assets of a service provider

include anything that could contribute to the delivery of a service. Assets can be one or more of the

following types: management, organization, process, knowledge, people, information, applications,

infrastructure, and financial capital.

State and Status

The distinction between a “state” and a “status” is more granular in the domain of configuration

management and warrants clarification against the more general Operational nomenclature. In the CMS, a

“State” is specific to configuration management, and is implemented by HP as “authorized”, “actual”, and

“planned”. A “status” is an attribute which indicates a specific condition as determined, owned, and

provided by a specific process. A status may be real-time in nature and may need to be federated to the

CMS (rather than replicated) to be useful. While there are only a few states, there can be many statuses,

including:

- Operational/health status, from the operations monitoring system(s). For example, availability and

performance statuses such as “up/down”, “green/yellow/red”, or “performing within SLA”, could all

be valid statuses depending on which tools are used and how each IT organization chooses to

implement them.

- Security status, from the security management system(s). A real-time security status could be

useful in determining how to proceed with a proposed change to a CI. For example, the security

status could be “secure”, “compromised”, “suspect”, “surveilled”, etc.

- Financial status, such as “owned”, “leased”, “behind on payments”, anything meaningful to some

consumer

- Capacity or Usage status, from the capacity planning system, such as “overutilized”, “underutilized”,

or “balanced”.

- Specialized statuses: For example, locational status, static or dynamic. While a static location may

not be much of a status, the intent here is to introduce the concept that any attribute that may

change where that change is useful to a consumer may be considered a status. For example, if your

business considers vehicles CIs, their location could be a status. Realize that it is not predictable

whether vehicles should be CIs without knowing how your IT runs, what business you are in, etc.

77

Index

asset, 14, 20, 22, 23, 24, 25, 32, 33, 41, 42, 46, 48, 51, 69, 74, 76

attribute, 33, 35, 36, 47

audit, 19, 32, 47

authoritative source of record, see managed data repository

authority, 39, 43, 66

availability, 32, 38

CMDB, see configuration management database

CMS, see configuration management system

conduit, 30

configuration data, 28, 75

configuration Item, 6, 12, 18, 19, 20, 23, 24, 25, 26, 27, 28, 29, 30, 34, 35, 40, 41, 46, 47, 48, 49, 53, 67, 68, 70, 72, 73, 74, 75, 76

configuration Management, 1, 6, 9, 10, 11, 14, 17, 18, 19, 22, 34, 36, 47, 48, 50, 52, 68, 69, 70, 71, 72, 74

configuration management database, 6, 8, 9, 10, 11, 12, 13, 14, 18, 19, 20, 21, 25, 28, 30, 31, 32, 33, 34, 36, 46, 47, 48, 49, 50, 52, 60, 68, 70, 71, 72, 74, 75

Configuration Management System, 1, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 34, 35, 36, 37, 38, 39, 40, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 58, 60, 63, 64, 65, 66, 68, 69, 70, 71, 72, 73, 74, 75, 76

configuration manager, 29, 43, 44, 49

conflict, 29, 37, 38, 39

consumer, 28, 29, 30, 31, 32, 33, 40, 41, 43, 44, 51, 52, 65, 66, 75

consumer/Owner/Provider Model, 7, 12, 14, 18, 19, 21, 22, 25, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 51, 52, 56, 59, 65, 66, 72, 74, 74, 75, 76

data model, 14, 26, 27, 28, 30, 32, 43, 46, 47, 65, 74, 75

data quality, 6, 11, 13, 14, 18, 27, 28, 29, 30, 32, 33, 37, 39, 44, 46, 50, 59, 63, 72

DDM, see HP Discovery and Dependency Mapping

efficiency, 33

exceptions, 33, 38

federation, 10, 34, 35, 49, 51

HP Discovery and Dependency Mapping, 11, 12, 19, 33, 34, 41, 42, 46, 47, 48, 49, 51, 52, 68

HP Universal CMDB, 25, 68

implementation, 34, 35, 38, 39, 43, 63, 71

integration, 34

integrity, 29, 32, 34, 39, 44, 45

ITAM, see IT Asset Management

IT Asset Management, 6, 20, 21, 22, 28, 30, 50

ITIL, see IT Information Library

IT Information Library, 6, 8, 9, 10, 11, 12, 14, 18, 19, 22, 28, 31, 41, 47, 50, 63, 66, 71, 73, 74, 75

IT Service Management, 9, 10, 12, 14, 17, 22, 25, 28, 31, 33, 40, 51, 52, 61, 63, 66, 72, 74

latency, 38, 39, 43

managed data repository, 12, 14, 16, 23, 25, 29, 30, 32, 34, 38, 39, 46, 47, 49, 51, 74, 75

onboarding, 30, 39, 44, 65, 66

owner, 28, 29, 31, 32, 33, 35, 37, 43, 44, 65

performance, 32

process, 9, 10, 12, 13, 14, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 32, 33, 34, 35, 36, 38, 40, 41, 43, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 58, 59, 63, 65, 66, 68, 69, 70, 71, 72, 73, 74, 75, 76

provider, 14, 21, 25, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 43, 44, 45, 46, 51, 52, 59, 65, 66, 72, 76

quality, see data quality

rationalization, 17, 28, 29, 30, 33, 35, 36, 38, 39, 43, 44, 45, 65, 66, 75

reconciliation, 14, 25, 29, 42, 46, 47

relationships, 20, 31, 75

replication, 35, 38, 39, 43, 49

SACM, see service asset and configuration management

security, 12, 14, 32, 34, 36, 38, 41, 42, 46, 63, 76

service, 6, 8, 9, 10, 11, 12, 13, 14, 15, 16, 18, 19, 20, 21, 22, 23, 25, 26, 27, 28, 29, 32, 34, 35, 36, 38, 40, 41, 46, 48, 49, 50, 51, 52, 54, 55, 59, 61, 64, 66, 68, 70, 72, 73, 74, 75, 76

78

service asset and configuration management, 6, 8, 9, 10, 12, 13, 14, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 32, 34, 35, 36, 40, 41, 46, 48, 49, 50, 51, 52, 54, 66, 68, 72, 73, 74, 75, 76

states, 14, 24, 25, 41, 42, 46, 48, 51, 64, 68, 69, 76

statuses, 12, 18, 19, 20, 24, 51, 53, 54, 73, 76

strategy, 1, 6, 33

tenets, 28

transparency, 29, 32, 38, 43

UCMDB, see HP Universal CMDB

use case, 8, 10, 12, 13, 14, 17, 20, 21, 27, 28, 29, 30, 33, 35, 40, 43, 45, 49, 50, 51, 52, 60, 61, 64, 65, 66, 67, 68, 71, 73