CMDBs: An IT Goldmine?

A 21ST century gold rush Is poised to sweep across the enterprise landscape. The vendors' promise: Configuration management databases will provide a single source of truth for IT infrastructures. No longer will compartmentalized functions blind us to the complexity that leads to outages of critical business services. Instead, CMDBs will provide a unified view of network assets and their configurations, map device and application dependencies, and let us manage services, not machines. All this should yield increased productivity, less downtime, automation of routine tasks and a platform for a brave new generation of network and systems management.

Problem is, gold rushes are driven by greed. Many vendors that profess to have customers' best interests at heart will enrich themselves by holding us hostage with their "integrated" CMDB platforms. Sure, software companies are in business to make money, and lock-in is a time-tested method for generating repeat sales. That doesn't mean we have to like it.

Moreover, most evangelizers gloss over the fact that any IT organization setting up camp around a CMDB will face a host of difficulties. Atop the list is the pain of federating disparate IT data repositories and reconciling information stored in incompatible schemas. Vendors, of course, have a solution: Buy more software--in this case, a management suite architected around the CMDB.In fact, vendors are taking two main architectural approaches to CMDB. Some offer standalone products, which let IT roll out a CMDB without having to buy another application, such as an asset-management system. But don't confuse standalone with independent. A standalone CMDB will federate more successfully with products from the vendor's own family than with third-party systems.

Other vendors embed the CMDB in one or more management-suite components, such as a service-desk application. Enterprises that use multiple applications in the suite will find integration vastly simplified, but will still struggle to federate third-party data stores. Several vendors have plays in both categories.

What of those hardy IT shops committed to maintaining heterogeneous toolsets? For now, they must put their faith in a dubious prestandard CMDB working group that pays lip service to the notion of interoperability without inviting all stakeholders to the table.

Continue Reading This Story...

Mission: Control

IT management vendors are architecting their product suites around CMDBs for one reason: control. They understand that a CMDB is the key to influencing the purchase of management software. "If you own the CMDB, you'll own the management infrastructure," says Arlen Beylerian, director of product management for CA's Business Service Optimization unit.What gives the CMDB this power? Configuration management--having a clear picture of assets and their relationships--is the bedrock of IT. It underpins essential tasks, such as change management and root-cause analysis, as well as things like data center automation.

By using a CMDB, IT can understand the current configuration of a server, what apps run on it, what business services it supports, and which users or groups consume those services. All this information is then available for IT processes such as helpdesk, change management, internal SLA monitoring and so on.

EFW, an electronics supplier to defense contractors, recently deployed a CMDB that it uses to associate services with hardware and software assets.

"An e-mail server is a lot more than just an Exchange server," says Harry Butler, solutions center manager at EFW, in Fort Worth, Texas. Butler points out that the Exchange server is tied into a larger communications service web, and changes to any asset will have repercussions.

"If you need to push a Microsoft patch, you can see everything you'll reach out and touch," Butler says. "If you shut down an Exchange server, then the BlackBerry Enterprise Server has nothing to talk to." By modeling changes with the CMDB, Butler can avoid mistakenly shutting down all the executives' BlackBerrys, a smart career move.The ability to provide that sort of crystal-clear picture rides not on a single database, as the term CMDB might suggest, but on an aggregation of information from discovery tools, asset-management products, helpdesk apps, Excel files and more; in our survey for this article, sources for configuration information ranged from asset- and configuration-management systems to Visio and manual diagrams (see chart, above).

A well-designed CMDB should be able to access information in many data repositories through a federation model, in which a CMDB stores limited information about assets--say, a server's name and the apps and services it's associated with (see diagram, page 54). More detailed information will reside in other data stores, such as an asset-management app or discovery tool. Depending on the task or process you want to perform, the CMDB fetches additional information about an asset by reaching out to the appropriate data store, including other CMDBs.

A CMDB also must be able to reconcile information gathered from disparate data repositories. Reconciliation has two functions. First, because a CMDB will draw from multiple data stores, more than one discovery tool will likely gather information about the same asset. Reconciliation lets IT decide which tool's information will be used by the CMDB. You might determine, for example, that a patch-management agent provides the best information on the status of an OS on a particular server, while a helpdesk tool provides the best detail on device drivers installed on the same server. If the patch-management agent also provides device-driver information, the CMDB will ignore it in favor of the helpdesk tool.

Second, reconciliation must match up the different schemas used by third-party tools to describe assets and their attributes. The patch-management agent might describe a server by name, for example, while the helpdesk agent uses MAC address. Reconciliation ensures the CMDB understands when different tools refer to the same asset.

