Raise your level of abstraction
In various recent discussions (Tool for mdd, feedback on Fenomen, CG2011 fishbowl session, LWC 2011 etc.), attempts were made or at least the question was raised to compare different MDx approaches.
It seems, at present, we have a few rather different ideas of what MDx technology is, or should be. Far too often we compare apples and oranges.
For comparison, at least we should distinguish the following aspects:
- How do you interact with your model?
(graphical, textual, guided by a tool, validation)
- What do you model?
(level of abstraction, amount of models, completeness)
- What do you get "out of the box"?
(ranging from: complete domain specific business solution, up to: raw technical model to code transformations)
- What do you create?
(artefacts, completeness, level of abstraction of artefacts etc.)
- What can be modified, and how?
(the answer to this question must be a really lengthy one and goes to the heart of MDx)
Related to the last question is, e.g.:
- How does your transformation chain look like?
(one stage, MDA, interpretation, something else/more/less)
All these questions can't be answered simply "yes/no" (except in marketing brochures, where of course all solutions are business oriented, totally complete and absolutely felxible).
For a different context, I was preparing an overview of MDx technologies. It's work-in-progress, but I thought it might be interesting to present it here in this early stage. The link is
The diagram shows the area of models and artefacts in MDx context. From left to right it goes through abstraction levels from business to software. The other axis corresponds vaguely to multi tier software leves (UI, BL, DB).
The purpose of the diagram is to be able to draw different approaches into it, and allowing a comparison of what each approach actually does in the area.
If you like, you can help improving that overview (your contributions will be save since it will be under a creative commons license). You can also help editing the diagram itself via an integrated browser-based svg-editor.
I'd appreciate your comments, either here at MDSN or in the wiki.
Ok, so that would make another good list: "Goals of MDx".
1st draft (from above):
- make software production faster and more reliable
- enable non-technical business people to get a grip on their systems
- make software production more agile
And yes, fully agree with your "...hate to ... choose...". I was just quoting vendors' claims :)
Andreas and Meinte,
I think there are a number of different things implicitly present in this thread: technology, methodology and innovation process. I will give some examples to explain what these mean for me:
Technology: MetaEdit+, Mendix Suite, Obeo Designer, etc.. LWC2011 focus on capabilities of tools to model and transform.
Methodology: DSM, MDA, AALM (by Mendix), etc..
Innovation process: how to "do"/introduce/evolve MDx in real-life project situations.
Do you recognize these as well in the discussion? Is there more?
I guess I do but personally, I find Methodology to be completely uninteresting. Most "methodologies" boil down to a combination of common sense, some well-known principles and best practices (Separation of Concerns, the Single Source-Principle, etc.) and some kind of flavoring through a manifesto of sorts. In view of that, most MDx methodologies reduce to "some_other_methodology using models" anyway.
So I don't think they are really valuable on their own, at least not without bringing more to the table. The most important thing would be how to combine MDx with the dev methodology that's presumably already in place. I don't really believe total MDx green fields projects exists: there's always some kind of company or project standard to conform to. That's not bad, we just have to know how to work with that and that's precisely what something like MDA doesn't do, period.
Without some discussion on the combination aspect, any comparison is going to be as useful as one on whether steam or nuclear power is better for dish washers ;)
Usually, my innovation process looks something like this:
1. Get to know the domain.
2. Identify a part of the domain that would benefit from modelization.
3. Create an (end-to-end) implementation for that part (language, modeling environment, code generation, integration into continuous deployment, etc.).
4. Provide business value with that implementation (roll out, train users, etc.).
5. Goto 1.
If the comparison were to address how a particular fits in with this process, I'd be vary happy.
Hm, I can easily understand for (3) that you can show e.g. which standards are supported so that something fits into a given scenario.
What do you have in mind with (1), (2), and (4), with regard to "fitting with the process"?
@3: I really don't care about standards. In fact, I think that word has done more damage to MDx than it brought good - except for the EMF and XMI standards, but these arose as "working standards" which is a bit different from the ivory tower-kind like MDA and UML. I've never encountered a situation where having a standard in itself brought any value to the table.
@the rest: With "fitting with [in] the process", I mean how well any tool or methodology fits in with "my" innovation process. So it's really an easy rephrasing game: how well does tool X/methodology Y allow me to get to know the domain, etc.
@"Goals of MDx": the goals shouldn't really be different from "goals of software creation", IMHO.
Sadly enough, yes. Considering XMI and tool support, it's not even a working standard, but a rough idea of a potentially working standard.
Anyway. I dare to question whether this is due to too many/bad standards, but instead due to a lack of an amount of really working standards. After all, it might be a reason why MDx is not so widespread accepted as we wish here; it was not just once that I heard from the customers' side that he does not know what to bet on; even with open source there's possibly a "vendor" lock-in.
I see your point. Do you have a list in mind of such potential benefits of technologies (business/IT approaches, tools, methodologies etc.), or possibly properties they shall have to serve the various steps?
software creation, yes agreed, plus: business issues at the intersection of organisation/management/architecture/IT. As an example, there's BPM (all flavours). It does not necessarily concern software creation, it might affect in addition or alone work coordination, while it's for sure (to some degree) "model driven". More than that, there's the finally most interesting integrating area of "enterprise modelling" - defintely related to software (today), as well as definitely radically more than software (today).
I'm pretty much restricted to the Java/Eclipse/EMF ecology but over there XMI and EMF are very much working standards. The perceived need to adhere to some standard is mostly a manager thing, IMHO and usually not because of fear for "vendor lock-in" but because a built-in and irrational "we need standards!"-type of thinking, where real, rational reasons have little or no place.
Besides that: I think that standards for which you can't readily create a reference implementation are useless anyway. Usually, anything outside the communication/formats (like XML, XMI, etc.) or platform (like the JVM) domain doesn't meet that condition.
I always feel that lists sort-of insinuate exhaustiveness and having checkboxes in front of the items, which typically prevents thinking about these... One simple "thing" is that tooling should support agility/software evolution.
I don't see BPM as a business goal, but rather as a means (and usually a very poorly implemented one, at that). Also, "business issues at the intersection of organisation/management/architecture/IT" already implies a precise direction in which you're willing to find business value which might very well detract from finding the real business value. In the end, the goal is probably something like "improving people's lives" (+ a description of the scope of that statement). While it's useful to keep that in mind, MDx could focus just as well on allowing the software creation effort to be as efficient as possible, not just in execution but in discovering the actual business value as well.
So let me go back to the original question. Do you have a suggestion how a comparison might look light to meet your requirement?
> 1 ... 5
> If the comparison were to address how a particular fits in with this process, I'd be vary happy.
You are clearly interested in MDE development process. What you outline is approximately the process I follow in MDE projects as well. In my opinion this process is a traditional development process. (In fact, I found that sensible use of MDA process works very well for me). However, there are a few peculiarities and a complication:
The complication is that MDE development is usually coupled with introducing a relatively drastic change within an organization, because it affects knowledge workers, and MDE is still relatively new and unknown. So this complication needs to be managed in addition to the primary work. This however belongs to social/organizational sphere.
One peculiarity is that domain knowledge/ontology analysis is very important as its artifacts have strong (isomorphic) relationship with DSL concepts. (This is in contrast to traditional development and methodologies, DDD being an exception.) Therefore, it would help if MDx tools had proper support for such analysis.
Another peculiarity is that MDE subjects are knowledge processes, and therefore process view (and appropriate tech support) is important e.g. to learn domain and identify subject activities with best ROI.
The bad news is that no MDx tech gives me what I need for the above work. All of them focus on step #3 (in your post) with possibility to use traditional development methodology.
The (semi-)good news is that good quality MDx tools allow me to make my own DSLs to support my MDE process. (However in practice I tend to use simple tools).
Taking Meinte's angle, it would be nice if the comparison addressed dedicated support for domain modeling and process modeling.
Thank you for the time you took to think over my points. At the moment I can give only a few brief answers.
> I'm not sure where you see the "traditional MDE development process",
I was referring to the 5 steps described by Meinte. This is an MDE development process that leads to MDE infrustructure (Tools +DSLs + transformation) to support a traditional business or development process. In my experience, an MDE process is just a traditional development process with a few complications I outlined previously.
>> ... complication ... MDE ... drastic change ... knowledge workers ...social/organizational sphere...
> .. Yes. I agree very much to that. So: who exactly (which roles) in
> which organisation is affected by which part of which new process?
> We can differentiate at least business people interacting with high
>level (abstract) models, business and/or IT people analysing,
The point is that it does not matter. MDE does not fixate problem domain, nor particular type of activity. In fact MDE can be applied to improve work of MDE developers as well.
>> ... MDE subjects are knowledge processes, and therefore process view...
>> ... learn domain and identify subject activities with best ROI...
> Are you referring to business processes or development processes, or both?
>> ... bad news ... no MDx tech ... for the above work ... focus on step #3
> Well, given that not even the task of performing step #3 is
>managed sufficiently and this fact is a reason for high software
>development costs and insufficient flexibility, I can't see why it
>should be bad news that MDx technology tries to improve that.
I think you are placing step 3 in the context of traditional development process. My comment was in the context of MDE development process. Here all tools I know focus on part of step 3 only. (To make an analogy, imagine a traditional dev. process with only software developers equipped with IDEs..)
>> ...domain knowledge/ontology analysis ... strong (isomorphic) relationship with DSL concepts...
>> ... support for such analysis...
>> ... good news ... MDx tools ...own DSLs ...
>> ... dedicated support for domain modeling and process
> Which kind of support? You mention DSL crafting. What does
> support for domain/process analysis/modeling comprise?
This is a very big question. Here is s brief answer:
Before I even start making DSLs (step 3), I usually sketch the processes in the domain. Flow charts and even ER can be repurposed for this. However, the focus is not on flow of data or contol, or on concepts, but on knowledge, languages and technology/tools and costs of mapping different kinds of knowledge. This helps process analysis.
Domain analysis: before going to metamodelling, I create an ontology of the problem domain. This is the most concise and close to customer world summary of domain knowledge. Modelling this has its specifics, that again are not directly supported by available tools. I tend to use simple ER language and spend too much time manually maintaining consistency and readability of domain models.
(The above is not a common practice, but what I found useful in my work.)
>> ... embrace the "unembraceable"... four different things...
> Yes, these aspects are present, what is the problem with that? I
> mean, to compare MDx approaches, one has to understand the
> various implications and connections. In which way would you like
>to separate them to make them more comprehensible?
The problem is if these are implicit in the discussion, which is bad for communication. It is good to make them explicit and to establish links among them.. In which way to do it? I don't know.. focus on each independently and then on relations among them?
>> ... measuring metamodel quality...
>Thanks for the link. This is indeed useful, I'll do my best to
>incorporate it. I think I should read that metamodelling paper.
Glad the link was useful! :)
Andreas, I have to look at your diagrams again and to think about your other points. But this will have to wait until after my vacation :)
How could "MDE" change that?
Maybe I do not understand what you precisely mean by "MDE"...
> > Are you referring to business processes or development processes, or both?
> Yes, both.
Ok. And agreed.
> > > ... bad news ... no MDx tech ... for the above work ... focus on step #3
> > ...can't see... should be bad news ... tries to improve...
> I think you are placing step 3 in the context of traditional development process. My comment was in the context of MDE development process. Here all tools I know focus on part of step 3 only.
Don't get this exactly, too. Can you explain what in your understanding is "MDx tech ... for the above work"?
> > > ...domain knowledge/ontology analysis ...
> > ...DSL... [more] support for domain/process analysis/modeling...
> Before I even start making DSLs [...]
> Domain analysis: [...]
I'd be interested in what information the models you describe capture, and what kind of tooling you'd wish for that.
Do you have more information on that? If it gets too much offtopic here, we could get in direct exchange.
Have a nice time :)