Myths of a CMDB

WHITE PAPER: Myths of the Configuration Management Data Base (CMDB)
Myths of the Configuration
Management Data Base
(CMDB)
April 2009
David A. Messineo
CA SERVICES

Table of Contents
Executive Summary 3
Understanding the CMDB — Seven 4
Fundamental Use Cases
Where Do Myths Come From
The Different Types of Myths
Understanding CMDB Myths Helps Align 7
Business Value to IT — A Baker’s Dozen
Conceptual Myths
Process Myths
Organizational Myths
Technology Myths
Avoiding the Myths — The Benefits of a 15
Proper CMDB Implementation
Conclusions 16
About the Author 16
Copyright © 2009 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. This document is for your informational purposes only. To the extent
permitted by applicable law, CA provides this document “As Is” without warranty of any kind, including, without limitation, any implied warranties of merchantability or fitness for a particular purpose, or noninfringement. In no event
will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, business interruption, goodwill or lost data, even if CA is expressly advised of such damages.
ITIL® is a Registered Community Trademark of the Office of Government Commerce and is registered in the U.S. Patent and Trademark Office.

white paper: Myths of the Configuration Management Data Base (CMDB) 3
Executive Summary
Challenge
With the evolution of IT, service management has taken the driver’s seat to the front office.
CFOs who routinely had viewed IT as a cost, now see IT as directly related to cash flow.
When IT fails, the cash flow evaporates. Further, the relationship between investments in IT
and support for business strategy has become more direct in nature. Just as the internet has
eliminated the need for the middle-person in many circumstances, service management,
through ITIL®, has removed the mystery that separated IT from the business. IT is today a major
economic driver, and ITIL is a major contributor. The challenge for IT is to dynamically articulate
the relationship between IT resources and business value.
Opportunity
The CMDB is an information repository that is leveraged by the various processes and functions
of ITIL. The CMDB is essentially a data set containing critical it business resources and their
relationships with one another. Through successful design and deployment, the CMDB becomes
a logical representation of the business through the lens of technology. Essentially, the CMDB
is a blueprint for business capacity and availability. The challenges of selling and implementing
a CMDB, both internally and externally, have led to a fair amount of misjudgements. By
understanding these myths and accounting for them, the chances of having a successful
investment in building a CMDB is improved substantially.
Benefits
A successful deployment of a CMDB provides business value in several dimensions. First,
it improves the technology profitability equation: avoiding costs, reducing costs, protecting
revenue, and increasing revenue. Second, it helps streamline the management of time as
a resource through better execution of essential services and maintenance, regulatory
enforcement, and adoption of changes. Third, the CMDB improves the economy of an
organization’s business model through resource coordination, strategy planning, and
management visibility. By focusing the CMDB on seven use cases and avoiding time wasted
due to misunderstanding hype, the information in this white paper helps organizations improve
the chances for success in adopting best practices and aligning business value with it capacity
utilization.

