1. Inside this issue
Exclusive Interview
with Gartner Analyst
Ronni Colville
Gartner has stated in
the past that Exclusive Interview with Gartner Analyst
"configuration
Ronni Colville on Configuration Management
management is at the
very heart of IT Databases
service
management." What Gartner has stated in the past that "configuration
do you mean by this? management is at the very heart of IT service
What is driving management." What do you mean by this?
increased customer
interest in Configuration management is nothing new. Enterprises have worked with
configuration it in many areas of their infrastructure, but now we view configuration
management management as a very integral part to many of the different disciplines
databases (CMDBs)? that IT must manage on a daily basis.
What approach does
Gartner recommend It is the keystone to enterprise management in general. Today, as we
for building a CMDB? move toward more of a service management persona for IT, where IT
must become more business-focused, configuration management becomes
What are some of the a truly critical component. It involves understanding the relationships and
primary challenges dependencies among various elements that make up a service.
that you see Configuration management is the combination of all IT components:
companies facing in networking, servers and applications, and many other pieces that make up
developing CMDBs? an IT service.
What are some of the
Historically, many configuration management initiatives have failed
technology
because the information needed to document what is required for an IT
requirements that
service is found in too many different places and cannot be pulled together
companies should
in real-time, or even near real-time. Because these efforts have often
consider when
been done manually, they are not real-time, or even near real-time
planning their CMDB
enough to actually be able to show benefit to the business.
project?
What are some of the A new breed of tools has emerged in the last 12 to 18 months that now
business benefits enable IT to view the configuration of infrastructure components and their
companies will realize relationships – hierarchically and peer-to-peer. We call these tools IT
as a result of a Service Dependency Mapping solutions, and they do exactly that: discover
successful CMDB and document the relationships between the components that make up an
implementation? IT service, focused in particular around the server and applications world.
We believe that IT service configuration management is a pre-requisite for
achieving overall success around service-level management and around IT
service management itself. However, it certainly is not an island unto
itself. IT service management also requires other pieces to be in line
around change, incident, availability, performance, and other management
processes.

2. What is driving increased customer interest in configuration
management databases (CMDBs)?
First, it is important to define what a CMDB is, because frankly it may
have a few different identities, depending on how the client wants to use
it. A CMDB is a federated system of discovery information in a centralized
view where the data from various feeds is rationalized. It will start to show
the relationships between components hierarchically, and peer-to-peer, in
a way that allows IT to deliver a service to their end-users or businesses
and show how that service is behaving and performing.
A CMDB will also include capabilities centered around risk analysis for
impact of changes. It may include the change workflow or integrate with
other change tools that will facilitate workflow management to make sure
that the right sign-offs are in place before changes occur. So the broader
the reach of a CMDB, the more processes one is going to need to have
integrated with it.
Today, many of the drivers around CMDB initiatives have a great deal to
do with audit and compliance. IT organizations need to know exactly what
systems and applications are actually installed, how they are actually
configured, and how they are being used. With the number of changes and
frequency of changes, this driver becomes a critical path to high
availability and security compliance as well.
Another driver, much in line with that, deals with the Information
Technology Infrastructure Library (ITIL), which is a process methodology
that many enterprises are beginning to use to ensure that their processes
are defined and documented and can work together across management
disciplines. Once these ITIL initiatives are underway, IT is compelled to
look at how automation layers on top of the processes.
Even looking at Sarbanes-Oxley, we are finding that some enterprises
want to discover and document their financial systems and how these
systems are configured. Additionally, I think there are some broader
drivers, like architecture personnel looking at the next wave of how to pull
all of the IT infrastructure elements together and how to move IT to a
business service. Asset management, as it is moving closer to IT in its
persona and its role, is now also looking at not just the financial aspects of
an asset, but also the configuration of relationships among other assets.
Once the CMDB initiative gets started and enterprises have an accurate
view of how devices are configured, the CMDB is going to enable effective
risk and impact analysis so that IT staff can understand the impact of
planned changes before they are implemented.
What approach does Gartner recommend for building a
CMDB?
To start with, in order to build the database, one needs to have several
processes in line around it. The projects need to be bounded; they need to
have a beginning and an end. The enterprise needs to have goals in place.
IT needs to understand the actual area of pain that it is trying to address.
Is it some kind of audit and compliance exercise? Is the goal to align
processes with automation or broaden the enterprise's asset management
view? Once the goals are established, IT must set up a team to run the
project, and fund it.
Whatever the driver, one also needs to be aware of which infrastructure