My Way Or The HighwayOn paper, federation and reconciliation are easy to describe. In reality, they can be devilishly complex to accomplish, often involving custom integration, SDKs, published APIs from vendors or some form of Web service. CMDBs include reconciliation engines to integrate third-party data, but these still require significant up-front effort by IT to create a well-defined naming schema for assets and their attributes.

Vendors promise to remove some of this complexity if we buy into a single management suite. BMC claims tight integration among its Atrium CMDB and other products--a click of a button will call relevant information from, for instance, Remedy or the BMC Configuration Manager portfolio, and deliver it into the CMDB user interface.

Products from Altiris, CA and Opsware have similar capabilities. CA's CMDB CI (configuration item) viewer shows up as a tab in its Unicenter Service Desk application and federates with other CA products, such as Unicenter Network and Systems Management. Other vendors are working to integrate CMDBs as centerpieces of broader management suites.

On the reconciliation front, BMC follows the DMTF CIM (Common Information Model) standard in its products for easy integration. All CA management products use a standard repository, called the Management Database, which simplifies reconciliation within the CA product family. For third-party products, CA touts its Universal Federation Adapter, software that can import data over XML and translate it into CA's CMDB schema.

EMC offers prebuilt adapters to federate and reconcile information from third-party products, including those from BMC, Hewlett-Packard, IBM Tivoli and Managed Objects. Like CA, however, EMC says its professional services team should be on hand to help get the adapters up and running. HP uses a federation and reconciliation technology acquired from Peregrine, called ConnectIT, that maps fields from one data source to another."Once you buy into the CMDB, all the preintegration of applications becomes a compelling story," says Brian Emerson, senior solutions marketing manager for BMC Atrium. "It becomes easier to sell new or other applications to the same customer."

Oddly, you don't seem worried. Only 11 percent of readers polled said the ability to federate from a variety of vendor tools was most important when implementing a CMDB, compared with nearly 40 percent who were most concerned about complexity.

EFW's Butler has a CMDB from CA and some non-CA tools that he federates with it. But he has purchased other CA products because of the CMDB. "We bought some non-CA tools and then switched to CA because a lot of it is seamless," he says. "Federation of data is critical."

John Frazier, at software developer I2, agrees. Frazier uses a CMDB from Altiris. He also federates third-party products with the Altiris CMDB, but says Altiris now has more influence on future purchases. "I'd have to say yes, we'd be more likely to buy Altiris products. This spring we purchased its service desk."

Standards Or Lip Service?Organizations that prize diversity won't find a champion in an open standard anytime soon. Only a limited subset of vendors is participating in the creation of a draft specification to federate information from disparate resources. The project is being driven by the CMDB Federation Working Group, launched in April 2006. When completed, the spec will be submitted to a standards body.

The working group is focusing on three main issues: First, to provide a way for data stores to register the resources they're managing. Second, to develop a system, called an identifier service, that will understand the different ways that the same resource is identified--for instance, to know that a server may be listed by MAC address in one repository, by name or location in another. Third, the group is examining interchange formats to query information from various data stores.

To avoid reinventing the wheel, the group will look to incorporate the work of existing standards where possible, says Mark Johnson, a senior programmer at IBM and member of the working group (find excerpts of our interview with Johnson below). For instance, CIM provides a schema to define IT elements as common objects.

"I'm sure CIM is going to be an influence in what's done," Johnson says. "If you think about the data-modeling aspects, what are all the attributes associated with resources, we don't have to try and tackle much of that."

Johnson says the group is looking at other specs, such as Web Services Distributed Management (WSDM), an OASIS standard that describes an integration layer to connect management systems using Web services. SML (Service Modeling Language), itself a draft specification for modeling complex IT services and systems, is also up for possible inclusion. Considering that BMC, HP, IBM and Microsoft are members of both the CMDB and SLM working groups, assimilation is likely.All this reuse sounds good, but the problem is, the consortium is an exclusive club. Membership was expanded from the original founders--BMC, Fujitsu, HP and IBM--to include CA and Microsoft. But other players, such as EMC and Managed Objects, have been rebuffed.

"We can't support having an unlimited number [of participants]," Johnson says. "There are discussions for other vendors to participate in some capacity." We don't see this as a promising attitude for a draft specification purportedly undertaken to promote interoperability in heterogeneous environments.

It's also not clear just when a specification will emerge. The original goal was December 2006, but the release of a draft has been pushed out to an unspecified date this year.

