Spaghetti Modelling

The modelling based architectures, like MDA, MDE, MDD, enforce essentially a strong separation of concerns bewteen the business architecture and the technical architecture. By simply having models for defining the processes, the rules and the functional specification in general separated from the technicalities such as service binding, design pattern, deployment, state management ... is a great strategy to improve reuse, scalability, division of work across team, software life cycle, asset creation and so forth.
In essence, the application can be defined as a set of models; for example business processes, business entities class model, interfaces, UIs, business rules, component models, ... but this is not sufficient for a clear and neat model structure. The risk in ending with Spaghetti Modelling is still here; we will not end up with a comprehansible set of models of the application just because we are adopting a model driven approach.
Care must be taken in creating a proper model set that is comprehensible and that does not mix the various logical views. This risk can be reduced by adopting an application metamodel (call it application template if you wish) but it's not sufficient, in general there is the need for a good modelling practise that comes of course from the experience but also from the the good old motto "think before modelling" (aka "think before coding").
We will less an less write lines of programming language in the future (that is already here) but we will always abstract the problem space into a solution space, that is the same class of problem.