The Value of Standards-based CMDB Federation

WHITE PAPER: The Value of Standards-based CMDB Federation
The Value of Standards-
based CMDB Federation
April 2009
Peter Doherty, Randal Locke, Ram Melkote,
David Messineo, Marv Waschke
CA SERVICE MANAGEMENT

Table of Contents
Executive Summary
The Complexity of Managing Multiple Sources of
Data 4
What are the Underlying Issues?
The CMDBf: A Multi-function Initiative 6
What Value Does the CMDBf Provide?
What is the Need for Federation?
Data Models and CMDBf
Conclusions 16
About the Authors 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 non-infringement. 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.

analyst white paper:The Value of Standards-based CMDB Federation 3
Executive Summary
Challenge
Without accurate business impact assessments and risk management, IT infrastructure
enhancements can quickly turn catastrophic. Service Asset and Configuration Management
(SACM) and a Configuration Management System (CMS) are known to increase the accuracy
of impact analysis and reduce risk when they are implemented to manage IT change. Given
the importance of SACM and CMS, what limits successful implementations? A simple answer:
SACM and CMS are extraordinarily difficult to implement. However, hard is not impossible and
help is on the way.
IT Infrastructure Library® (ITIL) SACM and CMS are straightforward to design but the technical
implementation is often extremely complex. SACM defines and records business services and
the underlying components that support them. In other words, it builds a service model, and
then institutes Change Management to control modification and transformation of this model
as business evolves. This process is challenging, but not extremely complex.
The difficulty is in the complexity of the existing underlying infrastructure. Typically, the
relevant data is stored in any number of different tools, often from different vendors. This cross
repository data is difficult to interpret and correlate consistently. Mapping, visualizing and
maintaining complex cross-repository relationships is very hard.
This brings us to the crux of the challenge: How do you build a service model, when some or
all of the information about the underlying components are stored in radically different data
sources? After the model is built, how is it kept current? Until an organization can address this
problem, SACM is daunting. This paper focuses on an approach to data access in support of
your SACM.
Opportunity
Challenges breed opportunities. A number of CMS vendors, understanding the complexities of
sharing data across product boundaries, set out to develop a specification to simplify sharing
this data via federation. CA, IBM, HP, BMC, Microsoft and Fujitsu formed the Configuration
Management Database Federation (CMDBf) Working Group. The CMDBf set out to develop
a vendor-neutral standard for federating CMDBs and other management data repositories
(MDRs). In 2007, the CMDBf released a draft specification. A DMTF working group is vetting
the CMDBf specification as a DMTF standard. Completion is likely by mid-2009.
Benefits
As the standard becomes more widely used, it will ease the task of federation with external
sources and implementation of a SACM and CMS. Different vendors will be able to access data
in other systems facilitating the construction of sophisticated service models for reliable impact
and risk assessments. Overall, this will reduce the cost and uncertainty of IT deployments and
foster better decisions that will increase service availability and decrease resource consumption.

4 white paper: The Value of Standards-based CMDB Federation
The Complexity of Managing Multiple Sources of Data
Organizations of substantial size or complexity never rely on a single tool to hold all the
information on all the components that contribute to their Business or IT Services. They
generally have a range of tools that discover and manage the network, servers and applications.
They have other tools that contain information about software, storage, and financial
management. Usually, these tools are a mix of off the shelf commercial products, customized
commercial applications, as well as home grown software.
Generally each system has its own store of information, but these systems often do not
integrate well with other systems. Moreover, overlaps are common between systems that know
about the same component but may identify components differently. Service management
solutions often store data on components that the server, software and financial management
systems store as well. A single component may look like four different components on four
different systems. However, each discrete system is likely to contain some unique information
about a given component that contributes to a service.
In this mélange of systems, the ultimate goals of IT—like driving innovation in new markets,
increasing the productivity of the workforce, and enhancing product and service quality—can
easily become lost in the daily grind of keeping IT systems running. ITIL has been very effective
in identifying management of services as a unifying theme for orchestrating this activity.
SACM is the system that defines and controls components of services and the infrastructure.
It provides the critical bridge from the business of services to engineering the logical and
physical components of the IT infrastructure.
When SACM is executed well, the business can see the opportunities and limitations available
from the technicians and the technicians can understand business requirements and challenges.
When SACM is executed poorly, both technicians and businessmen are stymied, and alignment
between business and IT becomes an exercise in comparing coconuts and cuckoo clocks.
Supporting SACM requires access to the correct level of accurate information for informed
decisions. Historically none of these systems could easily communicate so vendors have
provided one-off solutions to get the data but these solutions have seldom been easy or cost
effective. This is especially true when combining more than one Configuration Management
Database (CMDB) from different vendors. In the past, when an organization decided on a
service management platform they chose the integrated CMDB that went with that platform.
Now more and more vendors are offering CMDBs in support of other functions. For example,
you may have an incident and problem management tool from one vendor that comes with
a CMDB and a change and release management tool from another vendor that also has
CMDB. They will, in most likelihood, have common configuration items (CIs) with differing
attributes depending on the needs of the processes the CMDB supports. From an organizational
perspective it does not make sense to have the data inaccessible to the other system.

white paper: The Value of Standards-based CMDB Federation 5
What are the Underlying Issues?
The issue is clear: prior to the CMDBf, there was no standard for data interchange between
CMDB’s and other data repositories from different vendors. This meant relying on the ability of
the individual vendor to ‘federate’ these sources into a solution.
Let’s examine the term federate. This is a common term frequently used when discussing
CMDBs and there are a number of definitions.
The most commonly accepted definition for federation is a central master repository that has a
number of feeder repositories, i.e. one central federating CMDB and a number of federated data
sources which are often referred to as management data repositories (MDRs).
Federation often includes some form of an Extract, Transform and Load (ETL) process that
extracts data from the MDRs, transforms the data and import it into the central repository.
This is nearly always a one way flow wherein MDRs are updated and these updates exported
to the CMDB. These ETL tools can bring in CI’s, attributes and sometimes relationships.
Any technology that copies data must be used with caution because copying data raises the
possibility that the data will be updated in one place but not the other. When possible, copying
data should be avoided, but there are circumstances when copying is unavoidable. For example,
when troubleshooting, it is often desirable to compare the value of a property at a time in the
past with the “authorized value” that has the approval of a change advisory board (CAB) a copy
of the value made at the historical moment is one way to provide a value for comparison. For
comparison and other purposes, the results of ETL are crucial, although these many sources of
different truths have to be managed with care and intelligence.
This first part of federation is extracting the information from the MDRs; the next part is loading
it into the CMDB. A critical issue is whether to create a new CI, or update an existing CI if the
CI being loaded into the CMDB is really one that is already known to the CMDB. This decision
process is called reconciliation. Reconciliation looks at key attributes of the CI that is about
to be loaded to determine if it already exists in the CMDB. For network devices, reconciliation
generally uses properties like serial number, asset tag, host name, fully qualified domain name,
physical address, and CI name to determine if the CI already exists. The difficulty is that the
combined information in the MDR and the CMDB may not be enough to determine if the CI
in the MDR exists or does not exist in the CMDB. The quality of reconciliation relies on the
completeness of the data and the vendor’s reconciliation algorithm and rules.
Without an industry standard to allow a common approach to federating data, this struggle
that has kept many organizations from reaping the full benefit of SACM will continue and this
is where the value of the CMDBf begins.

The CMDBf: A Multi-function Initiative
When setting up a CMDB, one sets up a database and will need to deal with its population,
security, modification and maintenance. CMDB population usually relies on numerous external
sources i.e. MDRs via federation for that data. This is a systems integration problem. Setting up
a CMDB is a systems integration project has all the attending pain and challenges associated
with that endeavour, but the initial deployment, although challenging, can be less of an issue
than maintaining the links or federations to those external MDRs.
The systems integration world has dealt with these issues for decades. There, the systems being
integrated (federated) evolve through time and often change their integration mechanisms. This
often requires changes to the basic integration on both sides of the integrated products. This
builds cost and consumes time; the more products integrated, the more complex the challenge
and the greater the expense. Organizations face the same problem when they attempt to
integrate an MDR into the CMDB. If the MDR changes its integration mechanism a prior
integration may simply fail and with its failure, it will require that the point to point integration
be executed again at a cost in both time and money. A mechanism put in place to reduce costs
and risks of IT change becomes a costly risk in itself!
Another major issue is that almost all external data sources have a data model that is unique
and not close to the data model of the CMDB. To incorporate data from the world external to
the CMDB, a mapping and transformation of the CIs and the relationships must be performed.
Clearly, superior approaches are needed to simplify data integration.
Figure 1
CMDB Data Source Configuration
Management
Incident/
Problem
Management
Change
Management
Discovery
Management
Other
System/
Network
Management
Capacity
Management
Asset
Management
MDR 1
Custom
Interface
Code
Federating
CMDB
MDR 4
MDR 1 Query
Interface
MDR 1 Query
Code
MDR3
MDR3Query
Interface
MDR3Query
Code
MDR2
MDR2Query
Interface
MDR2Query
Code
MDR 4 Query
Code
MDR 4 Query
Interface

Enter the CMDBf. In April 2006, a number of software vendors formed a group to address this
integration issue. They called themselves the CMDBf working group. The CMDBf was created
to develop a specification for integration to reduce the complexity of this problem. Their goal
was to develop a standard that would enable MDRs to work with any CMDBf federated CMDB.
The group was comprised of CA Inc., BMC Software, Fujitsu, HP, IBM and Microsoft. On August
20, 2007, a press release announced the availability of a specification and white paper which
are available at http://cmdbf.org. A few months later on November 27, 2007 the Distributed
Management Task Force (DMTF) announced that it had accepted the CMDBf draft specification
for sharing of information between CMDBs and other management data repositories (MDRs).
http://www.dmtf.org/newsroom/pr/view?item_key=70a4918082fe4f24892b8c939f6e512e29
76a56c. The CMDB Federation Working Group was formed in the DMTF. At present, in addition
to the original companies, over twenty companies have members in the working group. The
working group is chartered to produce a DMTF standard based upon the CMDBf specification.
Although the DMTF work group is not strictly obliged to exactly follow the consortium
specification, at least one member of the consortium and the work group, CA, has released an
implementation based on the 2007 specification. This suggests that the standard produced by
the work group will not differ substantially from the 2007 consortium specification.
Although the timetable for standards process is somewhat unpredictable, a ratified DMTF
standard is expected to appear in 2009.
In this document, the terms “CMDBf specification” and “CMDBf standard” are used
interchangeably. Strictly speaking, the specification will not be a standard until it is accepted
by the DMTF board of directors. The DMFT is a widely accepted de facto standards group.
The next step beyond a de facto standard would be for the specification to become a de jure
standard sanctioned by a governmental standards body such as ANSI or ISO. The DMTF
regularly offers its standards for ratification by ISO, so this may be in the future for the CMDBf
specification. The DMTF does not make work in progress available publicly, so the only public
version of the specification is the 2007 version on the cmdbf.org site.
What Value Does the CMDBf Provide?
The CMDBf standard provides to customers a vendor neutral standard for federation within
a multi-vendor customer environment. Although the standard was composed to support ITIL
practices, including SACM and CMS, it was not intended to enforce ITIL practices or preclude
practices not included in ITIL. In fact, the value of the CMDBf may far exceed the value of
current ITIL practices because it addresses a somewhat wider set of goals. SACM and CMS
primarily address service transition, the critical phase in the service lifecycle when services are
built out and deployed into operation. A CMDBf enabled CMDB is not limited to transition. The
CMDBf services will make it possible to automate CMDB federation to the point that so-called
“operational CMDBs” will become practical. An operational CMDB has access to the real-time
state of the infrastructure and links it with defined business services.

A principal purpose of the CMDB in SACM is to aggregate data and integrates silos within an
IT infrastructure. To accomplish this, the CMDB must collect data from diverse sources. Since
there was no standard prior to CMDBf that addresses federation, the problem of gathering
the data from various sources can be daunting. Following the CMDBf standard, the problem
becomes more execution of a strategy rather than designing and creating one-off solutions.
The CMDBf standard:
• Defines web services for federating the data into the CMDB across a common interface.
• Provides a common mechanism that data providers can use to support its products’
federation with a CMDB.
• Enables a common approach for combining data from varying sources thus helping fulfil the
value promise of the CMDB.
There are two alternatives to the emerging standard. One alternative is to rely on a strategy
developed by a vendor and hope that the vendor has created a sufficiently open solution that
can accommodate your particular heterogeneous environment. A second alternative is to
create a solution from scratch. Neither approach maximizes resources or minimizes cost to the
consumer. Both alternatives garner considerable risk.
Choosing a standards approach enables the following:
• Most organizations have made a commitment to SOA (Service Oriented Architecture)
which views functionality as a collection of web-services. The main advantages of using web
services are that they are transparent to the operating system and programming language of
the base application. The CMDBf standard is built on SOA standards like: SOAP, WSDL, XML
Schema, WS-I Basic Profile etc.
• Standards free your technical staff to focus on issues that are unique to your organization
rather than wasting scarce resources on reinventing the wheel.
• The standards approach mitigates both technical and business risk. Since many vexing issues
have been resolved by the consortium, the probability of success in implementing the CMDB
greatly improves.
• Using standards will shorten the time and cost of deployment.
• The standards approach means consistency across all federations which saves time
implementing and maintaining a solution.

