Microsoft's Jezz Santos has quite a nice post about how to model variability. The start is a little heavy going, but the section on How to Use/Abuse Variability is great. Here's what I see as the core message:

I know - you just can't wait to break down your solutions into a product and types, and the possibilities are endless on the variability you can model - right?!? ... To be successful, your factory needs to provide highly specialised, proven solutions to known specific problems that accommodate some variability for customization.

The degree of variability varies, but almost without exception developers overestimate how much is needed. We're used to working with languages that allow us to build anything from toasters to database apps to space shuttles. Because we have that freedom, we tend to think that anything that narrows down our possibilities is bad and couldn't work -- even if it has been shown to be much faster in practice.

Compare the freedom of C or Java to walking. If you walk, you can get pretty much anywhere, by pretty much any route you choose. When trains were invented, you could suddenly travel between a limited number of points much faster. The downside was that the choice of points and the timetables were set by the train companies, and they might not suit you. This was something like the CASE tools of the 80s: the tool vendors fixed the modeling languages and code generators. Just like a train could move you a large distance, the tools could generate lots of code -- but if the result was that you ended up somewhere you didn't want to be, the fact that you got there quickly was little comfort.

With the advent of the automobile, people could travel quickly to a destination of their choice, at a time that suited them -- but only if the road network was in place. That's rather like the situation with domain-specific modeling: you have a tool that lets you model as you want, and generate the code you want -- but until someone builds the "roads", you're going nowhere.

Whilst no company would take it upon themselves to build a whole nationwide road network, they don't need to either. All they need to do is build a network for the area they are working in. And they don't need to build the whole network before using it: they can get the basics in place, and add new parts as necessary. It's the same with DSM: an experienced developer designs the modeling language and generators. The modeling language is like planning the road network: which points are in the network and how are they connected -- in other words, where the modeling "drivers" are allowed to go. The generators are like building the actual roads: making use of the road network actually work, so when you say "go from A to B" in the modeling language, you actually do end up at "B" in the code.

As this may or may not show, DSM goes further than variability modeling. In the road analogy, variability would let you take one of a set of pre-defined journeys. Each step would be something like "when you reach A you can turn onto either road 2 or 3". Of course such choices are also a vital part of many DSM languages, but if that's all you have, you're not getting the full benefit out of your road network. That only comes when you have the roads and local traffic rules, but each modeler/driver has the freedom to make their own routes up within the network. Also, the local should have the freedom to add new roads as needed -- without all your cars stopping working just because a new road was added.