The CMDB Landscape: Market Directions,

Vendor Solutions and IT Deployments

A Research Report Prepared by EMA
June 2005
 Executive Summary
EMA’s work in assessing the probable advantages and possible pitfalls of the industry movement towards a Configuration
Management Database (CMDB) began with analysis of the requirements for next-generation management architecture.
As described in the first report in this series, “The ITIL Configuration Management Database: Panacea or Pandora’s
Box?,” this architecturally-centered work took on a new life in 2004, when industry awareness of IT Infrastructure Library
(ITIL) best practices, and in particular ITIL’s notion of a CMDB, began to soar. During the course of researching and
developing the first two reports in this series – the first in December and this one during the first five months of 2005, the
industry interest in an ITIL-driven CMDB visibly expanded. It became, in fact, an even more intense discussion than EMA
anticipated, as many vendors and many IT implementers began asking some of the same questions that EMA had posed
surrounding ITIL’s process-centric notion of a CMDB and its real-world, software-based, architectural equivalents.
In its first report, EMA discussed ITIL’s view of the CMDB. In short, the CMDB becomes for ITIL a trusted resource for
assuring consistency and efficiency across many IT disciplines in support of service management (IT Service Management
or ITSM). According to ITIL, “Many organizations are already using some elements of Configuration Management, often
using spreadsheets, local databases, or paper-based systems. In today’s large and complex IT infrastructures, Configuration
Management requires the use of support tools, which includes a Configuration Management Database (CMDB). Physical and
electronic libraries are needed along with the CMDB to hold definitive copies of software documentation. The CMDB is
likely to be based upon database technology that provides flexible and powerful interrogation facilities.” ITIL also posits
that the CMDB should capture both the interrelationships and relevant histories across all system components, including
incidents, problems, known errors, changes, and releases as they relate to services and business requirements.
EMA, along with many vendors, and to a lesser extent some IT implementers, has focused in particular on the
opportunities and pitfalls of taking ITIL processes and practices surrounding its CMDB – and from these trying to
develop an architecture and a real database system to support them. While some IT implementers are developing their
own CMDB software, most are very early in the adoption curve and are, for the most part, seeking to invest in third-party
software and products that can be customized to serve them. As a result, their concerns are typically less architectural,
per se, and more investment and process oriented. This report surveys product implementations (planned and shipping)
from more than 20 vendors, and assesses early-phase IT perspectives and implementation concerns.

Methodology
EMA surveyed more than 20 vendors in depth, and has had CMDB-related discussions with more than 50 vendors across
the enterprise management marketplace. As discussed below, these vendors ranged from centrist, “framework” providers
to configuration and change vendors, to asset and help desk vendors, to storage and security vendors. For the vendors
profiled in the report, a detailed questionnaire was used (See Appendix A). In some cases, vendors received as many
as five interviews in order to complete a balanced view of what for many was a still evolving story. For other vendors,
discussions were more self-contained.
EMA also researched IT perspectives and implementation directions regarding the CMDB. More than 20 IT organizations
were surveyed in some manner or other. These IT surveys took the following forms:
• Engagements (actual and pending) with IT organizations seeking guidance on CMDB adoption strategies
• In-depth phone dialogs with IT organizations
• E-mail correspondence with IT organizations
EMA has tapped six of its analysts to cover the full CMDB marketplace, and in the course of this report, many conclusions
are the results of internal discussions and assessments within EMA itself.

Page 1 The CMDB Landscape: Market Directions, Vendor Solutions and IT Deployments
©2005 Enterprise Management Associates, Inc. All Rights Reserved.
Summary of Conclusions
The conclusions within the following report follow its table of contents and organizational structure. A very condensed
summary of key findings might be as follows:
• Vendor activity regarding CMDB-related development exceeded EMA’s expectations. In EMA’s view, the
pervasiveness of vendor attention to the CMDB phenomenon is reflective of a broader trend within enterprise
management – the trend towards a more structural approach to market evolution. This structural approach places
more attention on architectural elements, which have in the past been typically “under the hood.” Along with the
CMDB, and related to it, there is similarly an increasing focus on analytics, portals and visualization, topological
discovery, workflow, identity management, and software-centric policy enforcement.
• Vendor CMDB development was, not surprisingly, viewed according to the native role that each vendor had
within the enterprise management marketplace. Configuration vendors, for instance, emphasized configuration
and change. Portal-oriented vendors emphasized visualization. Asset and Help Desk vendors took an asset focus,
etc. Even within the framework vendors, there is usually a clear beginning point from which a broader CMDB
direction evolves, typically within the context of the service desk and/or asset management.
• IT organizations are less sure than their vendor counterparts about the urgency and value of the CMDB, and as a
group seem to be in more disarray on the subject. But even here EMA saw a strong interest in creating standards
and consistency for critical management tasks. These tasks spanned operationally focused service assurance,
change and configuration management, and asset management. Most IT organizations were in the process of
assessing CMDB directions rather than doing actual deployments, and among those with deployments, few had
gotten beyond a first phase, single-discipline focus for the CMDB.
• The ITIL roots of the CMDB were strongest overall not among the vendor community, but among those few IT
organizations that had already undergone significant process-oriented initiatives. In these cases, planned or actual
CMDB deployments were a part of a broader ITIL ITSM initiative. Vendors, probably correctly, needed to focus
more on the architectural demands of developing an ITIL-supportive CMDB in conjunction with their own product
development directions. As a result, a number were only marginally conversant with ITIL processes per se, but
understood the need for a consistent architectural, trusted source for data sharing across management applications.

