ACCU - Model Driven Development

The outstanding thing about this talk was Frank Buschmann spending some time discussing the characteristics of the domains in which MDD worked and discussing thoughts about the costs/benefits. It is unusual in my experience to go to a technology talk where the context within which something should be applied is described so well, it made for a great talk. In summary Frank was saying that MDD could be cost effective in domains that had the following characteristics:
+ Closed.
+ Well understood.
+ Undergoing a low rate of change.
+ Had very clear borders, concepts were either in or out of the domain, there were no grey areas.

It looked like the effort required to build the MDD infrastructure (e.g. generators etc) was high and the cost could only be recouped if the infrastructure could be re-applied frequently without incurring more significant cost rev'ing the infrastructure.

Successful examples given related to situations where a product had many different variants that needed generating. These were often drawn from the automobile domain, where software is configured and assembled based on the target car, engine and associated gadgetry (e.g. aircon). Other domains used in the examples included technological areas such as error handling. An interesting side effect of this approach related to coupling. The models had components with low coupling but it was noted the output was often tightly coupled. Since the developers were operating at the model level this tight coupling wasn't important.

It felt like MDD was really tied to product line architectures and not so useful in a service company that works in many different domains and build many different (rather than similar) applications. Having said that, some service companies build a lot of web based CRUD/Workflow apps so there will be mileage there.

As an aside; several conversations were overheard of the form 'generated code isn't elegant, it's useless'. I'm not sure elegance is important. After all, do we care whether the assembler generated by compilers is elegant?. Generated code needs to be efficient, but unless a developer is expected to regularly interact with the generated code (e.g. editing/debugging), it doesn't have to have many other characteristics.