Partilhar via

Factories 201 - When would you build one?

  • Artigo

Read this post to find out what the context for these 'Factories 201' posts is.

Following on from Edward's post "Factories 201 - What are they (concretely)?", I am going to contribute what I think is the next question in the logical sequence hopefully going through your mind -> "So, when would you build one then?" .

Here, we are going to explore the reasons you would look to building a software factory and the things you need to have in place to start that process. The process you need to take to achieve a factory, we can talk about later (perhaps a future post called "How would you build it?") . For now let's look at 'when' it's applicable to build one.

I am going to break this post into 3 sections, the first one is the pre-requisites you need to have in place to build one, the second section is the objectives you have driving you to build one. (It's a little 'back-asswards', but most developers think of the 'what' before they think of the 'why'). Then finally, the third section is a quick summary re-iterating basically 'when not to build one'.

Pre-Requisites

In order to start down the path of building a factory, for the most part, you need to have done a bit of work up front to get to a stage of considering building a software factory. You may not have done that consciously or indeed even with factories in mind. But nonetheless you need to have done that already. Starting from scratch in a new domain with no assets and no domain knowledge is not a recommended path for factory success.

This section lists the things you need in place to consider building a factory.

A Specific Domain

The very first thing is to have identified a specific problem domain and solution domain that your factory will address. That involves scoping the problem domain tightly enough that it is 'specific enough' to warrant investment in a factory. Without a specific enough domain, you are either 'biting off more than you can chew' and your factory will never be successful (relative to others that are more specific and specialised enough), or your domain is too generic that the value of your factory can provide to solving a particular problem well enough is too limited.

[Have a look at this article (in the 'Abuse' section) about some of those pitfalls.].

The right balance to achieve between 'specific enough' and 'too generic' is pretty hard to advise upon, but I think common sense prevails generally here. You might want to look at existing frameworks or tools already available for an indication of domain scope.

A Well-known Domain

The second step is to target a solution domain which you know very well. It's very important you choose one you have already solved successively and successfully many times over. This means that you already have the domain understanding and expertise in this domain to generalise the domain. You already know the problem domain and a solution domain intimately well, and know what to preserve of that knowledge and experience in a concrete tool that builds specialised products for that domain. The next steps of realising a factory from that should be reasonably straightforward enough from here.

Without this knowledge you are bringing too many ‘unknowns’ to the table. Unknown scope, assets, variability, concerns, roles, resources, technology, patterns etc. Since the process of building a software factory is the automation of existing assets and variability, and assembly of a product line of product variants (product ‘flavours’ if you like), you will not know how to do this the best way without the prior knowledge and experience of doing that at least for one 'flavour' of your product.

You would be poorly advised to attempt to build a factory for an unknown domain.

Existing Assets

To follow on from the previous section, having assets in some form before you start building a factory is absolutely a pre-requisite. Without them you have an arduous task of creating assets for you domain, which is both time consuming and risky. You don't need to create all your own assets, some of the best ones are done by other domain experts. Your job as a factory builder is to bring them together to address a specific domain.

So what do we mean by assets? Assets are physical things that are used to define and assemble the product of the factory.

We can look at the assets in more detail perhaps in a future post called "What would you build?") . But for now, the assets we are talking about are things like: Reference Implementations, Frameworks, Class Libraries, Code Templates, Patterns, and other guidance.

Skilled Resources

In order to have the above domain knowledge and assets, it goes without saying you must also have the time and skilled domain resources to build and support the development of a factory. These resources are absolutely required to have the domain experience and skills to follow that through. Software factory development demands the very best skilled resources to focus upon them. Since in building a factory you are codifying that domain knowledge and experience and onselling it.

Later we can look at how long that development may take based upon some rules of thumb (perhaps a future post called "How long will it take?" ), but for now its suffice to say: You won't succeed without the domain skills, and time and resources to construct your factory.

