Introducing the Software Factory

In my previous posts, I’ve been providing bits and pieces of information about the Software Factory and what it does. I’ve stated that it is used to generate the entire system, but I’ve been quite vague about how this is done.

In this post, I will start laying out how it works.

What is in a name?

I use the term Software Factory very loosely. Maybe I lack imagination, but over all of these years, I still have not found a better name for it.

To me, Software Factory is a term, not a name. It is like Command Line Interface (CLI) or Integrate Development Environment (IDE). I often refer to it as SF.

In the industry, Software Factory has been used to represent several things in the past.

But I think it really applies to what I’m describing here. I define a Software Factory as:

A system that automates the manufacturing of software or software parts

How does it work?

I’m sorry, but there is no AI here. The only intelligence required is from people. This is just a computer system that does what computers do best: Perform massive amounts of small, menial tasks over and over again.

At a high level, the Software Factory is pretty simple. The SF takes in two inputs: Models and Solutions. And it processes this information to produce Code.

The following diagram shows the major pieces:

Software Factory – High-level diagram

Here is a list of those pieces and the role they play in the system:

  • Designer: A person that analyzes the problem space and that uses models to describe it.
  • Models: Describes the expected content and behaviour of the desired system.
  • Engineer: A person that defines the model(s) structure and uses solutions to describe how to convert it into the desired end product.
  • Solutions: Provides information to the code generation system on how to transform models into code.
  • Code Generation: Mechanisms that applies Solutions to Models and model elements to generate code.
  • Results: Provides the results of the code generation.
  • Generated Code: Is the code that is actually generated by the system.


Models are nothing new. They are tools used by people to describe and simplify complicated things that surround us. We use them in pretty much every domain including science, medicine, chemistry, etc…

By leveraging a specific set of models, the Software Factory offers its users a tool to think about the problem space and provides the user with the ability to document it in a way that the generation system can interpret it.

Models are the language used to communicate between the Software Factory and its users.


While all the instructions to generate code could be built and compiled directly into the software factory, that would be very limiting.

In order for the SF to be flexible, Solutions are built with all the information required by the Software Factory to convert Models into source code. That makes it possible to write a generic system that is able to adapt to multiple different situations,

This flexibility means that we can modify the system at run time and re-use Models for different purposes, targets, and even entirely different programming languages.

Code Generation

This is the core of a Software Factory. The factory needs to divide the models into manageable pieces and apply Solutions to them to generate the pieces of code. Then it needs to assemble all those pieces into a set of files that is the source code for the generated software.


Result provides information that describes the code generation operations. Each step of code generation reports status and error messages if relevant.

This information provides the final status of the generation operation.

In addition, this information can be useful to the Engineer when designing solutions.

Generated Code

This is the final output of the Software Factory. The resulting code files are laid out as defined in the solution.

Simple right?

Well, this is a gross simplification. As I will describe in future posts, the reality is much messier. There is a lot of complexity that comes with each of those elements.

Add to that using multiple models, multiple solutions, multiple builds, multiple results. Heck, sometimes just the sheer volume of information becomes problematic. There are a lot of challenges.

However, even now we can start to see the awesome potential of this technology.

But those are all stories for another post…

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: