Model Driven approaches have been around for years. There are a multitude of tools, from the venerable MetaEdit or the recently open-sourced BridgePoint to newer entrants such as Mendix. There are parsers, generators, transformation tools, language workbenches and meta (-meta…) models galore.
And the opportunity has never been greater. The technology landscape is evolving at an ever-quickening pace: HTML5, the multitude of javascript libraries; the many and varied SQL/NoSQL storage options; multi-core; physical and virtual machines, on premise and in the cloud. A developer could easily spend twice their available working time just trying to keep up with the myriad technology choices available.
And there’s no reduction in the number of problems to be solved; as Marc Andreessen observed back in 2011, Software is eating the world.
Model-driven approaches promise a cleaner separation of problem domain and technology infrastructure. That enables us to divide – and so more easily conquer – the twin challenges they present.
So there’s a litany of tools; the problems are growing; and MDx should be able to address the challenges more effectively than mainstream approaches. MDx must be the hottest ticket on the software planet then, right? Right?
Ahh. No. Despite all that, MDx remains a backwater in the global software development world. It’s had brief moments in the sun, for example the OMG’s (in)famous Model-Driven Architecture(MDA) and the more recent interest in Domain-Specific Languages. But they’ve been no more than flurries; light snow showers while the big storms made the news elsewhere.
Why should that be? Attend any gathering of model driven people and there’ll be a mixture of perplexity and a slightly aloof suspicion it’s because the “Muggles can’t abstract”. Joe-Blue-Collar-Programmer just doesn’t see the elegance and beauty in the rarified Model Driven world. And so the disciples resolve to conceive ever more cleverness; new metamodels, projectional/graphical/web editors and the like. And a year later they all meet up again; and MDx still hasn’t taken off; rinse and repeat.
As Albert Einstein reputedly said (or perhaps didn’t): insanity is doing the same thing over and over again and expecting different results.
What’s Wrong?
So what are we missing in the MDx community? There may be several factors. But two stand out above all the others:
- We forgot why we model;
- We forgot who models.
These are kind of important. In fact, stark-raving fundamentally critical. No wonder we’re in a pickle.
I’ll look at each in the next couple of posts.
Software Architect and Developer with a deep interest in building better software faster. Long time advocate of model driven techniques.
Very nice! I look forward to the next posts.
I really appreciate the questions you ask at the end of your post. In particular the one about “who models”. My suspicion based on personal observation and talking to a few people (i.e. no strong evidence available) is that a whole lot of knowledge-workers model using languages that are familiar to us. What they are not doing, however, is trying to program a computer – which is where a lot of research in our community is directed. Maybe other research communities can help them, or maybe it should be us.
Shameless plug: for some time now, the research group I am part of has been running a survey on why people model, and it is still open – http://tinyurl.com/MU-survey-2014
IMO there is nothing wrong, and little missing in Model Driven Development. Npwdays it is pretty easy to use the techniques for anybody that has taken some time to lean the releavant disciplines. Actually, anybody can Do It Yourself in a snap – no limitations on tools, standards or vendors.
The issues always arise when somebody tries to use Model Driven Development as a flagship, branding or drive a business line or academical career on it alone.
Good article and relevant questions.
I share the view of Antonio.
Related to question 1, model (and MDx) is just a tool/mechanism to do something and not a value itself. When used correctly (proper language, tool, generator) it is possible to get significant improvements in productivity, quality etc. There are a lot of examples on these on wide variety of domains (e.g. http://www.dsmforum.org/cases.html). Typically then domain-specific languages are used and since they are special for a narrow area of interest they never get attention of the masses.
Related to question 2, I see that large portion, perhaps the majority of modeling that produces some formal outcomes (code, config, test, simulation, interaction design, prototyping, analysis for safety/performance etc.) is done by non-programmers. Programmers can also do formal modeling, but I don’t see how modeling approaches where the modeling language is at the same level of abstraction than the code could work. Why programmer would create class diagrams when they can do already the same in a programming language? Instead, if a model allows raising the level of abstraction (and still generates the code, config etc.) it then also answers the first question.
Dear all, belated thanks for your comments. I’ve tried to address questions in the follow up which should appear shortly.