Featured in
Architecture & Design

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Operations & Infrastructure

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Enterprise Architecture

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

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

Model-Driven approaches have been used for several decades now. Over the last 10 years we have experienced an acceleration of the development of a strong theoretical background, frameworks and tools dedicated to Model-Driven-Engineering (MDE). Yet, MDE is difficult and projects yield sometimes disappointing results. Fernando Cardenas comments:

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.

I worked on modeling tools in a previous life and quickly realized that attempting to write software with graphical tools is misguided, for the following reasons:

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

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

I found the second point to be true even if I didn't attempt to capture all the details of methods, for example, in diagrams. I still "model", but using high-level DSL's in whatever programming language I happen to be using (Ruby, Java, Scala, ...).

Are you using model-driven approaches in your organization? what are your conclusions? Do you prefer graphical tools or general purpose languages?

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.

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;

I worked on modeling tools in a previous life and quickly realized that attempting to write software with graphical tools is misguided, for the following reasons:

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 found the second point to be true even if I didn't attempt to capture all the details of methods, for example, in diagrams.I still "model", but using high-level DSL's in whatever programming language I happen to be using (Ruby, Java, Scala, ...).

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.

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.

If you model the wrong thing you're starting with 2 strikes against you.
by
John Reynolds

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.

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.

That's exactly why we at Mendix created an MDE platform for Service-Oriented Business Applications - SOBA. I think building your own DSL's and combining them into a software factory will cost you a lot of effort which can only be paided back when using it multiple times for different projects.

Re: If you model the wrong thing you're starting with 2 strikes against you
by
Francois Ward

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.

Re: If you model the wrong thing you're starting with 2 strikes against you
by
John Reynolds

Francois...

And its why it works so darn well :)

Yes indeed... and it point out that Graphical Programming is the best way to approach specific aspects of a project. Process diagrams are one example... Page Flow is another.Graphic Only programming may fail... but in many cases Text Only programming is just plain dumb.

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.

MDA is good if we understand its limitations and advantages
by
Kalyan Lanka

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.

Re: MDA is good if we understand its limitations and advantages
by
Vinay Kulkarni

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.