* The link between merger activity and the Configuration Management Database
The topic for this column combines two gorilla-level subjects demanding my attention: mergers and acquisitions on the one hand, and implementations of the IT Infrastructure Library’s Configuration Management Database (CMDB) on the other.
The former have occupied my attention because, well, they just “keep on keeping on” and because they’re certainly changing the enterprise management landscape. The latter is occupying my attention because Enterprise Management Associates is finishing up the second in a series of reports on the CMDB, looking at vendor and IT implementations.
The CMDB would be a common trusted repository of information involving configuration, topology and service relationships in support of a whole host of management disciplines and applications. Like mergers and acquisitions, industry CMDB initiatives are also beginning to change the enterprise landscape in some significant ways.
These initiatives are bringing together very distinctive communities of vendors, ranging from platforms and frameworks that, yes, will compete to be the center of the CMDB universe, to vendors focused on application service discovery, such as Collation, nLayers and Tideway; to service catalog vendors such as Centrata; to business service management vendors such as Managed Objects; to network and systems change and configuration vendors, such as BladeLogic, Opsware, Configuresoft and Ecora; and AlterPoint, Intelliden and Voyence. The initiatives will also touch help desk vendors, asset management vendors and lifecycle application development and planning vendors.
In the best of all possible worlds (don’t hold your breath for at least 10 years on all of this being real) – it will enable a modular, federated approach to integrating different types of data stores in a single, cohesive, trusted system for understanding the health and state of critical business services. And it will do this across changes in configuration, topological dependencies, asset and contractual information, customer information, policies (business, operational, security, compliance), and the health and availability of all service components.
This federated system should, moreover, be dynamically current, administratively light and support virtually all management disciplines and applications with consistent, current and accurate information. And it will allow for multi-brand choice in a modular way.
I did say in the “best of all possible worlds,” right?
Well, needless to say, a truly workable approach to the CMDB in the near term would require narrowing the focus to make “doable” chunks. It also would require collaboration among vendors (witness Collation working with Compuware, nLayers with Managed Objects, Peregrine with Mercury, etc.).
Most vendors supporting the CMDB direction are designing for multi-brand integration from the start, sensing that one of the best ways to lose the CMDB wars is to announce, “We can do it all!” This can be an affront to buyers (many of whom, nevertheless, do want to start with a single core brand) – as well as an R&D nightmare.
CMDB initiatives might inspire acquisitions in that vendors may simply pursue a strategy to go out and acquire all meaningful CMDB components – but that’s not happening, at least not yet. Although it’s true that, for instance, HP’s acquisition of Novadigm and BMC’s acquisition of Marimba could directly support CMDB directions, it would probably be a stretch to assume that CMDB was the primary motivating factor. Mercury’s acquisition of Appilog may seem a little more directly related. And certainly, the future may see a number of such moves – even if, in the best of all worlds, CMDB strategies really should favor multi-brand choice.
The other connection between CMDB and merger activity is a new attention to structure and architecture that truly is beginning to transform the enterprise management marketplace.
The old-fashioned approach to product development, focused on a checklist of functions with element-centric products and minimal levels of integration and consistency, is finally coming to an end. It is and always was a failing strategy. But in all fairness many of the enabling technologies – for more effective data gathering, data transformation, discovery, topology, configuration, data store, analytics, visualizations and automated actions – were really not in place in the mid to late ’90s when most grand framework initiatives collapsed from their own weight.
There’s still a long way to go – but if you look at that list of functions and reinterpret the management marketplace accordingly, you’ll see more signs of progress than you might have expected. That’s where the notion of the CMDB is coming together with smarter, better acquisitions.
Smarter vendors are looking for structural as well as market-centric investments. The CMDB is one type of initiative, no matter how far-reaching, that reflects another even larger requirement: architectural and functional solidarity. This, rather than raw cut-and-paste market building, will represent the future of enterprise management growth.
HP’s multiple acquisitions in 2004 were almost all driven by this broader requirement. NetScout’s acquisition of Quantiva was a clearly an investment in “analytics” coupled with NetScout’s strong visualization and data gathering. CA gets powerful root-cause diagnostics, among other enabling capabilities, through Concord-Aprisma.
This list goes on, and it is just the beginning. The CMDB is perhaps the most visible symbol of these building-block requirements – and as such it is a fitting herald of a new, more structurally aware and consolidating marketplace.