4 white paper: Myths of the Configuration Management Data Base (CMDB)
Understanding the CMDB — Seven Fundamental Use Cases
Where Do Myths Come From?
For many IT people, the discipline of Service Management, if not the industry itself, has
become synonymous with ITIL. Through three versions, ITIL has continued to transform
IT from the being hidden in the basement to the economic value creating organization that
today literally is the business. IT is front and center in the war of competitive difference. By
creating a common vocabulary to coordinate the efforts of IT staff throughout the world, ITIL
became the authoritative voice for Service Management. More recently, as ITIL v3 centered
around the concept of a Service Lifecycle, and formalized alignment with the business through
Service Strategy, ITIL has become a communication vehicle — not only within IT, but amongst
customers, partners and service providers alike.
With the evolution of IT, Service Management has taken the driver’s seat to the front office.
CFOs who routinely had viewed IT as a cost, now see it as directly related to cash flow. When IT
fails, the cash flow evaporates. Further, the relationship between investments in IT and support
for business strategy has become more direct in nature. Just as the internet has eliminated the
middle-person in many circumstances, Service Management, through ITIL, has removed the
mystery that separated IT from the business. IT is today a major economic driver, and ITIL is a
major contributor.
Yet, the question of how ITIL contributes to the business can still be complicated to answer.
Often, value is identified through business results that are tracked over time. IT and its
automation is almost unique in its effect on benefit realization accomplished over a period of
time, well after the initial investment has been made. Because of this, the presumptive ROI of
technology has often been inflated, and then unrealized. The irony is that there are specific
effects that can immediately impact the bottom line, and therefore profitability, in many ways.
One example is the use of a Configuration Management Data Base, which is usually referred to
as the CMDB.
Briefly, the CMDB is an information repository that is leveraged by the various processes and
functions of ITIL. The CMDB is essentially a data set of defined Configuration Items (CIs) with
attributes tracked about each. Additionally, the CMDB also tracks the relationships between
CIs. The CMDB information becomes a logical representation of key enterprise IT objects,
such as hardware, software, people, services, processes, and documentation and how they
are interrelated. Imagine if a blueprint could be made of an entire business model, from key
stakeholders to supporting services, from key systems to key components, and from key
resources to key assets. The CMDB is essentially an information repository that reflects this
blueprint on demand.
The convenience of having this blueprint available as an information repository is in its support
for understanding, planning and automating specific operational tasks for coordinating
enterprise objects. That is, through the management of relationships of CI’s, particularly using
ITIL processes, IT can provide discernible value to the business in ways that were previously
invisible or not economically viable.

Fundamentally, the design of a CMDB can support the gain of business value through several
dimensions. For one, leveraging the CMDB helps in solving the terms of the profitability
equation: avoiding costs, reducing costs, protecting revenue, and increasing revenue. Another
is about managing time better as a resource. By exposing the most critical CIs and relationships
more immediately, the CMDB focuses the usage of time required to execute essential services
and maintenance, regulatory enforcement, and successful adoption of changes. These clearly
support the equation for profitability. In another dimension, the CMDB improves the economy
of a company’s business model through informing resource coordination, strategy planning, and
management measurement.
For realizing these benefits, seven fundamental use cases for the CMDB have been identified in
Table 1. Each uses case impacts these dimensions in different ways. Each can be implemented
over time and within various level of process maturity. Describing this range of options provides
the mechanism to set goals and link to a specific IT and business strategy.
Table 1

Historically, the problem with understanding the link of IT to business value has been a lack
of this kind of description, made worse by misunderstandings that stubbornly took its place.
Those misunderstandings, or myths, are significant challengers to effective leverage of an
appropriate CMDB.
The Different Types of Myths
There has been considerable skepticism when it comes to IT’s ability to contribute to the
business. That same skepticism can affect the implementation of a CMDB in several ways, one
of which is the implementation of the seven fundamental use cases. These are referred to as
the Myths of the CMDB. However, before we get specific about these key myths are specifically
discussed, it is important to first understand the nature of a myth.
A myth is a collectively held belief that has no basis in fact and has been manufactured over
time to resist extinction. Myths develop over time because people are concerned about
something that they desire or fear; in general, each person is concerned about the value and
execution of what they want. Even though there may be no factual requirement for meeting that
desire, or even evidence that the desire represents what they really need, it is these myths that
communicate strongly the desires and fears of their experience.
Because of this emotional basis, myths are hard to overcome. They are ever present and need
to be specifically exposed in the assumptions of business plans, goals, policies, etc. Therefore,
having a list of myths is not enough. There must be diligence in seeking out where these myths
might exist within the business. In IT, myth holders generally want predictable benefits or safety
and the ease of getting or giving them. But to aid in the discovery and unmasking of these myths
as they relate to the CMDB, it is helpful to understand four key types of myths.
The Conceptual Myth grows around the manner in which the CMDB has been described in the
ITIL books, or other similar types of material that have been provided by Service Management
practitioners in the past few years. These myths focus on the nature of the CMDB as it pertains
to being a repository of information. They often advocate specific information that should or
should not be included in a CMDB.
The Process Myth is focused around the manner in which the CMDB supports ITIL processes or
business processes in general. These myths often advocate how a CMDB will instantaneously
improve the efficacy of the business and the organization simply through its adoption. They
myths are often perpetuated when stated benefits give no specific guidance into the type or
amount of information required by the process, nor how expensive it is to maintain.
The Organizational Myth is focused around the manner in which the CMDB, through the
adoption of ITIL, will improve organizational execution and organizational communication. It’s
true that ITIL improves both by providing a distinctive vocabulary. However, ITIL as a tool for
adopting best practices in Service Management often influences or requires changes to the
types and distribution of process responsibility. This naturally exacerbates an organization’s
resistance to change. Because the CMDB is a primary contributor of shared standard
information, this myth often touts a CMDB’s ability to dissolve organizational differences, but
in fact, the CMDB can make them much more visible — particularly differences related to
outcome management and accountability. These challenges will be found anytime there is an
ITIL related project that ignores the softer side of change management.