For the time being, the federation working group lets major vendors pay lip service to the notion of interoperability standards. It also gives them a significant time period--at least two or three years before standards-based products hit the market--in which to corral customers with the promise of simple, in-suite integration.

Johnson says a lack of standards hasn't stopped enterprises that want CMDBs from deployment. One reason is, they tend to start small, with a subset of IT assets and CMDBs populated with rudimentary data. "They will grow it over time as products and processes mature," he says.Overall, the CMDB market is in its infancy, but healthy growth is projected. Forrester Research estimates that the number of installations will go from around 600 today to more than 4,000 in the next five years.

Until a standard emerges, however, IT will have to put some effort into linking disparate data stores. If two vendors are established partners, or if one specializes in integration, APIs or other connectors may be available to link the CMDB with the data store out of the box. In most cases, however, you'll need one or both of the vendors' professional services teams and/or a consultant to make federation work. And once links are established, proceed cautiously when one product or another is upgraded, because changes could break the integration. Such issues will surely increase operating expenses over time.

Sign Me Up

With the potential to dominate a customer's IT management purchases, it's no wonder IT vendors are rallying around the CMDB banner. Last year saw a flurry of acquisitions designed to beef up vendors' CMDB offerings or get them into the market. HP purchased Mercury, CA bought Cendura, Symantec snapped up Relicore, and EMC added nLayers to its stable. And in late 2005, IBM picked up a company called Collation. The common thread among these acquisitions: application-dependency mapping.

Application-dependency mapping is a key technology for CMDBs; it identifies and creates a visual map of the devices that support an application, including servers, routers and switches. Application-dependency mapping also looks at software components and code dependencies that an application relies on, as well as network configurations (for instance, routing tables and port assignments) that allow apps to travel across an enterprise.The connections among, and configuration of, the underlying devices that support an application have considerable effect on uptime. But given the complexity of today's networks, it's difficult for IT to have a clear picture of dependencies among the application infrastructure. By providing a map, a CMDB will help IT better understand the impact of potential changes and diagnose app failures.

Some vendors, including BMC, Managed Objects and Opsware, built their own app-dependency mapping technologies. Altiris says it plans to make app-dependency mapping available later this year. Tideway is the last of the standalone app-dependency mapping companies.

The Holy Rollers

The acquisitions derby demonstrates that the CMDB market is in flux. Some vendors still have work ahead of them to incorporate the CMDB as the foundation for their IT management suites. As we mentioned, two main go-to-market strategies have emerged for CMDB vendors; both are designed to influence IT's future purchase decisions. Vendors that offer standalone CMDBs generally position them as an overlay technology that can be brought into an organization and fitted atop a variety of third-party data sources.

Standalone products are aimed at IT shops looking to implement a CMDB without necessarily buying into a vendor's entire product line. That said, the standalone CMDB will federate more easily with other components in a vendor's suite, greasing the skids for future product sales.The second approach embeds the CMDB in one or more products in a suite. A helpdesk application will also include a CMDB, for example. For companies that have a management vendor of choice, this approach provides the fastest path to integration because other products in the suite will share the data schema, easing reconciliation, and be able to invoke other applications without the need to create connections. On the downside, third-party federation will take additional effort.

Altiris embeds a CMDB within several products, including its Service & Asset Management Suite and its Inventory offering. The company's strategy, which centers around tightly coupling the CMDB with its own products, plays to Altiris' strengths as a leader in the midmarket asset-management and helpdesk arenas.

Still, Altiris recognizes the importance of third-party federation and provides specific connectors for products such as BMC's Remedy Help Desk. It also has a general Connector Solution to acquire data from other stores, such as Excel files and financial or HR apps. Altiris doesn't have strong application-dependency mapping, but told us it has a "short timeline" for delivering such capabilities.

BMC has spent the past several years developing and executing its CMDB strategy. Compared with other setups, BMC's CMDB is the most tightly integrated with other products in its portfolio. It offers its Atrium CMDB as a component of several of its Remedy offerings, as well as a standalone product. This means BMC can provide the benefits of a CMDB to its existing base while competing to offer a CMDB to non-BMC customers.

