ITIL v3 and your CMDB: using actionablefederation to create a configurationmanagement systemWhite paper

Table of contentsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2What is actionable federation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Key requirements for actionable federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Requirement #1: service data metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Requirement #2: data source registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Requirement #3: CI identity reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Requirement #4: dynamic query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Requirement #5: transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Actionable federation advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Actionable versus view-only federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Federation economies of scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Actionable federation as a foundation for automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Practical considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Data andInformationSources andTools

InformationIntegrationLayer

Data Integration

IntroductionIT initiatives such as IT-business alignment, service man -agement, data center transformation and applicationquality are driving IT organizations to pursue greaterinformation transparency across management domains,using the perspective of services provided to the busi -ness as a common context. The IT Infrastructure Library(ITIL) Version 3 provides a practical response to thisneed with the concept of a configuration managementsystem (CMS).

A CMS creates a common view of business services byproviding access to service information across special -ized IT management silos, thus facilitating an IT organi -za tion’s transformation from a focus on technology to afocus on business outcomes driven by business services.Rather than creating and maintaining a single mono -lithic configuration management database (CMDB)that physically stores all service information, a feder -ated CMS features an integrated CMDB that cannotonly store configuration items (CIs) and model theirservice relationships, but also dynamically access otherdata sources to provide all IT management domainswith a more complete, common understanding of

business services. Thus the integrated CMDB providesa single point of access to multiple federated datasources without becoming the single repository. Byusing a federated approach, IT organizations canquickly access current information across teams andtools in a common service context, resulting in faster,better, business-aware decisions that improve businessservice quality and reduce cost.

In a federated CMS, the integrated CMDB uses a setof federation services that facilitate queries betweenclients (users and applications that request serviceinformation from the CMS) and external, autonomousdata sources that maintain additional informationabout the configuration and management of services.Federation services are tightly coupled with the servicedata model in the integrated CMDB so they candynamically associate data in external data sources(extended service data) to the CIs physically stored in the integrated CMDB (core service data). Thus, the integrated CMDB provides CMS clients with aseam less, single point of access to service informationthat may be distributed across multiple otherwise-incompatible systems.

2

Figure 1. Whereas the CMDB is characterized as a database, a configuration managementsystem includes tools forinformation integration,knowledge processing andpresentation. The integratedCMDB provides a unified pointof access to information from a variety of sources.

PresentationLayer

AssetManagement

View

ConfigurationLifecycle

View

TechnicalConfiguration

View

QualityManagement

View

ServiceDeskView

Changeand Release

View

KnowledgeProcessingLayer

ReportingPerformanceManagement

Modeling MonitoringQueryand

Analysis

CMDBs PlatformConfiguration

Tools

SoftwareConfigurationManagement

Discovery,Asset

Managementand Audit

Tools

EnterpriseApplicationsStructured

DefinitiveMediaLibrary

ProjectDocumentation

ProjectSoftware

Integrated CMDB

DataReconciliation

DataSynchronization

Extract,Transform,

LoadMining

Common ProcessData and

Information Model

MetadataManagement

SchemaMapping

What is actionablefederation?A key requirement for increasing value from a feder -ated CMS is verifying that the information it providesis actionable, i.e., usable by applications and users tomake decisions and take action that improves businessoutcomes. With an actionable federation approach,federated information is accessed and used just like theapplication’s own native data. The key to action ablefederation is a combination of transparency and context.

Behind the scenes, queries from client applicationsinvolving CMS data are directed to the integratedCMDB, which in turn queries both the physically storeddata in the integrated CMDB and federated data inexternal sources. The physical location of the federateddata is transparent to the client application. Queryresults are then delivered to the client application incontext of its own data model and user interface sothey can be programmatically consumed, displayed,sorted and acted upon by the client application’sbusiness logic.

Thus, actionable federation allows IT specialists fromone domain (e.g., network management) to use theirfamiliar tools to access information from data sources inother IT domains (e.g., application management) with -out learning how to use other interfaces. As far as theycan tell, the application they work with every day nowsimply has a richer set of information available to it.

