Software Factories: Part 2 – Types of Factory

[Software Factories Series]

There are a number of ways to implement the Software Factory Principle (Remember the principle says that any method to enable mass-production of software (especially standardized non-functional requirements) at a lower cost and in a shorter time constitutes a software factory of sorts.

Here are a few of the more common approaches:

1. Service orientation
Common Services (standard non-functional requirements) are implemented as SOA services. These need to be understood and published so that developers are aware of which common services they can use and exactly how to use them. SOA provides standard ways of doing this. The effect is that code should only be written for explicit functional requirements as the critical-mass of standardized non-functional requirements can be built up as needed.

Strengths

• Very loosely coupled
• Changes to a common module are immediately available to consumers
• Source-code for common services need not be seen by external developers, only the contracts for using these services needs to be known.
• Allows parallel development efforts, provided development of common services is well managed.

Weaknesses

• Governance of deployed common services is complex to manage

2. Smart Clients
The non-functional requirements are coded into a smart-client that exposes a library of functions to the functional modules which simply snap-in to the smart client framework.

Strengths

• Code for the non-functional requirements need never be seen by external developers, only the calls need to be known.
• Code executes in a distributed environment with greater flexibility to provide performance requirements.
• Allows for extremely parallel development efforts, while maintaining a common framework.
• Will scale very well.

Weaknesses

• Need to deploy the smart-client to all users when changes are made to common modules.
• Fairly tightly coupled, although functional requirements could be deployed as SOA services.

3. Common Code Libraries only
This method simply relies on the developer to re-use code from a common code library.

Strengths

• Ensures common approach to standard problems

Weaknesses

• Relies on the discipline of the developer to use the standard modules and not code their own version
• A Change to a standard module would require that all applications using that module would need to be recompiled and tested.
• Very tightly coupled.

4. Monolithic Applications
SAP for example is a single Uber-application that has many modules and performs many tasks. All of the non-functional requirements are standardised and cannot be changed. If one were to be changed, it would automatically be changed for all the other functional modules. All of the non-functional requirements are already coded into the SAP application and adding functionality involves coding the functional requirements only.

Strengths

• Similar to the Smart Client approach

Weaknesses

• Businesses can seldom function on a single piece of software
• This software will become extremely complex
• Very tightly coupled

Summary
There are numerous ways of deploying the Software-Factory Concept to speed up delivery of functional requirements, each with its own strengths and weaknesses.

I recommend either of the first two approaches (Service-orientation or smart-client) or a combination of the two. These provide most of the benefits of a software factory and less of the drawbacks.

Note that they have a management overhead. If they are not managed properly you will gain little benefit or in extreme cases if very poorly managed you may end-up worse-off than you were when you had discrete unmanaged code for each application.

Technorati Tags: Software Factory, Development, Custom Code, Code Generation,