The Technology Myth is the most common myth of all. Basically, it’s the idea that a CMDB that
is built or bought will just work as designed, and that the whole IT organization will embrace
it without question. Most often, an organization is prone to a technology myth when the
proposed idea or tool sounds like it will be the total solution. According to industry literature,
this has been largely the case around the CMDB. Contrary to the promise, any suggestion that
a technology is the perfect fit for all is a myth. Most IT organizations are heterogeneous, and
the pragmatics of coordinating the functions and departments require that resources be tied
together in a way that makes a perfect fit impossible. This is especially true with the CMDB.
It’s been proven in both academia and in industry that the perfect system, an organization with
the exact balance of optimized resource, is impossible. There will always be some slack, gap or
noise in the system.
The way to succeed in deploying a CMDB is in understanding and anticipating these four types
of myths, and working around them by being precise with requirements. It’s also important
to set the right expectations with key stakeholders. The preparations to look for will include
organizational descriptions, requirements documentation, process design, technology
specifications, and more.
Understanding CMDB Myths Helps Align Business Value to IT —
A Baker’s Dozen
Conceptual Myths
MYTH #1: The CMDB is simply a database.
The reality: The CMDB is more of a data view than a true database. In fact, the CMDB is both
a subset and superset of individual databases. It is not a single monolithic structure. While
the implementation of a CMDB may be by maintaining a database, the reality is that as it is
leveraged to support a widening range of IT processes and functionality, the data required to
make it useful will need to cover an increasingly wider set of data sources. That is why the
industry has been recently talking about the need for the CMDB to leverage the concept of data
federation. (The CMDBf is one such open standard). Federation allows some combination of
data to stay in source systems and moves other data into a more centralized system. From the
user perspective, the CMDB looks like one system, even though the data is in fact decentralized.
Shared with this myth are the notions that all data should be considered equally important, that
only the CMDB is the valid database for ITIL, and that all data needs to be in the CMDB before it
is valuable. In fact:
• Data in the CMDB reflects the notion that management has committed that specific CIs
are under specific change control. That in no way means that data outside of this control is
unimportant to the business.
• ITIL itself leverages information from many repositories, including performance databases,
asset repositories, financial systems, etc.