The Remedy family is key to BMC's CMDB success. Its Remedy customers give BMC a valuable footprint the company can expand on, while other CMDB vendors inevitably put Remedy at the top of their lists for third-party federation and have APIs or dedicated connectors available. Thus, BMC becomes a strong candidate to be the primary CMDB in an organization or at least a key data store. BMC also remains closely aligned to ITIL. It provides out-of-the-box workflows to help companies implement ITIL best practices using BMC tools.CA is new to the CMDB market, launching the CA CMDB r11 in September 2006. It's a standalone product but has tight integration with CA's Unicenter Service Desk. Since CA uses a common data repository across its product line, the CMDB r11 can be federated with other CA apps with less effort than third-party data stores. CA also has a mechanism to import XML data from non-CA products.

The Cendura acquisition gives CA a respectable application-mapping capability with a strong focus on detailed configuration information, which may attract green-field accounts. That said, we expect CA's initial success with its CMDB offering to come largely from existing customers.

EMC is another newcomer. It launched the EMC Smarts ADM (Application Discovery Manager) product in April 2006. The product was built around an OEM agreement with nLayers, a leading application-dependency mapping company that EMC bought outright two months later. In addition to providing EMC with agentless, real-time application discovery, nLayers also included a CMDB to store and manage CIs. The Smarts ADM, which is also available as a standalone offering, includes native integration with other Smarts products and uses XML to pull data from third-party sources.

EMC has been moving outside its storage-centric roots with Smarts to offer a more comprehensive IT management portfolio, along the lines of those from BMC, CA, HP and IBM Tivoli. A CMDB is now an essential component for any vendor that wants to compete in this realm, so the nLayers acquisition was key to putting EMC on fairly equal footing with rivals. However, unlike the aforementioned vendors, EMC isn't yet synonymous with IT management, nor was nLayers established enough to get EMC in the front door on the strength of that name alone. It will have to trade on its strong position in the storage and data center arenas to appear on customer shortlists.

HP includes a CMDB in its OpenView ServiceDesk and ServiceCenter products, which came from its Peregrine acquisition in 2005. However, the CMDB lacked application-dependency mapping. The Mercury Interactive acquisition in September 2006 filled that gap--but it also left HP with two CMDBs. The company says it's working to integrate the Peregrine and Mercury CMDBs, but no additional information was available at press time. Once integrated, the Mercury technology will let HP provide improved modeling and analysis of the potential risk associated with changes to an IT environment. Assuming HP can successfully integrate its CMDB technologies, it's well-positioned to lead, thanks in part to the strong presence of OpenView in large enterprises.The standalone IBM Tivoli Change and Configuration Management Database (CCMDB) serves as the integration platform for other products in IBM's portfolio. IBM uses Discovery Library Adapters (DLAs), which are based on XML, to federate the CCMDB with IBM Tivoli and third-party products. Within the portfolio, DLAs are available for Provisioning Manager, Configuration Manager, Business Systems Manager and others. DLAs are offered for BMC Remedy and HP OpenView ServiceCenter.

In addition, IBM has created process managers for the CCMDB to automate IT processes according to ITIL specs. Three process managers are available: Release Process Manager for software updates, Availability Process Manager for root-cause analysis and problem resolution, and Storage Process Manager for storage consolidation.

The company's 2005 acquisition of Collation gave the CCMDB a competitive app-dependency mapping and visualization component. Like HP and BMC, IBM Tivoli is a strong presence in large enterprise accounts. IBM can exploit that presence to drive adoption of its CCMDB platform. The system is also designed to streamline federation with service-desk products from BMC and HP.

Managed Objects likewise offers a standalone product, CMDB360. While the CMDB360 can integrate with other software in the company's own management portfolio, Managed Objects is aiming to be the independent CMDB vendor of choice, as evidenced by its strong focus on working with third-party data. Managed Objects offers more than 60 adapters (sold separately) to gather and reconcile CI data. CMDB360 uses an XML-based schema that conforms to the DTMF's CIM standard.

However, Managed Objects' quest to be the quintessential neutral CMDB that plays well with others may be thwarted by the company's size: A $30 million dollar company going up against multibillion dollar behemoths will have a much harder time connecting with organizations that are interested in a CMDB, even though it may have an edge with those concerned about vendor lock-in.Speaking of behemoths, Microsoft is expanding its IT management role under a new brand, called System Center, which will be a portfolio of systems-management products based around Microsoft extensions to ITIL. The goal is to provide better integration of Microsoft management products.

The company has announced that existing management products will be rebranded under the System Center name. For instance, SMS will be renamed System Center Configuration Manager. Microsoft also will launch a new product under the System Center umbrella, code-named Service Desk, that will include a CMDB to support change and configuration management. A public beta of Service Desk is scheduled for release in the first half of this year.

