Article: 8 Reasons Why Model-Driven Approaches (will) Fail

As I know, MDA and MDD are different things. MDA - Model Driven Approach - focus on something like model-translation (especially from independent form to a platform specific one), and MDD has its place in Domain Driven Design context (see Eric Evans book) and is more like a software design approach and NOT a "model-translation" technique ...

MDA (as defined by the OMG) also focusses on domain models. They define a CIM (computation independent model) which should be transformed into a PIM, which on its turn should be translated into a PSM. Problem is that a lot of definitions are going around, which is very confusing.



As I said in the introduction, I prefer the term MDE, but in principle all definitions have commonalities, e.g. model the domain and translate that model into working software. The important questions are: how to define such models and how to make them executable. I hope this article gives some thoughts as a starting point for answering these questions.

Good analysis, for the most part. However, you make this statement

The language should offer graphical constructs in the cases that the concepts represented are more concise and intuitive in graphical form compared to a textual one;

• 1) While diagrams are great for capturing the "gestalt" of a design, none of the graphical languages I have seen can capture the details of programs except in very tedious ways, which leads to the observation that...


• 2) Textual representations are inherently more productive to use by the developer and also by tools.

I think we should separate at least two different roles in working with modeling tools: developers and business/domain experts.



For developers textual DSL's are in most cases more productive. For domain experts I think graphical DSL's can be very useful, by example for modelling workflows, GUI's or a domain model (the information objects). In these cases graphical models can give more insight and the models can be more easy to understand.



I do agree with you that graphical models shouldn't be used for each DSL. DSL's aimed at more technical parts of an application (like validation rules, queries, etc.) should make use of textual DSL's.

Johan,

Good article (if a bit dense for those of us trying to learn the concepts). You mention the importance of tooling, but no actual tools. Is there a resource you would recommend that can serve as an unbiased introduction to what tools currently exist? My primary environment is .Net/SQL Server, however am branching out into Ruby et al.

I really enjoyed this article, so thank you Johan! I think your article does a great job of discussing the current state of the MDx stuff. My take on modeling is that it is too complicated for all but larger projects/companies. Only they can afford to make the investment of time, expertise, and tooling.

To your last point in your article, our company is making tools to address many of the shortcomings you mention (although some of those features are still one to two years out on our roadmap). Over the next few weeks, I will be blogging about our approach to MDx, which is meant to give developers a streamlined modeling, generation, and custom coding experience along with a deeper dive if you so choose. You can check us out at AppVenture.com and read our blog. We just launched, so the content will be there soon.

My recent experiences have confirmed to me the dramatic improvements in productivity and maintainability that can be achieved by using a model driven environment... but we don't model the OBJECTS - we model the PROCESS.

I know this isn't applicable to all domains, but if you are implementing managed business processes you'd be foolish not to use a modelling environment.

As to your point about tooling... It's only a matter of time.

My take on modeling is that it is too complicated for all but larger projects/companies. Only they can afford to make the investment of time, expertise, and tooling.

To John: Technically, I've always heard approaches where the processes are the focus point of the development as being the anti-thesis of model driven approaches. Like, its polar opposite. Sure, you can twist the "real" model driven approaches to make it work, but in the end, its not really MDA/MDD.

And its why it works so darn well :)

Francois...

And its why it works so darn well :)

At one time folks thought that GUI screen designers were a bad idea... but now most folks would agree that they have their place.

New approaches won't be as "supported by tools" as the established approaches (in the beginning)... but if they are good approaches they'll rapidly catch up.

Is it just me or is this article an infomercial for Mendix's stuff?

Definitely this article emphasis on how MDA/MDD can fail. But I have been working on projects where MDA has been successful. It depends on what we are supposed to do with tools available on hand. All tools (Custom DSLs) have their own limitations. If a project has enough expertise and the learning curve is less for MDD, then that project can be successful. How many projects use the tools they have to the full potential. Again, a success of a project is mostly depended on people (Stake Holders and Good Architects) who know their stuff and limitations and managing the scope and changes. Tools play a role to a small extent in supporting architects and developers implementing the solution.

Is it just me or is this article an infomercial for Mendix's stuff?

I have worked on several projects where MDE has been successful - albeit with varying degrees.

In essense, MDD (or MDE or MDA - choose your pick) is all about raising the level of abstraction, and abstractions when used judiciously lead to less clutter in specification. But, MDE is not a panacea. Good design, sound architecture and common sense play as much a role in development using MDE as in traditional style. In fact, more, as mistakes introduced at a higher level of abstraction can be costlier. But, MDE can help detect mistakes early and help prevent some from occuring altogether. Moreover, being inherently better structured, models are more amenable for analysis, verification and translation to an execution platform of choice. Therein, I think, lies the true value of MDE.

> DSL's aimed at more technical parts of an application (like validation rules, queries, etc.) should make use of textual DSL's.

I tend to agree, if you take 'technical' in the broadest sense. I've recently seen an example of a textual DSL created for use by payroll experts. It's a textual language that helps them create formulae to calculate salaries based on tax rules, insurance policies, union agreements and so on. It's not coding (they're not software people), and it's hard to make graphical - but it is technical from their point of view.

Dear Author, If you are available. Kindly provide me the validity of these conclusions and your current thinking about Model Driven Software Engineering.
As you wrote this article at 2008 and now it is 2016 (8 years are gone)
Thank you.