MYTH #2: The CMDB is an asset repository.
The reality: The CMDB, by both its nature and its definition, focuses on resource versions and
relationships. An asset repository, on the other hand, is focused on resource ownership and
availability. The concept of a CMDB is to provide the ability to map key intangible assets, like
services, to tangible resources, like hardware and software. That’s what provides the context to
understand not only an item’s capital resource value, as managed in an asset repository, but its
business value, by understanding its contribution to the organization.
Shared with this myth are the notions that the CMDB needs to store all asset data, that the
CMDB is the place to manage inventory, and that the CMDB is just an asset repository with
relationship information. In fact:
• The CMDB is ultimately a federated information repository, a pointer to critical information
about the configurations of a resource under change control.
• Having all asset data in the CMDB will not improve your Configuration Management process,
and in fact will impact your Asset Management process by complicating the need to keep a
second set of asset data from contradicting the first.
• Likewise, ownership-dependent information supporting Asset Management is managed
through inventory, not through the CMDB.
• The notion that all CIs are assets, and that all assets are CIs. As assets, objects reflect capital
investments made by the organization to establish resource capacity. But defined as CI,
objects reflect the assignment of those investments to the manufacturing and supporting of
IT and Business services. CIs, as providers or dependents, carry some type of responsibility
to operational continuity in the organization and are therefore placed under change control to
reduce the risk of disruption.
MYTH #3: The CMDB is the single source of truth.
The reality: One of the most challenging aspects of deploying a CMDB is to understand the
nature of the data it contains. Often, a CMDB is thought of as a data warehouse for ITIL. That is,
it assembles data from around the organization and puts it in one place. While it true that the
CMDB requires having accurate up-to-date data, its focus is on being the source of truth about
the authorized state for those resources under change control. In fact:
• This focus rules out the CMDB as the single source of truth about all IT objects, because not
all IT resources are under change control. Nor does it guarantee that the data it contains is
actually reflective of the actual current state of a resource, since the current state may differ
from the authorized state. This boundary of the CMDB is by design.
• Often many organizations push information about currently discovered items into the CMDB
as a way to get it initially populated. However, this information load only suffices beyond that
moment if the IT department has decided that a formalized Change Management program
will not be adopted to manage IT.

• The reason for Change Management is simple; the concept behind Change Management
is to understand and control the differences between a CI’s actual state and its authorized
state. By ensuring that these two states are the same, the change process ensures that
the organization’s risk management policies are being followed and that any unauthorized
changes are minimized.
It should also be noted that as part of the process of designing the CMDB, applications that
store data about both authorized and audited (discovered) states should be identified as to
which should represent the authoritative source of record. In this way, whether the CMDB
imports that data into a repository, or federates the data, the organization understands what
data should be trusted from which source.
MYTH #4: ITIL strictly defines the contents of a CMDB.
The reality: In the three released versions of ITIL, the definition of the purpose of a CMDB has
not changed nearly as much as the definition of what a CMDB should contain. The reality is
that the CMDB should contain any major IT resource under change control — whether it be for
example, a person or a modem. If the resource plays a critical role in ensuring that a service will
operate correctly, or plays a role in making sure a service can be returned to normal operation,
it should be placed under change control. When designing the CMDB, an architect should work
with the business to determine which CIs are critical and what level of detail is required to
track them. This exercise is often accomplished through the definition of an IT Service Model.
Therefore what defines the contents of the CMDB is not the ITIL books, but the IT Service Model.
Shared with this myth are the ideas that the CMDB should not include people CIs, that the
CMDB should not contain any operational data, and that all information involved in change
control must be in the CMDB. In fact:
• If understanding a resource role, or specific person, is critical to delivering a service, having a
people object as a CI is entirely reasonable.
• Meanwhile, the CMDB is not a repository for operational systems as such. However,
when assessing data for authorizing service delivery, there is a certain minimal range of
specificity that qualifies as being thorough. Operational data like CI relationships, or specific
attributes that are tracked operationally, can be legitimately placed into the CMDB with the
understanding that doing so implicitly accepts the audited state as the authorized state. The
Change Advisory Board will understand that certain best practices of change control and
auditing may therefore not be possible.
• Finally, while having a CI in the CMDB is an indication that it is under change control, it does
not imply that all data related to change control is in the CMDB. Other data repositories such
as financial planning, lease management, and warranty contracts, may become a critical part
of change control due to their influence on approvals and other policy constraints. In cases
where the CMDB repository is implemented to contain copies of only certain external data,
control data from these additional repositories still may not be included. A typical approach
to get beyond this limit is federation.

