Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[modeling-pmc] Fwd: Two Messages from Michael Guttman regarding the landing page discussion

Dear PMC.
I've read through all the posts reacting to my initial request to NOT change the intro text. Thanks to everyone.
Ed Merks: after your answers, I am convinced it is in good hands.

I'd like to forward you the following two messages from Michael Guttman, regarding the landing page discussion. They where addressed to the PMC, but since Michael is not on the mailing list, they never reached the PMC.

First Message: Do not limit too the needs of programmers!
----------------------------------------------------------
The main point in the first, newermail is to state that the scope of EMP was never limited to software modeling, and
that we should not repeat the error of UML to reach out only to the needs of programmers.

He claims, and explains why the potential of EMP in business analysis and modeling is much higher than in
programming.


Second Message: Relation of EMP and MDA
---------------------------------------
As already discussed, this is more relevant for the subpage on open standards.

In thiss second message, which is older, the main point is to confirm what was confirmed by Ed Merks as well, e.g.
EMF is a pragmatic implementation of MDA..

        Date:   Sun, 19 Aug 2012 16:14:42 +0200
        From:   Ed Merks <ed.merks@xxxxxxxxx>
        To:     kutter@xxxxxxxxxxxx, PMC members mailing list <modeling-pmc@xxxxxxxxxxx>
        ....
                > Philipp Kutter wrote:
                > As the OMG community accepts ECore as the pragmatic implementation of Mof,
                > Eclipse Modeling Project, with its "onion layers" like Ed Merks described in his text is
                > thus an a pragmatic implementation of MDA.
        Exactly.
        ....



Best Regards,
Philipp


-------- Original Message --------
Subject:
Re: Sven's comment on [modeling-pmc] Comment to Ed's new main text for the Eclipse Modeling Project
Date:
Sat, 18 Aug 2012 09:51:50 -0400
From:
Michael Guttman <michael@xxxxxxxxxxx>
To:
kutter@xxxxxxxxxxxx

Phillip,

Thanks for bringing me into the loop.  I should note that, besides being long ago one of the author's
of CORBA 1.0 and 2.0, much more recently I ran the OMG' MDA FastStart Program, which, during the early
years of MDA,  was the OMG's main public outreach for MDA to the business community.  Probably more
than anyone else at OMG, I had to explain to business people and development managers on a day-to-day
what MDA really is and isn't.  In fairness, I should also note that, as I am no longer on OMG staff,
the view expressed here are entirely my own.

I will also freely admit that I am not intimately familiar with all the different interest groups at
EMP, their key players, or their various motives and philosophies.  However, it is my strong sense that
the EMP, as originally envisioned, is first and foremost a program to achieve a practical open-source
implementation of the core standards and principles of MDA.  As such, it has also become the defacto
reference implementation of MDA.  The resulting 'products' (e.g. the UML editor and associated code
generators) are, in this context, just 'examples' of how MDA/EMP can be applied to solve practical,
commercially interesting problems.

Based on my understanding of publications from the OAW/XPand/XText people, some of them appear to
misunderstand the purpose of MDA and the OMG in general, and therefore their relationship to EMP.
Sadly, the OMG itself has a minuscule marketing budget, devoted mostly to promoting its meetings
and special events. Therefore, their misunderstanding is perfectly understandable.  To correct it,
some history is in order.

First of all, the OMG is NOT a vendor - it is an industry consortium.  Its members collectively
decide which specifications to endorse, and its members then voluntarily adopt and promote those
standards as they see fit.  The OMG's clearly stated main goal is interoperability between software
and software development and deployment tools.  For example, CORBA, OMG's first specification,
provided interoperability of heterogeneous software systems over a distributed network, including
the Internet.  Even today, CORBA is used to process billions of complex transactions over private
and public networks, such as the ATM network.

