Unfortunately this is not the case. I can of course answer this question, and I mostly try to adapt my answer to the practical case at hand, but there is no clear overview (as far as I know) answering the question from a business owner: why should I start using MDD?

So, why MDD? What are the advantages of MDD, MDE, MDA or other model-driven related acronyms? In this article I will to try to answer this question by listing 15 advantages of Model-Driven Development. Note that some advantages depend on the type of model driven software development you use.

Article highlights:

15 clear advantages of Model Driven Software Development.

In short: productivity, quality, alignment.

1. MDD is faster

In Model-Driven Development the model of a software application is specified on a higher abstraction level than traditional programming languages. This model is automatically transformed into a working software application by generating code or interpreting / executing the model. While the used model is on a higher abstraction level it is much smaller compared to the same model expressed in code. In other words: each element in the model represents multiple lines of code. Hence, you can build more functionality in the same time. See for example this comparison between Mendix and Java development. MetaEdit+, another MDD tool is told to be five times faster than traditional programming.

2. MDD is more cost-effective

MDD can be more cost effective. The first reason is that you have a shorter time-to-market because MDD is faster (see point 1). The second reason is that it is possible to do it at lower cost (i.e. with less people, non-specialists, increased quality, etc. – see the points that follow). This of course depends on the costs of learning the MDD approach and the costs to develop or buy the tool. It also depends on your business model. If you are used to selling programming hours your business will be affected by using MDD.

Changing and maintaining applications build using an MDD approach is also more cost-effective. It is easier to understand the behavior of an application by reading high-level models (see also point 6). Additionally it is faster to add functionality or change existing functionality using a high-level language.

3. MDD leads to increased quality

Because a software application is specified in a high-level model which is executed by an engine or transformed into code; the (technical) quality of the application depends on the generator or engine. Hence, the quality can increase a lot because we can let our best people work on the generator. Furthermore, all best practices we learn in projects can be included in the generator and will automatically be applied to projects build using the MDD tool. In case of buying an MDD tool the tool can contain even more best practices because it builds on the knowledge of all projects build by the MDD tool in the past.

4. MDD is less error-prone

Everyone having experience with delivering a new software application knows that testing costs a lot of time and expertise. MDD ensures that you can focus on testing the functionality of the application, i.e. acceptance testing. Technical problems are covered by testing the MDD tool. Think for example about infrastructure related problems or security leaks in the technology.

5. MDD leads to meaningful validation

Even the functionality itself is less-error prone when using an MDD approach, because meaningful validations can be executed on the high-level models. When using traditional programming languages you will have some syntax checking in your IDE and maybe even some static code analyzers. However, due to the generality of the programming language this does not really help you to avoid functional errors.

When using an MDD approach domain-specific validations can be executed at design-time. The resulting error message can be domain-specific too. See for example this article on the static verification of a textual DSL. In the Mendix modeling environment we use real-time consistency checking to ensure that the model is consistent and can be executed by the runtime environment.

6. MDD results in software being less sensitive to changes in personnel

When using an MDD approach the resulting software will be less sensitive for changes in personnel. As you do not need a technical specialist anymore to build software you can draw from a larger pool of people. Furthermore, if someone joins a project it is far easier to understand the high-level model of the software application compared to trying to understand the behavior of the application by reading source code.

7. MDD empowers domain experts

MDD enforces a separation of concerns and skills. Domain experts can focus on modeling the domain, while technical specialist focus on building the tools needed for MDD (see also point 8). Building complex applications is not only for ‘elite’ programmers anymore. MDD can introduce suitable notations (e.g. textual, graphical, tabular) to empower domain experts. They can model a software solution by translating their knowledge of the domain into a high-level model.

8. MDD lets advanced programmers focus on the hard stuff

In MDD, advanced developers do far less repetitive work. They can focus on the creative aspects of their work. They can focus, for example, on building the MDD tools. They can also mentor junior developers or domain experts, or they can pick up the hard parts of application building. A domain expert can for example model the graphical user interface, processes and business rules. The integration parts of the application (using webservices, API calls, database integration, etc.) can be too difficult or technical for domain experts. Programmers can focus on this kind of tasks as part of the project team.

9. MDD bridges the gap between business and IT

Business-IT alignment is a returning item when talking about building software. MDD can bring business and IT closer together in the following ways:

Domain experts (or business analysts) are directly involved in the development process (see also point 7).

IT (a software application) is defined on a much higher-level. The models are as much as possible declarative and defined in domain concepts.

