Factorías de Software ¿Horizontales y Verticales? II

Siguiendo la nota anterior...
El planteo de Factorías de Software sostenido por Microsoft contiene un componente que produce confusión, al denominar su iniciativa con las mismas palabras usadas durante mucho tiempo por distintos emprendimientos de desarrollo con criterios de rigor industrial. "Software Factory" implica un concepto de mayor alcance que el dado por el conjunto de recomendaciones y productos asociados a la idea por Microsoft. Pero existe un segundo componente en la definición que también resulta controversial: el desarrollo como líneas de producto (Software Product Lines, SPL, en los conceptos del SEI (Software Engineering Institute). En este caso, el concepto es central, y explícitamente indicado como base de las Software Factories por Jack Greenfield. Sin embargo, existen diferencias en el desarrollo práctico de las factorías, si nos atenemos a Jezz, y a lo que se puede ver en el sitio de MS. Al comienzo de su nota, Jezz declara una vez más la relación existente entre SF y SPL:

In order for a horizontal software factory itself to be reusable in multiple vertical domains (which is where it is ultimately destined for) there has to be some level of customization that allows it to be specialized towards any particular vertical domain. If we don’t allow this, then we simply can’t adapt a factory to create specific enough product lines, which means we are limited to the productivity we can achieve with it as a reusable asset. That’s not to say we can’t. We can do the product lines, but the overhead of doing so is much larger than it needs to be, because some things in the particular domain will either be common, or specific across the whole product line for that domain. Remember, the power of factories is in how specific they can be.

La vinculación es central en el libro de Greenfield, fundamento de esta iniciativa:

Recognizing and planning around these assumptions leads to defining families of similar solutions, and separating their common features, which make them similar, from their variable features, which make one member of the family different from the next. The common features are used to develop a custom process for building the members of the family, and of a set of reusable assets supporting the process. The variable features are used to drive parameterization, configuration, assembly and other techniques for accommodating the differences between the family members.
This is the thinking underlying the development of the components that are truly reusable, such as RDBMSs and GUI frameworks, although it may not have been recognized at the time by all of the people involved in building those components.
Work at the Software Engineering Institute (SEI) formalized this thinking in the concept of Software Product Lines. Software Product Line practices have been well established through many books, case studies and experience reports, and are widely accepted in the software engineering community.
Software Factories is a methodology for using domain specific languages and other technologies to automate Software Product Lines. They were developed by leveraging the work of David Garlan, as described in the book, in consultation with the authors of Software Product Lines at the SEI, and with other experts in related disciplines, such as pattern languages, generative programming and feature based development.[Comentado en su blog]

Por lo tanto, es razonable ver cuánto ayuda SF en ese terreno, así como deslindar el valor de la idea de Líneas de Producto Software más allá de la encarnación en el proyecto de Microsoft. Y vale lo mismo para las Factorías de Software. Es decir, es importante discernir que ambos conceptos no son necesariamente lo que Microsoft postule, y que pueden diverger. Que el concepto es del mayor interés, y que no tiene por qué acompañar el resultado que le dé a Microsoft, así como también las ideas de la empresa pueden contribuír al perfeccionamiento de la iniciativa. Como lo puede hacer MDA (Model Driven Architecture), aunque Jezz no desee entrar en esa discusión.
Más aún, es absolutamente legítimo suponer que el libro de Greenfield, que obra como sustento de SF (uno referencia al otro, mutuamente), sea aplicable con otro conjunto de herramientas que no sea Visual Studio Team System (VSTS), ni sus extensiones. Por esto mismo el concepto es interesante, conveniente de analizar, poniendo entre paréntesis los recursos concretos con que Jezz construye. ¿Es generalizable el tipo de problemas con que Jezz se encuentra? ¿O tienen que ver con su implementación de la idea de SPL?.
Sobre esto trataremos de escribir, con los limitados recursos de tiempo que disponemos. Si fuera posible, sería bueno presentar también otros puntos de vista que hoy existen sobre cómo resolver SPL.