Why there is no future for Model Driven Development
Last week I visited Nantes to do an invited talk about Model Driven Development. I had a great time in France and met a lot of interesting people. The theme of my presentation was "Why there is no future for Model Driven Development", but I started my presentation by talking about the story of trying to fix a business agility problem using Model Driven Development. I also shared some lessons learned in building a Model Driven Software Factory and lessons learned in designing and growing Domain Specific Languages.
In this post I want to explain to you, using five practical examples, how I came to the conclusion that there is no future for Model Driven Development (MDD). I also included the video and slides of my presentation.
What do you think about the future of software development? Is there a future for MDD? Join the discussion in the comments!
The video of my talk
1. Development isn’t the difficult part, the challenge is to translate a business problem into a solution (model)
The other day a user of our platform requested a couple of new features regarding our presentation layer. As root cause analysis is step one in handling a feature request, I asked him why he needed these features. After discovering his needs based on the needs of his customer I proposed another way of modeling the user interface which was possible in the current version of the platform and we agreed it would also create a better user experience. However, he still insisted on the features because he couldn’t change the user interface because his customer had signed-off on the mock-ups.
They idea of MDD is to limit the flexibility in favor of simplicity and productivity. Hence, it isn’t possible to create everything you want. However, this is almost never a problem, unless you use a waterfall approach as described in the example. In fact, in the example a lack of flexibility wasn’t the problem (the solution provided by the platform was much better than the initial idea), elements outside the tool were the problem. It did lead me to the conclusion that if your MDD tool reaches a certain level, development isn’t the difficult part anymore. Once you have a model you’re only left with a one-click deploy to create the final application. The challenging part however, is to turn ideas and/or business problems into such a model.
Important elements in this process are requirements gathering and project management. In my opinion the benefits of MDD are strongly connected to the use of an agile approach. MDD and agile are a happy couple. Due to the use of high(er) level models MDD enables close collaboration with the "customer". MDD also enables very short iterations because much of the development process is automated. MDD without agile doesn’t reach its full potential.
2. Development isn’t the slowest part of developing software, deploying and taking it into production is
Once we did a fixed price, fixed date project. We promised to deliver a full-blown application for a big customer within three months. No problem… we modeled the application within 2 months. Then the application needed to be moved to production. That’s where the problems started. We needed a server to deploy the application on… we needed to contact system administration and IT guys started to talk about corporate policies, security, reference architectures, ordering new hardware, etc. In the end it took another 2 months to actually move the application to production!
I’m not saying all these things like policies, security, and reference architectures are not needed, don’t get me wrong. The problem however is: if your MDD tool reaches a certain level, development isn’t the slowest part of developing software anymore, deploying and taking it into production is. MDD can’t help you out here. You’ll need to think about automating all kinds of things like builds and deployment. You’ll need to look at the possibilities of cloud deployment and Model-Execution-as-a-Service.
3. Being able to change software is more important than building it in a fast way
When we started to sell our platform a couple of years ago, we did build an application to support our own sales guys. The application was a seamless fit to the actual business process and we did have happy users. However, we did grow global. After a while we discovered that new people did not use the application and existing users started to complain about it. The problem? The environment had changed, the application didn’t fit the processes anymore. Just a little example: you’ll need multiple currency types if you operate globally.
The important lesson is: agile businesses ask for agile software. A changing environment asks for changes in the software supporting the processes in that environment. Software doesn’t need to be built once, it needs to evolve and grow during its lifetime. Furthermore, version one of an application is mainly released to start getting feedback from users. You will only start learning the real wishes for a piece of software if people start using it.
This led me to the conclusion that we need Model-Driven Evolution in addition to Model-Driven Development.
4. From an economic perspective MDD doesn’t matter that much
As a follow-up on the previous point we can look at the money spent at software maintenance as compared to software development costs. Several studies (e.g. , ) show that more than 90% of the total cost of software ownership are spent at software maintenance. Software maintenance is defined as: software cost devoted to system maintenance and evolution.
This means that software development costs only comprise the smaller portion of the total cost of software ownership, maintenance / evolution costs are the bigger portion. Hence, pure MDD doesn’t matter that much from an economic perspective.
Note that I’m not saying that MDD doesn’t have any value at all. There are a lot of reasons to start using MDD, among them is the faster time-to-market for new products dependent on new software. However, maybe the economics have less impact than we hope.
5. MDD is a technology enabler, it does not have business value
If you have experience in selling a software development tool you probably recognize the fact that it isn’t an easy sell. Especially if you talk to IT departments and your message is that less people are needed and less-technical people are needed to build software. That’s why our initial success depended on selling to business people. They did like live demonstrations during a sales conversation, showing them how to fix their business problems with a fast and flexible development environment. We didn’t talk that much about technology.
When thinking about your MDD solution you have to think about the customers you want to target. What is your market? Who wants to pay for your MDD solution? In my opinion MDD is a solution for a software development problem, it doesn’t have value itself (from a business perspective). You can of course translate the result of using MDD in business value, especially in more agility for the business (the don’t have to wait for new software when they want to change the business). However, this business agility thing isn’t reached by MDD itself. We need more…
I described five situations in which MDD didn’t help us out. Do these five points lead us to the conclusion that there is no future for Model Driven Development?
I don’t think so… It means that if we do MDD in a proper way we will get new challenges. Model Driven Development is necessary, but not sufficient!
We need to focus on the full application lifecycle. We need to support the requirements gathering process. We need to translate requirements into models and deploy these models in an easy way. Once an application is deployed we need to gather feedback from users and translate this feedback into new requirements, create a new model version, and deploy a new version of the application. What we need is Agile Application Lifecycle Management.
 Erlikh, L. (2000). "Leveraging legacy system dollars for E-business". (IEEE) IT Pro, May/June 2000, 17-23.
 Moad, J. (1990). "Maintaining the competitive edge". Datamation 61-62, 64, 66.