It’s tough to avoid someone or another touting the joys of MDA (Model Driven Architecture). Another session I attended at the AJSS was “Agile MDA”. While I certainly was apprehensive that it was going to be a load of fluff, I felt the need to attend anyhow primarily because my gracious employer has been entertaining sales calls from IBM/Rational and CompuWare. IBM is telling them they need an MDA tool, so they believe it. Rather than stand idly by and watch, I felt the need to have a clue about MDA, so I went.
First things first, if you are thinking about attending this session at one of these conferences, and you aren’t in a similar predicament (i.e. – you actually hope to learn something), don’t bother. It’s little more than a thinly veiled marketing presentation. No product is directly sold, but it is more propaganda than proof.
The session abstract claimed, “Model-Driven Developers Do It Faster”, and that they would “get into the details of model-driven, pattern-based development”. The claim is that you draw some pretty UML-style pictures using a tool, hit the big green button, and it generates 65% of the code for your application. From there, you edit “free blocks” of code where you fill in the blanks of the business logic, and voila, you have your application. Funny thing is, anything you change outside of these free blocks can't be round-tripped back into the model.
Their primary “evidence” for the benefits of MDA was TheServerSide's Productivity Study which happened to be sponsored by them, a vendor of MDA tools. The more the attendees delved into the inner workings of their product, the more suspect it sounded. All of the data access, including the SQL generation, is generated directly from the model. If the model changes, you get to generate the code over again. Now recall that they don’t support any round-tripping of code. I understand this, because honestly, it seems as though full round-tripping is an exceedingly tough nut to crack. Too bad they didn’t frame it that way – they said that they didn’t support it because “it's a bad idea”, since “round-tripping can allow bad code to be propagated up into the model”. Well then don’t write bad code, or at least admit that it’s a tough problem instead of trying to justify the design decision by promoting the alternative as a bad idea.
The end result is, of course, that supposedly the MDA group accomplished the same task (functionally) as the “traditional” group, and with slightly fewer defects. The magic is that the MDA tool generates all of your architecture for you, and supposedly you just fill in the business rules, but it sounds a bit far fetched. Furthermore, any changes made outside of the “free blocks” has to be re-integrated each time you generate the model again. This includes any performance tweaks at the data access level – a common place for application bottlenecks, and I find it highly unlikely that their generated SQL provides the most highly optimized query for every situation.
Now spread this issue into every tier because, after all, THEY are dictating, err, deciding the architecture for you. So now, you have no control over the architecture in any tier unless you want to rewrite your changes every time your business requirements change. You can’t choose your web tier architecture, your business tier architecture (which is unfortunate, because they are crazy for EJBs), or your data access architecture. In many cases, you can’t even change your implementation – their approach replaces your EVERY time requirements change.
Full, true round-tripping is pie-in-the-sky, and enterprise apps require more care in design than just pushing the big green button. As such, MDA seems mostly useful for the bonehead applications that you’d turn your least educated VB developers loose on – the non-critical departmental apps. For these apps, I’d then question why you want to spend so much money on an MDA tool for a non-critical tool?
At one of the discussion panels at the symposium, Dave Thomas quipped (paraphrased), “It seems to me to be extremely bad practice to believe that you can write an application by drawing pictures.” Also, when the panel was asked about MDA, I believe it was Stuart Halloway who added, “I find MDA every bit as essential to the development of quality software as UML.” I couldn’t say it any better.
Update: In an amusing twist of fate, it seems that one of these vendors is coming in today to give a demo of their product. Oh joy.
Rob's Blog - Technology, Atlanta, Startups and Stuff 
There is a lot of handwaving around MDA, and that is the regrettable side effect of working in an area where there are benefits and there are no clear winners at the moment.
If you look at the MDA standard what they are trying to do is pretty simple. They are defining a standard for representing the object model of the application, which can be restricted to the persistence model for a more pragmatic approach.
They are also defining that there should be two models, a platform specific one and a platform independent one. The platform specific one should be built from the independent one by a mechanism that understands the territory. So if you don’t want EJBs, you want POJOs, then change the translator to build POJOs. A good system should make that easy.
I think your BS-ometer is on and functioning. I just think you need to look beyond particular vendors. There is value in building the grunt code with a generator. The trick is in building or buying a good generator. You might want to look at other projects, like AndroMDA, which is an open-source MDA implementation.
Thanks for the insights, Jack.
If for no other reason, I may give AndroMDA a solid look just to present a cost-saving alternative if we decide we’re just hell-bent on having such a tool.
I’ll also try and give the idea more of a chance than I’m willing to give CompuWare from here forward. Problem is, you have them (whose solution I don’t like at all), IBM/Rational (I’ve found Rational’s products to be far too restrictive/difficult to use in the past), and then the runners-up (although I’ve heard a good bit about AndroMDA). And it’s always dicey going with a non-front-runner.
Any way you go you are going to have to put a substantial amount of work into understanding and developing the generator to make it worth your while. I think the big advantage of MDA is that it’s a pseudo-standard so that there should be some transportability of skills. That being said, the MDA standard is pretty soft.