Steven Kelly interview for MDSN - recording online in Vimeo

Replies to This Discussion

Permalink Reply by Rafael Chaves on November 19, 2010 at 0:19

Thanks to Steven, Angelo and all involved. Great questions, great answers, high quality interview all around.

• ▶ Reply

Permalink Reply by Jean Bezivin on November 20, 2010 at 7:56

Excellent interview with a lot of success stories for MDD. Congratulations Steven and Angelo. About the M2M transformations, I do believe they are quite important: wp.me/p1auAH-81

• ▶ Reply

Permalink Reply by Andreas Leue on November 22, 2010 at 12:15

I think so, too, and I'd like to explain why.

In the 90'ies, the community headed to solve a challenging goal: creating whole (mostly enterprise) applications based on models - that failed fantastically! To be fair, we should take into account that applications were much simpler in those days, remember, Windows 3.x was released then for the first time.

Why did it fail? Steven argues that languages and solutions did not fit customers needs, and that is quite true. So one approach (DSM) is to build languages that do fit - individually, per customer. Does it solve the general problem? No - and it is not even aimed at doing so. As far as that, there's still agreement on the reason: the general problem is _very_ complex. But is it _too_ complex? Is it hubristic? BDUF?

To describe the scenery, I like a metaphor of a bridge: "The bridge of abstraction leading over the river of complexity". There are of course differently wide rivers, depending, some contain little islands. A river has to sides: left, there's the customer with his individual requirements, right, there are specific software solutions.

Around 2000, MDA suggested to build a bridge pier in the midths of the river, to make the bridge more stable. That alone didn't really help, and it introduced another complication into the projects: build a model, build a M2M-, and build a M2T-transformation. It seems, next to noone really did this within his project, and the few who did failed again. So very soon, all projects I could gain insight at, even if they claimed to to MDA and were using MDA tools, in fact just and only did plain old M2T.

Is DSM (building short bridges, not spanning broad rivers) better than MDA? In a sense, yes, since it delivers productivity gains, while MDA (alone - piers for still crashing bridges) does rarely. But in another sense, both are not conmpeting, but mutually complementing approaches, ingredients of a larger MDSD framework.

The bridge can be divided into abstraction levels: starting from the technical side, there are technically specific details. Going to the midths of the bridge, it's getting more and more abstract, in a technical sense. Ideally, in the midths, there's a completely neutral model, with respect to technical details and with respect to business details. Continuing to the customer, it's getting specific again, but now in a business sense: that's where DSLs come into play.

In this picture, both approaches have their place. Does such a neutral model exist? Is it manageable? What is the benefit of these intermediate layers (they have costs, too)?

First: it is quite clear that a neutral model is economically extremely benefical: it simply enables not to build each bridge starting from scratch, but to use prebuilt bridgeparts. Very attractive, I'd say.

Second, I don't see any acceptable reason against a universal modelling language _except_ it's provenly too complex, which noone has shown so far.

Does that suffice: DSM + MDA? To my experience: no. As described in detail in the post http://www.modeldrivensoftware.net/forum/topics/introducing-emos we discovered a substantial amount of more problems and had to find solutions for them.

To close the circle of this post, one technology we apply are Object Construction Plans (xocp.org, open source) to describe our transformations. With this approach, we can dynamically build "Object Views", i.e. models that provide a "view" to an underlying model, thereby representing a transformation. These stacked views are not bound to a predefined scheme of Model A, Model B, Model C but can be applied partially, in small pieces and repeatedly on top of each other. Thereby we're open to introduce new "intermediate" models or get "rid of them", as much we like.

We often asked ourselves, reflecting on architecture, whether the intermediate parts are necessary at all. In fact, in the beginning, we had not planned a certain architecture, but it evolved from our code itself (ok, with some educated guesses), in a reiterated sequence of refactorings of our templates with the goal of eliminating redundancy, organising information better and making it more maintainable. We observed repeatedly a strong tendency of the system for emergence of as well "the neutral model" as "domain specific models". Last not least, the result of this process looks aesthetically satisfying. These observations give us confidence that the whole approach is a "Good Thing".

To compare it with traditional software development: yes, it is true that for the customer the only thing that counts is the working application. Still noone would doubt today that e.g. a three tier architecture is helpful for all the "ilities". Same with MDSD: what counts is only the running application in the end, but talking about the whole bridge, architectural advances are inevitable.

Andreas

• ▶ Reply

Permalink Reply by Rui Curado on November 19, 2010 at 14:50

I listened to the whole interview. Very good. Keep'em coming!...

But Angelo still needs experience as a podcaster. Well, one more reason to continue!

• ▶ Reply

Permalink Reply by Angelo Hulshout on November 19, 2010 at 15:00

Thanks. Never did a podcast before, so you got a point there.

• ▶ Reply