Key requirements foractionable federation Actionable federation requires CMS federation servicesthat work together to provide both common service con-text and coordination of information access betweenclients and federated data sources. To better understandrequirements for how CMS federation services worktogether, let’s look at a travel website analogy.

Arranging a trip has been made far simpler and morepowerful through travel websites such as Expedia,Travelocity and Orbitz. Any one of these sites providesa single logical information source that federatesacross many disparate sources, from airline, hotel and rental car systems to street maps, attractions andactivities. A single query to the travel website returns a coordinated set of answers spanning air, car, hoteland even sightseeing attractions. These results can besorted, reworked based on new parameters such asdifferent travel dates, and ultimately transacted upon.

Just as the travel website provides a single point ofquery about virtually any aspect of your trip, CMSfederation does the same for business services, frominfrastructure components to applications, detailedconfigurations to specific management data, regard -less of where and how that information is indepen -dently managed and stored. Now let’s focus on someof the underlying capabilities that make it work.

3

Figure 2. With actionablefederation, rich service data froma variety of sources is deliveredwithin the user interface anddata model context of clientapplications. Client applicationsand users do not need to knowwhere the external informationresides.

Businessservice

automation

Businessservice

management

LDAP

Outsourcer’sCMDB

Extended service data

SVC owner

End-user experience

Configuration

Registry setting

Scheduled change

Federation

IntegratedCMDB

Project andportfolio

Applicationquality

Servicedesk Asset

Your environment

Discovery

Client (consumer)

Core service data

Owners

SLAs

J2EE

UNIXClie

nts

WANs

SANs

User id

entiti

es

Chang

es

Incide

nts

Even

tsLic

ense

usage

Projec

ts

Costs

SLA st

atus

Compli

ance

statu

s

Secu

rity st

atus

Configuration data Management data Processed data

®

Client integration

Data sources

• Common service context. The travel site can makesense of different information from different vendorsby relating it to the concept of a “trip.” It understandsthat a trip can have multiple components includingflights, rental cars, hotels and attractions. It under -stands that flights have certain attributes such asduration (measured in hours and minutes) and fareclasses. And it knows important ways in which infor -mation about one trip component relates with another,so it can coordinate your car pickup time with yourflight arrival time, or find a hotel close to a landmark.

• Data source registry. The travel site doesn’t store dataabout all the flights, car rentals and hotels available,but it knows where to look. It has a registry of infor -mation needed to extract data from data sources forairlines, car rental companies, hotels and more.

• Common reference points. To find a flight and ahotel for your desired destination, the travel site usescommon reference points such as cities and streetaddresses to look up flights, hotels, cars and attrac -tions in external databases managed by airlines,hotels and cars. What the user enters may not beexactly what these external databases use, so recon -ciliation between reference points is needed. Forexample, if the user’s query specifies “San Francisco,”the travel site will need to reconcile to airline systems’records of flights with airport code = “SFO.” Or if a zip code is provided, it may reconcile to hotelsystems’ properties with addresses containing thenearest three zip codes.

• Query. Using its data model for a “trip” service, thetravel site helps a user compose a query with validstructure and parameters (e.g., travel dates based ona web calendar); parses and translates that queryinto different queries understood by all external air -line, car and hotel systems; submits the queries toeach data source; and then gathers the results andreturns them as a single answer to the user.

• Translation. If the travel-site user specifies a hotelroom with “high-speed Internet access,” the travel site may need to translate this term between differenthotel systems’ representation of this amenity. Perhapsit may need to query Hilton for “Internet = yes” andMarriott for “in-room Internet” = yes. No matter howhotel systems format their data, translation allows theuser to use a single term, and the travel site to displayall the results in a common apples-to-apples format,so it is easy for the user to understand and act on.

The analogy above highlights the fundamentalimportance of five actionable federation requirements.

Requirement #1: service datametamodelJust as a travel site maintains a model for informationabout a “trip” as its common service context across the many systems it communicates with, an integratedCMDB needs a common model of information about a business service that spans its physically stored dataand federated data sources. With actionable federa -tion, the federation service that creates and maintainsmodels of both core (physically stored) and extended(federated) service data is referred to as a “servicedata metamodel.”

