Software Factories: Part 1 – An Introduction

[Software Factories Series]

I have been aware of the Concept of a Software Factory since about 2003. The Principle is very simple: If you are producing software, tool-up in order to produce good quality software that meets your requirements, at a very low marginal cost (cost of delivering one more business requirement) and in a very short marginal time (time to deliver one more business requirement).

Software is like a Car
Some cars have air-bags and navigation systems, but can be produced in the same factory as cars without either. Software Factories should be designed with the non-functional requirements in mind. If we consider the example of a car, the only real functional requirement is that it should transport people from A to B using public or private roads. Some of the definitions of what is considered a “car” constrain the designs (weight, number of axles etc). Other than these the remainder of a car’s features are in software terms considered non-functional requirements:

  • Is it safe?
  • What are its performance ratings?
  • Convertible or fixed roof?
  • Is it secure?
  • Luxurious or Basic?
  • Manual or Automatic?
  • Spare Tyre or run-flat tyres with no-spare?

The Software equivalents should be fairly obvious:

  • Redundant systems with fail-over capability
  • Hardware requirements vs algorithmic efficiency
  • User Interface for speed or ease of use
  • Secure User Authentication and Authorisation methods
  • Manual Installs or automatic updates
  • Fat client or Thin client or both
  • etc

Software is not like a Car
The Difference between Cars and Software is that potentially every piece of software has a different functional requirement, while pretty-much every car has the same functional requirement.

So in a car factory we can tool-up to produce homogeneous units with a uniform purpose, but with modular non-functional requirements that can be selected as options.

In a Software scenario the non-functional requirements remain modular and “optional” while the functional requirements have to be handcrafted or individually tooled.

So immediately the benefit of automating the numerous non-functional requirements for both software and cars is evident. There are several approaches to achieving this which will be discussed in “Software Factories: Part 2”

Standardized non-functionals are a prerequisite

The optimisation of the software coding process to ensure that non-functional requirements are not handcrafted or individually tooled is not sufficient. The greater organisation needs to accept the standardisation of these non-functional requirements before this becomes viable.

Once everyone accepts that tyres are made of rubber and filled with air, then the variables become size, durability, speed rating and aesthetics. If we cannot get everyone to accept the basic design of a tyre, our variables become infinitely more complex and we end up re-inventing the wheel with every new car design! (I know you saw that one coming).

Software is very similar in this respect. If the organisation can accept that the user interface for all web-based software looks the same and the user interface for all fat-client software looks the same, then I can derive benefit from tooling up to automate the creation of these.

An Ideal Example
I was involved in designing a software factory where all the software our company needed to produce was either form-based or generated a report. A standardized method for defining stored-procedures allowed us to automate the creation of the forms on-the-fly in the front-end and also automate the forms for inputting the report-parameters.

So the only handcrafting was the database design and the stored-procedures that interacted with the database. Everything else was written once, compiled once and deployed to everyone once. This fat-client included Authorisation and Authentication modules, data access and routing modules, presentation formatting, workflow calls, disaster recovery processes etc.

Now this was an ideal environment where we only had SQL databases and almost all software was internally developed.


We had the option of writing each discrete business requirement as a discrete and monolithic piece of custom code. We chose NOT to do that. We chose to design a software factory that allowed us to dramatically reduce the quantity of custom code written (which now only needed to support functional requirements) and we never again had to write any code to support non-functional requirements.

The time-to-market for each new business requirement was slashed, and we gained many other benefits as side-effects of this process.

So in each corporate environment where significant quantities of custom development takes place there will be some combination of non-functional requirements which can be automated to a greater or lesser extent to get the very real benefits of a Software Factory.

OK. Concept introduced! Next time we’ll talk about the various options for designing a Software Factory.

Technorati Tags: , , , ,

This entry was posted in Technology, Trends and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *