The Value of Standards-based CMDB Federation

WHITE PAPER: The Value of STandardS-baSed CMdb federaTion

The Value of Standards-based CMdb federationapril 2009

peter doherty, randal locke, ram Melkote, david Messineo, Marv WaschkeCa 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.

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

benefitsas 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 dataorganizations 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 1CMdb data Source

FederatingCMDB

Configuration Management

Incident/Problem

Management

Change Management

DiscoveryManagement

OtherSystem/Network

Management

CapacityManagement

AssetManagement

MDR 1

CustomInterfaceCode

FederatingCMDB

MDR 4

MDR 1 QueryInterface

MDR 1 QueryCode

MD

R 3

MD

R 3 Query

Interface

MD

R 3 Query

Code

MD

R 2

MD

R 2

Que

ryIn

terf

ace

MD

R 2

Que

ryC

ode

MDR 4 QueryCode


MDR 1 MDR 2 MDR 3 MDR 4

CMDBf Query

CMDBf 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=70a4918082fe4f24892b8c939f6e512e2976a56c. 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 2propriertary CMdb/

Mdr Scenario

FederatingCMDB


Incident/Problem

Management

Change Management

DiscoveryManagement

OtherSystem/Network

Management

CapacityManagement

AssetManagement

MDR 1

CustomInterfaceCode

FederatingCMDB

MDR 4


MDR 1 QueryCode

MD

R 3

MD

R 3 Query

Interface

MD

R 3 Query

Code

MD

R 2

MD

R 2

Que

ryIn

terf

ace

MD

R 2

Que

ryC

ode

MDR 4 QueryCode



CMDBf Query



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 3CMdbf Scenario

FederatingCMDB


Incident/Problem

Management

Change Management

DiscoveryManagement

OtherSystem/Network

Management

CapacityManagement

AssetManagement

MDR 1

CustomInterfaceCode

FederatingCMDB

MDR 4


MDR 1 QueryCode

MD

R 3

MD

R 3 Query

Interface

MD

R 3 Query

Code

MD

R 2

MD

R 2

Que

ryIn

terf

ace

MD

R 2

Que

ryC

ode

MDR 4 QueryCode



CMDBf Query



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


ConclusionsSaCM 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 authorsPeter 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 Lockedirector 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 Melkoteprincipal 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 MessineoGlobal 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 WaschkeSenior 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.

Documents

The Value of Standards-based CMDB Federation