A service data metamodel doesn’t hold any data itself.Rather, it describes the structure and format of bothcore service data stored in the integrated CMDB plusextended service data available in federated datasources—and how they relate to each other. In thecase of core service data, the service data metamodeldetermines the actual data model instance in the inte -grated CMDB; that is, it sets up how the integratedCMDB will accept, store, manage and understand CI data. For extended service data, it determines how data that is dynamically accessed from externalrepositories will relate to CI data stored in the integrated

4

The close interplay between the servicedata metamodel and the integrated CMDBdata model is one reason why federationservices and an authoritative integratedCMDB should be tightly coupled: it createsa unified model for understanding core andextended service information.

CMDB. For example, the service data metamodel maydetermine that performance and availability data mayrelate to infrastructure CIs, but not people CIs. Thisclose interplay between the service data metamodeland integrated CMDB data model is one reason whyfederation services and the integrated CMDB shouldbe tightly coupled: It creates a single model for under -standing core and extended service information.

Of course, a service data metamodel cannot start outas a comprehensive universal data model for all of IT management. But it is a central place where newmanagement data types can be incorporated as theyneed to be shared. As process maturity and datasharing among IT management domains expands, andmore data is selected for cross-domain access, theservice data metamodel expands with it, creating avaluable, strategic asset in an IT organization’s abilityto work across teams to improve service quality andreduce cost and risk.

By using interrelated CIs stored in the integrated CMDBas the reference points for federation, users and man -agement applications can quickly find data related notjust to a single CI, but also related CIs, from a businessservice to an application and down to a network port.

For example, if a change management application userwants to understand the impact of a change to an SAPFinancials application server, she can issue a singlequery about “SAP Financial application server andrelated CIs” and have the integrated CMDB do thework of identifying which related CIs to include inqueries to federated data sources.

Getting this core service information right in the inte -grated CMDB is fundamental to an effective CMS, and why dependency mapping is worth specialconsideration.

Dependency mappingOne reason behind many of the failures of early CMDBefforts was the lack of mature technology to create andmaintain service dependency maps and a reliance onhighly manual methods of CMDB population. Out-of-date, inaccurate CI information lacking the context ofrelationships to applications and services often led to a lack of confidence in the CMDB project and eventualfailure to adopt. To properly plan for and execute soft -ware changes, for example, the CMDB should be ableto render details such as database tablespace settingsand J2EE sockets of custom applications, and under -stand the impact relationships between components.

5

Figure 3. The service datametamodel maintains datarelationships between CI dataphysically stored in the integratedCMDB and extended data infederated data sources.

Project andportfolio

Applicationquality

Servicedesk

Asset Businessservice

automation

Businessservice

management

LDAP Outsourcer’sCMDB

RFC

Known errors

Problem

Incident

State

Performance

Availability

Route

Socket

Container

SW license

Contract

Cluster component

J2EE managed object

Network resources

Database

Software element

Cluster component

Customer

LOB

Process

Application

Owner

SAP

Oracle

Windows

UNIX

Host

Load balancer

Router

RAS

Business service

Service management Operations System Link Business Asset

®

Application dependency mapping software is a power -ful class of auto-discovery tools that probe the IT envi -ron ment not only for software and devices, but also the intricate details of their relationships to enable abusiness service. The most important considerations for application dependency mapping is the level ofaccuracy and detail provided to the integrated CMDB,and the ability of the tool to dynamically map what itfinds to applications and services.

To maintain an accurate and useful model of the ITenvironment, several capabilities are important. First,the tool should provide discovery users with fine-grainedcontrol over the discovery logic to discover custom andlegacy applications as well as more accurately discoverpackaged applications. Second, automated rules formaintain ing mappings are important to verifying thatthe integrated CMDB’s service models of discoveredinfra structure and applications are accurate andefficiently maintained.

Finally, more powerful auto-discovery solutions alsoprovide tools for defining impact rules that specify whatthe impact to an application or service would be if apar ticular CI were to suffer in performance or avail -ability. This information can be used by change man -agement to automate what-if analysis for change riskassess ment, by operations to determine the businessseverity of performance and availability events, and bythe service desk to determine incident priority.

