IT Modernization < V. Hanniet

software model driven approaches

Is MDA the Holly Grail of Agile Manifesto?

OK, I’m in a teasing mood… But let’s take the four Agile Manifesto values and have a look on MDA(*)  through these values.

  1. Individuals and interactions over processes and tools
    The fact is that tools have a huge importance in MDA. Individuals, even interacting well, will not succeed if MDA tools don’t work (modeler and model-to-code generator). This is a key difference between non MDA development and MDA development. Leaving aside this key point, the MDA process globally use an Y-cycle (modeling / making generator + using generators and completing code) which benefits well from interactions between functional modelers, architect and developers. But MDA is a process.
    MDA ranks 3/5 on this scale
  2. Working software over comprehensive documentation
    At first glance, agile processes advocate that source code is the (unique) material that worth to spend time working on. On MDA side, the focus is on formal specifications through models (for part of specifications that can be easily modeled) and source code automated generation. Aside from source code, models and generators have to be taken into configuration management as they hold an important part of the final source code direct responsibility. So, in an MDA project the formal relation:
    application_source_code = application_architecture_generation(application_functional_model) + non_generated_added_source_code
    leads to consider generators and models as working software parts. The happy end is that models are also documentation!
    MDA ranks 5+/5 on this scale
  3. Customer collaboration over contract negotiation
    This axis is technically neutral (whatever the development techniques are, we can always choose to spend more time with end users than with buyers & lawyers!). However, one noticeable point is that MDA techniques are very useful to build mocks and prototypes, notably for UI workflows, using modeling/generating quick iterations. By drawing a quick & direct relationship between a customer exigency’s evolution and the impact on the application, MDA gives better control to the customer.
    MDA ranks 5+/5 on this scale
  4. Responding to change over following a plan
    MDA is the champion of “responding to a change” challenge! Don’t forget that the main part of the application source code is generated (usually about 80% in modern languages). So, as soon as the change is described until it can be modeled and the non-modeled functional details may be given in natural (or formal) language, the change implementation is mainly achieved by launching a code generation (and completing this code with the non-modeled functional details). And the other happy end is that it almost does not matter when this change occurs: even at the end of an iteration the change may be implemented!
    MDA ranks 5+/5 on this scale

So, the result is: through Agile manifesto values prism MDA is an incredibly good choice! Looking at the Twelve Principles of Agile Software for the same challenge leads to the same conclusion. Not so surprising in fact: Agile values and principles say nothing about how to produce good code (ie code that implements a correct response to user needs and is sustainable in software life-cycle). Nothing but: the team will find a way. MDA is a process which aims to link a non (so) technical way to express exigencies (modeling) with a structural way to produce repeatable source code (generating). An MDA agile team can surely find a path to success!

What’s wrong in this reasoning? I don’t know yet, and maybe you’ll tell me. One fact however: I never saw a development project finishing in initial time frame with the whole initial perimeter implemented. Never but in some MDA projects…

(*): MDA is here used in a generic way that means using models to generate (structural) code. I could have used terms as MDD or “MDE development” but MDA seems more meaningful to me in a straight interpretation:  Model Driven Architecture.

Featured image taken from


4 comments on “Is MDA the Holly Grail of Agile Manifesto?

  1. Rafael Chaves

    Very good points, Vincent.

    Not essentially agile but frequently related is the DRY principle. I can’t see what more DRY than MDD.

  2. Xavier Seignard

    Hello, finally someone took the time to write that kind of blog post, thanks Vincent!
    Everybody say “I’m Agile”, nice, but this is not enough.
    Agile is a real thing, with principles behind it. So if you want to say “I’m Agile” you have to demonstrate how you stick to the Agile Manifesto. And that’s what you’ve just done.

    It reminds me the conclusion of the MDDay 2010. And this blog post :
    I had the same conclusion about how Agile is MDE.



  3. vhanniet

    @Rafael: glad to see that Ted is beginning to learn MDD:). By the way, in DRY perspective MDD may be seen as a giant industrialized copy/paste (and thanks for learning me blog etiquette: always give a word to someone leaving a comment on your blog :D)

    @Xavier: I did not yet get comments from Agile community. Looks like merging MDD & Agile is a long long road…

  4. Pingback: MDA/MDD: Model is not code!? « Vincent Hanniet * IT Modernization

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


This entry was posted on 23/03/2011 by in MDD / MDA, Modeling and tagged , , , , .

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 187 other followers

Creative Commons License
IT Modernization < V. Hanniet by Vincent Hanniet is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.