Process Myths
MYTH #5: Change, Configuration, and Asset Management are the same.
The reality: Until recently with the release of ITIL v3, Asset Management was completely
separate from Change and Configuration Management. That often meant that common
requests related to moves, adds, and changes to assets were compromised by a lack of
coordination between the various processes. As mentioned previously, Asset Management
focuses on ownership and availability. Configuration Management focuses on assembly
of resources, and Change Management focuses on managing risks and governance. There
is actually minimal overlap of scope if these three functions are practiced correctly with
appropriate roles defined. The key is to see how Asset Management plays a critical role in
providing resources to be consumed by IT Processes and Business Services. Change and
Configuration Management together focus on making sure the resources work well together to
deliver the expected result.
Along with this myth are the notions that Change Management is not needed if Asset
Management is in place, that IMACs (Installs, Moves, Adds, and Changes) in Asset
Management don’t impact Change and Configuration Management, that Change, Configuration
and Asset Management use the same data, and that the maturity of one process does not affect
the maturity of the others. In fact:
• Managers leverage Change Management and Asset Management for different reasons.
Asset Management is linked to a financial strategy, and Configuration Management is linked
to a risk management strategy.
• IMACs that manipulate assets to impact the assembly of services represent a risk to the
business, and all three management processes need to be in place.
• Finally, the different roles within each of the processes allow each process a degree of
opportunity to mature independently, but only to some degree. The processes will still have
interdependencies. For example, from the business point of view, an organization simply
cannot safely execute and track the changes to assets without understanding how the
underlying change impacts the organization’s operational capacity and continuity. Therefore,
pursuing maturity in each process calls for a degree of process parity.
MYTH #6 Implementing a CMDB will make you ITIL compliant.
The reality: Before addressing this myth, there is an underlying assumption that must be
corrected. There is no such industry-validated concept as being ITIL Compliant. ITIL is not
a standard; it is a set of recommended practices that has proved to provide better, more
predictable results when formalizing Service Management as an organizational discipline. ISO
20000, on the other hand, which was based on ITIL v2, is a standard. Therefore, when an IT
organization is looking to be certified, it is not aiming to be ITIL Compliant; instead it is being
certified in ISO 20000. The big difference between ITIL and ISO 20000 is that as a standard,
there are specific objectives that can be measured that must be adhered to. ITIL does not
require an organization to adopt any specific standards, while ISO 20000 does.

Shared with this myth are the ideas that following ITIL practices will guarantee better
performance, that implementing a CMDB will ensure better decision making, and that
implementing a CMDB ensures SOX Compliance (or any other regulatory standard). In fact:
• Adopting ITIL does not guarantee better performance, nor does implementing a CMDB. The
key to creating value with ITIL is to ensure that investments in adopting its best practices are
dedicated to operational improvements that are visible by management. For example, better
decision making or adherence to regulatory targets requires that these commitments be
embedded into the overall use of the ITIL processes, not just added as some addendum.
• The CMDB can absolutely help to achieve better results, but only when joined properly with
other processes that directly improve business performance.
MYTH #7: CMDB is an overarching or executive process coordinator.
The reality: According to several IT analyst groups, the word CMDB is better known than the
word ITIL. This is attributed in part because the CMDB is a unique requirement of ITIL that
can be automated. Its popularity also stems from its unique contribution to ITIL processes
and functions. Because of these two characteristics, the CMDB is often seen as a means to
align execution of operational processes. In fact, the CMDB supports processes; it does not
deliver them. This is true even for Configuration Management. As an information repository,
the CMDB provides a means to coordinate the efforts of IT. It encourages the alignment of IT
with the business by providing a natural opportunity to build an overarching service model. It
provides a means to organize how various processes contribute and consume information in an
asynchronous manner. The CMDB is not, however, a process coordinator.
Shared with this myth are the notions that implementing a CMDB will automatically integrate
ITIL processes, that implementing a CMDB will streamline process output, and that by leveraging
a CMDB, ITIL provides a standard set of processes, metrics, and reports, etc. In fact:
• As noted above, the CMDB contributes to the coordination and execution of ITIL processes
but does not actually focus on specific tasks. That is the role of Configuration Management.
• The CMDB will not streamline process output. This reflects the manifestation of various ITIL
processes in an operational environment.
• Finally, the CMDB generally does not focus on reports, metrics, etc While ITIL provides some
guidance around these, the particulars are left to specific implementation efforts. The CMDB
may contribute to such oversight, but is not specifically accountable for it.
Organizational Myths
MYTH #8: Implementing a CMDB is not political.
The reality: One of the biggest mistakes when implementing ITIL is to assume that politics
are not involved. For implementing both ITIL and the CMDB, managing expectations and
campaigning for their acceptance is a large part of a successful implementation. The
CMDB is a major contributor to information that encourages decisions one way or another.