Requirement #2: data source registryJust as a travel website needs a data source registry toknow where and how to access the latest flight or hoteldata, a CMS needs to know where and how to accessdifferent types of extended service data (outside theCMDB). With actionable federation, the federationservice that creates and maintains information onwhere and how to access extended service data infederated data sources is the data source registry.

A data source registry determines which federateddata source will serve as a source of truth for whichkinds of data by mapping which classes of CIs andmanagement data in the service data metamodel areowned by which federated data sources. For example,the data source registry would know that router per -formance status is provided by a particular networkmanagement application. The data source registry alsocontains information on how to access data from theappropriate federated data source, such as the path toa federation adapter.

Thus the data source registry, working in conjunctionwith the service data metamodel, provides transparency:the client system or user does not need to know whatsystem holds what kinds of data.

Requirement #3: CI identityreconciliationJust as a travel website needs common reference pointssuch as cities and addresses to match up a user’s queryto information in flight and hotel systems, a CMS needsto match up a user’s query about CIs with extendedservice data related to that CI in federated data sources.With actionable federation, the federation service thatidentifies one or more matches between a CI in a queryand a representation of that CI in a federated datasource is called CI identity reconciliation.

Even when multiple systems (e.g., asset management,event management and server automation) have anotion of the same CI in the physical world (e.g., aserver), they often don’t identify that CI in the samemanner. In our travel website example, we saw that auser may specify “San Francisco” while an airline reser -vation system uses the airport code “SFO.” In a CMS,one system may refer to a server using a serial number,another a media access control (MAC) address, andanother a host name. CI identity reconciliation is theprocess of matching up the client system’s representa -tion of a CI with a federated data source’s differentrepresentation of that same CI.

For example, if a service desk application wants thereal-time operational status of what it knows as “bladeserver XYZ,” but the event management system thatmonitors operational status knows the same system as“blade host 123,” the query about “blade server XYZ”from the client application must be reconciled to “bladehost 123” in the federated data source in order toobtain the operational status of the correct device.

Requirement #4: dynamic queryIn our travel example, we saw how the travel site helpedthe user compose a single query with a single resultfrom multiple data sources. Behind the scenes, theinitial query was automatically parsed, translated, sub -mitted to the appropriate data sources and compiledinto a single result. Likewise, in order for federateddata to become actionable information in a CMS, theinformation should be transparent and in context of theaction or decision being considered by the client. In an actionable federation approach, both transparencyand context are achieved through dynamic query.

A key concept for actionable federation is that theintegrated CMDB provides a single point of query tomultiple federated data sources without becoming thesingle repository. Federation services are tightly coupledwith the integrated CMDB so it can associate data infederated data sources to the CIs represented in theCMDB, creating a virtual data model combining thedata in the CMDB and the federated data sources.

6

Thus, the integrated CMDB can provide a seamless,single point of access to service data distributed acrossmultiple systems, including the CMDB. By using federa -tion as a broker for information exchange behind thescenes, the user does not need to know what federateddata source holds which information. Queries aremade to the integrated CMDB which acts as a brokerto parse and direct the query (or queries) to the appro -priate federated data sources and/or its own storedcore service data.

A query may be composed dynamically (versus static,pre-defined queries) by a person directly using the querytool in an integrated CMDB interface, or it may be aquery sent from within an application that is integratedto the integrated CMDB as a client. In either case, theservice data metamodel can structure the query optionsso the user can preview which data elements andrelationships they can ask of the integrated CMDB.

A dynamic query can be a single-source query wherethe desired information is found in a single federateddata source, or it can be a multi-source or distributedquery, where different portions of the answer areowned by different federated data sources. When aquery seeks information distributed across multiple fed -erated data sources, the query is parsed and submittedautomatically to the appropriate federated data sources.The query engine then merges the answers from all thefederated data sources into a single query result.

For example, after completion of a planned SAP patchrelease to an application server, a change managerneeds to perform the verification step of the change

