DCML moving toward standardization

At Computer Associates’ CA World conference last week, the Data Center Markup Language organization announced the first publicly available draft of the DCML framework specification.

The idea behind DCML is to provide an open XML-based model and language that will serve as the lingua franca in the data center, providing an inventory of the elements in the data center as well as the functional relationships between them. A model based on DCML would contain component relationships, dependencies, configuration information, operational policies, and management policies.

The desired end result is a standards-based repository in which all of the information about a data center may be stored, regardless of vendor. For the various “on demand,” “adaptive” and “utility” visions to become reality, they all need to play well with each other, and DCML is part of the glue required to make that happen. In the fully realized DCML vision, all vendors that support DCML should seamlessly interoperate with one another.

Put on your Buck Rogers hat for a moment. In the fully actualized real-time data center of tomorrow, management technologies should be able to manage any hardware, regardless of which vendor provides it or which software you choose to manage it with. We are, of course, a long way from that today. Most IT people today are still struggling with core issues like how to prevent IT fire drills and minimize downtime, and do so in only 40 hours per week.

Today, DCML seems to have received the most traction, with around 50 companies supporting the specification. While a number of these are smaller vendors like Marimba, Opsware and Vieo, there are also quite a few larger vendors on the list, including Computer Associates, EDS, Tibco, BMC, BEA, Mercury Interactive and NetIQ. Notably absent from the list are IBM, HP and Microsoft, each of which have their own DCML-like specifications in the works. Microsoft, for example, is pushing its Systems Definition Model, which is a key foundational element in the company’s Dynamic Systems Initiative. All of these specifications are good ideas, but until the vendors realize that they need to fully and seamlessly interoperate with one another, their appeal will be limited. This is more than just the usual “tug of war” that goes on between vendors – in a real data center, which is inherently a heterogeneous environment, the only way that any of these visions is going to work is if they work with one another.

The key next step, then, is for one of the standards bodies to take on the task of ratifying a DCML-like specification. Once an architecture such as DCML becomes a standard, it hopefully will be easier for competing specifications to merge with DCML or, worst case, interoperate with it. One of the announcements made at the DCML session was that the organization has submitted the DCML 1.0 specification to “various” standards bodies, including OASIS. This is a key hurdle that DCML must overcome before it begins the path toward true ubiquity.

I applaud the investment that the companies supporting the DCML specification have made, and hopefully it will gain enough traction with the standards bodies to make it a framework other vendors can rally around. For me, as an IT guy, it doesn’t really matter which specification becomes the standard. What really matters is that all of the vendors that want the data center to become a “real time” utility play well with one another, so that I don’t have to worry if a SAN from vendor “A” and a switch from vendor “B” will be able to be seamlessly managed by management vendor “A,” “B” and/or “C.”