As MDD is faster (see point 1) software can be build in shorter iterations and therefore have a better fit-for-purpose (due to fast feedback of the business / end-users).

By defining explicit transformations between a model of an organization and a model of an IT system. For example by using a framework for model-driven SOA.

10. MDD results in software being less sensitive to changes in business requirements

One of the problems of software development is that business requirements often change faster than the supporting software systems. In a previous article I stated: it is questionable whether enterprises can actually maintain a focused strategy long enough to align their core business processes with IT. The current dynamic business environments do not give enterprises that time.

However, MDD can provide a solution because it makes software development faster (see point 1), it also leads to easier to change applications (due to point 2 and 6). If there is an explicit link between business requirements and the model of the software application it is even possible to propagate part of the changes automatically (see also point 9).

11. MDD results in software being less sensitive to changes in technology

Technology changes follow each other faster and faster. Think about things like Java EE, SOA / SOBA, webservices, REST, SCA, OSGi, and more recently restrictions in technology when moving applications to the cloud (e.g. other database structures). MDD makes sure you do not have to change your application model when you want to migrate your application to other technologies. The only thing which needs to change is the code generator (or interpreter). After changing the code generator (or adding additional code generating options) all application models can directly be transformed into code for the new technology.

12. MDD really enforces architecture

Companies often define architecture principles. Software applications have to comply with these principles, but how to check or enforce compliance when all code is created by hand? When using MDD software applications are guaranteed to comply with the chosen architecture. You can really standardize your IT landscape because architecture principles are enforced in the MDD tools. See also this article about the relation of Model Driven Engineering and architecture.

In general, functional architecture principles guide function design. These principles are reflected in the domain specific languages used in your MDD approach. They also condition the model validations (see also point 5). Constructional architecture principles guide construction design and are reflected in the code generator or interpreter.

13. MDD captures domain knowledge

The nice thing about MDD is that you are not only creating software, but you are also capturing domain knowledge in formal, high-level models. In most cases this knowledge is not explicit and you need to talk with people in the domain or let different people in the domain work together on describing their knowledge with formal models. In this context there is a strong relation between MDD and Domain Driven Design (DDD).

14. MDD provides up-to-date documentation

When using MDD you will not suffer from incomplete or outdated documentation, because the model is the documentation. When using the right abstractions, the models are readable for domain experts and business owners. This point is of course related to point 13.

15. MDD enables to focus on business problems instead of technology

Building on the previous fourteen points we can state that MDD allows you to focus on business problems and how to solve these problems using IT, instead of focusing on technology. So, stop discussing whether you should use WS-* or REST (or any other technology discussion) and start using MDD to deliver business value fast.

If you really think the list provided above is totally unrealistic and just an unbalanced promotion of MDD, you can read the following articles for some counter-balance:

15 Comments Added

MDD results in software being less sensitive for changes in personnel No it doesn’t. Organizations still need people who can work with their MDD tool of choice, and more importantly, people who know the model. I’d even go as far as to argue that the "pool of people" you can draw talent from is actually smaller because there simply is not enough people with relevant MDD tool skills out there. Furthermore, as you anyway need people with the right programming mindset, you really can’t get leverage pure domain experts either. Using a modeling tool to do the programming doesn’t take away the inherent complexity of software development. Pretending that it’s okay for people who are not trained in software development to write code just leads to insanely complex (and crappy) legacy code (see the vast amounts of copy-paste legacy COBOL code out there for reference) [1]. My main frustration with MDD advocates is that they completely ignore the fact that programming _is_ a human activity [2] and that none of us have the brainpower to manage the full complexity of any medium or large sized software project. Yes, using higher abstraction levels are desirable for lot of the software that’s being developed, but trying to hide the reality of computer software under the rug is not helpful because law of leaky abstractions [3] will bite you every time. [1] http://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD540.html [2] http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html [3] http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Hi “Anonymous”, thanks for your detailed reply! I agree with you that MDD does not solve all problems. You are right: abstractions are leaky, and you will need IT knowledge sometimes. That’s why I state in point 7 that MDD enforces a separation of concerns and skills. Domain experts can be involved in software development, more than compared to using programming languages. As I state in point 8, you will still need some technical experts doing the hard stuff. However, in my experience, MDD really changes the needed skills in a project team. Instead of a project team consisting of programmers you will have a project team which consists for 75% of domain experts and 25% of programmers (these are numbers from real-life projects).

