Free seminar on domain-specific modeling

[Martijn Iseger]

Hello Michael,


> The alternate point is that during computing history, many, many, many
> promises were made for many, many, many, technologies based on the
> same principle of raising the abstraction level. Many, many, many of
> those technologies promised much and failed to deliver on their claims
> when used beyond the people inventing/using those technologies.

True, DSM however is not so much a new method for develping software. It's 
been used since the early 1990ies as far as I know and seen many sccessful 
implementations of it in varying sectors of industry: From mobile phones 
(Nokia uses it to develop the software running in all their phones) to IP 
switching platforms (Lucent), CRM systems, pacemakers, home automation systems, 
J2EE-based B2B portals (insurance industry), car infotainment systems (Audi 
A6), messaging systems (USAF), enterprise apps on smartphones (Nokia series60), 
Tooling industry and many more. Success with DSM depends on several factors 
like a common platform used for developing applications or variants of applications 
and the presence of domain-expertise: That leaves out one-time projects.

> One thing is relatively clear - your approach appears to include a
> graphical approach to systems building. Personally I suspect that the
> fact people are able to engage other parts of their brain when
> building these systems beyond linguistic is the real reason you see
> benefits, rather than actually the specific thing that led to the
> visual approach being possible.

It is actually based on the graphical approach. The important thing I see 
here is that specific instances of this approach are defined by a company's 
expert developer instead of by a standards-body or a vendor, this puts the 
expert in the driver-seat so to say, he/she gets the ability to formalize 
(changing) development practices in his/her problem domain for the rest of 
the (less experienced) developers to follow automatically. Instead of adopting 
a one-size-fits-all approach companies/developers get to tailor the approach 
to the specific needs of their unique problem domain. It does not eliminate 
coding but attempts to minimize the need for it and leave it to the people 
who are really good at it.

> (On a sad note it looks like you're reinvented how hardware is
> designed and made, but not made the intuitive leap :-/ )

I suppose you mean software here? It seems I fail to make the "leap" towards 
understanding what you mean with this, feel free to elaborate.

Regards,

Martijn