3. components need to be included up front and which ones will be
subsequently added as the CMDB gets used more broadly. We are finding
that some IT shops are driving this through server-based application
initiatives, with the goal of understanding what is actually in their data
center server environment. In any case, one must be sure to think
through the integration points that the CMDB is going to need – we call
that the federated view. So any one of these drivers alone is not going to
establish one CMDB. There are many different components that make up
any one of those drivers, in which case they have to be federated or
integrated into this single view.
Hence, each element-specific CMDB (discovery from server or network or
desktop configuration tools) will be the feeder into this centralized view.
The result is a CMDB that can pull it all together and present a visual
representation that enables both IT and business users to make more
meaningful decisions.
Organizations can probably expect to maintain as many as six different
sources for the CMDB (from some of the silos I have mentioned, among
others). In many enterprises, there are different inventory tools already in
place. We recommend trying to automate as much as possible, and what
we mean by that is to try to leverage these discovery tools. If possible, try
to integrate them into this single view, because with more automated
efforts, the data will be more accurate and real-time, or near real-time.
The foundation of a CMDB begins with an accurate inventory based on
accurate discovery techniques. Technologies that are providing discovery
do this in a variety of ways and depict graphical representations of
elements in different ways, with varying depths depending on the
discovery technique. Consequently, it becomes critical to assimilate
disparate tools and technologies around discovery.
What are some of the primary challenges that you see
companies facing in developing CMDBs?
One of the biggest challenges that we have seen across all IT areas is
process maturity, but it becomes even more prevalent in the CMDB area.
Many enterprises are focused on process re-engineering or have already
"matured" their processes around each individual silo or IT domain
(networking, servers, storage, etc.). But a CMDB requires cross-
coordination amongst different silos. To be able to document processes
individually, and then tie them together, is a mammoth task that requires
quite a bit of synergy across what are usually more individualized
approaches.
Each organization needs to take responsibility for ensuring consistency
and accuracy in their own data feeds. What is meant by that is, even
though all the views are going to be federated into a single view, each silo
still needs to be responsible for the day-to-day changes and the day-to-
day views that are required for managing their own domains. For example,
server personnel need to discover what is on the servers for day-to-day
tasks that do not necessarily percolate up to the CMDB.
Mapping IT components to business processes has historically been very
challenging, not just from a technical perspective, but from a cultural
perspective as well. So as new tools emerge that can help enable this
effort, it begins to push IT into a more real-time, or near real-time,
persona. The tools will provide a presentation to IT and to the business in
such a way that the views are representing real-time activity associated
with the delivery of IT services.
One of the most important things that we are finding is because the

