MDA is it worth it? And always write EXTERNAL requirements

In short I've found that any potential gains of MDA are done punctually and not globally. Trying to adopt a global MDA approach is too contraining for the architectural choices and will ultimately lead to miscommunication within the team and with the client.

Two of the major drawbacks of MDA are:

1. Defining a model
2. The problem of regeneration.

The project that I'm currently working on is large and complicated. Because of this the assumption was made and sold to the client to embrace a "Model Driven Architecture" approach. We were doing MDA not to have different technology choices but given the sheer volume of code needed to be written. By having a model we could then modify the model and the code would be generated. The technology was already chosen from the begining J2EE.

We started by modeling the domain objects and getting the client to approve them as requirements. The user interface and data model would then be extrapolated from the 'domain model". This was a huge mistake. This basically cost the project 15 analysts time for a year. Right now we're trying to implement the model and basically most of the time the model is either wrong, really inefficient, or relationships are not in the right direction.

So I'm now a firm believer in driving the domain model from the outside or the database and the user interface. This is called external requirements. I'm also a firm believer in only specifying and delivering to the client the user interface, data model, and business rules attached preferably to the user interface, datamodel, or messages, etc. Keep all domain object models, internal workings for yourself or else specifications and development will crawl to a halt, getting approval for each internal change. Some clients demand this transparancy but don't give approval, at least if you're on a fixed-bid contract. If you're on a time and materials then do whatever the client asks, the longer a project lasts the more money you make!!

So my best practice is to:

1. model the database with a good tool like Power Designer and generate the database. Keep the physical model in synch with the actual sql.
2. define really well the user interface (web, fat client, messages, etc) and all the business rules associated with the user interface events even though they might not be implemented in the presentation layer. Do a real mock-up of all or most of the screens or template screens.
   

Then think about generating certain things like:

• once the database is created you can generate persistance objects and Hibernate mappings with Middlegen, or cocoabase.
• If you have html mock-ups then you can generate jsps with xslt or presentation objects with xmlc
• using xdoclet for struts is nice and keeps everything in the Action classes. Not the bullshit struts-config.xml

Getting back to the two major problems with MDA, the first being the problem of defining a model. The database model is well specified with entity relationship diagrams. These have been around for a while and most DBA's worth anything speak this language. Page mock-ups are WYSIWYG. No client surprises.

The other problem is regeneration. What happens if the model changes? What happens to your changes? are they lost? Most of the time the answer is yes, unless you adopt a full blown round trip engineering tool like Together or Rational XDE. Personally I favor Together but since they were acquired by Borland the quality has dropped off. I wouldn't recommend anything from Rational. Just way too complicated and very unstable. It will be a while before I'd bet my career on on of their products. So if you think that you're in for an iterative and shifty requirements based project (which most are) then forget about regeneration and make sure that it won't be a major slowdown in the development cycle to always modify the model, regenerate, then compile.