10 things you should know about Model Driven Development

Last saturday I gave a talk at the Devnology community day about Model Driven Development (MDD). I have talked about ten things you should know before you start with MDD. It was an introduction to MDD with some highlights of more advanced topics. In this article I share the slides of my presentation including a short explanation of each of the 10 points.

1. Differs from model-based development

Johan den Haan presenting at the Devnology Community Day

Using a model in your software development approach does not mean you are doing Model-Driven Development. The key concepts of MDD are abstraction and automation. The model of a software application is defined on a higher abstraction level (than 3GL languages) and this model is converted into a working application using automated transformation or interpretation.

2. Is still a software development approach

When using MDD do not forget you are still building software. See 8 reasons why MDD is dangerous for a more detailed explanation of the points. One additional point I mentioned is the law of leaky abstractions. This law coined by Joel Spolsky states: All non-trivial abstractions, to some degree, are leaky. I do not fully agree with the full article about this law, but it is true that if you use MDD and model on a higher abstraction level, sometimes you will need knowledge about the details ‘behind’ the model. For example to optimize the performance of the resulting system.

3. Asks for agile development

To get all advantages of MDD you need to use it in an agile way. Involve all stakeholders in the development process, use short iterations, and do not forget that YAGNI also holds for modeling. Because it is so easy to add functionality when using MDD, you will not be the first one ending up with a ‘spaghetti-model’. MDD, on the other hand, also enables agile development. MDD enables short iterations and makes it possible to show the results of a model change almost directly in the working application.

4. Needs a standardized architecture

MDD needs a standardize architecture. The functional principles of the architecture are enclosed in the Domain-Specific Languages (DSLs) and the associated model validations. The constructional principles are reflected in the code generator or interpreter. On the other hand, MDD really enforces the architecture. Each architecture principle is guaranteed to be followed by the resulting applications.

5. Asks for different tools

See Model Driven Engineering tools compared on user activities for a detailed explanation of this point.

6. Leads to a change in roles

See roles in Model Driven Engineering for a detailed explanation of this point.

7. Can lead to business-IT alignment

By using domain-specific concepts, involving domain experts in the development process, and by enabling shorter iterations MDD can lead to more business-IT alignment. This alignment can possibly become more explicit by using a framework for Model-Driven SOA.

8. Needs another business model

MDD needs another business model than traditional software development approaches. One example is that companies cannot keep selling development hours. They can of course keep doing it, but in most cases you will need less hours to develop a solution…

9. Is not enough

We need more than MDD! We need to integrate modeling and programming. See this presentation for an excellent view on this topic. We also need to focus more on changing applications. Just building applications very fast does not solve our problems. We need to be able to adapt applications to changing business requirements with preservation of runtime data, long running processes, etc. Another point of attention is the runtime flexibility of applications. Due to the fact that MDD enable fast changes in applications a lot of the resulting applications are not flexible themselves. A change in your model means however that you need to test everything again. What we still need is the ability to change an application at runtime in a controlled way. For example: changing security rules, GUI elements, rules, etc. One solution direction is to use adaptive modeling (I will write more on this topic in a future article).

10. Leads to resistance

MDD leads to changes in roles, tools, and business models. Not everybody likes change…

The slides:

Be the first to comment!

Leave a Reply