Microsoft's move to enter the market is significant, but we expect little detrimental effect on the major vendors in this space--in fact, Redmond could help them by exposing midmarket and smaller customers to the CMDB concept. Microsoft's management products tend to focus on the Windows OS and Microsoft applications. The company will have to work hard to establish its credibility as an all-purpose IT management provider. That said, other vendors will ensure that adapters or connectors to pull data from Service Desk into their own CMDB platforms are readily available.

Opsware comes at the CMDB from the data center automation market. This month it plans to announce its Operational Management Database (OMDB), which will be incorporated into each product in the company's suite; general availability is expected at the end of the first quarter. OMDB will not be available as a standalone product in its first release.

OMDB provides all the common features of a CMDB, including CIs on network devices, servers and applications and the ability to map application dependencies. It allows data center managers to take action on CIs by invoking processes available within the product suite. But because it's available only within Opsware products, the OMDB isn't competing against standalone CMDBs. Rather, Opsware positions it as a crucial element of data center automation and as a third-party data store that can be federated with other CMDBs.Oracle Enterprise Manager CMDB, a data center management package, includes a CMDB for storing and tracking CIs. It has a strong focus on applications and middleware (both Oracle and third-party software) and OS information, less so on network infrastructure elements or asset information, such as software licenses. Thus, like Opsware OMDB, Oracle Enterprise Manager CMDB will likely play a role as a trusted data store that feeds CI information to a CMDB with broader enterprise coverage.

Symantec also is getting into the CMDB market by way of data center automation. In February 2006 the company acquired Relicore, which, along with nLayers, was regarded as a leader in application-dependency mapping. Symantec bought Relicore to automate discovery in the data center and tie in configuration management with real-time change tracking. Relicore's built-in CMDB provides information that other data center tools can then use to automate management tasks.

The company wouldn't comment on plans to expand the CMDB outside the data center, but it's unlikely Symantec will fail to exploit what it regards as the market's premier configuration management technology. We expect the company to ramp up its CMDB strategy in 2007.

Finally, Tideway offers a CMDB as part of its Tideway Foundation 6.1 product, which is the last independent application-dependency mapping system on the market. It features strong visualization of dependencies among network infrastructure, applications and business services, and provides a reporting engine to help IT professionals track configuration changes.

Independence is both a blessing and a curse for Tideway. In green-field accounts it can go toe-to-toe with other application-dependency mapping products without forcing organizations into an overall IT management suite. But the company will have a harder time convincing potential customers who've already invested in management products from BMC, CA, HP or IBM to forgo the benefits of an integrated portfolio.Celebrate Diversity

As the CMDB market grows, vendors are differentiating themselves through the capabilities that can be built on top of a CMDB, for example, ensuring that changes are associated with a work order. BMC's CMDB has a function to compare the state of a CI in its database to actual state based on the latest discovery of that CI. If there's a discrepancy, the CMDB will look for a change request. If an approved request exists, the CMDB will update the CI attribute; if not, it can trigger an incident or an alert.

Managed Objects has a similar feature, in which the CMDB reconciles infrastructure changes with trouble tickets in a Remedy system. If a change doesn't have an associated ticket, the CMDB can request an investigation.

Through a partnership with mValent, HP's Universal CMDB also can compare existing configuration settings to spot divergence from an ideal state. The HP-mValent partnership provides automated remediation as well.

As CMDBs mature, IT can expect to delve into more analytics around real-time monitoring and analysis of all the components of a business service, deep root-cause analysis and advanced warning of emerging problems.If you're looking to stake a CMDB claim, identify how and where IT practices need to change, and evaluate existing CMDB offerings. Then, place your bets on the ability of your CMDB provider (or providers) to meet federation and data-reconciliation needs and deliver future apps that will live up to the promise of the CMDB. If you choose well, you could strike a mother lode of productivity realized by automating routine tasks. n

Business Technology Editor Andrew Conry-Murray can be reached at [email protected].

Interview: Mark Johnson

What have you heard from customers or implementers about CMDB federation? What are the key problems?If you look at the way IT shops have evolved, the management data has tended to be created around the tools, resulting in islands of data. And the processes for managing IT tend to be tool-centric and not as broad as customers would like.

We're interested in helping customers with both problems by federating the data that exists in the repositories so they have a more homogenous view of the data and a better base for building IT processes on top of the data.

How will the working group address those problems?

The focus is on the technologies and interfaces required to do the federation. That is, for the repositories that have data to be federated, to provide the means for those repositories to register the resources they are managing, and for an identifier service to reconcile data when different tools know the same resource by different names.

