Thursday, April 23, 2009

How to explain EMF?

Have you ever tried to explain EMF to nonbelievers? I find it difficult to explain what EMF is and why it makes sense to use it. I had this a few times in my career:

  • In the mid 80ies when I started with object oriented programming. For procedural programmers (modula2/pascal/C/Fortran) it sounded like a lot of buzzwords and seemed to add no real value...
  • End of 80ies and in the beginning of the 90ies (before the GOF book was out), patterns seemed to be quite fuzzy and it was hard to explain what the value of describing "patterns" is.
  • Around the same time I discovered scripting languages (starting with (g)awk->TCL->perl and ending with python, which I used for a decade). It was hard to motivate why those "slow" languages are in any way useful.
  • Aspect oriented programming is still in the "hard to explain/motivate" phase.

The common pattern with those "hard to explain" new technologies is that they are incremental changes to existing stuff but once you understand and use them, they change the way you are thinking. If you adopt the "new technology" you feel a boost in productivity and you see better ways to solve old problems. The level of abstraction raises and you can focus more on the problem instead of dealing with low level implementation details (or reinventing the wheel). And then comes the time when you think all problems can be solved with the new "hammer"....

It is similar to converting to a new religion. For the believers it changes their life. It changes the way they see, experience and interact with the world. For the nonbelievers it looks like a stupid set of paradigms that make no sense. They learn how to block the arguments of missioners of the new religion and the more missionary the believers are the more skeptical the nonbelievers get.

So, how do you explain the benefit of EMF?
What is the best strategy to evangelize nonbelievers?
What is the best way to get the converts over the initial pain of change?

What are the typical questions and problems with EMF?
Here is a list of things I hear often:
Why to use EMF for my DSLs instead of some hand-written well tuned Java?
It generates lots of code and bloats my project.
EMF is so complicated, it takes a long time to learn -- in that time I have solved my problem twice without EMF.

What are scenarios where EMF increases productivity and where is it the wrong tool?

I have seen Peter Frieses talk at eclipsecon. I really liked it but I am not sure it helps nonbelievers to understand what EMF (and modeling in general) is. I think what is needed is a hands-on way with some real examples that show step by step how modeling and EMF can be applied to real problems.

