This article discusses common myths about configuration management databases (CMDBs). It begins by providing background on the growth of CMDBs and why they are needed to help organizations better manage frequent IT changes. It then addresses four common myths: 1) A CMDB is only an internal IT project rather than providing business benefits. 2) Process improvement should be completed before implementing tools. 3) Asset management databases alone can serve as a CMDB. 4) A CMDB needs a single centralized database rather than a coordinated view across systems. The article argues that CMDBs should focus on improving IT services for business users and that tools can help improve processes.

1. HOME VENDOR DIRECTORIES MY DATA CENTER SPACE EDUCATION ASK THE PRO WHITE PAPERS FREE MEMBERSHIP F
Search - Stories and More... Search
NEWS MENU
ARTICLE
ARCHIVES
RESOURCES
INDUSTRY LINKS
JOB MARKET
CLASSIFIEDS
REAL ESTATE
IT NEWS
FACILITIES NEWS
DESIGN NEWS
DCJ NEWS
PRESS RELEASES
IT ARCHIVE
FACILITIES ARCHIVE
DESIGN ARCHIVE
PRESS RELEASE
ARCHIVE
GLOSSARY
WHITE PAPERS
WHAT IS A DATA
CENTER
CALCULATORS
STANDARDS
POLL RESULTS
DATACENTER.TV
ANALYSTS
CONFERENCE
PROVIDERS
TRADE
ORGANIZATIONS
Become a
member of My
Data Center
Myths of the CMDB
Written by Michele Hudnall
WEDNESDAY, 06 FEBRUARY 2008
Is it a database? Is it software? Is it a system? What does it have to do with discovery
or application dependency mapping? Is an asset management a CMDB? What is a CMDB
supposed to do? There’s no shortage of questions which leaves one thing for certain –
CMDBs are indeed confusing.
Ironically, the confusion over what a CMDB is hasn’t stopped the growth. For example,
Forrester Research predicted that the change and configuration management market,
which includes CMDBs, would grow 28 percent from $2.099 billion in 2006 to $2.687
billion in 2007. Another research firm, IDC, wrote in early 2007 that CMDB deployments
would accelerate over the next three years as more companies extend their current work
on process standardization via ITIL and other capability maturity models.
While the CMDB has grown in global notoriety, there is anecdotal evidence to indicate that
CMDB adoption rates in Europe are outpacing those in North America. This may seem to
defy conventional wisdom at first, but when one considers the fact ITIL originated in
Europe, it is quite logical. The rest of the world still struggles with sprawling technology
infrastructure but with an increasing global drive towards IT and business alignment, it’s
catching up in a hurry.
Regardless of where the growth is occurring, it’s the pace of the growth itself that is
impressive and explains why both vendors and IT organizations alike are increasingly
paying more attention. Yet this begs the question – what is the business pain that’s
driving this growth?
Painful change
The answer to that question can be summarized in one word: change. The complexity of
today’s IT infrastructure places enterprises at great risk of prolonged and frequent IT
outages as a result of change. For example, market research has found that upwards of
80 percent of IT outages are caused by human error that stems from both planned and
unplanned IT changes, as well as shortfalls in testing and process inadequacies.
Yet simply avoiding change is not possible. Things break. Software needs patches.
Servers will always need memory upgrades. IDC Research wrote that a typical Global
2000 IT organization averages 500 to 600 manual configuration changes a month to its IT
infrastructure. Other analysts have publicized similar findings; for example, Forrester
Research wrote that on average, large organizations make approximately 500 changes
per month to their IT infrastructures.
Change is also necessary, in fact, pivotal, if IT is to have the agility to respond to ever-
shifting business needs. Agility in IT means responding to business needs when a
NEWSLETTE
Other DC
Weekly e
Receive HT
POLLS
gfedcb
gfedcb
Name
E-mail
gfedcb
Subscribe
Do you believ
power will ga
popularity in
Data Center?
Yes, we a
currently
a DC pow
solution
Yes, we a
considerin
DC power
solution
Yes, but t
technolog
needs to
No, the b
do not ou
the negat
No, it will
difficult to
change fr
to DC
I do not k
enough a
DC power
make a d
Vote Re
What is the f
of managing
density heat
removal in th
data center?
Thursday, 07 February 2008
Page 1 of 5The Data Center Journal - Myths of the CMDB
2/7/2008http://datacenterjournal.com/index.php?option=com_content&task=view&id=1477&Itemid=40

