Software Factories: Definición redefinida

En estos días estoy reescribiendo, en cualquier hueco de tiempo, algunos conceptos de La Cuarta Generación que son obsoletos o poco claros. Entrando en ello, veo que Jezz Santos, en Octubre de este año, escribe un utilísimo artículo explicando el alcance de las factorías de software en versión Microsoft, que ponen las cosas en su lugar. Lo adelanto, y espero poder volver sobre el tema, aquí y en "La Cuarta...".
Quiero destacar una llana confesión de Jezz:

Although a software factory sounds like a new type of development tool which may have its own integrated development environment (IDE), in actual fact, Microsoft software factories are intended to extend and configure the general IDE of Visual Studio .NET.

Ahora, si volviera sobre toda la hojarasca teórica acerca del UML y las servilletas de papel, creo que al menos podríamos decir que en esa discusión hay al menos un problema de descoordinación de dominio: Jezz está hablando de una extensión a un ambiente de desarrollo dedicado a un marco específico, .NET, y UML está en un nivel de generalización teórica superior.
Un poco más de Jezz:

First and foremost a software factory is a software development tool. Built by developers, primarily for developers, architects, and others roles in the software development life cycle, such as designers, testers, business analysts project managers. This ‘tool’ is used to manage and automate the assembly and/or configuration of a software solution that addresses a well-known, specific business/problem domain, and is primarily used to create an executable solution from that.
How does a software factory differ from other general development tools and technologies we use today, such as C#, VB, and Visual Studio? A software factory is a specific domain focused tool, with a specific set of instructions, targeted at solving a small specific business/problem domain. Whereas, a general development tool like C# or VB is used to build basically anything we want (within limits of course) it’s a relatively unspecific tool, used to solve any business/problem domain. The point here is that a general development tool can be used to build anything, and therefore it’s left to you to manage the bounds of creating that thing (it is boundless). A software factory, through the use of a software factory schema, tooling and a managed runtime actually instructs and guides you through a known process for building the thing it knows how to build. It is very much constrained to the domain it was designed to address, and not much more.
(...) This idea is really nothing new today in the Visual Studio IDE where we already use many existing abstractions to increase productivity in developing solutions: the Windows Forms Designer, Windows Workflow activity diagrams, XML schema editors, SQL, configuration files, among many others. What is new though, is providing custom dedicated abstractions tailored specifically to the product or solution we want to help build.

Volveremos sobre ésto. El artículo de Jezz es de real interés.