I will post some of my experience with EMF in this blog in the next weeks and months.


  1. Hi Michael,

    you're touching a very important point here. Model driven technology in general and EMF in particular seem to have a high entry barrier and apparently provoke people's emotions, see this thread: and this comment:

    I agree we should come up with some decent ideas on how to tell people what the benefits of using MDSD and EMF are.

    Regarding the "Stupid Modeling" talk: I'm glad you liked it, but I also agree with you that it did not show the benefits of EMF. Though this has not been the original goal of the talk, we should consider changing the talk for the next iteration to address your concerns.

  2. Michael,

    I am really glad you are starting this discussion. I think EMF and some of the other Eclipse modeling technology are the hidden gems of the Eclipse community. EMF is used by a lot of people but as you said it is very hard to explain to newbies.

    I think a great starting point would be to identify some real world case studies of how people have used it. I would be happy to help write up these case studies and publish them on We need some volunteers to act as the subject of the case studies.

  3. I slightly disagree with Ian Skerret. Its not only hard to explain to newbies, its freaking hard to explain for people who already know something about it.

    EMF brings an amazing solution to the table. It *is* a perfect fit between MDSD and "rocks and sticks" (to quote Ed).

    But I have found the learning curve for EMF and associated technologies like oaw to be amazingly steep. Its like climbing a 500000 meter mountain, but the face of the mountain is 90 degree granite.

    I have often wondered if I'm just stupid because it takes me so long to understand it. But, I guess its obvious I'm not the only one (and misery loves company :-)

  4. Memory, you're not alone. EMF is not a trivial tool to learn to use well. It doesn't help that there are all these "extensions" like CDO, transactional EMF, EMF Query, Validation framework, etc.
    I've been living in it almost daily for 2 years and still don't know anything about half of them; even my EMF Core knowledge has gaps.
    As much as I respect the EMF dev teams, I think there is a real danger of getting out of touch with the reality of the hill that newbies must climb; that is not to say it is not worth the climb (for the right projects/needs), just that the climb has to be considered when considering usage of EMF.
    I agree that this is an excellent discussion to be having.

  5. I would recommend that you frame your thinking by separating your base question into two questions. How do I explain model based development and how do I explain EMF?

    I find that many people get the concepts and advantages of model based development, but when you suggest that EMF should be used you get a visceral "hell no" reaction. Now you could dismiss that reaction as the result of ignorance, but that would be doing everyone a disservice. In many cases that I've seen, these people have struggled with EMF (and perhaps misuse of EMF by others) at some point in the past that led them to formulate that opinion.

    I think one of the biggest problems with EMF that leads to complexity and high barriers to entry is the breadth of scope. Trying to be a solution for every modeling problem by its nature makes the technology more complex to learn and use. Every level of generality is a level of complexity. There is an inflection point where generalizing a technology further starts harming your existing usecases. I believe that EMF today is well past that point.

    Ultimately, people are not looking for a technology to use. They are looking for a solution that will make them more productive. EMF is like a box of legos. The base EMF is not a solution for many problems. It only becomes a solution when you put it together with a bunch of related blocks. The problem is that it is extremely difficult for any individual to know what all those blocks are and how to put them together. The end result is that putting together a non-trivial solution using EMF is difficult even for the experts.

    A problem that I see at Eclipse today is implication that anything modeling-related must be EMF-based. I would argue that it harms the Ecosystem by discouraging the growth of other modeling technologies that might provide a better solution for some sets of problems.

    Believer in modeling. Not a believer in EMF.

  6. Micheal,

    Good that you popped up this question. I think there are two slight variations:

    a) How to answer concrete questions regarding possible misconception of EMF or modeling. Ed's talk can serve as a starting point for answers:

    b) How to explain in general what EMF is good for. I think this is the more interesting question and we definetely need to find good answers. Only recently we started some similar discussions within the Eclipse modeling space and we should soon dedicate some formal and visible place to these discussions (Bugzilla?).

    For example we plan to provide better overview about the different modeling components we have at Eclipse and how they depend and interact. Something like a navigable web diagram or so.

    We also talked about providing real life case studies (ideally success stories :P), as well as real life-like example applications.

    This brings me to another important point I discussed with Ed. Modeling is still to tighly associated with Tooling and design time activity in many people's minds. We need to make Modeling more visible in the runtime space! For this purpose I'm going to propose the addition of something like cross references to the projects meta-data and the top-level projects web sites.

    I don't want to pretend that I'm particularly smart, but personally I never had problems in understanding what EMF can be used for or how to do it. Although I can remember a small number of customers who shared your opinion (is it yours?) that it is hard to adopt EMF I better remember those who understood the benefits pretty well, adopted it pretty quickly and who can't imagine since these times to get along without it. But again, I fully agree that we should do a betterjob in convincing and assisting the first group.

    I think one reason why it is so hard to explain the benefits is that EMF can be used (i.e. deliver value) in so many different ways. We need to clearly identify these ways and give dedicated answers for each of them, accompanied by dedicated example applications (the EXTLibrary example model is just not very helpful here) and success stories.


    Can you explain a bit more detailed, what exactly you mean by "It doesn't help that there are all these extensions like CDO, ..."? I know of many cases and users where CDO helps a lot :P

    I know for sure that my EMF Core knowledge has severe gaps. But this is only because I never felt a need to dive deeper into these particular areas. And I like it this way: Gather a quick overview of what's there so that you have a mental link for future problems and study it decently when you face one of these problems.


    I completely agree with you when you say Modeling and EMF should be separated in the context of this discussion. It's not EMF's responsibility to explain the benefits of modeling, though it could certainly help with the adoption of EMF as well ;-)

    Regarding your statement about generality creating complexity by itself I'm not sure if I can follow. You're certainly right by saying that EMF has a very general and broad scope. But this is not bad. Just the opposite is the case and there is evidence that many many users and companies realized this and are successfully using EMF in so many different ways. Nevertheless we should not forget those who have problems to see where it could fit!

    Finally, can you give an example of "other modeling technologies that might provide a better solution [than EMF]"?


  7. Eike:
    "Eric, Can you explain a bit more detailed, what exactly you mean by "It doesn't help that there are all these extensions like CDO, ..."? I know of many cases and users where CDO helps a lot :P"

    I did not say there was no value in CDO; my comment was in the context of the difficulty in learning EMF. EMF Core is enough to learn, then all of the extensions/sub-projects just make it more unapproachable to some people. Looked at together, it all can be very intimidating.

  8. Eric,

    I still don't understand your argument. It sounds a bit like someone who has no idea of software development but wants to solve a complex problem, looks at Java, realizes that he needs database persistence, too and complains, "Oh, all this is too complicated!" ;-)

    What does this whining add?


  9. I have to agree with the crowd in this case. The barrier to entry is awfully high for EMF and even though some developers claim to be comfortable with modeling tools, they don't know where to start with it.
    Where I work, there's this internally-developed application that could benefit highly from being reimplemented using EMF, but I was brushed off by the maintainer. I guess some people would rather develop and maintain domain models, schema-based persistence, and code generators from scratch. Rocks and sticks indeed.

  10. Eike,
    First, I'm going to assume that English is not your primary language and thus you don't understand the negative connotation that usually surrounds the word "whining." This is an open discussion and I'm pretty sure you don't mean to insult.
    In any case, your comments just reinforce my point that the people who are steeped in EMF don't quite "get" the intimidation of it when it is first approached. They've simply been working intimately with it for so long, they're too close to see the forest.
    To re-iterate, I'm not saying that there isn't value in what EMF and its various sub-projects/extensions can do; what I'm saying is that there is definitely a mountain to climb, and the first leg of that difficult journey is the question that Michael is posing here: how to tell the uninitiated someone what EMF is and why it might be able to help them.

  11. Eric,

    I'm glad that you pardon me for not being a native speaker!! In fact sometimes it's hard to know special connotations and I certainly do not want to insult anybody. As many of you know my only concern is the success of modeling where it should be successful.

    And I should have made it clearer that I didn't want to refer to only you. My point should have been that Michael raised an interesting and important question, many others came in and complained more or less well-founded, but nobody (IIRC) came up with a productive attempt to solve this issue. Sure, this is an open discussion, but I would really appreciate if these reproaches against modeling and EMF were accompanied by hints how the situation can be enhanced.

    As I know many of you are not the typical modeling or EMF beginners but rather have a pretty clear idea of what they are good for. So why not come up with proposals?

    Let's see if someone takes at least the time to read my first (non-insulting :P) comment more carefully and enters a constructive discussion...

    As far as I know nobody owns the notion of modeling and I think even EMF is a product and a value of the community as a whole. EMF can only develop with the support and the contribution of the community and I fear that the fact that this does not only include code but also stuff like marketing is not so prevalent.


  12. Here's my 2 cents...

    Ever write a Swing application with lots of tables, trees, buttons, and other vanilla widgets. EMF let's you do this in a day...and I don't mean a lay out provides the widgets, the event notification, and a natural way to represent the data model.

    Does it take a long time to learn? Yes. Try learning Ruby on Rails in a day...frameworks take time

    Does it require better documentation? The books is good...but applications are better.

    Is it, there are weird things, it can be frustrating, and there are just things that are too hard to do. More simple examples are absolutely necessary.

  13. Charles (or Martin?),

    You're right: Example applications seem to be what people like to start with. I recently noticed that they can have more effect than the best presentation slides. We're planning to come up with a set ofexample applications for EMF to address the different usage scenarios.

    Preceding that we will start a public discussion in the eclipse.modeling newsgroup to analyze the problems around the perception and adoption of EMF and modeling in general. Everybody will be invited to contribute to the problem analysis and the possible solutions. I think Peter Friese is currently preparing a kick-off...

    Btw. for the CDO Model Repository component I already came up with a real life-like example application which, of course, demonstrates the usage and benefits of EMF at runtime as well. It's available via CVS and I announced it in my blog: Modeling goes Enterprise.


  14. I promised to file a bugzilla to make modeling more visible in the runtime space:

    If you think it's a good idea please vote for it ;-)

  15. Dear all,

    i was a passive observer until now to this thread and others which are similar. I am not an expert so i do not want to comment on what many of you have shared here. But i want to share my experience with learning EMF Core.

    Naturally i was confused as to where to start with ... then my eyes fell on the Eclipse Modeling Framework book authored by Ed Merks et. all.

    i especially like the first few chapters ... which can give you a hint of the potential use of EMF (Core).

    Chetan Kumar