process. From the change record in a change manage -ment application, the change manager issues a singlequery for the operational performance of the SAPapplication server and any closely related CIs:

• The query is received by the integrated CMDB whichrefers to its stored SAP application server CI andidentifies several closely related CIs including a data -base server, load balancer and Lightweight DirectoryAccess Protocol (LDAP) server.

• The query engine looks into the data source registryto see which federated data sources are authoritativefor operational performance status for each of theseCIs and identifies systems for event management,end user performance, transaction performance andservice level agreement (SLA) status.

• The query engine directs performance queries toeach of these tools for any out-of-band status for theCIs identified by the integrated CMDB and gathersthe results.

• When all the results are gathered by the queryengine, a single merged query result is sent back to the change management application with theoperational status for all the CIs closely related to theSAP application server. Results are appended to thechange record’s performance verification field.

• If all the CIs are operating within normal parameters,the change request could be closed. If an anomaly is detected, the change manager now has detailedinformation encapsulated in the change ticket to pro -vide to the appropriate team for investigation andfaster resolution.

7

With actionable federation, the integrated CMDB provides a point of query to multiplefederated data sources withoutbecoming a single repository.

Requirement #5: transformationIn our travel example we saw how one common term,“high-speed Internet service,” needed to be translatedto various representations of Internet service in differenthotel systems. Likewise, actionable federation providesdata translation between the service data metamodel,client applications and federated data sources, allow -ing the client to create queries and see results in acommon format. The federation service that translatesdata between clients and federated data sources isreferred to as transformation.

For example, a technician in operations using a serverconfiguration tool needs to quickly see all pendingrequests for change (RFCs) for a given server prior to performing routine maintenance. Yet changes maybe stored in two different systems, one depicting RFCstatus in a single field with “received,” “under review,”“approved,” “in progress” and “complete” as possiblevalues while the other system uses two status fields, onefor “open” or “closed” and another field for greaterdetail. Transformation allows the technician to simplyquery for “pending” RFCs (as described by the servicedata metamodel) and get back a single merged set ofresults from both systems within his server configurationtool. Behind the scenes, the integrated CMDB’s federa -tion services are transforming (translating) between theservice data metamodel’s value of “pending” and thetwo federated data sources’ different representations of “open,” “approved” and “in progress.”

Transformation can be performed in a partnershipbetween the integrated CMDB (which holds the servicedata metamodel), federation adapters (where physicaldata transformation between federated data sourcesand the service data metamodel is performed) andintegrations between client applications and integratedCMDB (where physical data transformation betweenthe applications native data model and the servicedata metamodel is performed).

The service data metamodel supplies a common struc -ture that data is transformed to and from.

The net result of using the service data metamodel as acommon representation for data is normalization. Actingas an Esperanto for applications and reposi toriesacross the CMS federation, the service data meta -model provides a common data structure to trans formto and from, creating an abstraction layer between the data structures of multiple client applications andfederated data sources. With normalization to acommon data model, any client can understand anyfederated data source for any data that has beenmapped to the service data metamodel.

Actionable federationadvantagesIn a CMS context, actionable federation providesseveral advantages over typical integration strategiessuch as point-to-point, hardwired, launch in context,and data warehouse and replication strategies:

• Service context: By leveraging the service infrastruc -ture context created by discovery and the integratedCMDB, queries can automatically branch out toinclude related CIs and services. By leveraging theservice data metamodel, extended service data infederated data sources are placed in the appropriateservice context. The net result is a more intelligent,holistic view of IT information from a business serviceperspective.

• Data accuracy: Because data is accessed on demanddirectly from the appropriate source of truth (federateddata source), even highly dynamic data can be asfresh, accurate and trusted as the federated datasource itself.

• Broader, deeper information: Because a federatedCMS is virtual, even near real-time, highly granularconfiguration data and management informa tion canbe made available in a highly cost-effective mannerto any person or tool with CMS access.

• Wider access: Because integrations are made to and from the integrated CMDB in a hub-and-spokemanner, it is possible to have many more federateddata sources and clients participate in the federationthan is feasible with point-to-point connections.

