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. [1], [2]) 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…

Conclusion

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.

Hi Johan, I am not sure it is accurate to exclude maintenance from “software development”. I see maintenance/evolution as an integral part of development. On that note, it seems you suggest MDD is only valuable for creating new systems, but not maintaining/evolving existing ones. Did I misread you? If I didn’t, why do you believe so?

Hi Rui, I love trick questions 😉 I think it does mean Mendix has been pretty succesful with MDD, but that we discovered along the way that we need more than just MDD to deliver customer value. That’s why we enable one-click cloud deployment and a community appstore to enable easier problem solving with pre-built templates. And we’re of course building new stuff continuously

Hi Rafael,>I am not sure it is accurate to exclude maintenance from â€œsoftware developmentâ€. I see maintenance/evolution as an integral part of development. On that note, it seems you suggest MDD is only valuable for creating new systems, but not maintaining/evolving existing ones. Did I misread you? If I didnâ€™t, why do you believe so? I mostly distinguish between software development and software engineering, the latter including elements like requirements gathering, maintenance, and evolution. However, that’s just semantics… I’m not saying model-driven techniques are only valuable for creating new systems. I think MDD is (in most cases) too much focused on creating new system, focused on the development part only. But… I think we’re on a turning point. As MDD is becoming mature it’s time to look at other aspects of software engineering. We should use model-driven techniques to support all phases of an application lifecycle. Cloud deployment, models at runtime, and the combination with agile project approaches will help a lot to reach the full potential of Model Driven Development (or Engineering if you want 😉 ).

Excellent presentation buildup and conclusion Johan! I agree completely on Agile Application Lifecycle Management, whatever form it may take. Speaking of the form, IMO MDE is bound to split in the future into two areas: 1) process analysis and optimization (about business value) 2) process automation (technical solutions: software factories, etc..) The former is currently a minor and implicit activity in MDE, while the latter is the mainstream focus. (IMO this disbalance between the two is the main reason why MDE adoption is so slow). I believe the former also has its own USP due to its traditional focus on strongly creative activities (e.g. design, programming). Where will the former go? I see a lot of synergy with BPM. How will it be called? Perhaps Agile Application Lifecycle Management

Hi Johan, I think MDD does have value for maintenance. In my opinion, modeled software usually has a much shallower learning curve as general / non-modeled software does, even if the latter has a supposedly vanilla architecture or even up-to-date documentation (yeah right, as if…). The model has a level of abstraction that’s much closer to the actual functionality than any low-level / old-fashioned implementation, which allows you to make understanding the software architecture a much easier second step of the hand-over. Furthermore, when using generation, the generated code is typically much more consistent than hand-crafted code, making things easier to understand, to keep in check and aligned with the architecture as well. All in all, the hand-over is much easier and most of the adaptive maintenance can be done through the model anyhow. The problem is that, typically, there’s no software architect and / or MDD expert involved with maintenance, so that evolution of the modeling language or a meaningful application of that might not always be feasible. The danger is then that MDD is abandoned altogether, e.g. sticking with the last-generated code base and adding the usual "pustules" from there.

Hi Meinte, Thanks for your detailed explanation. I agree with you that MDD has value for maintenance, especially in comparison with traditional software development. My point in the article / presentation is that we need more than just MDD to have an answer to the business agility requirements of a modern organization. We need flexibility / agility in the full application lifecycle.

MDD is not dead, it was just reborn for good. We cracked the puzzle for software development. In short, MDD done with XML Schemas as architectural models, flexible DSL based on schemas and code generators (all in sync, source code branchable/mergeable) allow (finally) true option to raise abstraction without sacrificing any productivity. This is reality now, will reform the entire software industry.http://abstraction.codeplex.com/documentation Current tool usage use existing standard tools on Visual Studio 2008/2010, relatively trivial to build on any other platform as well. Happy new year 2011, Kalle

Hi Johan, Two of the most important benefits coming from MDSD/MDE (as explicitly put by MDA) are related to business agility: – customer engagement in the requirements gathering, by having them describing their business needs through domain-specific languages. Theory and practice within the fields of software product lines, language-oriented programming and intentional programing give prove of that -IMHO, paradigms very interwoven with MDE from which the latter takes inspiration. – reuse of software development artifacts and design decisions by “touching” just those that describe the features to be changed. Changes are addressed at the right level of abstraction and/or concern (where those features are described), modifying just a small subset of design decisions and having the rest of the them automatically re-applied (reused). So I must disagree with several of your premises to say MDSD/MDE is dead. I’d rather say: bad MDE is dead. Bests Orlando

Hi Orlando, Thanks for explaining these benefits. I agree with them. I think we reached the same conclusion (MDD isn’t dead), as you can see in the conclusion of my article: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!

Hi Johan, I agree with that: “Model Driven Development is necessary, but not sufficient”. Another way to see it, as you put it: “MDD is a technology enabler”. MDD is a catalyzer, something that makes other things like reuse, separation of concerns (information hiding) and abstraction (step-wise refinement) happen in the best way. It is a paradigm for making all steps of a software process integrate and repeatable as much as possible. But we still need methods, concepts and technology from fields such as enterprise (business + technical) architecture, software product lines, software process engineering, requirements engineering, quality management, testing, integration, deployment, … holes that MDD can help to fill up. In your presentation you speak about “pure” MDD; If you mean straightforward or simple (naive) MDD, I must agree that it doesn’t help much, at least in an industrial setting. Creating a new DSL and the corresponding generator doesn’t seem to help much unless you integrate such an effort within the broader architecture effort, and combine it with frameworks, components, … technologies. Thank you for your presentation Johan: It reminds us what role MDD plays in the software engineering picture, for its defenders as well as detractors: MDD is the mean, not the end. Very fruitful and all too often forgotten reflexion. Bests Orlando

Then use CASE tools if you want requirement and deployment and everything fully automated (back to old time). If I am right MDD is supposed to help in design and implementation stage of the software development.

Nice article. As a product company that uses an Underlying MDD platform we learnt the value of life cycle management as we kept releasing newer versions of the products on it. It required rigid discipline not to veer off our own MDD platform to a complex code base, but its worth it. Now for us, just as Development life cycle costs have come down, so have maintenance life cycle costs have come down. Since maintenance costs are 90% today, and if that can come down, MDD does have a major impact on economics of software development and maintenance. It is definitely the future. Yes life cycle capability is a prerequisite.http://www.KServehrms.com and KServeOnline.com was built using an MDD.

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.