•  "some people still believe that MDA is just another technical approach for generating code - a new form of CASE based on UML"

And I have to say I am one of them

•  Is MDA a paradigm shift?

Perhaps, if/when it ever works and if/when business rules and analytics are properly integrated with it

•  MDA lets developers concentrate on the 15%-40% of project code that implements interesting things such as business logic and algorithms

I don't want to write code to implement business logic - it's a really bad idea. This is what business rules are for!

•  Does MDA enable agile development by eliminating the need to write lots of mechanical code?

Well perhaps. Using agile techniques with business rules to deliver business logic makes sense, but it's not clear this requires MDA

•  Projects using MDA have shown a clear reduction in time from problem identification to working code

But it is still code and IT is still making the change rather than the business

•  Some of the benefits stated for MDA seem simple to someone used to a Business Rules Management System (BRMS) or even of a Business Process Management Suite (BPMS)

For example, if MDA let's you make simple changes to "rules" quickly then that does not seem like much of a benefit given that rules engines let you do that without the step of generating code.

•  If the services built with MDA embody business rules then the models that generate them must also

If it is a bad idea to embed rules in applications (and it is) then why would I want to embed them, or decisions based on them, in a model of an application? I want to manage them as a real asset, not embed them

•  MDA is said to support the separation of concerns

But true separation of concerns should mean that busines logic is managed by business users and MDA won't do that because UML won't do that.