451 CAOS Theory 
A blog for the enterprise open source community
Proprietary, open source systems management get closer
Jay Lyman, September 9, 2008 @ 6:39 pm ETCA and IBM, two of the so-called Big Four in systems management software, announced this week a federated configuration management database (CMDB) system for interoperability of their software. Something like this comoing from two of Big Four (BMC, CA, HP and IBM) wouldn’t normally hold much meaning for open source players such as GroundWork, Hyperic and Zenoss, but it actually does for a couple of reasons.
First, part of the technology that CA and IBM are using to link up their systems management software, which allows it to share information between the two CMDBs, is actually open source software itself from the Eclipse Cosmos Project. CA and IBM said the Eclipse Cosmos software accelerated implementation of the CMDB Federation (CMDBf) specification and the two vendors plan to contribute code from their interoperability work back to COSMOS as reference code.
Second, we’ve been hearing from both open source and proprietary players that most mid-size and large enterprise systems management users rely on more than one vendor or suite to keep tabs on their servers, networks and applications. That trend seems to be continuing and all indications are that more and more open source systems management and monitoring software is sitting alongside the traditional, proprietary suites of the Big Four. In our report, CAOS 4 Managing in the Open, we we wrote about the significance of the open source players and others integrating with the entrenched, larger vendors.
It makes sense for the open source vendors to integrate and interoperate with the systems management suites from the Big Four of BMC, CA, HP and IBM, which makes developmental, divisional or trial use much easier. Why would these entrenched vendors want to integrate with other third-party monitoring and management products? Because customers are demanding it. Think about it, are CA or IBM better off with a continued strategy that says, ‘all us, only us or nothing’ or an approach that takes into account the reality of customer choice, which has broadened thanks to open source, SaaS offerings and other factors? Regardless of how deliberately the Big Four are integrating with open source and other components, customers are using different suites, both proprietary and open source, in combination. This is also helped by the use of open standards by both the open source companies and the traditional vendors.
This is good news for the open source vendors and even better news for customers that no longer have to choose between products that are too expensive and full of feature overkill, or assemblies of smaller, less expensive tools (including open source) that have often lacked commercial backing and require greater expertise to deploy. Now customers, who have commercial open source options, can use combinations of both, reinforcing the larger, ongoing trend of more open source and proprietary software used together in the enterprise.
Comments (5) Categories: Software
I was excited to see this CMDBf announcement because of the prospect of an open interface for querying data from CMDBs. However it seems that this type of highly structured approach to data exchange is likely to fail in practice. To be able to communicate in this structured way two CMDBs will need to share the same ontology. For common objects and relationships, like the computers and people used in the spec, mapping between CMDB ontologies is easy and likely to be implemented, however most implementers are probably not going to support mapping from every object type that they support to every object type that other CMDBs support. This will leave users only able to share the most generic of configuration and not much better off than before CMDBf.
Chris Waters, CTO, http://paglo.com
Thanks for posting, Chris. Interesting to hear your perspective on the limitations here. It makes me wonder, what would it take to make the data exchange and CMDBf in general more useful to your company, to other players and, most importantly, to users and customers of the different products?
JL
One of the issues with CMDBf is that it requires perfect knowledge of the CMDB before you can start querying. I need to know exactly what the items are in the CMDB and the possible relationships between them before I can query.
It would be nice if there was a more forgiving query interface so that I could issue queries without knowing exactly what the types of items are. For example, by knowing that the name of one of my computers is “Bart” it would be good if I could issue a query that returned everything in the CMDB that contained the keyword “BART”. That would give me a starting point to discover the CMDB schema, and to find the relationships between my computer “BART” and other entities.
Another feature that seems to be absent (though I may just be overlooking it, it is hard to truly grok a new specification until you try and implement it), is any kind of reflection or discovery. How would I discover what the schema is of the CMDB (i.e. the possible items and relationships).
I expect these things will come over time as people start implementing CMDBf interfaces, but sometimes it is easy to get caught up assuming that all the actors in a system have perfect knowledge (e.g. each actor completely supports your schema) whereas in practice cross-system schema support is usually very weak.
Chris Waters, CTO, http://paglo.com
Thanks for your response. It will help as we watch the rollout of CMDBf and the work among/between/against various players and what it means for customers.
JL
[...] 5.2 – Proprietary, open source systems management get closer Tue, Sep 9, 2008 11:39 PM CA and IBM, two of the so-called Big Four in systems management software, announced this week a federated configuration management database (CMDB) system for interoperability of their software. Something like this comoing from two of Big Four (BMC, CA, HP and IBM) wouldn’ t normally hold much meaning for open source players such as GroundWork, Hyperic […] [...]