Previous posts in the Factory 201 series:
In the previous posts we have set a good context for embarking on software factory development. Much of that depends on the support we get from management and what we have to start with (assets). One of the key questions from management to approve this kind of approach is "How long will it take?" which of course implies a similar hidden question "How much will it cost?".
Answering the hidden cost question above is not really what I want to give guidance on here since that clearly depends on so many different things. Better, I focus on the stated question about how long will it take.
[Before I do that, I want to make a BIG DISCLAIMER: The following guidance is based upon experience in this domain, and in no way represents absolute, verifiable estimates. I will give the reasons to the numbers I state and how they came about, (so you can derive your own specific calculations and factor in your own specific balances). Please use your common sense; this is not scientific proof, only best-guess estimates, and please comment if you see any errors that need to be corrected. Individual factory development cases may well deviate from those assumed here. When someone provides us a better means to make more accurate estimates, I’ll be sure to share that too]
I am going to split this post into the 3 areas to address answering this question. Firstly, the generation of assets, since that’s the core of what a factory is. Secondly the construction of the factory around those assets, and finally about the return on investment (ROI) you can expect from a factory development.
When we consider the time it takes to create the initial assets before you get started with building your factory, what we are really asking is "how long does it take before we can get started with building a factory?" This is because, as we saw in When would you build one?, you are strongly recommended to start with some initial assets before building the factory – typically, but not always a reference implementation.
Therefore the answer to this question is easy: You should have largely already made this investment in your initial assets!
You can probably skip this next bit, if you fulfilled the prerequisites as set out by When would you build one?
However, there may well be cases where your initial assets are in a state not quite ready for a factories approach, and require pre-work in further refinement - and this can be fine. Not all starting assets have been in the right re-use track from the get-go to be in the right state for re-use (i.e. fully generalised). For example you might just have a bunch of code templates or patterns to represent your product. However, the answer to this question is not so straightforward now.
Typically what is required for these assets is generalisation, refactoring and packaging into a reference implementation at the very least.
If your assets are just bare frameworks and class libraries then you can probably skip this refactoring step, and focus on building an initial reference implementation on that framework/library before you get started. The net result is that how much work you need to do there will depend very much on the following things: domain scope, technology availability, available best practices, asset maturity, domain skills, experience, knowledge and other factors that affect the quality of the assets.
[It's worth making a distinction at this point between the initial assets you have that make up your product (i.e. RI's, frameworks, libraries, code snippets etc), and the automation assets you build to make up your factory (i.e. recipes, templates, DSL's etc). Those factory assets you most certainly won’t have already created yet, and they are considered in the next section.]
Once your starting product-based assets are ready to go, the next consideration is how long will it take to actually build the factory-based assets, and complete the factory around those assets?
The answers really depends on what level of factory automation you want to go to. The simplest case might just be: you may just package your RI as it is and deliver a simple recipe with solution template that installs the RI as the final product. A more complex case might be a fully automated, integrated factory with multiple views, editors, DSL's, logical architectural designers, workflows, role management etc. Obviously, the effort to complete the latter example will require more investment than the former. Your factory might lie somewhere between the two eventually, but hopefully towards the later-end rather than towards the former-end, since this is where factories are going to go in the future.
As we will see later in "How would you build it?" the approach to building your factory is an iterative one. Each iteration focuses on a particular variability point of the product, and builds the automation assets for that. The factory is then used to create a new fully implemented product which would have only varied from the previous product, (from the previous iteration), by some variance in the product. The whole factory development will consist of many of these incremental iterations, and each iteration usually entails the creation of/modification to a factory asset.
Clearly we are going to have to go beyond a calculable estimate here to a rule of thumb, since the answer depend on so many variables. Building a factory is, in principal, the same thing as building any other developer tool or re-usable asset. Therefore, you can expect it to take of the order ~2-3 times longer to build the factory than building a product from it, from scratch.
What we mean here is the total time period from start to finish of the factory development as a whole, not the time for a single development iteration of the factory. You must consider that, at each iteration, (which will be considerably much shorter), you can still deliver a fully functional product. So the point of this is to highlight, that you don't need to wait 2-3 times longer than usual to get a product, you'll be getting one at every iteration right from the start. The only difference will be the products, at each iteration, will that it will become more and more customized and hence suited to a particular product scenario.
[You can imagine in reality this time may take longer if the resources that build the factory have to learn new factory building tools, and develop factory building skills and experience. The above estimate assumes the people building the factory are experienced at it. ]
The above estimate begs the question of course, if it takes longer to build a factory than the product, then what do we have to do to get a return on that investment?
The logical answer to this question is simply, that you must create more than one instance of a product for the factory to be financially viable. This was one for the stated objectives for building a factory in When would you build one?
Just how many instances are we talking about though?
Using the logic expanded below, you can roughly expect ROI only after ~3rd – 5th product instance is sold.
The ROI values stated above come from the following assumptions and estimate calculations:
To get our lower estimate, your first factory-made product sold only covers half the original cost of building the factory, so you need to sell more than 2 products (i.e. at least 3) to get the initial investment cost back.
The upper estimate comes from the realities of software development today.
All these considerations (and many others) contribute to the fact that more instances need to be sold to recover the cost. The actual upper estimate may well vary depending on many conditions affected by the variation of any of the above statements.
A Safer Estimate
For arguments sake, and to be on the safe side, considering the real world factors hinted at above, we should use a rough guide of requiring to creation of ‘many more than 5 instances of a product’ to recover costs. This is the estimate used in the other posts.
Hopefully we have given you some idea of how long it takes to develop factories (although not precisely scientific). Also that this type of development requires a larger initial investment with a deferred payback, which is typically quite different than normal product development for most, but nonetheless the same strategy as building reusable assets today.
This kind of monetisation strategy often conflicts with normal development projects (which normal generate profit after the first release of a product), and demands separate treatment from normal software developments. Another reason, why your management, and organisation needs to support a software factory approach.
Hopefully we have given you an idea of how to calculate the justification to move forward with a factories approach, and that you would not attempt a factory approach unless you were confident that you could return on your overall investment in one.