If you’ve been trying to figure out what this new Data Center Markup Language is all about, you’re not alone. And there’s a lot to figure out, if DCML’s backers at EDS, Opsware, Computer Associates and BEA are to be believed. DCML is for data centre management. And grid computing. And utility computing. And disaster recovery. And just about any other buzzword-compliant IT function making the rounds these days. It all sounds pretty grandiose.
But DCML is a lot less than it seems. And that’s a good thing.
What is DCML? It’s text. Highly structured text, sure. Text that’s as full of tags as the thickest HTML. Text that’s never going to qualify as anybody’s choice for bedtime reading.
But it’s not a protocol. It’s not a programming interface. It’s not a middleware framework. At its core, DCML is just a lot of words.
Specifically, it’s a lot of words that describe what’s in your inventory of IT systems and software, and how those systems and applications fit together, and what your best practices are for running, managing and maintaining it all.
And all that data about your IT setup is formatted using a standard set of XML tags. It’s not specially encoded or compressed, or subjected to any other complications or proprietary hacks.
Which means, in theory, that it should be usable by any vendor that has signed on to support DCML. And maybe — though no one is absolutely sure how this will come together — we’ll be able to use that information to solve data centre problems and make better use of IT for things like utility computing.
Oh yeah — and after all the years that the IT press and pundits have sung the praises of XML, corporate IT shops will finally get the chance to taste that XML dog food for themselves. (And if we can’t get XML working for data centre management, for once we won’t be able to blame it on those clueless nontechnical users.)
So if DCML is just a lot of text formatted with XML — if it’s really that simple — what’s so hard to figure out?
Answer: DCML is simple. But the things that vendors are promising we can do with it are complex. And so are the things we’re trying to describe with it.
And that’s the way it should be. Because the more complex the problem we’re trying to solve, the less complicated we need the technology to be.
We want to push the technical complexity down into the infrastructure — the networks, the servers, the storage systems. We want to clear out as much complexity as possible from any new technology that’s supposed to make them all work together.
Which is why DCML isn’t a protocol. Or a programming interface. Or a middleware framework. Those things can be useful, but they bring a lot of complex technical baggage with them. And we end up spending a lot of time and effort wrestling with those complexities instead of solving business problems.
DCML is intended to be simple, lightweight and hard to get wrong. The complexity is in the information and the business problem, not DCML itself.
That should give vendors less opportunity to foul up their DCML implementations. It should also make it a little harder for us to foul up with DCML, too.
It’s a good idea. Will it work? We’ll see. The first version of the DCML specification is due to be published in December. After that comes the tough task of applying DCML to real data centre management challenges.
Then, eventually, we’ll get our taste of DCML. And yes, I’m hoping this less-is-more, simpler-is-better approach works. Because the problems IT is trying to solve — inside and outside the data centre — are just going to get more complex.
And the less we have to figure out, the better.
Frank Hayes, Computerworld’s senior news columnist, has covered IT for more than 20 years. Contact him at [email protected].
