TECHNICAL WHITE PAPER

Maintain an Accurate CMDB

through Reconciliation
Table of Contents




EXECUTIVE SUMMARY ................................................................................................................. 1

WHAT DOES RECONCILIATION HAVE TO DO WITH A CMDB? ................................................. 1

UNDERSTANDING THE CONCEPT OF RECONCILIATION ............................................................. 1
> Identifying Configuration Items ............................................................................................. 1
- What is a unique identifier? ..............................................................................................2
- Creating a Reconciliation ID .............................................................................................2
> Comparing Configuration Items ............................................................................................ 2
- What does it mean to compare? ......................................................................................2
- Applying business rules to compare activities .................................................................3
> Merging Configuration Items ................................................................................................ 3
- What are the different uses for merging data? ................................................................3
- Precedence rules for merging data ..................................................................................4
MANAGING DATA SETS ................................................................................................................ 4
CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Executive Summary
Implementing a configuration management database
(CMDB) is an important step in tying together your IT
processes and enabling them to interact in a common way
with IT infrastructure data. By leveraging configuration items
(CIs) stored within the CMDB, IT processes have a common
reference point that can be used to connect various IT
tools and processes. The IT Infrastructure Library (ITIL

)
defines a CMDB, but does not tell how to best go about
implementing one which is more than just putting your IT
components information into a single repository.
The goals of CMDB implementation are to be able to
manage that single repository over time, keep information
about your IT infrastructure up-to-date, and create an
environment that can be realistically maintained. To
accomplish these goals, a CMDB must provide capabilities
that help you rationalize IT infrastructure data coming
from many different areas from multiple discovery
sources, to existing data repositories, to IT applications.
The reconciliation process helps rationalize this data, bring
it into a common format, and ultimately use the data to
help keep an accurate representation of the IT environment
stored within a CMDB, which can then by leveraged by IT
processes.
This paper discusses the important role reconciliation plays
in a CMDB, the key capabilities a reconciliation process
should support, and why reconciliation is a critical factor in
determining a successful CMDB implementation.
What does reconciliation have to do
with a CMDB?
When it comes to configuration management, enterprise
organizations often rely on many different data repositories
and automated discovery tools to capture and record data
about IT components. This configuration item (CI) data
is then leveraged by IT management processes such
as asset, incident, and change management to make
educated decisions about infrastructure updates or changes,
based on the configuration data. To align these management
processes, organizations can populate this discovered
information into a configuration management database
(CMDB). The CMDB provides a single source of truth for
CI data that all IT processes can then use.
That is not the end to the story, though. Automated
discovery tools often conflict with each other, and you
cannot simply update a CMDB with the information
supplied by these sources, without applying some level of
logic. So how does an organization rationalize and make
sense of this discovered data, bring it together, and be
able to understand how CI data captured by these tools
relates to CIs stored within the CMDB? And, when conflicts
between the CMDB and incoming data do occur, how do
they get resolved?
The reconciliation process plays a critical role in answering
these questions and is a key requirement for both managing
and maintaining a CMDB. Reconciliation should not be
considered a separate function that may or may not occur
within a CMDB, but as a key requirement to making any
CMDB implementation and ongoing operation successful.
Understanding the Concept of
Reconciliation
There are different approaches and capabilities for data
reconciliation, but all revolve around three important
activities. Working together to ensure consistency and
accuracy across CI data stored within a CMDB, these three
activities comprise:
Identifying data
Comparing data
Merging data
These activities provide the means to organize data coming
from multiple discovery sources, create rules for how that
data should be brought together, and determine how to
reconcile incoming data with information stored in the
CMDB. It is important to note that these three activities
do not represent all of the functionality that may be part
of your reconciliation process, but they do represent the
more critical activities required for reconciling CMDB data.
By understanding each of these activities and their roles in
managing CI data, we can determine how to build a CMDB
that can be successfully managed and maintained in a
constantly changing and dynamic IT environment.
For more information please visit www.bmc.com/atrium.

