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.