It sounds like there's an emphasis on reconciliation.Reconciliation is the building block. You can't get to the other things without it. So the initial emphasis is on reconciliation and a common query interface to get the data from the various repositories.

When will we have a draft specification?

It will be some time into 2007. I'm not in a position to narrow it down more than that.

What role will existing standards, such as CIM or WSDM, play in regard to the end product of the working group?

To the extent we can build on standards, that's what we're trying to do. We're looking at CIM, WSDM and other Web services standards.Have you identified a standards body to submit the draft specification to?

The final determination hasn't been made.

A major selling point for vendors with a CMDB is how easily it integrates with their own management products. If a strong federation standard emerges, how will they distinguish themselves?

The customer problems we want to solve aren't low-level issues of how to wire the data together; it's higher-value problems. This standard is to avoid reinventing the wheel every time someone wants to pull data from a repository.

Vendors will compete on the quality of implementation, the value-add built on top of the federated data. Just because there's a standard with a common interface, there won't be exact clones of products. To the extent that people can manage a greater set of data and take advantage with more automated processes, that's where we'll see the competition.Mark Johnson, a senior programmer at IBM, is a member of the CMDB Federation Working Group. this group, founded in april 2006, aims to create a specification for sharing information between CMDBS and other data repositories. the group will submit the specification to an industry standards body.

ITIL: Can You See The Big Picture?

Configuration management is at the heart of major trends in IT, including ITIL (IT Infrastructure Library)--a set of best practices developed by the British government--and service management, which orients IT around supporting business services rather than traditional fiefdoms such as server groups, switch and router groups, and so on.

ITIL describes a CMDB as the single source of truth about configuration items. A CI (configuration item) is a physical or logical asset of the network architecture--a server, a router, a desktop or a software license. The CI contains information about the asset--server name, MAC address, OS version, physical location--and the asset's relationship to other CIs--what subnet it sits on, what other servers it talks to, what services it supports.

All Politics Is Local

CMDBS are evolving from an IT Infrastructure Library concept into a product category existing both within and independent of the ITIL framework. Vendors say about half of the inquiries they receive about CMDBs are driven by ITIL conformance, but the rest see the value of a CMDB--improving IT efficiency and streamlining operations--without necessarily being interested in ITIL."ITIL is like a number of other process-maturity initiatives, like Six Sigma--we tend to go from process-maturity model to process-maturity model," says Dustin McNab, VP of marketing for Managed Objects. "In time, ITIL adoption will wane as another process-maturity model emerges or companies have adopted as much as they want to."

Adopting a CMDB outside the ITIL framework isn't a bad thing--as long as customers realize a CMDB isn't just a product. It's a transformation of the IT organization itself.

Over the years, IT shops have evolved into discrete operational fiefdoms that take a proprietary view of their assets. Within these walled kingdoms, IT processes are driven by disparate toolsets, and management data is tucked away in databases, Excel files, Visio diagrams ... and the heads of subject-area experts.

A CMDB requires that IT change its operational habits. Fiefdoms must forfeit some of their autonomy, which means managerial groundwork must be laid before you start twiddling with technology.

"The political issues are huge," says Dennis Drogseth, vice president at consultancy Enterprise Management Associates. "You have entrenched organizations that don't want to use the same tools or have common views--they don't even believe in having the same processes."One way to address the politics of the CMDB is to find a common starting point where constituencies can agree that current practices need improvement. Change management is an area where various IT groups can begin to collaborate around a CMDB.

That was the experience for Harry Butler, solutions center manager at electronics supplier EFW. Despite weekly change control meetings in which requests would be submitted and examined for potential problems, the company was still experiencing change-related outages.

"It never failed that the guy who knew about one piece of software on a box wasn't at the meeting," Butler says. "So we'd make a change during a maintenance window and shut something down." Butler says the CIO and the managers of each IT group meet to discuss common issues. They agreed that a CMDB might help them all. "We said, 'Hell yeah, let's give it a shot.'"

Another option is to start with a line of business, such as order management. In this case, various IT groups associated with a service assist with discovering all the pertinent CIs (configuration items), then populate the CMDB and map the topology of the service. This helps IT recognize all the pieces that support the service and get them under control.

In all cases, vendors and consultants advise against trying to discover every CI in the organization and map those relationships. By starting small and scaling up, IT will develop the processes and capabilities needed to extract value from the CMDB. Over time, it will grow as products, processes--and, hopefully, standards--mature.0