The CMDB Landscape: Market Directions, Vendor Solutions and IT Deployments Page 2
©2005 Enterprise Management Associates, Inc. All Rights Reserved.
 Hewlett Packard’s OpenView
Context and Market Focus
Hewlett Packard’s OpenView management solution first introduced inventory and configuration management in 1994 and
has been supporting CMDB capabilities in its HP OpenView Service Desk offering for several years. As an interesting aside,
HP has documented a current “CMDB” environment in one of its customer environments with 121,593 Configuration
Items (CIs), across 4,995 locations, supportive of 28 maintenance contracts and 43,051 organizations representing
174,051 people requiring 948 services. HP claims that there are already thousands of CMDB implementations already in
place via OpenView Service Desk.
However, HP is formally introducing a new, federated CMDB offering with HP OpenView Service Desk in mid 2005,
which is based on a common core data model and will leverage SOA as an integration platform. This CMDB offering
should be viewed as the first phase in a longer-term rollout that will include a deeper integration with operations
processes and more dynamic updates for real-time currency of CIs and their topological as well as performance-related
interdependencies. This rollout will also direct HP from a more distributed/monolithic architecture toward a truly
federated CMDB system that will extend HP’s investments in CIM, and broaden its support for SOA-based information
exchange across multiple sources, including third-party brands.
The importance of the CMDB for HP is profound – not so much as a marketing initiative in itself, but because the
notion of the CMDB, with its ITIL roots, is pivotal to HP’s broader ITSM and service management strategy. Given the
CMDB’s pervasive relevance to the entire OpenView portfolio, HP is taking its investment in architecture and design
very seriously, in order to maximize the value of its overarching direction to support “model-based automation” across
a whole host of IT management disciplines.
HP’s definition of the CMDB not surprisingly follows ITIL’s: “The CMDB should hold the relationships between all
System components, including Incidents, Problems, Known Errors, Changes, and Releases. The CMDB also contains
information about Incidents, Known Errors, and Problems, and corporate data about Employees, Suppliers, Locations,
and Business units.”

CMDB: Concept, Product and Design

When HP adapted ITIL best practices in 1994, work began on HP’s first CMDB, which then launched in 1997. It
contained operations information for systems, applications, LANs/WANs, storage transactions, and the Internet. In the
late 90s, OpenView’s data store, then separate from the CMDB, began to include service-related information, and the
relationships between business services and the computing elements they depend on. This information included services,
service level agreements, projects, change orders, service calls, and customer and operational affiliations.
In 2000, the two data stores were harmonized through XML, leading to the formation of the CMDB that is available
today. The OpenView Service Desk is CIM-based, with extensions to support organizational and other requirements. As
it evolves, it will become a federated system exploiting HP’s overarching commitment to model-based automation.
Central to HP’s directions in the evolving of its CMDB product strategy is the notion of “State.” HP posits six key states
to be supported through either a single or federated system for the CMDB:
• Actual state is the real state of CIs and their topological interrelationships at any given moment of time, as for
instance would be apparent in real-time monitoring applications.
• Discovered state is the real state as it is discovered by autodiscovery-related solutions, such as network layer 2 and
3 discoveries of systems configuration, inventory, and discovery.
• Desired state is the approved standard deployment for individual CIs, including configurations and
interdependencies. Central to the notion of desired state is the concept of enforcement to support a standardized
and stable environment. Desired state technology drives a continuous automated process to make the environment
reflect the CI’s describing it in the CMDB.

Page 3 The CMDB Landscape: Market Directions, Vendor Solutions and IT Deployments
©2005 Enterprise Management Associates, Inc. All Rights Reserved.
 • Formal state is the environment as IT expects it to be, a trusted state from which IT can plan longer term evolution
