The words 'software' and 'components' are being put together with increasing regularity these days, but the combination is already starting to look limited and restricting. The combination that now seems to sum up the trend more accurately brings together the words 'software' and 'industrialisation'.

The recent announcement By Fujitsu-Siemens of its Infrastructure as a Service included an update of FlexFrame, with an SAP-specific implementation marking the start of what is expected to be a growing range of application-specific implementations of the technology. FlexFrame provides what is, in effect, a container for the core code of an application like SAP, together with the specifics of the implementation that tailor that code to a specific set of business tasks. This creates an environment in which that specific implementation can be replicated and re-used within the Infrastructure as a Service.

Many users are going to fit a business model where multiple implementations of the same application will be required around different operating divisions, regional offices and the rest of that panoply of geographic options that are the stock in trade of the big global businesses. This way, they will get the opportunity to develop the application once and then re-use it, quite often with only minor localising adaptations, around the rest of the business.

Given the costs associated with implementing even a single instance of such applications, the potential for cutting implementation costs while at the same time speeding up the delivery process is a capability that must be worthy of closer inspection by potential users. And the fact is we can be sure that other popular applications will be the target for FlexFraming in the near future.

This does have the potential to be the start-point of a new industrialisation movement. This is not just die-stamping the few hundred lines of specialist code that make up a software component; it is not even the die stamping of a large applications package. This is getting close to die-stamping a complete, tailored implementation of a finished applications solution. Because of the savings in hand-crafting specific implementations—which is still often the case for different offices or divisions within the same global business—what seems at first like over-kill ends up making economic sense for users.

But this will interest not just users, however. There are many specialist integrators that have built businesses around these major applications, and the possibility of industrialising the integration process is likely to be seen as a two-edged sword. On the one hand it will allow them to package much of their implementation technologies and Intellectual Property. That could allow them the opportunity to develop new markets by offering faster, lower cost implementations to a far wider range of customers. The traditional 80:20 rule would no doubt apply, where the industrialised package would contain 80% of the implementation and IP, with only 20% being in the form of final adjustments to fit the customers' specific needs. This would certainly suit those integrators working in a vertical market sector, where the same IP and core implementation routines are employed for every customer.

On the other hand, of course, some of these implementers are likely to see such industrialisation as a negative development that simply reduces their revenue potential. It will, of course, be up to customers to decide which route they prefer to follow if the choice is available.

As it develops, software industrialisation may also change applications and service development practices. An important stage in the development process is defining the requirements needed. This is now the driver of that process, but it could easily become the key to future industrialisation. One only has to take Requirements Management systems a few logical steps further to see how the definition process could be mapped onto increasingly industrialised infrastructure and business process building environments.

This could be one more step towards the point where business users become, in effect, service and applications developers. Within an Infrastructure as a Service environment, such a model would allow business users to define and create the services required for 'just now', and order their removal once the task is completed.