Of course, in most organisations the distribution of resources, particularly skilled ones, is very much dependent on the organisational culture, values, middle-management support and customers. This is one aspect many organisations naively ignore. Software factory development, like application framework development, is often seen as an investment commitment separate from the core line of business. This means, that you see no immediate return on this investment, and unless the organisation ardently protects its skilled resources and lets them focus on this investment undisturbed for the duration - the development will fail. Perhaps we can explore this some more in a future post called "What do I tell my manager?"

Objectives

You need to have a clear picture of why you want to build a software factory. There has to be concrete business objectives driving for the construction of one. Building a factory is no trivial task, (especially today) so, to make it worthwhile you need to be clear why you are making an investment in one.

This section lists some of the more important objectives for wanting to build a software factory.

Economies of Scale and Scope

In order to justify the additional expense in building a software factory (compared to a one-off development project), you need to at least be required to want to build multiple instances of a ‘product variant’ from the factory.

[A 'product variant' is simply the same product created as before but with different characteristics - perhaps a different colour (in the simplest sense). So a factory creates product variants which each have similar structure for the most part but different characteristics.]

As a general rule, you will need to want to build of the order, no less than ~5 instances of a product from your factory (during its useful lifetime). And perhaps no less than 2 variant types. We can investigate more deeply how we came to this number, and the additional costs perhaps in a future post called "How long will it take?" . But any less than this number and you will simply not be able to justify the additional cost it takes to automate the production of your products.

The number of product instances achieves economies of scale. The number of different product variants created by the same factory achieves economies of scope. You need to achieve one or other with your factory to be profitable.

Guidance and Re-use

You will want to build a factory to encapsulate your expert domain guidance, experiences and knowledge, your architectures and your patterns. You want to do this in a way that allows others to re-use that in their products. That way, no one will want to re-invent the wheel every time they approach this domain, instead they will use your factory to solve the problem.

Encapsulating your guidance in your assets represents your value in the re-use market for that domain. The factory that encapsulates the best guidance for re-use, ought to win the deal. (The truth of that remains to be seen of course).

Automation

The basic objective of building a software factory is to provide a tool to automate design and development tasks. There are many tasks that need to be performed in building a solution to a problem domain. Without automation, you are simply providing only written guidance for completing manual steps of a process.

This does not have to be full automation. In fact in most cases, most tasks will only ever be partially automated, and will require further modification either manually or by another process.

Automation can take many forms, but you'll want to use automation to remove the mundane, and predictable, whilst preserving the creative design experience for those using your factory. Don't underestimate how potent creative thinking is when trying to find people to program computers. The future users of factories tomorrow are the programmers of today, they want to be lazier, not less smart.

Usability & Productivity

In order to reach high levels of productivity, you need to increase the use of abstraction, and supplement that with high usability of your factory.

Increasing the level of abstraction, increases productivity through these mechanisms: 

  • Addressing a larger, less-highly domain-skilled audience
    • More users are available, and able, to use your tool to get the job done
  • Providing simplified representations of the domain
    • The users can focus on what makes the product variants unique rather that what makes them the same.
    • The users can focus on the important aspects of the variable parts of the product (in terms of the generally understood problem domain)

Abstraction and Usability are key quality attributes of a software factory, and key to the adoption of any specific factory. Perhaps we can see how that is in more depth in a future post called "What should you strive for? "as a builder of a factory.

Summary - 'Don't build one when...'

So, a bit longer than intended, but I’m hoping to drive some points home, particularly emphasising when a software factory is appropriate based upon what you have and what you want to achieve.

To summarise here are some general guidelines when NOT to create a software factory.

  • When confronted with a new problem domain.
  • When the solution domain is unknown or untried.
  • When the solution domain is broad and generic.
  • When you don’t have the domain skills, knowledge and experience of this domain.
  • When you possess no existing assets.
  • When you don’t know the variability of the solution, or your desired product variants.
  • When there is nothing to automate.
  • Just because it sounds like, and looks like, a cool thing to do!  - very, very bad idea - be shamed!

Comments

  • Anonymous
    February 12, 2007
    There have been a few great posts in the last couple of weeks about building software factories. Jezz

  • Anonymous
    February 25, 2007
    Tom Hollander's blog mentions a Software Factory Building Roundup: There have been a few great posts