• Simplify the deployment in that a single rather than multiple technologies need be learned
and deployed to implement federations.
• Streamline the effective spread of best practices.
• Maximize compatibility across vendors.
• And in an ever complicated and competing world those organizations that use standards can
use that as part of their marketing story showing evidence of quality.
To understand the advantage of using CMDBf, let us explore a typical CMDB integration
scenario.
Depicts a CMDB being integrated with 4 different MDRs. Each MDR integrates with the
CMDB in both a push mode (registration API) and a pull mode (query API). To accomplish the
integration, the eight integration points have to be implemented using a combination of tools
and custom programming owing to non-standard, proprietary APIs.
Figure 2
Propriertary CMDB/
MDR Scenario
Federating
CMDB
Configuration
Management
Incident/
Problem
Management
Change
Management
Discovery
Management
Other
System/
Network
Management
Capacity
Management
Asset
Management
MDR 1
Custom
Interface
Code
Federating
CMDB
MDR 4
MDR 1 Query
Interface
MDR 1 Query
Code
MDR3
MDR3Query
Interface
MDR3Query
Code
MDR2
MDR2Query
Interface
MDR2Query
Code
MDR 4 Query
Code
MDR 4 Query
Interface
MDR 1 MDR 2 MDR 3 MDR 4
CMDBf Query
CMDBf Query Interface

Depicts the integration using CMDBf web services. The query APIs and the calls to the
CMDB registration APIs will be prebuilt into the MDRs by the MDR vendor. Similarly, the
registration APIs are prebuilt into the federating CMDB and the calls to the query APIs will
also be incorporated into federating CMDB. To accomplish the integration, the effort needed to
execute the eight integration points is reduced to a sequence of setup steps hence dramatically
reducing the total cost of ownership of the CMDB.
Another scenario where CMDBf can add significant value is in federating two different
CMDBs. CMDB to CMDB federation is not the most common federation use case, CMDB to
MDR federation is more frequent, but it is still important under many circumstances and is
expected to become more prominent as the ITIL v3 CMS movement gains momentum. Many
large customers have more than one CMDB that must be federated. This happens for different
reasons. Sometimes it stems from merger or acquisition. In other cases, different regions have
different purchase policies. Whatever the reason, we see over and over again that customers
want to avoid the fragmentary view of IT that disconnected CMDBs promote, without the risk
and cost of replacing their existing CMDB implementations.
Lastly, adoption of the standard lowers replacement cost of CMDBs and MDRs. Customers
can hence choose products that suit their needs the best instead of being locked in to a single
vendor suite. Prior investments in CMDB technologies (including discovery) can be preserved
and leveraged.
Figure 3
CMDBf Scenario
Federating
CMDB
Custom
Interface
Code
MDR 4
MDR 4 Query
Code
MDR 4 Query
Interface
MDR 1 MDR 2 MDR 3 MDR 4
CMDBf Query
CMDBf Query Interface

