If you consider domain specific modeling products as simply glorified code generation tools, you might get away with just rushing through the product documentation and jotting down the first thing that comes to your mind.

However, as vendors are becoming more successful in fulfilling the promise of enabling people within organizations to model their own domain specific languages, many are realizing that simply mastering the features (and limitations) of a particular modeling tool is manifestly insufficient.

I’m certainly not trying to classify such tools as interchangeable commodities; in fact, I speculate that, at least for the next few years, the choice of one tool versus another could easily contribute to the failure of a project.
There are already several documented cases of organizations that use modeling tools to drive entire product lines with enormous success. Frankly, I just assume that the very same tools have been employed within different realities with opposite results.

One of the goals for DSL authors is to generate as much code as possible whilst hiding implementation details behind reasonably flexible models and notations. This goal presents challenges that go beyond the tool in use.

If it is that hard, who should create DSLs? Will organizations need to create a specialized development role as some are arguing?
It is realistic to assume that experienced developers/architects who fully understand the domain and have been involved in the development of enterprise frameworks are the natural candidates for authoring well thought DSLs for an individual organization.

On the other hand, there is a danger that such authors might treat DSLs exactly like class frameworks, without realizing that the forces at work are significantly different.

When building frameworks we don’t necessarily know how our components will be consumed. For example, if we create a custom control and omit to expose a particular event, the entire control might turn out to be totally unsuitable for a whole category of users. It is then reasonable to take a “safe” approach by adding extra options, in the form of events, method overloads, extra parameters, extensibility patterns, etc.

However, using this tactic for DSLs would lead us to create “flexible” implementations of a language through the introduction of (superfluous) configuration/customization options to our models, without considering that every time we add an extra element, attribute or connection to a DSL we arguably make the language more difficult to use and, ironically, less adaptable:

• It is more difficult from the user perspective because there are more elements in the language to understand and deal with.
• It is less resilient to change because those options might expose subtle aspects of design and implementation of a solution that, over time, would be harder to modify and improve.

Of course, since we want to use DSLs to solve categories of problems, we cannot totally eliminate all forms of variation, but my point is that, in order to add flexibility to a domain specific language, we should take a systematic approach and reduce options rather than blindly increase them!
Is it possible? Yes, if we narrow the scope of application of the language to a well-known domain and we favor abstractions and conventions over configuration options.