According to this InfoQ article , Gartner’s believes that the technology “Model Driven Architectures” is still Sliding Into the Trough viewed from the perspective of the hype cycle.
I beg to disagree. Instead I agree with Stephen J. Mellor that believes MDA is progressing through the Slope of enlightment.
I think MDE hit rock bottom a couple of years ago and that we are much better at knowing when and how to employ MDE to get out of it the benefits that were promised to us in the beginning.
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
I don’t think we should clump MDA and MDSD/MDE together: MDA is just the (very restricted, ivory-tower-styled) OMG’s version of MDSD, while MDE might be wider than just software.
Because of that, I think MDA never made it out of the Through, but I agree with you that MDSD (/MDE) might be (very slowly) climbing out of it. There’s still a lot of work to be done, though: because there’s always some “meta aspect” to doing MDSD -even if you have a vertical/technological-oriented modeling environment, you need to know about both the modeling as well as the technology which the modeling targets, whereas in traditional software development you only need to know about the latter- it’s always going to be harder, even if there are definite productivity gains to be had in the end.
On the other hand: code generation has been with us since almost the beginning of computers, so about half of MDSD already is a commodity of sorts – it’s just not included in any standard bag of tools.
I think a combination of tools which do not exhibit a plateaued hockey stick learning curve combined with a somewhat-general awareness of the “technique” of MDSD (as opposed to it being a development methodology of its own, next to or surpassing things like Agile, etc.) should go a long way.
I completely agree with not mixing together MDA and MDE (unfortunately, and strangely, Gartner only seems to acknolwedge the existence of MDA)
I totally agree with Meinte.
I can add that good (and simple) tooling is the one of the keys for a larger adoption of MDSD. But because MDSD is “too horizontal”, we need a vertical (ie. a specific, focused) application of MDSD. And this is the other key.
With AtomWeaver we’re trying now to build specific, vertical applications of MDSD through the availability of specific libraries. So, instead of disseminating the concept, then promoting its application, we’ll be trying to promote its application, learning the concept along the way as a consequence.
Just be careful as you go through the Slope of Enlightenment not to fall into the Cliff of Oblivion:
http://catenary.wordpress.com/2006/10/22/cheap-shots-at-the-gartner-hype-curve/
@Rui: totally agree – we need a clear demonstration (“poster child”) of the benefits of MDSD with the DSLs in play catering for a real life business domain instead of a “regular” technological domain (like “Web apps”).
In fact, such examples do exist but are not widely communicated (for strategic business reasons?): http://www.youtube.com/watch?v=UBI33yXJZxg http://www.infoq.com/presentations/intentional-software http://www.infoq.com/presentations/Intentional-Software-at-Work
Intentional Software has more-or-less gone underground, unfortunately, and are apparently doing a fair amount of government/DoD contracting which obviously is not going to see the light of day (from what I’ve heard a pixie tell me).
I agree that we need a poster child, but because each industry seems not to believe case studies from other industries (see Crossing The Chasm), we need several.
It would also be helpful to have a common format to make comparison and analysis easier. I propose:
Project:
Company:
Effort (People*Time):
Approach:
Tools:
Outcome:
Future:
or something. Then we _could_ have a unified resource….
tried to find a marketable case among the above videos. sorry, but couldn’t find any. perhaps due to a different understanding of what happens at the biz/IT borderline? and, how to define ‘success’ in ‘success story’ without such a common understanding in the first place?
|=
After having worked on http://www.dynamicalsoftware.com/mdsd/closure which is a domain specific MDSD that can import UML and not technically an MDA, I believe that I can profer a view that reconciles the two differing opinions on where MD* is in the hype cycle.
The ability to transfor models into code is an awesome way to accelerate time to market but only if it serves as a part of a larger and more strategic plan to reduce coding time by reusing already existing and previously debugged components and libraries. For example, projects using MDSD as a core asset in a software product line are on the slope of enlightenment.
IT vendors (which is what Gartner tracks) tend to make more money if they attempt to package and sell one-size-fits-all kitchen sink solutions. They tend to present MDSD as a silver bullet rather than a tool in the toolbox. Silver bullet MDSD is very much still sliding down the trough of disillusionment.
Good observation, Glenn.
I’m very much an advocate of introducing “MDSD in-the-small” to projects, rather than making your entire project MDSD from the get-go – which smells too much like MDA for my taste, anyway. Typically, projects have very project-specific “meta requirements”/non-functionals (such as a specific choice of technologies, architecture and conventions) and the one-size-fits-all solutions can’t -by their very nature- cater for such variability.
I rather pick parts (“low hanging fruit”) of an existing project that’s already underway to some extent and MDSD-ify these. By proving the benefits of MDSD for these parts, you gain traction for using MDSD for the rest of project, or at least parts where it makes sense. A logical contender for low hanging fruit is the data model, from which results database schema’s, O/RM configs, etc. Obviously, you need a generic MDSD tool (like Xtext + Xtend, but any combination of a meta modeling environment + templating tech for code generation) for this.