Factorías de Software ¿Horizontales y Verticales?

Jezz Santos abre en su blog una dimensión de las factorías de software, versión Microsoft, que posiblemente sea una de las mejores maneras de cotejar las diferencias con el estándar MDA y otras variantes de desarrollo orientado por modelos. Desgraciadamente no tengo casi tiempo, lo que limita mis posibilidades de desmenuzar en detalle sus comentarios, pero trataré de releerlo, analizarlo, y luego apuntar algunas diferencias.
Para comenzar, se presenta el problema, en palabras de Jezz:

The title of this post would not mean anything if you didn't know what 'horizontal' and 'vertical' software factories were. In that case then for simplification, ‘Factory Verticalization’ merely means ‘Factory Specialization’. Ironically enough though, most of the factories being build today are ‘Horizontal Factories’, so specialization in these cases means ‘Factory Verticalization’.
In almost all my interactions with customers about factories I am constantly reminded that ‘verticalization’ is the one key principal aspects of software factories today which is largely going unaddressed (and poorly understood). I am convinced that there is a clear and immediate requirement that we need to deal with more effectively in the present. I go so far to say that without catering for Verticalization of any factory, would seriously limit the adoption of factories in the future. It is such an important aspect to provide for if we are to realize the full vision of product lines and asset reuse.

Inmediatamente, Jezz carga un poco más la definición:

Before I get into this lengthy discussion about different aspects of verticalization, I think I need to explain what we mean by 'Horizontal' and 'Vertical' software factories in order to set the right context for the discussion.
In software factories we use these terms (vertical and horizontal) in the respect as they use them to describe markets. In software development these terms are generally well understood to differentiate broad skill-sets (or more general capabilities) typically focused at particular technologies and platforms, from the skill-sets/capabilities applied to specific industry domains (e.g. finance, manufacturing, retail, etc). The intersection of these axes in software engineering, in theory at least, applies the expert technical solution people to build instances of solutions for particular vertical domains, under the guidance and knowledge provided by the industry domain experts. The assumption is that the horizontal assets (people and artifacts) can be reused (with some specialization) across many vertical domains - it’s really a synergy of the two axes.

Existen en este planteo dos aspectos para analizar:

1. ¿Software Factories representa un "mercado horizontal" para Microsoft?
2. ¿Qué distancia existe entre este concepto de lineas de producto, y el de Software Product Lines del SEI (para mencionar el centro que probablemente más trabaja sobre este punto)

Sobre el primer punto, así parecería demostrarlo el repositorio visible en Codeplex, (Microsoft patterns and practices, Software Factories), con cuatro casos desarrollados. Asimismo, las referencias de Jezz en su nota:

From a marketing perspective, if you can call it that (which is really isn’t), one of the primary reasons Microsoft currently releases only horizontal factories is that: at present, software factories are a new concept to the industry, and Microsoft is leading the charge here. It makes perfect sense that the first factories from Microsoft must have some large significance and impact and benefit to the existing marketplace. So they chose horizontal factories to tackle first

Sobre el segundo, las definiciones del SEI dicen algo distinto:

A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.
(...) How is production made more economical? Each product is formed by taking applicable components from the base of common assets, tailoring them as necessary through preplanned variation mechanisms such as parameterization or inheritance, adding any new components that may be necessary, and assembling the collection according to the rules of a common, product-line-wide architecture. Building a new product (system) becomes more a matter of assembly or generation than one of creation; the predominant activity is integration rather than programming. For each software product line, there is a predefined guide or plan that specifies the exact product-building approach.
(...) The common set of assets and the plan for how they are used to build products don't just materialize without planning, and they certainly don't come free. They require organizational foresight, investment, planning, and direction. They require strategic thinking that looks beyond a single product. The disciplined use of the common assets to build products doesn't just happen either. Management must direct, track, and enforce the use of the assets. Software product lines are as much about business practices as they are about technical practices.

A partir de aquí, conversaremos. Comenzando esta semana...

Nota: Esto es muy curioso...Desapareció del sitio de Microsoft el ítem sobre SF en Arquitecturas, y ya no se encuentra el enlace a la explicación difundida durante meses sobre el tema (http://msdn.microsoft.com/architecture/overview/softwarefactories/) . Tendré que buscar más (¿?)