to a next trusted state, which is the envisioned state described below. It requires an aggregate, formal stature across
all CIs and their interdependencies versus the more component-centric approach of “Desired State.” HP’s view of
the core CMDB for Service Desk is directed at ensuring a formal state standard.
• Envisioned state is a desired evolution of the formal state with key associated functions such as planning, design,
and simulation.
• Modeled State describes the model of an IT service, its components and their relationships. HP provides
predefined models for standard applications such as SAP – customers can define their own models to define an IT
service. HP maps products to the various states in the following way:
° Actual state – OV Operations, NNM, Radia
° Discovered State – Radia, Automation Manager, OV Operations, Service Navigator, NNM
° Desired State – Radia
° Formal State – OV Service Desk
° Envisioned State – OV Service Desk
° Modeled State – OV Service Desk SLM
The CI’s included in HP’s CMDB include network, systems, application, business policy, and identities (such as people
groups and roles as well as machine identities). HP is also making contractual information accessible to its CMDB system
– for example SLAs with provider and receiver, valid dates, prices, and performance metrics. Cost-accounting data is
also captured. This includes information such as purchase prices of equipment and software associated with contracts as
well additional cost related to repairs and upgrades. Some other capabilities supported in HP’s currently shipping CMDB
offering are discovery and reconciliation, lifecycle history and tracking, automatic downtime planning and license usage
metering.
CI relationships include parent-child – or one CI contained within the other. Users can define dependencies in terms
of such metrics as consumption and connectivity. Dependency relationships can be defined in “Service Definitions”
– which indicate levels and types of dependencies. HP also retains ITIL’s strong focus on CI relationships, supporting CI
mapping to users, owners, and administrators of the CIs themselves for the assignment of problems, or for notification,
or for impact analysis.
While HP’s Service Desk CMDB does not directly support ITIL’s notion of the Definitive Software Library (DSL),
OpenView Radia does. HP has referred to Radia as a “CMDB Lite” – focused on software configuration and change in
a systems context.
HP’s CMDB strategy, as it moves from the initial Service-Desk-centric offering towards a more federated system supportive
of operations, can be understood as broadening and enriching CMDB scope in terms of the states above. For instance,
operational requirements dictate powerful, dynamic insights into “Actual” and “Discovered” states. Some of this will
be achieved in HP’s Service Operations Manager, which will act as a bridge between Service Desk and Operations, and
provide enhanced autodiscovery automation to dynamically update the CMDB and help minimize administration.
Discovery and CMDB Population
HP supports third-party as well as HP sources of discovery. While Service Desk’s CMDB will automate import systems and
desktop inventory and discovery from Radia, and network autodiscovery from Network Node Manager, it will eventually
support agent-less discovery, file registry analysis, and Smart Plug-In (SPI) autodiscovery. Automation and reconciliation
of HP and third-party solutions into the CMDB system will be done through object reconciliation leveraging XML, and
eventually, Service-Oriented Architecture (SOA).

The CMDB Landscape: Market Directions, Vendor Solutions and IT Deployments Page 4
©2005 Enterprise Management Associates, Inc. All Rights Reserved.
 Reconciliation rules allow IT to put unplanned changes under formal change control. The reconciled information is
accompanied by a change history that will log all the changes to the CIs and their relationships for the purposes of change
monitoring, compliance reporting, and troubleshooting.
Multi-vendor Directions
HP is designing its CMDB to be a very generic data model that can be customized on the attribute level in order
to support extensible integration across multi-brand management investments. As mentioned above, while initial data
import is done via XML, SOA will over time become a dominant means of communicating and exchanging information
bi-directionally throughout a federated CMDB system.
Standards Directions
HP is currently supporting CIM and XML in its CMDB, and is examining other standards as they may become relevant.
Chief among these are DCML, SLP, UML, and BPL, as well as WSDM and other Web Services-related standards.
Product-related Availability
HP OpenView Service Desk provides the foundation for the currently shipping HP OpenView CMDB, and HP recently
launched the ITSM Express Pack for Consolidated Service Desk as a way of enabling rapid CMDB implementations
based on ITIL best practices. The current offering provides a context for harmonizing data across multiple OpenView
solutions, and their relationships to services, incidents, problems, changes, contracts, etc. Later in 2005, HP will
introduce a new, federated CMDB offering, which is based on a common core model and will leverage SOA as an
integration platform.

EMA Perspective
EMA believes that HP is taking an evolutionary approach to its CMDB rollout, focusing primarily on Service Desk
support in its initial offering, with a broadening requirement over time to support more real-time, operations-centric
tasks, as well as multiple data sources that will need to be integrated and reconciled. HP is firm in its strategy to support
a model-based approach to CMDB as a part of its overall direction in terms of model-based automation, which it favors
as “declarative” – or contextually rich meta data supportive of analysis and scrutiny (you can see the modeling and the
conceptions behind them) versus “imperative” – as is the case with scripts and workflow, where typically more linear
chains of action are defined without the same level of context. The challenge that HP will face is that its deliberately
strict approach to model-based automation may allow more niche, or less architecturally ambitious new entrants to claim
CMDB high ground before HP has had the time to roll out its fully federated view of the CMDB. However, since there
is little likelihood of a fully federated, all-points-addressable CMDB becoming both effective and viable before at least
several more years, HP’s caution and discipline may well prove wise in hindsight.

Page 5 The CMDB Landscape: Market Directions, Vendor Solutions and IT Deployments
©2005 Enterprise Management Associates, Inc. All Rights Reserved.