INSPIRE and Model-Driven Architecture

I'm trying to keep up with INSPIRE developments because I'm curious about how big time architects approach big time geospatial projects. I don't have time to ingest all the papers coming out of the INSPIRE community and am partially dependent on the recommendations of others such as Jeff Thurston, who is following INSPIRE more than any other blogger. I was surprised to see, in the European Commission's Data State of Play, such an emphasis on Model-driven architecture (MDA). Surprised in part because of Ed Parson's explanation of the conservative approach required by INSPIRE:

Now here is the rub, despite the fact that much of the INSPIRE directive is not expected to be implemented until at least 2010, it is been designed now and must used well specified and recognised standards - things like the ISO 19100 series of standards developed by the Open GeoSpatial Consortium.

It’s not difficult to appreciate the problem, REST based interfaces, KML, GeoJSON, GeoRSS etc might actually be the best technologies to use today and would be the tools of choice of many, however like many other Government IT projects INSPIRE needs to follow the low risk route of SOAP, WSDL, WMS, WFS etc.

Nevermind that I think Ed's assessment of WS-risk is wrong. Gartner's 2006 analysis had MDA 5-10 years out and nowhere near the so-called plateau of productivity that INSPIRE should be mining for technology. MDA is emerging technology. It is conceivable that, like CORBA (probably the most famous OMG technology), MDA may never really emerge into mainstream use.

Here's where I agree with proponents of MDA: code is not an asset. Under MDA, designers write models and code is generated by tools. The tools are presumably written by extremely talented programmers using bombproof processes, or by meta tools, or by a hierarchy of meta tools and AIs. Or idiot-savant demons from another universe where time runs faster. Theodore Sturgeon's Neoterics. Gods of programming. Ideally, the code generated by these tools would be of higher quality and lower cost than code written by merely mortal programmers. It would also be practically disposable. As Steve Vinoski explains, very few of us write machine code anymore, and MDA is just taking the abstraction to greater heights.

Lest you think I'm just talking through my hat, know that I'm actually "doing" MDA for Pleiades: we have an entity model in annotated UML from which we generate Python classes for Plone using the ArchGenXML tool. It works well enough, but I honestly think we're only just breaking even. Python is a terse language already, and learning and writing the UML annotations eats up the resources I would have spent writing Python code directly. Perhaps if we were using a language full of boilerplate and syntactic noise we would find code generation more productive. Certainly if productivity were measured by lines of code, but maybe also if measured by the time to deliver products. But we're not using such languages. We're using Python, which lets me accomplish the same tasks with the fraction of the code I'd need to write in C, or Java, or C#.

Maybe the INSPIRE community is overlooking a simpler and more mature solution to the overabundance of code problem: more productive programming languages like Python and Ruby? It's a large and sure step in the right direction.

Incidently, Vinoski's and Tomayko's views on definition languages and code generation came together Monday on Vinoski's blog. Lots of food for thought in that post.