Model Driven Engineering, hot or not?

I’m just wondering… how popular is Model Driven Engineering (MDE)? How often are Model Driven Engineering techniques applied in practice?

There’s quite some research activity in the field of Model Driven Engineering. See for example the Model Driven Engineering tag on researchr or search Google Scholar for MDE related content. To get a more complete overview you should also include research about all MDE-related acronyms and related research fields like modeling, language design, transformations, etc.

With some effort it should be possible to get some numbers about the popularity of MDE among scientific researchers. My question, however, is: how popular is MDE in the software industry? There are quite some reasons to start using Model Driven Engineering, but are people actually doing it? And, even more important, are they experiencing the benefits of MDE?

What is MDE?

Let’s first try to define Model Driven Engineering. MDE is not the same as Model-Based Development. Using a model in your software development approach does not mean you are doing Model Driven Engineering. The key concepts of MDE are abstraction and automation. The model of a software application is defined on a higher abstraction level (than 3GL languages) and this model is automatically converted into a working application using code generation or model interpretation.

Read the full MDE reference guide to learn some more details or read this explanation of MDE using a simple metaphor.

When do we call something MDE?

It’s nice to have some kind of a definition of MDE, but the question can remain what practical solutions can be seen as MDE.

The following two approaches / products can of course be seen as MDE:

There are, however, a lot more approaches or products which use models to drive some sort of an implementation. The following approaches / products are in most cases not referred to as MDE but, in my opinion, they contain elements of MDE:

  • Business process engines: the language to define business / integration processes is as high-level as possible and targeted at a specific domain (in most cases BPEL is used). These processes are directly executed on an engine.
  • Business rules engines: a high-level, tailored language is used to define business rules. In most cases the language is declarative (e.g. decision tables). The rules are executed on a rules engine.
  • Platform-as-a-Service solutions: there are a lot of PaaS solutions available using all different kinds of language to define / configure an application. In a previous article I argued that MDE is essential for PaaS. Not all PaaS solutions can be seen as MDE, but a lot of them use high-level languages to let users / developers define applications.

Just a few examples I thought about. You can probably come up with more examples of the use of models driving implementations.

What is the relevance of MDE for business success?

It’s nice to give all kinds of products and approaches an MDE badge, but what’s in it for us? I think it is important to know the different usages of MDE and to learn from them. I’m especially interested in the question whether the application of MDE techniques did lead to business value (e.g. more productivity, higher quality). I know, just a tool doesn’t bring you business success, but it can help a lot.

83% of the questionnaire respondents of the EA-MDE project think that MDE is a good thing. This case study shows an improvement from 670 days Java coding to 171 days modeling for the same project. Do you have additional numbers about the usage of MDE (even if it isn’t called MDE) in practice?

My questions for you

I would like to know what you think about this subject. Please consider the following questions:

  • When do you call something Model Driven Engineering?
  • Have you seen MDE being used in practice?
  • Do you have numbers / facts about the usage of MDE in real-life projects? Please share them!
  • Why is MDE hot or not?

Please put your answers in the comments! Don’t hesitate to answer just one of the questions instead of all of them at once.


Photo by ReRe

6 Comments Added

