15 Reasons for Model Driven Software Development (MDD)

In this text MDD is a synonym for  MDE in the context of software engineering.

There are a lot of good books and articles about MDD which describe the different technical approaches and dependencies (http://modeling-languages.com/list-mddmda-books/). But I would like to cite some reasons why you should start using model driven software development. The reasons are written down by Johan den Haan, CTO at Mendix, in 2009. ( http://www.theenterprisearchitect.eu/blog/2009/11/25/15-reasons-why-you-should-start-using-model-driven-development/). He stated those reasons several years ago, but they still give a good overview of the advantages of switching your software development paradigma to MDD. I embed the reasons, so that they cannot vanish from the internet and I can include some comments. All kudos go to Johan den Haan!

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. […]

There is still a lot of discussion about the upfront effort in analysis, design and modeling. Experience shows that using the right tools the MDD approach scales very good and the advantages of model-driven code generation and enhanced code quality exceed the additional analysis and design effort.

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.

There we have to make a difference between the development of small solutions and programming in the large with multi-million lines of code. Currently MDD in a complex context depends on the modeling skills of some expert team members. Some aspect can be compensated by the development tools and framework, but in real-life scenarios the efficiency and maintainability of the resulting software product/solution depends heaviliy on the experience and know-how of the domain-modeling and code generation specialists.

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.

But remember, „a fool with a tool is still a fool“

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.

But if a detail functionality is missing, you have sometimes to call the experts to solve the problem on the tool level not the solution level.

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. [..]

Be aware of the additional effort for encoding the domain knowledge into vallidation rules!

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.

This is the primary show stopper / road block for MDD! The power is taken from the individual to the organisation and from the developer to the business expert (see 7).

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.

Be aware of a potential MDD tool vendor lock-in!

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.

But what’s about the not so advanced programmers? They are threatended by MDD. In some cases the expertise of some application developers, database designers becomes obsolete!

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.

As long as there is no general standard for MDD tools, the resulting software solution depends on the functionality of the MDD framework and can only be migrated to an new runtime platform or technology if the tool vendor supports the new target environment.

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.