Therefore, designing and deploying a CMDB is political. Many IT projects fail because
the major stakeholders are unaware of how entangling alliances often assemble to defeat
ideas that influence accountability and responsibility. The CMDB in fact supports specific
types of accountability and responsibility because of its ability to track changes, enforce
standards, describe dependencies, and essentially bring a holistic picture of how a service is
implemented. One key to overcoming these political challenges is to formalize the instrumental
role for identifying the CMDB data ownership and maintaining the data integrity. Another
recommendation is to separate CMDB contributors from CMDB consumers. Moreover,
avoid setting the idea that the CMDB is owned by one team (for example, the Configuration
Management team). Using these approaches helps key stakeholders to see the value of the
CMDB without being overwhelmed by its potential impacts.
False observations that are shared with this myth are that everyone will see the value of the
CMDB, and that management will automatically view building a CMDB as a good investment.
Another similar myth is that if the data is there, people will use it. In fact:
• In fact, the scope and size of the CMDB is not proportional to the value received. Most of
the value comes from efficiently protecting the most important business services from
unnecessary failures. The CMDB information should focus on the minimum amount of
critical data that maintains that protection.
• A good investment requires an argument for ROI that impacts the bottom line of the
business, not to simply provide soft cost reductions. Often the CMDB will cost more than
previous approaches, and it will be some time before the overall investment actually returns
a discernible improvement. Getting people to use the data requires a specific effort around
selfish needs. The more tightly coupled the information is with specific roles, specific people
and specific decisions, the more likely a CMDB effort will remain a true contributor to IT
business alignment.
MYTH #9: The CMDB is not a management tool.
The reality: One reasonable way to think about management is to understand the five
essential questions that must be continually reviewed:
• What is going on?
• What needs to change?
• What does the future look like?
• How do we transition from the current state to the future state?
• How do we know that the change has been successful?
Clearly the CMDB, by itself, will not adequately cover each of these questions.
The CMDB invokes many opinions about what it is, what it is not, who contributes to it, and who
benefits. Regardless of what level of maturity an organization is working towards, the CMDB is
always playing a dynamic role with management. This role is played through decision support
and by providing proactive visibility to the impacts of the ITIL process and functions on the IT
organization and the business.

