One of the new buzz words in IT is “Software Factories”. Although this methodology is in its very early stage, I think it is important to understand the concepts behind this methodology. Because Software Factories is a “new concept” and the topic covers a lot of new stuff, introducing these concepts can be hard (at least for me). Therefore I am looking for a way to get familiar with Software Factories bit by bit. Maybe, mapping Software Factories to concepts that I am already using at this moment can help. At least it gives me a starting point from were I can think about Software Factories and explore the possibilities of this new methodology. Let me share some of my thoughts about the roadmap I think is best for me to get familiar with Software Factories and start working with it in the near future.

Software Factory

In short, a Software Factory can be best described as a fully configured development environment for developing a particular type of software. Based on the fact that currently software development isn’t as successful as we want it to be this new methodology is introduced. The methodology is build on experiences gathered from more successful and much more productive industries like for example the car industry. Within these industries it is very common to use highly standardized processes, predefined designs and reusable components to rapidly manufacture products. This results in a very productive manufacturing process with predictable quality of the manufactured products. Lessons learned from these industries are now used to create a new methodology, called Software Factories. Software Factories targets the software development industry and aims to provide the same kind of advantages achieved in other industries.

Although Software Factories are still evolving and the methodology isn’t fully supported by tools yet, I think it is possible to start using some of these concepts in software development. To explain what I think can be done today, let me try to map the concepts of Software Factories to concepts that are more common (for me) within software development. For this purpose, let’s assume we have a logical architecture defined within our organisation that we are using for software development. Let me explain what I mean by a logical architecture (I will not cover this in detail at this moment, just enough to make my point. This is just my imaginary architecture J).

Logical Architecture

A standardized logical architecture can help architects break down the requested business functionality to one of the different responsibility domains. Well defined responsibility domains provide guidance to IT project members during the design and implementation phase of a software development project. Some of the keys to success in this area are standardization, patterns and frameworks. Having these in place makes software development more manageable and can guarantee a constant quality. Most of the time there is some guidance available, very often in the form of a Word document or some standard components (framework) that can be used. Unfortunately the usage of these guidelines isn’t embedded in the whole development process and is not supported by development tools at all. Let’s have a look at how Software Factories can help solve this “problem”. To make things more clear let’s assume we have a logical architecture defined within our company. Within this architecture we make a distinction between different domains:

·         Presentation domain; this domain hosts all user interaction related features. It hosts features like dialog management, multi channel support, etc.

·         Process domain; this domain is responsible for controlling the actual business process. The business process can be best described as the way an organisation is handling its procedures, workflow, tasks and information. The business process coordinates the tasks and makes sure they get executed by either communicating with the end user (through the presentation domain) or the business information services.

·         Business information domain; this domain maintains all information within the organisation. Information can be grouped together in logical area resulting in one or more business information services. Business information services are autonomous services and deliver information, or perform a business action on behalf of the business process.

·         Infrastructure domain; this domain represents the infrastructure that will be used for the application. This includes the messaging infrastructure and other generic services providing the so called ‘cross-cutting concerns’ (e.g. security, logging, instrumentation, etc.). Services and features included in this domain are not application specific and can serve more applications at a time.

From logical architecture to Software Factory

So, now we have our logical architecture defined, what’s next? The reason we defined separate domains within our logical architecture is to group together services with similar responsibilities or capabilities. In the ideal world there should be guidelines available that helps architects and developers to implement services in one of the above described domains. These guidelines can be in the form of a simple word document but can also be represented by a framework or a set of patterns that must be used by the development team. This is exactly where I think Software Factories come in!

Software Factories aims to provide a fully described and configured development environment for a specific type of application (read: domain) Thinking a little further and having a look at our logical architecture I can define at least four Software Factories (one for every domain in the logical architecture). Although four fully implemented Software Factories should be sufficient for providing the necessary guidance for implementing services or components in each of the four domains, I think I am not there yet! I still need a standardized way for translating the business needs to components or services in one of our four domains. To solve this issue I can create another Software Factory that provides guidance in mapping the business requirements to one of the described domains in our logical architecture. This overall Software Factory can be my factory that targets web based distributed applications and is composed out of the other four Software Factories. The five Software Factories together cover all concerns for building web based distributed applications.

Because I defined five separate Software Factories (instead of one big one) each of the factories exactly targets a group of people in an ordinary IT project. The overall Factory for example, targets the business analyst and the architect who work together to gather the necessary information from the end user. This software factory describes the process how to translate and group together the requirements from the end user to services in one of our four domains. The Factory that targets the presentation services domain provides the web developers in the project with the necessary patterns, frameworks, and guidance to implement the user interface services and so on for the rest of the factories.

So, now I defined my Software Factories, what’s next on my to-do list?

Software Factory schema and template

One of the important things in Software Factories is a software factory schema. Basically this is a document that summarizes all artifacts we need to produce, to successfully develop a piece of software. This schema doesn’t only tell us what products we have to deliver and how they look like, it also tells us in what order we have to do this and what is the relation between the several products. The software factory schema contains both fixed and variable products which makes the software factory more flexible. Having a well defined software factory schema isn’t actually new (except for the name). Some other methodologies (like RUP) also summarize and describe the artifacts that must be created during a software development project. However, I think there are some differences between these methodologies and the Software Factories methodology. Within Software Factories the list of artifacts and the description of the artifacts are much more targeted at a specific type of software. Other methodologies tend to have a more general way of describing the artifacts, they don’t really target the specific domains in our logical architecture for example. I think the advantage of the software factory is that in the end it provides much more guidance!

Having the full list of artifacts (and their description) in place doesn’t do the job. To make it really useful we need the implementation of all these artifacts and more importantly we have to make them available to the development team. This is where the Software Factory template comes in. A Software Factory template is a collection of patterns, frameworks and a Domain Specific Language (DSL) that can be loaded into a tool (for example Visual Studio 2005 Team System). The combination of the software template and the tool helps us automating the software development process. One of the main purposes of the template is to configure the tool and “guide” the development team through the process of building a specific type of software (in our case, software that fits in one of our domains in the logical architecture).

So, where are we? If we think Software Factories is promising enough to invest in, I now have a possible approach to start implementing (or at least think about it) this methodology step by step within my daily work. I can simply pick one of the responsibility domains within the logical architecture and start describing the artifacts that we need to successfully deliver software within that domain. Although I think this still is a lot off work (and challenging), focussing on one responsibility domain can help to reduce the complexibility. By the time I defined and implemented the artifacts for the first responsibility domain, Microsoft might be ready to provide me with the (stable) tools that make it (better) possible to write my own Domain Specific Language’s and support our Software Factory from within our development environment (VSTS).

The above are my first steps in the world of Software Factories. If any of you have a better approach to get familiar with this, please let me know!