Join Discussion
  1. Eric Jan Malotaux October 16, 2010 | Reply

    MDE is a great technique. Yes, it can speed up software development tremendously. But, in my view for the broad applicability of MDE, a maintainable modeling and code generation (or model execution) environment is essential, in order to be able to keep up with the rate of change of the kind of applications that need to be developed. Or, in other words, you need a good language workbench.
    The available workbenches are getting better all the time, but still need a lot of work to reach that goal.

  2. Andriy Levytskyy October 16, 2010 | Reply

    I have been active in the MDE field in academia and industry for 10 years now and had seen cases when a software factory would reduce development from weeks to hours (via automation), and when clients had breakthrough in understanding their own domains (via domain models). These were the most bright examples. I’ve also seen ongoing MDD projects that slowly grow within large organizations, gradually improving their added value..
    Unfortunately, such successes are hard to sustain as MDD is a hard conceptual work, and a typical client simply does not have right skills to evolve the MDD solution with its organization. There are issues on MDD development side as well (e.g. I strongly resonate with Jan Malotaux on tools). Luckily these issues could be managed by experienced MDD professionals, and I see a steady growth in numbers of those.

  3. Alcedo Coenen October 17, 2010 | Reply

    Hi Johan,
    You ask some interesting questions and issues. Let me try to answer your questions, rather from a business/architecture point of view than a technical point of view.
    * My understanding of Model driven engineering is that it enables the possibility to concentrate all efforts on modeling the core functionality (sometimes called “business”), while all other functionalities (secundary to the core, like user interface, interfacing with other systems, database structure etc.) are taken care of automatically. In any case, this understanding of MDE is the main reason why any business should be interested.
    * My experience so far is limited to introducing the idea, and currently I’m working on a small pilot. I have experienced two quite extreme reactions to these introductions: either very cynical and resistant, or very enthousiastic.
    Therefore, I would say, MDE is more controversial than hot (or not). Why is it controversial?
    My suggestion is that the main reason lies in the fact that MDE involves automation of quite some knowledge. MDE (on a business level) is only possible if the MDE-tools already contain substantial knowledge on the non-core domains. You could say, effective MDE needs quite a lot of pre-engineering. Example: when you expect a simple set of UML models of the business to be translated into an effective user interface, the MDE-tool (engine) needs to know quite precisely which interface style is appropriate to the given UML models. The tool needs to have meta-knowledge on engineering an application.
    When looking at the prevailing paradigm of development tools for software development, it is characterized by an extreme openess: everything is possible, the programmer needs to make thousands of decisions. That feels very flexible, and there have been good reasons in the past for doing so. But these tools lack one essential element to enable MDE: they lack specific knowledge on the technical aspects. It is quite clear that in order to transform a model on business level to a more technical interpretation/model, the tool needs be able to take the right decisions without leaving it to the designer to decide on all technical details. That is essential to MDE, I think: it takes decisions on the technical level.
    It is my opinion that MDE will be succesfull on the long run only if engineers invest in developing the technical knowledge that is needed to transform business models into technical constructs. Developing domain models for specific businesses is not that important, in my opinion, because that will be done by the business itself. Business domain models need fundamental technical models.
    Developing this pre-knowledge is time consuming and not easy, and that is, I think, one of the meain reasons why MDE is evolving very slowly.
    I consider MDE not being “hot”, but evolving slowly and steadily towards the promise it makes.
    regards,
    Alcedo

  4. Marco Brambilla October 19, 2010 | Reply

    Good motivational question.
    However, to measure “hotness” (aka, success) we should define the target and the expectations first.
    Actually, for MDD I think the question should be rephrased as: “MDE, FOR WHOM hot or not?”.
    As good technologists, MDE people always thought to make the approaches smarter, but never wondered about who was their target user.
    I think that the main controversial aspect for MDE is that: who is the target user?
    Unfortunately, it’s not easy to respond: there is no unique target, because different MDE techniques and approaches are focusing on different directions (see for instance the BPM community and the MDA community, that target completely different users).
    But I think this remains a critical point for all of the MDE approaches: MDE as such is an innovative (revolutionary?) way of thinking, that could make all the possible target users uneasy. For instance, a hardcore sw developer would not accept the idea of conceptual modeling in place of pure coding; an high-level conceptual analyst would despise the detailed models that are needed for making MDE really working; and so on (we had a similar experience in our early days with WebML).
    Bottom line: MDE IS hot, we only need to find the right user segments that can appreciate it (and these segments can vary depending on the technique, language, approach…). Maybe the MDE guys are not the right ones for this task? What do you think?

  5. Johan den Haan October 20, 2010 | Reply

    Thanks for all the valuable comments!
    In summary I see the following statements:
    * Maintainability of the MDE tools is important. We need better language workbenches.
    * Evolving MDE tools asks for experienced MDD professionals.
    * The essence of MDE is that it takes decisions on the technical level, engineers should focus on creating fundamental technical models.
    * MDE needs to find the right target user.
    Some question raise when looking at these statements:
    * What functionality is missing in the current workbenches?
    * When is developing an evolving your own MDE tool feasible? Do we always need MDD professionals or can we improve workbenches to empower less experienced people?
    * How to link the last two statements? What kind of technical models do we need for which target users?

  6. Andriy Levytskyy October 23, 2010 | Reply

    @Do we always need MDD professionals or can we improve workbenches to empower less experienced people?
    In my experience, technology/tools is not the biggest problem with running MDD projects (even so technology needs attention as well, but on this in a moment). A good domain analysis/ontology is pretty much a must for an MDD project. The problem is that typically organizations do not have experts that can do such analysis well. (So called domain models that I have seen is just dictionary visualizations connecting words with lines, which is a not sufficient). Without this analysis, it is very hard to develop good metamodel or and architecture of DSLs. It is also very hard for an organization to acquire the skill, as typical DSL trainings still focus on meta-languages.
    @What functionality is missing in the current workbenches?
    In my opinion, it is not the matter of quantity but quality. In all my MDD projects in the last 10 years I needed 3 things:
    1. DSL and transformation development based on paradigms optimal and specific for this development task.
    A persistent trend in Model-Driven Software Development is looking for correct abstractions and their semantics (in other words, correct paradigms) to raise development to higher levels.
    (DSM has some particular impressive success stories.) Workbenches are software systems as well and need to be developed too. Moreover, language workbenches is a specialized domain, which is a perfect candidate for a DSM solution (DSM for DSM so to speak). In practice, too many workbenches do not exploit this opportunity and contain too many “abstraction leaks” to 3GL languages (e.g. Java, XML). One may wonder, how big is the impact of paradigms on development of workbenches? In my experience DSM productivity numbers hold for workbenches as well: 5-10 times faster DSL development.
    2. Robust transformation support (M2M, same/different domain, M2T, etc..).
    As mentioned by Marco Brambilla, there is no unique target user for MDD. (This is the view also shared within my company and we look for MDD opportunities among various target groups – business, engineering, manufacturing, support, etc..). It is very limiting to work with workbenches that favor a particular target user (e.g. software engineer) and particular transformation kind (e.g. code generation). Such limitations are usually alleviated by introducing new “workaround” artifacts processes, that unnecessary complicate lives of end users and workbench developers.
    3. Tool interface tailorable to a specific DSL.
    A typical meta-case tool allows DSL developers define custom symbols for language concept. In practice, user interaction is not limited to language concepts. There are other frequent and repeatable interactions: model checkin/checkout, model updates, reuse, configuration management, model maintenance, model scaling, workarounds for workbench limitations and bugs, etc.. These activities are domain-specific and are not supported by workbenches. They may seem trivial, but they are mindless, time-consuming and push end-user away before the added value of MDD is fully recognized. Optimal solution is to automate these activities by means of transformations (here comes the robust transformation support as well) and integrate them in a tailored interface. Tailorability also extends to dialog windows, context menu’s etc..

Leave a Reply