DCML Framework published

A draft version (0.11) of the foundational framework for Data Center Markup Language (DCML) has been published.

I'm very critical of DCML's direction in this post; let's lay out my assumptions at the top:

1. DCML is aimed at large-scale enterprise IT, capitalist organizations with a strong and pragmatic emphasis on value proposition -- not academia.

2. DCML is not solving a research problem. It is not even solving a software engineering problem. It is a solution for a data management problem.

3. Large-scale enterprise IT is most comfortable with the relational database, and has built substantial infrastructure around data management using this platform. Object-orientation is restricted to software; object-oriented data management has failed to date. XML-based data management is going the same direction.

4. To the extent RDF is used, it will alienate the very customers that DCML is seeking: IT enterprise architects charged with evaluating new technologies and applying them to business problems.

--------------------------------------------------------------

As reported, DCML is based on RDF from the W3C, which I find unfortunate; this semantics is even further from the experience of mainstream IT professionals than UML and object orientation is.

Let's be clear however (especially for my itsm-l readers): this spec explicitly references the concept of configuration management, which the OMG has been somewhat tardy in addressing. It clearly is aimed at a significant, if not core, domain of the ERP for IT problem.

The DCML effort does recognize that it needs a visual formalism, and UML is mentioned as a possibility pending the OMG's establishment of the Ontology Definition Metamodel (ODM). However, this is by no means a satisfactory solution. The DMTF framework has some characteristics of a meta-meta-model, and layering such abstraction on top of the ODM which in turn would be layered on top of the OMG's Meta-Object Facility - ugh!! Three layers of intellectually challenging abstraction before any meaningful data structures are expressed?

I'll have some further comments after I review the spec in detail. But this may require me to break down and burn some valuable time coming up to speed on RDF, which in all honesty I'm not too thrilled with. I'm somewhat of a stick in the mud who believes that the relational model and object orientation are quite enough in the way of core abstract semantics, thank you very much...

RDF comes out of the artificial intelligence community and from what I have seen, it's just plain overkill for the internal IT problem domain. I admit to having some homework to do in this area. However, if an obsessive-compulsive like me (writing this on a Saturday night) is reluctant to climb this hugely nontrivial learning curve, how will DCML ever be sold broadly? I don't buy the argument it's just for the tools vendors; large, sophisticated IT shops will need to grapple with it first hand as they try to drive real value out of DCML-based tools.

With all due respect to the information theorists working in the OMG and W3C, I feel I have to keep pointing out that most enterprise IT data management practices are based on relational databases and SQL. Object orientation is making some headway, but OODBMSes failed and most OO programmers still map to relational data structures. XML is having decidedly mixed success; as a tactical serialization format it is passable (albeit with performance issues); as a primary data definition language it is no substitute for relational modeling, and is being shunted aside by most data practitioners for this reason (this assertion based on numerous conversations I had at the last DAMA/Wilshire conference). The influence of relational pioneers Ted Codd and Chris Date is still strong, and XML is viewed as simply a throwback to IMS.

RDF is yet another fundamental data structure paradigm, with its own query languages, schema definition, and so on. SQL won't work unless the RDF structures are mapped into a relational database. This alone with drive away 90% of potential customers IMHO ("I can't use Crystal Reports? What the h*ll are they thinking?"). As a practitioner in a $27bn enterprise, I see object orientation struggling for acceptance on the data management side, let alone RDF. Existing repository vendors such as ASG, MetaMatrix, Adaptive, DAG, and others will have to re-tool significantly, or RDF tooling will perhaps require XML databases (a non-starter with most DBA teams, unless based on existing products - admittedly, the major RDBMS vendors are getting very strong with XML support). But even if the base persistence/querying are solved, real RDF repositories (with supporting frameworks, versioning, audit trails, delta capture, and everything else required by a robust repository) will require significant effort.

Never underestimate the costs of a new paradigm: core infrastructure tooling, steep learning curves for senior staff, shortages of qualified personnel: and for what? A non-deterministic, AI-based data management paradigm? Where is the requirement for such hairy complexity in the internal IT problem domain? The (meta) data may have deep inheritance, deep composition, and a lot of recursion -but first-order predicate logic works just fine for all this.

For further commentary on DCML, see here.

For an interesting perspective on how RDF compares to relational data management, see Data Modeling, Left and Right by Philip Engle. Frame logics? Higher order predicate logics? Urrgghhh.....

-Charlie

Comments

[Anonymous Coward]

I think the idea would be that companies who want to play with DCML will use a product (tivoli, HP, etc.) and will require the compliance of that product with DCML. This would simply force the vendors to adopt an RDF transform layer or some such (if they were to play nice in this space as well).

BTW, are you suggesting that people use straight up SQL for this type of data structure or UML? It seems like you're arguing both (and yes, I see UML having trouble gaining acceptance in large scale enterprises for development efforts, much less most things outside of that realm (read: IT asset representation, etc.))

[Ken Meltsner]

It seems more likely to me that DCML-based tools will not use "real" DCML except as a data exchange standard, and that the tools will need to convert between other representations (SQL and tables, XML, CSVs, etc.) and DCML for communication with other tools.

My preference would be for a simpler format based on straight XML, but with a standard mapping to RDF. Simple tools could work with the simple XML format, but full data exchange and consolidation of complicated information sets would still be based on the more powerful RDF-based definitions.

There's at least one precedent for this sort of approach: one of the new weblogging syndication formats is straight XML, but includes a normative (part of the standard) transformation to/from RDF so that more generalized tools based on RDF can use the information in the feeds without requiring that all tools speak full RDF.

You can consider it comparable to using CSV files for simple data exchange, but moving up to XML if you need to handle Unicode, metadata, or odd delimiter situations (e.g. embedded commas, tabs, or double quote marks).

By the way, just to complicate matters further, the DCML framework draft uses OWL (an information modelling/ontology definition language built on top of RDF), which adds another layer of capabilities and complexity to the stack. I cannot imagine that anyone will expect users to work with straight DCML directly as a result -- I'd sooner work with ASN.1 binary files....

Given that the draft describes a framework, and not every applicable standard or definition, there's a lot of room for simpler specs, just as long as they can be rolled up into the DCML framework when needed.

[Steve Chambers]

Charles, loved your book - great work.

So DCML appears to be dead and buried... I checked out the Oasis site and saw closure notices from Mary in 2007... and all the TC's seem to be closed.

I haven't got time to dig into the reasons why it died (if it is really dead, but it looks at least dormant to me) but would love to know if it was for the reasons you highlight (complexity being a big one) or commercial / partnership difficulties.

I work at VMware and we are looking at creating an operational framework that pulls ITIL/ISO20000/COBIT closer to the technology to provide a more specific, actionable framework in response to customer requests.

Cheers
Steve