Hi Johan,Domain experts can be involved in software development, more than compared to using programming languages. As I state in point 8, you will still need some technical experts doing the hard stuff. I think you are still missing the point here: yes, having more domain knowledge in a team is good but that does not mean the "pool of developers" is bigger. Those domain experts _still_ need to know the *model* to be productive. The domain experts also need technical know-how due to the "law of leaky abstractions". If you try to "outsource" technical knowledge to 25% of the team, you are creating a bottleneck for the team. You’re also _increasing_ the technical risk as 75% of the team are more or less incapable of doing any meaningful work when they hit technical problems (and vice versa for "business problems"). So I am arguing that the "MDD gives you a bigger pool of developers" is a pipe dream and ignores reality. I am also arguing that programming on higher abstraction levels is actually _harder_, not easier because of the law of leaky abstractions and because it allows you to create abstractions that are totally incomprehensible to other people. And that’s why I think that the proposition of MDD that it makes development _easier_ is fundamentally flawed. It might make development more *efficient* for certain class of software projects with the right set of people but so do domain specific languages (DSL). The difference is that DSLs don’t require costly proprietary tools (with vendor lock-in) and they don’t try to hide the ugly reality under the rug. I can understand why MDD is a tempting idea for the "programming is hard, lets go shopping" type of executives that make the decision to buy such tools but I really don’t see why any serious software developer would choose MDD over an expressive programming environment (Haskell and Scala come to mind) where you can create your own DSL.

Hi “Anonymous”, First a small clarification: I see DSLs as part of MDD. The models in MDD are defined in a certain language, preferably DSLs. See also this article on MDD/MDE tools: http://www.theenterprisearchitect.eu/archive/2009/02/18/model-driven-engineering-tools-compared-on-user-activities which compares DSL tools with Model-Driven Software Factories ("costly proprietary tools" as you call them ;). In that article I also try to give some considerations when to build your own DSLs and when to use a MDSF. The idea in MDD is to search for abstraction which are as close as possible to the domain you’re developing a software solution for. In that case the domain experts can understand the models. Abstractions are indeed leaky, but leaky doesn’t mean that all team members need the same know-how as without using abstractions. It means: don’t think everything is easy and be prepared that at some times during the project you will need expertise on a lower abstraction level. It is certainly not my goal to present MDD as the silver-bullet or one-size-fits-all solution. In this article I focused on the possible advantages, but don’t miss the more critical articles listed at the end of this article.

Now that’s an interesting discussion, it completely draws my attention away from the actual blog post… Anonymous, Johan tried to explain what he sees as MDD, might be useful if you tell us what you think is MDD. From your reaction I gather that you may have missed some recent and less recent developments in MDD. You say that you prefer Scala or Haskell over MDD, because you can build your own DSLs there. That is true, but most of the MDD tools that Johan has in mind, and that a lot of people are working on and with (XText, MetaEdit+, DSL Tools,MPS, Intentional, MS-M, and even some UML tools) are doing exactly that: they allow you to create your own graphical, textual and/or programming language derived DSL and build your code from that. With tools like Xtext or ME+ you can really have domain experts write software by ‘declaring’ using these DSLs, without having to write a single line of programming language code. But, I have to agree with Johan, MDD and DSLs are not a silver-bullet, although they have quite a few advantages (see the 15 Johan listed) over what we have been doing for far too long in software development. If he were still around, I think even dear Edsger would have been able to appreciate some of the new ideas, despite their remoteness from his mathematically founded approach.

Should it be of interest, I have an HRM domain object model "starter li" that I have licensed widely to HRM software vendors and BPO providers. More details can be found here http://infullbloom.us/wp-content/uploads/2009/11/busmodlt11102009.pdf I’ve been an outspoken proponent of models-driven development in HRM for 20+ years and found the discussion here of great interest.

Hi Johan, thank you for this list. If you had not written it I would have. Though I have already often worked with mdd and dsls I share the doubts that Anonymous has. I made the experience that sometimes these higher level models that should be an abstraction with less complexitiy also become very complex. I think that this is the ‘fascination for complexity’ syndrome, which is dangerous for the success of a software project. So it needs realy good architects to do MDD at the high level. If this is done correctly MDD has gread advantages. Svenja

Search

Search for:

About

I’m Johan den Haan, CTO at Mendix. I am interested in a lot of things, but I mainly blog about model driven software development (MDE, MDD, DSL), cloud-related topics like Platform-as-a-Service (PaaS), and the combination of these topics.I also have a passion for building products, product management, and shaping great engineering teams.This blog is personal, all opinions are mine and should be taken with a pinch of salt.