FAQ - What is a Software Factory?

The question usually goes something like this:

Define what is a Software Factory? Followed by something like this: I built a command line application/a guidance package/a script (make your choice) that code generates some useful component – is that then a software factory too?

This one is a real challenge to define in a short post.

Chinnese version here.

Backgrounder

This is more than a fair enough question, and most people are now asking it, and trying to distinguish whether they already have factories or whether these things are something new, using something they already built or know about as a starting point for understanding the difference.

Answer

Let's start with an official definition of a software factory, then I will try to interpret that in simpler terms and expand those with examples to hopefully aid your understanding.

An official, extensive definition can be found here, but I am going to start with this shorter one from Jack and Keith's book on software factories. Or you can find some others definitions here in our glossary.

"A Software Factory is a software product line that configures extensible tools, processes and content using a software factory template based on a software factory schema to automate the development and maintenance of variants of an archetypical product by adapting, assembling and configuring framework-based components."

Woah, okay, (gulp!) that's the academic definition, let's expand that a little: So, the essential ingredients of a factory are a product line, which is created using a set of tools (i.e. editors, code templates, recipes, domain specific languages, command line tools, etc.). These tools then configure a generic, extensible development tool (like Visual Studio) using a thing called a 'factory template' that is really just a physical incantation of a 'factory schema' (i.e. the factory template contains the tools, guidance and a blueprint of the things the tools create of configure). Then provide automation for the development and maintenance of different things the factory creates (a 'product') by assembling the required components, ideally re-using existing frameworks that are tailored for the created products to work on.

OK, the key pieces here are the product line, the factory schema, its factory template and a product. I reckon, if you have all these you have a pretty good approximation of a factory, because most of the other stuff comes along with having these.

The frameworks are pretty important too, because with one you have taken a large step in the process of defining the variability points of the products in your product line, and most of the work is already done for you. Remember, you should not be creating factories for solutions you have not yet solved, so the basic pre-condition of wanting to create a factory is that you already have some solutions with assets to automate.

[If and when the Visual Studio team release tools to enable you create custom Software Factories of your own, the Microsoft definition of the term will be concrete, and, I guess, you only have a Microsoft approved factory if it fits this concrete template. But until then, you can still create your own factories with the current tools and a bit of innovation to fit the definition above].

A Product

Let's start with the product. To clarify; a product is the thing a particular factory builds.

"A product is what falls of the end of a factory production line."

Don't confuse a 'production line' with a 'product line'.

Now, a product does not have to be a complete, finished, shrink-wrapped, boxed product like 'Microsoft Word', which is the thing most people have in mind when they hear this. It is simply the term to describe the output of the factory.

For example, a car engine manufacturer created car engines as their 'products' and sells them to other factories to assemble them into cars. The engine is still a 'product' of the engine factory.

So, all factories create a useful product that may or may not be assembled into larger products by other factories.

Factories define a model of this product, (a meta-model) which is the schema of that product, containing the parts and their variability points. This model provides the user with a means to create, configure and maintain the parts independently.

A Factory Schema and its Template

We already did quite a bit of work explaining a factory schema, so I won't repeat all that here.

But suffice to say in this context: it is the blueprint of the things the factory builds - the product (and its variants) and there configurations. It defines not only what the factory builds, but how to build it, the pieces it's built from, and the tools used to build them.

Incidentally, the 'factory template' is nothing but the tools, runtime, documentation, frameworks and other assets packaged and shipped as 'your factory' – perhaps within an installable MSI.

A Product Line

Now to the product line – what on earth is that? This is not the 'production line'.

"A product line consists of the product variants the factory creates"

OK, factories are expected to create more than one instance of product to be really useful (we call each one of these a 'product variant' ). To be precise, a product 'variant' is the instance of the product you have created, rather than the actual type of the product. A factory could define several different 'types' of products (each one fixing perhaps some variable aspect of the product).

Therefore, the solution domain of your factory is defined by its product line.

[There is a more in depth discussion on product variability and variants, (what it is and when to use) found here.]

So - is your command line app/guidance package/script a software factory?