What is the Need for Federation?
Federation is the power of any CMS/CMDB implementation. Only with federation can an
organization have the ability to easily access information necessary for providing effective root
cause analysis, impact analysis and have the ability to manage attributes and relationships and
changes to them in an effective manner.
When building a CMS, information regarding assets that are not CIs (i.e., whose configuration
is not managed), must be taken into account as well as information regarding managed CIs.
This information is normally very similar in base content, but, is quite different when you
begin to manage each set of data. Within Asset Management, the focus is on those things
in the environment that the business deems necessary to manage associated costs such as
laptops, desktops, servers, routers, switches, mainframes, software licenses, etc. Effective asset
management requires a mechanism to manage the contractual components of assets and
where it makes sense to leverage discovered asset information to validate actual deployment
of licenses and active assets. Essentially, asset management looks at the owned asset world
and validates it against the now discovered environment. Both automatically discovered and
manually populated CIs and CI attributes are necessary and they must be linked according to
the relationships that are naturally inherent in the business scenario.
This is somewhat different from managing the CMDB itself or even multiple CMDBs in an
environment. The CMDB itself is not just concerned with all assets, but, with those Components
that are part of a business service for the organization. This will include some assets from the
asset management process above, but it will also have some non-physical components such as
services, processes, organizations, locations, buildings, etc that can be critical when managing
a CMDB. The CMDB itself is not necessarily managing the as-is or discovered state of a CI, but,
the authorized state of that CI. The configuration manager will absolutely want to compare the
authorized state of the CI to a discovered state of that CI for certain managed attributes and
relationships, but not everything. This is where the main difference occurs.
Most of the information that gets processed to the CMDB comes from MDRs of trusted
sources of attribute and/or relationship information. This linkage to an MDR is what provides
a significant value for an effective CMDB. Having the ability to populate only the attributes
and relationships that are discoverable or managed in another application or source provides
a portal view of a CI from the CMDB. This portal view into a CI provides a critical capability of
providing the right information, to the right people, at the right time, to make the right decisions.
In addition to having the ability to populate the CMDB with the appropriate attributes and
relationships that are being managed by the CMDB, the MDRs normally can provide access
back to that data source for additional information. This is useful when troubleshooting an
outage in incident management, analysing a root cause in problem management or when the
change management team needs additional information prior to approving a pending change.

Having the ability to provide the service desk with access to both the asset list and the CI list is
critical for managing the incident management process. This ensures that either a CI or asset
is associated to each incident allowing for increased reporting capabilities and provide a sound
structure for problem management’s ability to perform analysis as necessary when critical
problems arise within the environment. It is also beneficial to be able on a single CI to know that
this is also a managed asset and vice versa.
The challenges to incorporating federated data into the CMDB are two-fold. First, you must be
able to trust the information being provided and know that inaccurate data will be managed
and maintained in the MDR, not updated to the CMDB repository. Secondly, you must be able
to incorporate only the attributes and relationships that are useful for CMDB practice. If the
CMDB is populated with too much data it will clutter the capabilities to quickly ascertain actual
valuable information to make decisions effectively. Software tools that consume the CMDB data
will “pick and choose” only the CIs and attributes they need, so why capture everything?
The CMDB is aimed at managed attributes and relationships. Contractual data from lease and
maintenance agreements, etc. are ordinarily not managed in the CMDB, but when there is an
outage on a CI, they can help the service desk make the correct remediation decision. Additional
data from MDRs could come from discovery asset management sources for information on total
amount of RAM on the Server, BIOS Level, Patch Level, etc, which can be extremely valuable
when managing attributes and changes to those attributes within a CMDB. With applications
that follow the CMDBf standard, decisions on how to federate MDRs can be made to tailor the
system to the unique requirements of the organization without having to invent new integration
solutions or rely on the decision of a single vendor.
As stated above, the CMDBf is a standard for communication and coordination of data between
MDRs (Note that multiple CMDBs can be MDRs to each other). As information is in disparate
places, often residing in multiple databases, and has both semantic differences in the definition
of data as well as syntactic data, the CMDBf provides a method to normalize that data. That
helps increase the accuracy of data across all of the MDRs, and reduce the costs related to
ongoing integration and maintenance.
It provides the mechanism to describe a set of global requirements of applications as
it pertains not only to its locally defined functionality, but its contribution to the bigger
picture. Requirements therefore become as much about maintaining the optimization of
interdependence of MDRs as it is in maximizing the performance of just one specific MDR.
The specific requirements for a CMDB and CMS to handle both synchronization and
reconciliation are greatly improved. The ability to uniquely identify a CI across applications is
improved through MDR synchronization and the unified service model (discussed below).
With decentralized synchronization reconciliation can be either centralized and/or decentralized
based on the business requirements. The ability to support specific roles is improved across a
much larger spectrum.

