The 5-10x productivity increases in Domain-Specific Modeling come from the combination of a number of factors. I think two of those factors contribute the most:

1. the raise in the level of abstraction of the language
2. the smooth mapping between concepts of the problem domain and concepts of the language

The "language" here is the Domain-Specific Modeling Language, contrasted with the earlier general-purpose programming language. Both languages allow products to be specified, and both can generate full products from those specifications.

The task when creating a DSM language is thus to achieve the raise in the level of abstraction away from the bits and bytes of the implementation, and to offer a smooth, impedance-free mapping between the problem domain and the language. For both of those, we need to focus on the problem domain (the domain expert view) not the solution domain (the implementation in code).

Interestingly, it's just as much work to build a DSM language focussing on the solution domain as it is to build one focussing on the problem domain. Similarly, the tool support needed to build DSM languages will be the same whichever way you build them. That's why it's a shame but not entirely unexpected to see people get the wrong end of the stick -- especially in an environment with a strong existing focus on code.

Let's look at a couple of other people's perspectives. First up, Microsoft's Jezz Santos:

If you understand the difference between problem domain and solution domain in software design, you will know that [software] factories are all about the solution domain. We are so far away from modeling problem domain and turning it into software just yet - forget it for now. It has proven impractical at this time, it is too big a step at this point, we need to evolve to that later.

If that really is the Microsoft party line then I'm seriously disappointed. Maybe Microsoft are "so far away" from a real raise in the level of abstraction, but others most certainly have proved that it's practical. Pushing out that kind of poor advice is a disservice to Microsoft's customers, dragging their modeling languages down to near the level of the code. Failing to raise the level of abstraction much was the key reason why Ordina only achieved a productivity increase of less than 20%, despite spending man-years on extending Microsoft's DSL Tools.

Maybe Microsoft are so focused on selling their platforms and frameworks that they are misled into thinking those are primary, and the customers' actual problems and needs are secondary? From a neutral point of view I'd have thought it would be self evident that problems come first, and solutions are dependent on the problems. There can be many different solutions, built with different technologies, that all solve the same problem. Only a technology vendor would take the technology as primary, and declare that all customer problems must be expressed in terms of that technology to be valid.

Let's move on to our second perspective, from Antoine Savelkoul [grammar corrected for clarity]

Bottom-Up Approach = Reverse Engineering = Wrong decisions?

I'm doing an investigation on business DSLs. For a proof-of-concept DSL I had to decide whether to apply the bottom-up or top-down approach. ... I made the choice to apply the top-down approach and not have a close look at the existing code before having defined the DSL. By talking to the domain expert I identified a number of customer needs which I would never have detected with the bottom-up approach. This is because a lot of the domain expert's knowledge and way of thinking couldn't possibly be recognized and restored to its original form from the code.

The analogy with reverse engineering is particularly telling. When you have the original developer around, you don't reverse engineer the code: you ask him to explain it to you. Similarly, when you have access to problem domain expertise, you don't try to reverse engineer the problem domain from the code. The code is already at least one step removed from the original, and reverse engineering adds another step: this is Chinese Whispers or the rumour mill, with all the attendant problems of lossiness and distortion.

UML is cited by many as an example of something that is not domain-specific. Microsoft were originally praised by many for not tying their DSL Tools down to UML. Yet even in 2004 the UML gurus recognised something that Microsoft seem not to have understood yet:

"the full value of MDA is only achieved when the modeling concepts map directly to domain concepts rather than computer technology concepts"

An MDA Manifesto, Grady Booch, Alan W. Brown, Sridhar Iyengar, James Rumbaugh, and Bran Selic, Business Process Trends/MDA Journal, May 2004

Note that I'm not saying you can't start from a framework as the source of your language concepts. That's one possible source, and not to be ruled out or ignored. However, the information there will be muddied by implementation details, concessions, historical factors and earlier mistakes. Why drink from the muddy pool downstream when you can go upstream to the clear spring it originally comes from?