Given the appropriate time and effort, a CMDB design supports both an operational and
planning perspective, and it fully represents a logical view of the IT organization’s resources.
Through its representation of the IT services model, the CMDB becomes a key contributor to
addressing each of the essential management questions. By reviewing Table 1 in this white
paper, it can be made clear as to how the seven fundamental CMDB use cases serve as a
tactical approach to accomplishing this goal.
Shared with this myth is the idea that the CMDB serves only one purpose, whether it be that the
CMDB is just a planning tool, just an operational tool, or just a supporting tool. In fact:
• The CMDB is versatile in nature. Therefore, it is critical to anticipate and prioritize the target
scope of the CMDB when drafting its logical design.
MYTH #10: Building a CMDB is a single, one-time project.
The reality: Like most IT projects of considerable complexity, building a CMDB is best
accomplished by using a phased approach. Configuration Management matures over time,
and is bounded in scope by its natural interdependencies with the other ITIL processes. But
throughout its maturation, Configuration Management relies on a CMDB. Planning for the
CMDB begins with three specific recommendations:
• Avoid too much analysis in any deployment. As indicated by the various myths addressed
in this white paper, it’s easy for management to find itself caught up in misunderstandings.
Focusing on the seven CMDB fundamental use cases will help orient an implementation
around discernible value that is achievable in phases.
• The second recommendation is to cCenter the CMDB around areas of high business value.
Focus the initial implementation of a CMDB around establishing an initial set of CIs that
map critical business services to supporting resources. This makes the ability to sell the
concept of a CMDB to internal sponsors easier, avoids politics, and shows logical promise of
immediate value.
• Stage CMDB projects in terms of the level of data accuracy required. This is arguably the
most important recommendation. It is easy, and risky to design requirements for the CMDB
without regard to the availability and integrity of the data required. Instead, building and
adopting a CMDB design strategy is a useful approach to ensuring that costs and methods
for ensuring supporting data are manageably in place and sustained. Tying that strategy to
building out the Service Model helps ensure the integrity of project stages over time.
Shared with this myth is the common idea that a CMDB is just a data project and not a strategic
program, and that an organization can create a CMDB easily by simply merging discovery data.
In fact:
• Building a CMDB shares the risks of all IT projects. It is relatively simple to describe and built
a prototype, but its ability to reach production level can be challenged by many issues. Some
of these are the capability of tracking non-discoverable data, the costs of maintaining data
feeds, and integrating the CMDB into the fabric of IT operations.

Technology Myths
MYTH #11: A CMDB can be purchased.
The reality: There has been a tendency for IT organizations to approach software
manufacturers for out of the box solutions. The same is true for the CMDB. Several vendors
provide a CMDB solution, but the basic fact remains that a CMDB cannot be purchased. It must
be built through carefully crafted projects over time and designed around process maturity.
There is no single CMDB design that fits all situations.
Shared with this myth is the notion that CMDB projects can be outsourced to a third-party
organization, and the notion that a CMDB is a one-time investment. In fact:
• The CMDB is neither a one-time investment nor a project that should be outsourced. The
CMDB is an investment over time. Benefits can be realized throughout various projects, but
they must be inherent in the CMDB design. The seven fundamental use cases is one guide of
methods by which to plan to build value, but there are others.
• Meanwhile, from a third-party perspective, there is a risk in having an external provider play
a strategic role. Often, a robust CMDB requires data from various parts of the organization
that have information needing protection from outside parties for competitive reasons or
regulatory issues. Adding a third-party to the mix may compromise the ability to leverage the
full range of data that would have value in the CMDB.
MYTH #12: The CMDB and its technology are identical.
The reality: According to ITIL, the CMDB is a logical representation of the IT environment. The
CMDB is fundamentally a model that requires a coherent design and relevant data to properly
stage and implement. However, that data can exist in many formats, such as a spreadsheet
or a diagram. The CMDB, as noted before is not truly a database, but rather a view. Separate
from that view are the particulars of applying technology to the requirements of a CMDB. The
implementation of a CMDB forces a set of technology decisions that lie outside of the services
model that underpins the definition of the CMDB.
One other distinction that is seldom part of the design is the separation of Configuration
Management from the implementation of the CMDB. While the ITIL books articulate several
responsibilities of Configuration Management and label it as the owner of the CMDB, it must
be remembered that a technological implementation of a CMDB takes additional responsibility.
Concepts such as normalization, transformation, profiling, federation, synchronization, backup,
restoration and reconciliation are all less a part of the formal definition of a CMDB.
Shared with this myth are themes that have been addressed previously in this white paper,
including the ideas that a CMDB automates Configuration Management and that a CMDB
Database is identical to a CMDB.

MYTH #13: CMDB-based technology is the ultimate solution.
The reality: While this is the last myth being covered, it may be the most destructive. For all
the previous myths discussed, technology is seen as the ultimate solution. Different vendors
provide different views of the CMDB, and many articles are written about how easy or hard it
is to manage a CMDB. Some argue that the CMDB is a myth itself and can never be managed.
Others argue that the CMDB is really just an extension of Asset Management. Others argue
that the permanent CMDB is a myth itself and can never finally be managed. Studying these
arguments and separating fact from fiction takes time. There are, however, certain fundamental
realities that can serve right away as reliable conclusions. Rules of thumb:
• The costs and efforts to design and maintain a CMDB are not trivial.
• CMDB technology will not discover all CIs and CI relationships.
• Data management and integration is very time consuming.
• Change Management is required to keep the CMDB accurate.
• CMDB data security needs must be carefully planned.
• Updating the CMDB in real time is generally discouraged.
• Managing CI Attributes and CI Relationships requires the same effort.
Avoiding the Myths — The Benefits of a Proper CMDB
Implementation
As identified in Table 1 — there are, at a minimum, seven fundamental benefits of implementing
a CMDB. However, these benefits must be built, they cannot be purchased. Achieving these
benefits must be specifically designed for. A successful outcome will not be achieved by simply
deploying a CMDB.
The aforementioned 13 myths identify areas where often CMDB projects tend to fail. Because
CMDB’s often cannot be implemented in one phase, it becomes critical keep all of these
challenges, and there impacts, in mind as CMDB projects are introduced and throughout
the project.
Keep in mind that the ultimate goal of a CMDB should be to provide the ability to continuously
introduce new services, support them by avoiding risks that would impact their effectiveness,
and ultimately disposing them in favor or more product services. By establishing the CMDB’s
contribution to this process, a process of Configuration Management, and its key supporting
process of Change and Release Management, becomes key contributors to adding and
maintaining the value of IT to the business.
A successful implementation of the CMDB should also support transparency of IT to the
business in terms it understands: resource coordination, strategy planning, and management
visibility.

CMDB is there are many things to consider when implementing a CMDB. The 13 myths
described in this white paper, along with the variations described for each, have proven over
time to impede the efforts of many. This can occur during the initial design and also as when
the transition to adopting. Avoiding false starts, inadequate support, and poor design are key
to achieving those goals.
Conclusions
There are many things to consider when implementing a CMDB. The 13 myths described in
this white paper, along with the variations described for each, have proven over time to impede
the efforts of many. This can occur during the initial design and also as when the transition to
adopting the ITIL begins. Hopefully, by being explicit about specific risks, the deployment of a
CMDB will not only be technically successful, but will legitimize the unique contribution of IT to
an organization’s competitiveness.
In concluding, here are five final recommendations:
1. Focus on the seven proven CMDB use cases.
2. Focus on process maturity over time and in incremental steps
3. Focus on the level of data accuracy that is required and achievable.
4. Focus on high impact areas with management visibility.
5. Anticipate political impacts when defining the project scope.
About the Author
David Messineo is an ITSM practitioner with more than 20 years experience in developing
and deploying enterprise-level software solutions focused on IT management. He is currently
a Practice Director at CA, where he focuses on establishing best practices for consistently
delivering large scale implementations. David holds both an ITIL Service Manager and eSCM
certification.
The author would like to thank various CMDB Services Experts throughout CA for their input.
The author wishes to thank the following people for their contributions: Enrico Boverino,
Guillermo Gualda, Robert Hargett, Zoltan Harsanyi, John Hutchinson, Phillip Mead, Raymond
Nicol, Barry Stern, Marc Vanthienen, Dietmar Werner and Malcolm Ryder.

CA, one of the world’s largest information technology (IT)
management software companies, unifies and simplifies
the management of enterprise-wide IT for greater business
results. Our vision, tools and expertise help customers
manage risk, improve service, manage costs and align
their IT investments with their business needs.
MP335980409

Myths of a CMDB

More Related Content

What's hot (20)

Similar to Myths of a CMDB (20)

More from David Messineo (20)

Myths of a CMDB