The CMDBf provides the flexibility to not only integrate MDRs at a data level, but facilitates
the coordination of ITIL processes through a common definition and understanding of CI and
CI relationships. It also provides a much better manner in which to present data, and provides
a more consistent interface by ensuring the definition of CMDB objects, and specific attributes
and relationships are consistent by all MDRs and their supporting applications. Adoption of new
systems is always a challenge, and the CMDBf provides a mechanism to make this transition
much easier.
The CMDBf provides the ability to integrate across diverse storage mediums. Each of the
databases can maintain its primary function of providing local autonomy to its typical use base
while still supporting a holistic view. This extends to the improvement of overall data quality.
CMDBf helps to reduce the risk of using multiple vendors’ products and reduces the costs. The
risks are related to data integrity and adoption of the system. From a cost perspective, providing
an easier method for maintaining integrations between the systems, reduces costs. The CMDBf
helps to support new architectural standard like Service Oriented Architecture. It provides the
ability to create web-based services that simultaneous help manage the coordination of the
various MDRs. Essentially, federation becomes the backbone of moving data around as a router
in the backbone of applications talking to one another. As such, federation is at the core of the
common services definition. Having common services definitions enables organizations to
provide consistent definitions and measurable performance metrics to services provided.
Data Models and CMDBf
The CMDBf consciously chose not to endorse a specific data model. Some have seen this as
a gigantic oversight and a flaw in the specification. Perhaps surprisingly, the decision not to
choose a data model was quickly accepted in the consortium. It was clear that agreement on a
data model would be difficult, if not impossible, among the participants. In addition, specifying
a data model—the DMTF CIM, the TeleManagement Forum Information Framework (SID),
or something new—would not cause existing models to disappear. Implementers would still
have to deal with the models in the diverse tools that are at the heart of a federated SACM
implementation. Thus the practical benefit to specifying a model was deemed secondary to the
overwhelming need to publish a standard for federation services, which could be agreed upon
in relatively short order.
However, data models are still important. The CMDBf decision not to specify a data model in
no way obviates the need for a coherent model of the IT system. In fact, by promoting easier
integration, the CMDBf specification increases the need for a consistent model, especially
for services.
A key reason for leveraging the power of the CMDBf specification to link diverse IT
management products and applications is to build a unified view of IT services that aligns
business goals and requirements with the resources and activities of the IT department.

Ultimately, IT is valued on its contribution to business goals. IT must justify all of its resources
and activities by contributing to business goals like increasing workforce productivity and
innovative offerings to the market. But in order to contribute, IT must be able to analyze itself as
thoroughly as any other business unit. Financial and managerial accounting is one part of that
analysis, but much of what happens in IT takes place on a level that is invisible to traditional
business monitoring. Perhaps the primary benefit of federating IT MDRs is the possibility of
greater transparency into IT, which is the basis for improved alignment of business and IT.
ITIL emphasizes the importance of aligning IT services to business goals by promoting continual
improvement of the IT services delivered to the business through continuous attention to the
strategy, design, transition and operation of IT services. This message has attracted many
adherents to the ITIL banner. A basic requirement for continual service improvement is a single
view of services from inception to final decommission. Without this view, following a service
from strategic inception through the phases of its lifecycle is very difficult. On the other hand,
when the applications that manage and maintain the service through its lifecycle are federated
around a unified service model, continual service improvement becomes an attainable goal.
Once deployed, a unified service model rapidly becomes a primary tool for aligning IT with
business. This is especially apparent when seen in the light of continual improvement. The
strategy phase of the service lifecycle is the phase most clearly tied to business alignment.
During this phase, the focus is on elucidating the business cases and business requirements
that justify the service. A unified service model includes the business background of the service.
In later life cycle phases, say operations, a unified service model ensures that the business
requirements that sustain the service are accessible for aligning operational IT decisions
with business decisions. A unified service model would, for example, help prevent a routine
order for an expensive replacement part supporting a service whose business case does not
justify the expense. However, a unified service model that accomplishes this alignment is
nearly impossible to implement without the standardized federation provided by the CMDBf
specification. The effort required to design, implement, and maintain each unique interface for
necessary integration is prohibitive without standardized interfaces for federation.
A unified service model requires a common definition of the component parts of the model. A
top down approach to the management of services across a set of applications begins with a
common service definition template as might be implemented in a service catalog, for example.
An IT enterprise instantiates this template at initial implementation and throughout the use
of the solution set over time by using the definition in the creation of new services. Defining a