2. Space!
What's this?
company builds, buys, divests or merges lines of business. It is defined by the ability to
quickly deploy and manage new services for example, a Web application that the business
launches in order to pursue an emerging market opportunity and stay ahead of the
competition. IT’s role as a strategic business partner stems from its ability to make
changes quickly – and less risk.
If change is mandatory, then IT organizations need a means to control change and
manage the impact of change when it does occur. This is the value proposition of a
CMDB.
CMDB’s purpose
A CMDB visually models information about IT infrastructure components in order to
understand the interdependencies among these components in the context of IT service.
If IT understands the relationships among its IT components – if it has the ability to map
components to applications to the business – then IT can control change and manage
impact. A contractor wouldn’t knock down walls of a kitchen during remodeling project
without blueprints to understand how that action might affect the structural integrity of
the home. Likewise, IT needs to understand the impact of change prior to implementing
changes in their house – the production environment.
For example, IT needs to understand impact the installation of a new O/S software patch
to a single box in a server farm will have on a business service – such as online trading –
and can take proactive steps to mitigate the risk of an outage. Similarly, should outages
arise from unplanned changes or for any other reason, such as fault failures, the
relationships the CMDB maps allows IT operations to quickly find the root cause of IT
outages or degradations – often before performance, availability or end-user satisfaction
are adversely affected.
So why all the confusion?
CMDB is shorthand for configuration management database – which is where people get
tripped up right away. The fact it is called a database is something of a misnomer, which
the IT Infrastructure Library’s (ITIL) third version aims to clarify by classifying the concept
as a configuration management system or CMS. Compounding the issue, analysts,
vendors and even customers have all weighed in with modified definitions. ITIL defines a
CMDB as a database used to store configuration items (CI) – the physical or logical items
that comprise an IT infrastructure – throughout their lifecycle.
Semantics aside, notice the example in paragraphs above provide a purpose for a CMDB,
rather than a definition. A CMDB project shouldn’t be about collecting and consolidating
massive amounts of data for data’s sake – it should be about what IT is able to do with
the data, which ought to be to improve service quality for the business. This is the first
and perhaps the biggest stumbling block to a successful CMDB project: an over-focus on
definition. The project needs a vision and purpose, not a definition.
The debate over CMDB definitions is complicated by the fact that IT’s functional disciplines
are divided by each organizational role’s own unique view of the world. Financial types
see a CMDB project through the lens of asset management systems; change managers
might have an affinity for discovery; and help desk staff see the service desk, a customer
facing tool, as the most logical basis for a CMDB. In truth, they are all partly right – quite
literally. Each functional discipline has a federated piece of the truth that needs to be
synchronized and reconciled to become a trusted single source.
Much like the tools they use, these siloed views have married semantics and give rise to a
host of myths about CMDBs.
Myths of the CMDB
Myth #1: If we build it, they will come
A CMDB is not just an IT project. The purpose of the CMDB should not be solely focused
inwardly on the efficiency of the IT organization. A CMDB should focus on a service that is
Liquid coo
Consolida
Virtualiza
Raising th
allowable
temperatu
IT equipm
Better de
racks
Chip leve
cooling
technolog
All of the
Vote Re
Do you believ
that most da
centers will b
outsourced i
next 10 year
Yes, we a
planning o
outsourci
data cent
Yes, we h
already
outsource
data cent
Yes, techn
changes,
and staffi
drive
outsourci
No, but sm
and medi
businesse
find it att
No, data c
will remai
house
Vote Re
Page 2 of 5The Data Center Journal - Myths of the CMDB
2/7/2008http://datacenterjournal.com/index.php?option=com_content&task=view&id=1477&Itemid=40

3. consumed by the business or external users and it should provide benefits to a service
that directly impacts the business.
Myth #2: Process before technology
Process is important – it’s so important that it’s nearly a religion some parts. Yet on the
same note, the effort and energy spent perfecting a process before automation can be
overkill. Even ITIL is talking tools now. To some degree, every IT organization has at
least some sort of process by virtue of commodity tools such as service desks and
discovery tools. Since it exists, there’s a tangible benefit to be gained by integrating data
from these tools into a service oriented CMDB.
Myth #3: Asset management is my CMDB
This myth comes in a variety of flavors such as ‘service desk is my CMDB’ or ‘discovery is
my CMDB.’ But these tools each only hold one piece of the puzzle. Asset management
contains physical data about components in your infrastructure – but provides nothing in
terms of relationships and dependencies. The mechanism to uncover relationships and
dependency mapping is discovery – also commonly referred to as application dependency
mapping. Yet both of these tools still do not furnish data associated with problem and
change, which are most often kept in the service desk. Each of these tools contain
repositories of information each sometimes referred to individually as a ‘CMDB.’ But in
reality, truly actionable information is derived only when data from these tools are tied
together. This is why ITIL’s effort to rename the concept CMS is perhaps a better choice.
Myth #4: CMDBs must be centralized
A CMDB does not have to be centralized; it should have a centralized service view. Some
CMDB products require IT to extract, transform and load (ETL) data from their existing
tools (asset management, discovery, and service desk) into a centralized database but the
challenge here is multi-faceted: 1) it’s expensive, 2) the minute you extract the data its
accuracy becomes dated, and 3) the amount of data being jammed into a centralized
repository quickly becomes unmanageable. A better solution is federated model with
application-interface (API) level integration that “points” to the original source in real time
or near-real time.
Myth #5: Every attribute should also be a CI
Some CMDB project managers argue that every IT component should be included in the
CMDB as a configuration item (CI). Here too the CMDB can quickly become
unmanageable – and can end up including data of little business value. A quick litmus
test for including a proposed CI is to ask two questions: 1) do I manage this CI through
change? and 2) should I manage and measure it? For example, a memory card in a
workstation may not be worth monitoring and may not be included as a CI, but a patch
release for a server that hosts all or part of a SAP application is certainly a more logical
consideration.
Myth #6: A CMDB is a colossal undertaking
Some CMDB projects are too broad and too deep when it should be just enough to
manage the service. IT can take a “just enough” approach. Here’s how: 1) identify the
purpose of the CMDB, 2) choose an application or service, 3) model the service, 4)
integrate federated data, 5) define rules and analyses, 6) create analytics and reporting,
7) define role-based views and, 8) repeat as desired. When a CMDB project is created in
a top-down manner with a just-enough orientation in mind, design and implementation
can be easier – especially when approached with a service-oriented perspective.
Conclusion
Interest and public discourse on CMDBs have grown exponentially in the last 12-18
months because CMDBs can solve two very real business pains: controlling change and
Page 3 of 5The Data Center Journal - Myths of the CMDB
2/7/2008http://datacenterjournal.com/index.php?option=com_content&task=view&id=1477&Itemid=40