4. drivers for CMDBs are coming from different environments, and often the
drivers are coming together, one may wind up having an asset
management person working with an architecture person. Or, in the case
of audit and compliance, security people may be working with people in
the data center. What really needs to happen here is the team must
coalesce around the initiative itself. The enterprise needs to bring together
a set of people who are responsible for the overall project and who can
also serve as active liaisons into the individual domains.
It becomes critical to sell this particular project both upwards to the
executive team and – I would characterize this as especially critical – to
sell it downwards back into the domain silos that are affected on a day-to-
day basis by the kinds of occurrences that might be analyzed in the CMDB.
What are some of the technology requirements that
companies should consider when planning their CMDB
project?
There are many, many requirements that will go into this initiative,
depending on which pain point a company is trying to address or the
driver behind the initiative. The main goal will have a significant impact on
what one needs to consider when looking at the tools.
If a company is trying to make this a very broad brushstroke across its IT
infrastructure, inclusive of myriad different elements, then discovery of
those elements will be critical. While the key requirement today is
discovery of applications and servers, elements such as switches, storage,
and other infrastructure devices will ultimately require representation in
the CMDB. If the infrastructure is large and the initiative focuses on
servers, tool requirements might include scalability. If there are a large
number of different application types on the servers, requirements might
include depth of discovery within a system. If there are a variety of
platforms, then the requirements should include breadth of platforms
discovered. If the problem is real-time audit, then the requirements
should include having dependency maps represent real-time, or near real-
time, activity versus what we call scan-time (in which the data is only as
accurate as the last scan or event trigger).
There are quite a few technical requirements that can be considered for a
particular CMDB. Again, however, the problem being addressed will
determine the most important requirements. Certainly there will be some
trade-offs depending on the problem being solved.
For example, if one is really focused on the server infrastructure and data
center, then the breadth of applications that are auto-discovered with
these tools is critical. Today the focus is primarily on packaged
applications, but an intuitive and simple mechanism for discovery and
identification of homegrown applications is highly desirable.
Some of the other things one needs to consider are the integration points
to other systems management tools for discovery. Additionally, impact
analysis becomes a critical function if the goal is to improve change
control. Does the tool have its own impact analysis or does it integrate
with other change and impact tools? Does the tool visually map all the
different components in a very intuitive way? The visualization becomes
quite critical in this particular area of the project because it must present
the infrastructure in such a way that the dependencies and the hierarchy
can be understood and become the point of definition for an IT service.

5. What are some of the business benefits companies will
realize as a result of a successful CMDB implementation?
There are plenty of different benefits that infrastructures will be able to
gain from a CMDB. One that would be most desirable for the majority of
enterprises today is the ability to do risk assessment and to be able to
have a view into what the IT infrastructure looks like, both before and
after a change. This allows one to minimize inadvertent changes that
would take down a system, or make something unavailable, or cause the
system to become vulnerable in the case of a security breach.
If an outage is caused by a change, having a CMDB that has change
impact analysis would allow IT to anticipate problems based on known
dependencies and thus better plan for changes. Therefore outage incident
rates will go down. Problem management will be also be improved
because the CMDB will also be able to assist with root cause analysis.
Change management will be improved because now one will have a means
of tying together the workflows into the actual configuration changes that
might occur on a system or set of systems.
Automation is required to handle every bit of today's infrastructure
complexity. Therefore, as one gets a better view of how automation is
going to affect each component in the infrastructure, there will be benefit
there as well.
Frankly, I think the biggest benefit is the one that allows IT to become
more business focused. It is going to allow them to understand how a
service is defined and how each individual piece of the service can impact
another part in order to see the holistic views that the business user really
needs to understand. Once IT begins to move in that direction, that is
where the value of a CMDB will really come through.
Ronni Colville Bio:
Ronni Colville is a member of the IT Operations Management group in Gartner
Research. Ms. Colville's area of research is software configuration, which
includes traditional desktop management as well as solutions and technologies
for laptops, personal devices and servers. Her latest area of research includes
the Configuration Management Database (CMDB).
For 10 years prior to joining Gartner, Ms. Colville was a senior networking
specialist at IBM, where she assisted Fortune 100 clients and midsize
enterprises with development and deployment of their networking architecture.
Ms. Colville earned a bachelor of science degree in mathematics and computer
science from Pace University.
Source: Gartner Exclusive Interview, Ronni Colville on Configuration
Management, 14 March 2005.
The Relicore Analyst Series Webletter is published by Relicore. Editorial supplied by
Relicore is independent of Gartner analysis. All Gartner research is © 2005 by Gartner,
Inc. and/or its Affiliates. All rights reserved. All Gartner materials are used with Gartner's
permission and in no way does the use or publication of Gartner research indicate
Gartner's endorsement of Relicore's products and/or strategies. Reproduction of this
publication in any form without prior written permission is forbidden. The information
contained herein has been obtained from sources believed to be reliable. Gartner
disclaims all warranties as to the accuracy, completeness or adequacy of such
information. Gartner shall have no liability for errors, omissions or inadequacies in the
information contained herein or for interpretations thereof. The reader assumes sole
responsibility for the selection of these materials to achieve its intended results. The
opinions expressed herein are subject to change without notice.