unified service model is essentially establishing a service template, and defining the component
parts and MDRs that contribute to the system. This definition is outside of any specific vendor.
It encourages an architecture design that is not partial to any one vendor and focused on the
needs of the business. Each vendor provides its own data model, in combination with the
standards of the CMDBf. The enterprise can confidently build a unified definition service model
and use it to ensure the proper coordination of effort between IT and the services IT delivers to
the business.
In conjunction with the CMDBf, a unified service model will also help provide requirements for
application development, process integration, and data aggregation. Requirements will take a
more holistic perspective and encourage the use of a SOA.
Critically important too is its ability to provide a form of intellectual glue between
responsibilities. The various roles that are required to manage the lifecycle of a service are
speaking a common language. The various technology and their support requirements are
viewed from a portfolio perspective instead of individually. The common service definition
allows the business to view IT as it delivers value to the bottom line of the business, not just
IT budgets.
The common services definition also provides the architect with the ability to look at the design
of services somewhat agnostically to specific services. Rules and policies for defining services
will leverage the same terminology, aiding in adoption of the final product as well as bridging
the gaps that commonly appear over the lifetime of a specific system or service.
A common services definition also helps in providing the CMDBf with a means of improving its
ability to synchronize data across MDRs but providing semantic integrity. The ability to have a
global data model, albeit virtual in nature, becomes a critical requirement and deliverable for IT.
A common services definition makes the process much easier.
Finally, a common services definition also makes the management of both tangible and
intangible configuration items easier. This improves the accuracy of data and helps to ensure
that a CMDB can be trusted across a broad coalition of systems, users, and management. The
concept of a gold standard for specific CI's becomes a lot more realistic as the common services
definition defines specifically what data is required and where it should come from. It lays out
assumptions around the level of accuracy required.

Conclusions
SACM and CMS help an enterprise implement an overall strategy that aligns business and
IT services accurately, with a minimum of resource investment, but to achieve those goals,
a range of data sources must be integrated. Without an industry standard for integrating IT
data sources, this integration is expensive, difficult to maintain, and unlikely to be effectively
implemented. The CMDBf standard provides a foundation for consistent, vendor-neutral
implementation of IT integration.
About the Authors
Peter Doherty
Principle Consultant, ITIL Certified Manager
Peter Doherty is an ITIL Master (Distinction), a contributing author to the ITILV3Service
Operations Book and a Principal Consultant for CA.
With 25 years’ Service Management experience he is CA’s foremost Service Management
evangelist in the Asia Pacific region. He is a widely published on the subjects of IT Service
Management, IT Asset Management and Cultural and Organizational Change Management,
and is a frequently-requested speaker at forums worldwide. He is also a practitioner who has
designed and implemented many Service Management Programs.
Randal Locke
Director of Technical Sales
Randal Locke has more than 20 years of experience in IT Service Management. He has been
instrumental in the development and delivery of ITIL solutions for large Clients in the Defense,
Services, Manufacturing, Financial industries and within the Federal Government. He has
performed these Service Management consulting services in North America and Europe.
Randal Locke is an ITIL Service Manager. He has also co-authored an ITIL Strategy book for
international publication by Van Haren called “Service Management Process Maps.” He is also
currently a member of the Help Desk Institute (HDI) and the IT Service Management Forum
(itSMF) and is a Certified Help Desk Director by HDI/STI Knowledge.

Ram Melkote
Principal Product Manager
Ram Melkote is the Product Manager for CA CMDB. He manages the product strategy for CA
CMDB along with the product federations that underly the Unified Service Model (USM). Ram
has over 20 years of cross functional experience in the IT industry across service management,
IT applications, SOA, Middleware, Databases, and Systems Management. His experience has
spanned Product Management, Product Development, Architecture, and Consulting. Prior to
CA he has worked for IBM, Bell, and Oracle, and has founded a startup. He has a Masters in
Engineering from Cornell, a Master in Computer Science from Columbia, and an MBA from
University of Chicago.
David Messineo
Global Practice Director
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.
Marv Waschke
Senior Advisor, Product Management
Marv Waschke is a Vice President of Development and Senior Advisor for Product Management
at CA. Now part of the platform architecture task force, Marv managed development of CA's
service desk product and chaired the DMTF Support Work Group, helped author the CMDBf
specification and now sits on the CMDB Federation Working Group. Marv was a reviewer for
the recently published book “The CMDB Imperative” by Glenn O’Donnell and Carlos Casanova
from Prentice-Hall. Marv's opinions on IT service management and standards appear regularly
in his blog: “Iterating on IT Service.”
The authors would like to give special thanks to Alan Kasper for his invaluable contribution to
this whitepaper.

031909
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.

The Value of Standards-based CMDB Federation

More Related Content

What's hot (19)

Similar to The Value of Standards-based CMDB Federation (20)

More from David Messineo (20)

The Value of Standards-based CMDB Federation