• Flexibility: Using the integrated CMDB as a hubbetween client applications and federated datasources, an IT organization can swap out one fed -erated data source or client application for anotherand only modify the integration to the integratedCMDB, rather than rebuilding all the hardwiredpoint-to-point integrations that touched the replacedsystem.

Actionable versus view-onlyfederationTo understand the power of queries, it is helpful to lookat actionable federation as a contrast to “view-onlyfederation.” View-only federation uses a “launch incontext” mechanism to open another application thatmay have more information about a CI. With launch incontext, when a user or application requests federateddata about a CI, the federated data source correspond-ing to that data type is launched in a separate windowand potentially opened to a screen containing moreinformation about the CI in the request. With this

8

approach, no extended service data is reconciled,mapped or exchanged. There is nothing to consume or act on by the client application.

View-only federation can be a useful approach. Forexample, setup time can be minimal because there isno query syntax or data mapping to configure. Launchin context is also appropriate when the user needs tointeract directly with a federated data source’s appli -cation interface—such as performing diagnostics orlogging in to a targeted device.

IT organizations should be aware of the limitations ofthis approach when the goal is to act on the federatedinformation. The user of the client system is now lookingat a second and likely unfamiliar user interface anddata model for a separate system, so they must be

trained in how to use the federated view to find andunderstand additional information about the CI. If theywish to transfer information from the federated datasource to the client application, they may need to makethe appropriate data transformations themselves (intheir heads) and then manually cut and paste informa -tion. And because users will be logging into sessionsand using the federated data source as an applicationor tool (and not just accessing its data), there may beadded complications in managing user licensing foran expanded group of potential federated users.

Given the limitation of launch in context, organizationswho wish to make information sharing actionableshould consider view-only federation as a supplementto an actionable federation approach.

9

View-only federation Actionable federation

Service data metamodel No, only CI data in CMDB is modeled Yes, models CIs in CMDB and data from federated data sources

Data source registry Yes Yes

Dynamic query No, launch in context only Yes, can also include launch in context

CI identity reconciliation Yes, but limited to ability of each Yes, queries with parameters federated data source’s user interface understood by federated data to present data on requested CIs source, returns results on as many

CIs as requested

Tool transparency No, client application launches view of Yes, query results returned within the federated data source in separate window, user interface and data model of user must know federated data source client applicationinterface

Transformation No, data is view-only in separate Yes, data transformed via service window of source application data metamodel into actionable

context for client application

Federation economies of scaleThere are times when point-to-point integration makessense, such as when replicating data from one appli -cation to another, or when millisecond response timesare needed to support asynchronous transactionsbetween the applications and when a common servicecontext is not needed. However, when three or moresystems need to access the same data, federation canoffer distinct economies of scale.

Federation adapters to external data sources act as“spokes” off the integrated CMDB “hub,” so there is noneed to individually define and build each permutationof possible integration combinations. For example, toenable bi-directional data sharing between all combi -nations of six different tools, traditional point-to-pointintegration approaches would require 15 integrationpoints. This could potentially include 15 different datatransport mechanisms, 15 different CI identity reconcili -ation setups, 15 different query methods and 15 differ -ent translations among data models. In a fed eratedconfiguration, information sharing for the same 15permutations is enabled with just six integration points.

Actionable federation as afoundation for automationThus far, we have talked about actionable federationprimarily in the sense of making information actionableto a user of a client application, e.g., in the user inter -face and data model context of the decision or actionthat the user is working on at the time. But deliveringinformation “from anywhere, to anywhere” in therequired context also opens the door for more fully auto -mated action, including automatic execution of queriesand automatic action taken based on query results.

One of the largest obstacles to interoperability amongdifferent management systems is dissimilar data models.Because the service data metamodel and query mech -

anisms of actionable federation can normalize data toand from a common universal model, queries can bemachine-generated, and query results can be machine-consumable. This opens the door to embedding fed -erated queries into automated workflows and for queryresults to be automatically written into and/or processedby other systems’ business logic as part of a largerworkflow, either with or without a user’s involvement.