Identifying Configuration Items
When you have more than one discovery tool or data
source providing CI information to the CMDB, these
tools often will find identical CI data. The initial step in
reconciliation, therefore, is identifying and matching
duplicate instances across the incoming data sets.
The identification activity lets you compare multiple data
sets and, based on unique identifiers, determine whether
information contained in these data sets refers to the same
PAGE > 1
CI. Not only is this step critical to identifying data across
multiple data sources, it is also key to identifying similarities
between discovered data and the discovered discovered data that is stored within data that is stored data that is stored
the CMDB.
What is a unique identifier?
A unique identifier is CI information that distinguishes one
CI from another in an IT environment. A unique identifier
can be a hostname, serial number, or other attribute that
will likely remain constant, regardless of whatever CI
changes occur. When there is not a single, unique attribute
for CI data, a unique identifier can also be a list of attributes
that, when combined, create a unique ID. For example, if create create
a hostname is not always unique and a serial number is
not always unique, you can combine the two attributes to
create a unique ID for a given CI.
In addition to being unique, the identifier should be
an attribute that is always captured in the same way
across data sources. This is important because, when
you cannot rely on the similarity of certain CI attributes
across discovery tools and other data sources contributing
information to the CMDB, it becomes difficult to automate
the process of identifying similar CIs across data sets. If
you can ensure that all data sources are finding the same
unique identifiers for a given class of CI, you can automate
the entire process of identification, drastically simplifying
the time and maintenance involved in CMDB reconciliations.
Creating a Reconciliation ID
After determining the unique identifier, the identification
activity can review all incoming data, determine similar
CIs across more than one data source, and mark where
these data sources refer to the same CI. By marking CIs
across data sources, the reconciliation process tells itself
that information from different data sources are talking
about the same CIs. It does this by marking CIs with
reconciliation IDs that are unique to individual CIs.
For example, if a server named Roadrunner (Roadrunner
also being the unique ID) was found across three different
discovered data sets, the reconciliation process would mark
all instances of that CI across data sets with the same
reconciliation ID (i.e., 123). Anytime new information about
the Roadrunner server comes in, the identification process
will mark the record as 123 to identify it as a specific CI
(see Figure 1.)
This initial marking step is critical to enabling the compare
and merge activities without causing conflicts from merge merge
overlapping data that could potentially corrupt your CMDB
with unreliable CI data. Once identification has occurred,
you can move to the next step and determine how to
interpret and combine this data.
Comparing Configuration Items
Being able to compare CI data across data sets is
probably the most beneficial reconciliation activity from a
configuration and change management perspective. After
all, the reason for a creating a CMDB is to provide a single
source of CI data that all IT processes can leverage for wise
decision-making. The compare activity plays a critical role compare compare
in comparing incoming information about CIs with what is
actually stored within the CMDB itself.
By comparing CMDB data with incoming discovery data,
you can determine whether unplanned changes have
occurred (e.g., the CMDB CI data was not supposed to
change, but the discovery tool indicates that it did). Or you
can verify if a planned change did occur (e.g., whether
a new patch planned to roll out to the Roadrunner sever
actually did, based on the latest set of discovered data).
What does it mean to compare?
In simple terms, the compare activity creates a list of
differences (deltas) between two different data sets. This
list can then be used to determine what may have changed,
why it changed, and whether it should have changed.
In addition to discovering events, the compare activity is
important in determining what future configurations might
look like, and then comparing the future configuration
with the current state of your environment. For example,
you might want to know what your environment would
look like if you moved SAP from UNIX to Microsoft
Windows or if you collapsed xyz application onto a VM
(virtualized) solution. In these cases, you could build out a
configuration of how these future states would look (i.e.,
build out a data set of hypothetical changes, and then use
PAGE > 2
Figure 1: Identification Activity assigns unique
Reconciliation ID
Identification Activity
After Identification
Before Identification
Discovery Source 1
UNIQUE ID:
Roadrunner
RECONCILIATION ID:
Not Available
Discovery Source 2
UNIQUE ID:
Roadrunner
RECONCILIATION ID:
Not Available
Discovery Source 1
UNIQUE ID:
Roadrunner
RECONCILIATION ID:
123
Discovery Source 2
UNIQUE ID:
Roadrunner
RECONCILIATION ID:
123
PAGE > 3
the compare activity to analyze how these changes can
impact CI relationships, and the potential differences in
the IT environment compared to your existing state). Such
information is valuable when creating a controlled change
and configuration process one that lets you proactively
determine your configuration plan and the best way to get
there, without disrupting your environment.
Applying business rules to compare activities
Consider this scenario: The compare activity just found
a delta between a discovered data set and the CMDB
data. What do you do about it? The compare activity is
tremendously helpful in understanding the deltas between
multiple data sets, but without some type of business logic
and workflow paradigm, the process of doing something
about it would be almost exclusively manual. In other
words, the compare activity would list the differences
between data sets and then pass that information to
someone in IT. The IT person would then determine
whether or not to do something about it not really the
ideal way to manage a dynamic IT environment.
To automate the compare activity, it must be able to
leverage defined business rules that tell the reconciliation
process what to do when differences are found between
data sets. If a difference is found, should someone be
notified? Should precedence be given to the discovery
source or the CMDB? Did a planned or unplanned change
occur? Most of these questions are answered by the
IT processes that leverage CMDB data (such as change
management); but it is critical that reconciliation provides
the means to automate the decision-making process.
To do so, the compare activity should provide workflow
capabilities that allow you to create If, If If Else, and Then
scenarios, based on your way of doing business. For
example, IF a discovery source records an amount of
memory for a server different than that in the CMDB,
THEN it should determine if there was a planned change
associated with the server or ELSE notify the Change
Manager that an unplanned change may have occurred (see
Figure 2).
Obviously, this is a rather simple example. Many different
scenarios can be created based on unique IT environments
and how IT processes leverage CMDB information. The
important point to remember is that you cannot simply
update the CMDB based on information obtained from
a discovery source, because you will not know whether
unplanned or planned changes occurred.
The compare activity and its associated workflow
capabilities are essential for keeping CMDB data accurate
while enabling IT processes, such as change management,
to act on delta information found during the reconciliation
process.
Merging Configuration Items
Merging can be considered the final step in the
reconciliation process. You have identified CIs across data
sets, compared that data to information in the CMDB,
and you now need to determine how and when to bring
this information into a single, reconciled data set that can
update the CMDB by making changes to CI data.
The merge activity is also essential when you have two merge merge
or more data sources that discover information about
the same CIs. Each data source will likely have areas of
strength and weakness compared to the others. By creating
rules that govern the merge activity, you can create one set
of CI information with the best of all discovered data.
What are the different uses for merging data?
We can break up the role of the merge activity into two
parts:
1. Merge data sets from discovery sources into a single set
of CI data
2. Merge data from the reconciled data set with information
stored within the CMDB
The first role of merge activity in the reconciliation process
is to bring together data from multiple data sources into
a single, reconciled data set. This allows the compare and compare compare
merge activities to occur against only two sets of data: 1) merge merge
the CMDB data set and 2) a single, reconciled data set for
discovered data.
Do nothing
Does CI Data
match?
Was a change
planned?
Did the planned
change occur?
Confirm change
successful
Notify Change
Manager
yes
no
yes
no no
yes
Figure 2: Mapping the Compare Activity to
business logic
PAGE > 4
Simplifying data from multiple sources into a single data
set creates a more approachable means to managing
differences that may be found between the reconciled
data set and the CMDB. It also reduces the amount of
processing the CMDB is required to perform and limits the
number of compare and compare compare merge activities that must occur
against the CMDB.
Precedence rules for merging data
In instances where multiple tools discover information about
the same CIs, the merge activity must be able to determine
what data source, or its attributes, take precedence over
another data set and its attributes. Precedence rules allow
you to set a weight to individual data sources, giving one
data source priority over another. Maybe you know that
information captured from one data source will always be
more reliable than information from another data source, so
you want the first data source to have precedence then
the two data sources will always capture information about
the same CIs (see Figure 3).
Or you may have data sources that provide different
information about CIs, and complement each other on
the coverage of a CIs attributes, so you want to be able
to choose which attributes will be used from which data
source. The result is a reconciled set of data that represents
the most accurate and comprehensive information available
for CIs across all discovery sources (see Figure 4).
Applying this level of logic and weighting to CI data ensures
that the CMDB is provided with the most comprehensive
and complete set of data about your IT environment
ensuring that you can make decisions based on the most
accurate set of IT infrastructure data available.
Managing Data Sets
Now that weve discussed the different activities and
capabilities that make data reconciliation work, lets discuss
how to manage data sets coming from multiple discovery
sources.
It is important to understand that, regardless where the
data originates, before reconciliation activities can occur, the
data from these different data sets needs to be represented
in the same way. In other words, the data needs to be
normalized into a common format that conforms to how the
CMDB stores CI information. Data normalization enhances
how manageable the merge and compare activities will
be. Without a form of normalization, it becomes nearly
impossible to compare or merge data that may be
represented in different formats and value.
For example, consider how a library card catalog represents
data about books. It normalizes data within the catalog
by key attributes such as author and title. Searches based
on these attributes are standardized across all books in
the library. Imagine if the card catalog allowed readers to
search for the author Ernest Hemingway using multiple
formats such as E. Hemingway, Ernest Hemingway,
or Hemingway, Ernest but provided no way to
understand that all formats refer to the same author. This
example can extend to include the different ways publishers
might define the author attribute for their books. Without
a standardized, single format for author to normalize the
book data within the card catalog, imagine how difficult it
would be for readers to search for a certain author. They
Merge Activity
Before Merge
(Discovery Source 1
takes precedence)
Discovery Source 1
UNIQUE ID:
Roadrunner
MEMORY:
2 GB
Discovery Source 2
UNIQUE ID:
Roadrunner
MEMORY:
1 GB
After Merge
Reconciled Data Set
UNIQUE ID:
Roadrunner
MEMORY:
2 GB
Figure 3: Merge Activity, with Discovery Source 1
taking precedence
Figure 4: Merge Activity results, with the most
accurate CI data
Merge Activity
Before Merge
Discovery Source 1
takes precedence on
CPU speed
Discovery Source 2
takes precedence on
hard drive size
Discovery Source 1
CPU SPEED:
2.483 GHz
HARD DRIVE SIZE:
80 GB
UNIQUE ID:
Roadrunner
Discovery Source 2
CPU SPEED:
2.4 GHz
HARD DRIVE SIZE:
80.45 GB
UNIQUE ID:
Roadrunner
After Merge
Reconciled Data Set
UNIQUE ID:
Roadrunner
CPU SPEED:
2.483 GHz
HARD DRIVE SPACE:
80.45 GB
would need to know exactly how each publisher defined its
author attribute to understand where to search for books.
The same holds true for multiple data sets and
reconciliation. Across CIs, if information is not stored in a
single, consistent format, then trying to reconcile data from
multiple data sources, with multiple formats, becomes
difficult and unmanageable. By bringing discovery data into
a common format, we can drastically simplify the accuracy
and effectiveness of the reconciliation process in keeping a
CMDB up-to-date.
Conclusion
Without adequate reconciliation capabilities, maintaining a
CMDB long-term will be difficult, if not impossible. However,
by implementing a CMDB with reconciliation capabilities
that can identify data from multiple data sources, identify identify compare
that data to information stored in the CMDB, and merge it merge merge
with CI data stored within the CMDB, you can create and
sustain a successful and manageable CMDB environment.
PAGE > 5
About BMC Software
BMC Software helps IT organizations drive greater business value through better management of technology. Our industry-leading Business
Service Management solutions ensure that everything IT does is prioritized according to business impact, so IT can proactively address busi-
ness requirements to lower costs, drive revenue, and mitigate risk. BMC solutions share BMC Atrium technologies to enable IT to manage
across the complexity of diverse systems and processes from mainframe to distributed, databases to applications, service to security.
Founded in 1980, BMC has offices worldwide and fiscal 2008 revenues of $1.73billion. BMC Software. Activate your business with the
power of IT. For more information, visit www.bmc.com.
57869
57869
*97561*
To learn more about how BMC can help activate your business, visit www.bmc.com or call (800) 841-2031.
BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark
Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending
registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners. 2005, 2009 BMC
Software, Inc. All rights reserved.