4. managing impact. The line between business and IT has blurred to the extent that in
many ways, technology has become the business. To this end, CMDB projects are no
longer optional, but rather a business imperative. While interest has grown, so too has
confusion, which tends to arise from esoteric definitions that center on theory, when IT
really needs a pragmatic approach; the best advice might be to avoid letting perfection
get in the way of a good start.
------------
About the Author: Michele Hudnall is a former-META Group analyst and is currently the
director of service management for BSM vendor Managed Objects, which is one of five
vendors in the industry that meet Gartner’s functional requirements to be classified as a
CMDB. She also sits on the board for the US-chapter of the IT Service Management
Forum – itSMF.
Comments (0)
Write comment
You must be logged in to a comment. Please register if you do not have an account yet.
Subscribe to this comment's feed
[ BACK ]
DCJ MENU
ABOUT US
ADVERTISE & MEDIA KIT
EDITORIAL & SUBMISSION
PRIVACY POLICY
TERMS OF SERVICE
PERMISSIONS & REPRINTS
DCJ MAGAZINE
MEDIA SERVICES
CONTACT US
FAQ
FEATURED WHITE
PAPERS
Data Center Availability
Comparison Chart
Managing Data Center
Power and Cooling
True Total Cost for Data
Centers
DC Power for Improved Data
Center Effeciency
A Design Guide to High
Performance Data Centers
4 Metrics Define Data Center
Greenness
Data Centers in Atlantic
Canada
Guideline for Energy
Effecient Data Centers
The Green Grid Data Center
Power Efficiency Metrics:
PUE and DCiE
UPCOMING EVENTS
Southern California Linux Expo
Fri, Feb 8th, 2008, @8:00am
Data Centre World - London,
UK
Tue, Feb 26th, 2008
IDC Green IT Forum New York
Thu, Feb 28th, 2008, @8:00am
Data Center Dynamics - New
York, NY
Tue, Mar 4th, 2008, @8:00am
Data Protection Summit
Tue, Mar 11th, 2008, @8:00am
LATEST JOBS
Page 4 of 5The Data Center Journal - Myths of the CMDB
2/7/2008http://datacenterjournal.com/index.php?option=com_content&task=view&id=1477&Itemid=40

5. Redundant Power, A Path to
Failure?
Powering Change in the
Data Center
Five Strategies for Cutting
Data Center Energy Costs
Through Enhanced Cooling
Efficiency
LATEST VIDEOS
Life in the data center,
episode#2
LATEST BLOGS
Managing VMware - a
Webcast Featuring Mosso
and Hyperic HQ
Predictions for 2008
(article)....
Data Centers in Europe
Clean Tech rebates and
incentives
Spiff Happens
INDUSTRY CALENDAR
«< February 2008 >»
S M T W T F S
27 28 29 30 31 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 1
LATEST COMMENTS
Hypoxic Air & Preventing Fires
Error on the above 7x24
Xchange Delaware Valley Ch...
Hypoxic Air & Preventing Fires
I also agree that it is time for
the NFPA and OSHA...
Hypoxic Air & Preventing Fires
I looked at this with FirePass
about six months ag...
The 10 Most Common Data
Security Issues and How to...
We tend to think about data
security 1) as it exis...
Page 5 of 5The Data Center Journal - Myths of the CMDB
2/7/2008http://datacenterjournal.com/index.php?option=com_content&task=view&id=1477&Itemid=40