In 1997, Rational (now IBM Rational) donated an early version of UML to the OMG, which, after some
tweaking was adopted by the OMG as its very first modeling specification. UML has been by almost
any measure remarkably successful in its target arena, application software modeling.  However, as
various people tried to apply UML to other kinds of modeling (e.g. business modeling, systems modeling,
etc.), it's design limitations became apparent.  Just cramming more features into UML did not solve
this problem, and arguably made it worse. Controversy over UML 2.0 still rages largely centered
around this very issue. :-(

So, early on some of us in the OMG realized that a 'one size fits all' approach to modeling would
never achieve the OMG's goal of promoting broad tool and software interoperability in the area of
modeling.  A much more flexible approach would be necessary that would allow ALL models and modeling
tools to interoperate, even if they were based on modeling languages other than UML.  This idea became
the basis for what is now called MDA.

As you have correctly noted, the core of the MDA is MOF, and the minimal core of MOF is EMOF. On the
rock of EMOF (to paraphrase), we then should be able to build ALL modeling languages.  And because
we do so, ALL EMOF-based modeling languages 'inherit' a base level of interoperability.  By extension,
modeling tools (and model execution tools) built on an EMOF-based framework like ECore also 'inherit'
that level of interoperability.

Thus EMOF achieves the core design goal of OMG based on its business mission - that is, heterogeneous
model and tool interoperability.  So, when one uses the phrase 'MDA modeling', it should really only
mean one thing: that the tools and models involved are based on EMOF.  At the OMG, every single
modeling specification proposed by a submitter must first meet this test to even be considered for
OMG endorsement.

Unfortunately, various ideas and examples promoted by individual OMG members, staff and MDA users
as to 'how to model' have led to differing public perceptions of what 'MDA modeling' is or should
be. However, these are at most just examples, and moreover just examples at one point in time, and
from one point of view.  They should not be used to characterize all 'MDA modeling'.  Once again,
'MDA modeling' is just modeling ultimately based on EMOF - or, in the context of EMP, on ECore.

Getting back to your discussion with Sven, and given the logic of what I just laid out, it would
seem that the EMP would do well to strengthen its connection to MDA, not dilute it.  This would
suggest that the EMP home page should continue to emphasize these ties, perhaps even more clearly
than it does today.  Meanwhile any derivative pages should then focus on specific genres, communities
and/or specific applications of EMP, all of which, by extension, are simply genres, communities
and/or specific applications of MDA.

Hope this adds value to the overall discussion....

Regards,

Michael Guttman


-------- Original Message --------
Subject:  Re: [modeling-pmc] Sven's comment on Comment to Ed's new main textfor the Eclipse Modeling Project
Date:  Sun, 19 Aug 2012 08:40:08 -0400 From:  Michael Guttman <michael@xxxxxxxxxxx>
To:  Wendland, Marc-Florian <marc-florian.wendland@xxxxxxxxxxxxxxxxxxx>

Thanks, Marc.  I would add the following:

However, it remains my understanding of EMP is that it is devoted to creating an open-source framework for
all types of formal modeling.  I don't recall that it has ever been limited to or especially focused on
any one form of formal modeling - e.g. software modeling, much less modeling for software programming,
which is what you have stated.  This is certainly one important application of formal modeling - but also
certainly not the only important one.

Now, if the EMP is going to continue to support different kinds of formal modeling, then I can tell you
from hard-won experience - beginning as a programmer and evolving into an enterprise architect and successful
software entrepreneur - that it better have some kind of strategy for supporting interoperability among those
models.  If EMP doesn't want to reinvent the wheel in this regard, then MDA is its best bet by far.  Furthermore,
for EMP in particular, MDA is a very cheap bet, because EMP already implements all the core facilities of MDA.

Sven, you make the assertion that "Business people can't program (or model) unless they think formally, i.e.
like a programmer."  You are quite wrong. In fact, formal modeling is a skill utterly separate from the modeling
target - e.g. software programming. Those programmers, like you, who really do formal modeling are a nearly
infinitesimal minority of the programming community worldwide.

The overwhelming majority of programmers today don't and can't do formal models or even 'think formally' -
they just code - usually in some mangled-up scripting language inside of some opaque 'wizard' -  and then
test and hope for the best.  Even most EMF users probably fall into this category at the moment, since they
most often using EMF is an etch-o-sketch API builder, filling in everything else with conventional, utterly
non-formal hand coding.

On the other hand, there are many business analysts that do think quite formally, and many of them use formal
modeling tools and techniques, although not necessarily those that programmers like you are familiar with.
Furthermore, business analysts are a far larger potential market for formal modeling tools than programmers
- ask any industry analyst - and they have far, far larger budgets than IT shops, most especially for anything
that will help them better analyze business problems and prepare precise implementation and deployment
specifications.

Moreover, business people actually have a lot more reason to use formal modeling than programmers.  If a
programmer fails to implement a business specification correctly, most likely he/she will be able to hack a
fix, and it will mostly work right - not a very efficient or elegant way to operate, but usually acceptable.
But what if a business user gets the problem definition and/or the resulting specification wrong in the first
place because he didn't properly model the problem space?  In that case, it won't matter at all what the
programmer does, and the negative consequences will ripple through every aspect of the whole business project,
often causing huge cost overruns and delays that may sink the whole project.

So why aren't those business people rushing to EMP, as you note?  Precisely because EMP, despite having broader
capabilities that could potentially benefit business users, continues to position and market itself primarily
to the programmer community, and a very limited subset of that community at that.

That's exactly the problem we noticed with UML, which is why we created MDA in the first place.  UML, whatever
its virtues or weaknesses, has been aimed squarely at the software modeling and programming market.  Even so,
after some 15 years as a well-known standard supported by virtually every major software tool vendor, only
about 20% of that market even attempts to use UML-based tools on a regular basis.  That's largely because,
to use them effectively, they require formal modeling skills most programmers don't have.  So, UML is caught
it a trap.  It can't expand much within the programmer community, and it can't expand outside of it.

IMHO, EMP should not go down that track and repeat UML's mistakes, even if its current user base is mostly
programmers like you.  That would be like Apple deciding NOT to introduce the iPhone or iPad because all of
its users (at that time) were used to desktop and laptop computers, and nobody had ever bought a phone of
any kind from Apple.  Instead, EMP should start thinking outside of its current box and setting the tone
for attracting other kinds of users, particularly business users.

But to build up a critical base of such users, EMP needs a strategy that promotes model and tool
interoperability.  Whether you personally care about that or not, it is a top functional requirement of
such users.  Fortunately, that requirement is also relatively easy to fulfill by simply continuing to
rigorously support and promote MDA, as Phillip has stated.

Once again, I completely understand why none of this is currently important to you in your existing business.
But you - and the rest of EMP leadership community - must also decide whether it is for or against your
collective self-interest to help EMP continue to grow and reach a wider audience, or to remain narrowly
focused on a very limited marketplace.

Regards,

Michael



Back to the top