Recall that in a previous example a change manage -ment user was able to conduct a verification step of an application release change request by querying an application monitoring federated data source forthe performance status of the application several hoursafter the release was executed. Expanding on thisscenario:

• Upon completion of a 17-step testing battery, a soft -ware quality assurance (QA) application could auto -matically approve the change request’s QA task andleave a record in the change request on what testingsteps were completed, avoiding the problem of some -one signing off on a change without following the fullQA procedure and creating a closed loop audit trail.

• Once the change request is approved, it could triggerthe execution of the change to a service automationsuite, which could provision a virtual server, installthe release, reboot the server and record the changeas completed in the change request record.

• During the time the change request specifies that sys -tems are to be taken offline for the application release,it could tell event management tools to suppress eventsrelated to the offline systems to avoid unnecessaryfirefighting and adjust the application’s SLA calendarso the offline time won’t be counted against it.

Of course, actionable federation alone will not enableall aspects of this level of automation, but the subsys -tems used for normalized queries provides a foundationof data mapping for such automation to be constructed.

10

Figure 4. A hub-and-spoke modelbecomes increasingly moreefficient than point-to-pointintegrations as more systems areadded to the CMS federation.

Businessservice

automation

LDAP

Servicedesk

Applicationquality

BSM

Asset

Businessservice

automation

BSMLDAP

Applicationquality

Servicedesk

Asset

Practical considerationsImplementing a CMS with actionable federation canbe far reaching, but an incremental approach canbring value at each step while building a scalable,highly re-usable foundation for cross-domain collabora -tion. While there isn’t a single right answer for allorganizations on the right sequence of steps, followingare some considerations:

1. Discover and share application dependency datawith a CMDB. Even before federated data sourcesare brought online, providing various IT functionswith a shared picture of application/infrastructuredependencies will increase the chances that betterdecisions will be made with regard to the service as a whole. Be sure to choose a combination ofapplication dependency mapping and CMDB thatprovides the level of granularity, accuracy andcurrency of data needed to support your keyprocesses and functions.

2. Identify your authoritative data sources. Decidingwhich tools are or should be systems of record fordifferent types of service information may be moreof a political issue than a technical one, but theconversation can be valuable, and ultimately neces -sary. Do you have different teams and tools manag -ing some of the same data? Which have the rightdata quality and context, as well as ongoingprocesses and skills for maintaining that data?

3. Bring a federated data source online. Identify themost critical near-term pain points and/or initiativesthat can benefit from extended service data, and setup a process to use federated queries to one or twoauthoritative federated data sources for that data. If possible, prioritize where there are two or moretools needing access to the same federated data

source to benefit from re-use and economies of scale.Depending on the tools involved, the breadth of datarequired, and the complexity of the federated datasource schema, setting up federated access can takeas little as a few hours or days.

4. Integrate client applications to the integrated CMDB.Provide a greater level of transparency and action -able use of query results. Enable CMS queries fromwithin the user interface of a client that regularlyneeds critical federated data source data and filterthe options to focus the user on high-value queries.

5. Enable distributed queries. Once you determine anexisting process or function regularly needs answersto questions that require compilation of data frommultiple federated data sources.

6. Embed queries in automated workflows. Identifywhere high-value queries are being regularlyrepeated with predictable actions taken accordingto the query results and make them part of a morefully automated action processed either directly bythe client system or through an automated runbooktool.

ConclusionAs IT organizations take a closer look at building asustainable CMS, a federated approach is emergingas the most practical and scalable method. A suc -cessful federated approach provides both commonservice context and coordination of informationbetween multiple data repositories and consumers of this information. Actionable federation can then, in turn, provide the basis for IT organizations to deliver on key initiatives such as IT-business alignment,service management, data center transformation andapplication quality.

11

To learn more, visit www.hp.com/software© Copyright 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject tochange without notice. The only warranties for HP products and services are set forth in the express warrantystatements accompanying such products and services. Nothing herein should be construed as constituting anadditional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. UNIX is a registered trademark of The Open Group. Oracle is a registered U.S. trademark of Oracle Corporation,Redwood City, California.

4AA1-9283ENW, June 2008

Technology for better business outcomes