Managing Data Centers Through XML

there are all kinds of different systems. DCML provides the vocabulary, the language if you will, for those systems to communicate with each other.

Tim Howes, CTO at Opsware Inc.

How long is the list of applications and systems potentially affected by DCML? The list is ultimately as long as the variety in the data center -- any system that you are using to manage your environment. We're focused on the data center because that's where we think the most complexity is, but the complexity actually extends beyond the data center to other environments as well, and there's nothing to prevent you from applying DCML to those environments.

What are the initial goals for DCML? We're trying to create a standard data format that can be used to exchange information between automation and utility computing systems and traditional management systems. The use cases that we have in mind are: making sure provisioning systems can communicate with the systems that manage the machines that they provision; making sure those systems can communicate with the asset-tracking, inventory and billing systems that are responsible for keeping track of what's going on in the environment; and translating that into billing for customers or cost accounting for internal purposes. We want all these things to be able to communicate with one another.

What technical challenges do you face? The biggest technical challenge is being able to deal with the level of diversity that's out there. Another technical challenge is to define DCML in such a way that it can be adopted incrementally so that neither vendors nor customers have to radically change their products or how those products are used.

What kind of information must be exchanged, and in what format? The format is XML-based. The information really falls into three categories. The first is the physical components themselves -- the environmental information, such as characteristics of the server and networking gear. The second type of information, called the library, is the best practices and policies that you want. Finally, there is the blueprint, which shows how to combine those physical components in with the best practices that you specified in the library to produce an actual environment. DCML is not going to mandate the best practices. Instead, it will provide the mechanism to express best practices that would be different from one IT department to another.

The big challenge in writing standards is often political -- balancing competing vendors' agendas. Is that true here? It's always a bit of a challenge. We've got an opportunityto decide whether we want to make a standard that's very useful on the ground and works or that satisfies the political winds of different players. Historically, the standards that are successful are the ones that stay focused on implementation and adoption. Success to me is not how many [vendors] sign up and say they are going to support the standard. Success is how many get it into their working code and then how many customers end up using it.

Some big vendors, including Sun, HP and IBM, aren't involved with DCML. Can you succeed without their participation? It's not at all surprising to me. The big companies are invested in their own proprietary technologies, and they often don't see it in their interest to migrate to an open standard until or unless their customers force them to do so.

Read more about data center in Computerworld's Data Center Knowledge Center.