Software Product Line Migration and Deployment

Abstract:

We describe a method to migrate multiple instances of a successful single information system to a product line. The deployed product line is able to deal with the over time evolved variants in a cost-effective manner. We proposed and used federated architectures that partition the software into so-called genericity layers. We argue that federated architectures are at the heart of product lines, and we provide compelling arguments as to why federated architectures are a sound weapon in today's corporate strategy: they enable smooth enterprise integration and rapid change. We support our arguments with a real-world case: we successfully migrated a large global transaction and settlement system with many site-specific variations to a product line with a federated architecture. Moreover, we measured the success rate of this architectural modification effort by showing that the annual direct cost savings are in the order of millions of dollars during the deployment of the product line.

0.0.0.1 keywords

proactive/reactive product line, software mitosis, configuration oscillation, grow-and-prune model, federated architecture, genericity layer, relativistic effects of software engineering, release indigestion

Introduction

Traditionally, hardware product lines enable the rapid production of variants of products. This so-called mass-customization can have a strong competitive advantage, for instance, National Bicycle increased its share in the Japanese sports bicycle market from 5 to 29% by moving from mass-produced bikes to mass-customized ones. Instead of a few models, a customer now has a selection of 2 million options for combining size, color, and components. And with an adjustable frame, the ideal measures are taken. In two weeks a fully customized bike is delivered to the customer. Of course, you cannot do this when each bike is seen as a unique product. You need a product line to produce the bikes: in this case computer-controlled welding robots that can handle all the variation points.

This can be rather successful, however, in an increasing number of products the information technology (IT) component is becoming the dominant part. Since IT is notoriously late, suffering from cost overruns, and not delivering what was asked for, this also influences the release date and overall quality of the embedded products. For instance, we heard from people working in the automotive industry, that the release date of a new car is sometimes delayed since the software supporting it is not ready. Also cars in operation start to resemble the nature of information technology. A new model car turned out to have a too sensitive airbag system. This is dangerous, so the cars were asked back for a standard repair. In one case we know of, this repair caused another error. To replace the airbag card, the battery was disconnected. For some unknown reason, the motor management processor restarted with the parameters for a smaller engine than actually present. At low speed the car did not expose any problem. But there was: by systematically injecting not enough fuel, the motor will be slowly destroyed. More speed, means more hydraulic power for steering the car. But the power steering routine apparently depended on the wrong cylinder capacity and not on actual speed, so that the necessary hydraulic power was not appropriate for the real velocity--another consequence of the motor management processor that thought the engine was smaller. This resulted in an uncontrollable car at 120 km/hour. We admit that these are the perfect conditions to test in vivo whether the new airbag card would operate correctly. Fortunately, in this case, it did not came that far: the owner, a retired machine designer, inferred in only two weeks from a combination of symptoms and indicators (like a systematic decrease in fuel consumption) that someone or something must have tuned the engine erroneously. The car mechanics told him that they could not even make a change to the entire engine, and they could not find anything. When they connected the car to a diagnosis station, the car owner noticed accidentally that the reported cylinder capacity was 23% too low. When the mechanics reset the motor management processor to the correct cylinder capacity the problems were solved. This feels more like debugging an embedded system, than maintaining a car.

To come to grips with the problems of IT in embedded products like cars, MRI scanners, high volume consumer electronics, etc, the hardware product line idea has been transposed to the software embedded in these systems. Thus the software product line was born . In some cases a number of unique instances of software are migrated to a software product line. For instance, CelciusTech, a company constructing radar systems on warships, decided to migrate to a software product line approach to shorten development schedules, and obtain more uniform systems. There are more examples of migrations like this, but nowadays the majority of the embedded systems, for instance high-volume consumer electronics, start with a software product line right away. We call this approach a proactive product line .

In the information systems world we see a different pattern. Information systems start relatively small, and they grow to larger systems when the business can deploy the software successfully to create value. As soon as business starts to use the software, other business prospects emerge leading to updates. When success is spread, so is the software: often such systems are adopted worldwide within globally operating organizations. When the software is in use at many sites, inevitably local modifications are necessary. A local modification can be either a change made by a site, or a site-customized centrally controlled modification. Without proper central governance, only local modifications are made, and the original core system will multiply like a living organism, and after a while a significant number of variants of the system will emerge. We call this phenomenon software mitosis .

For large information system owners it is not uncommon to fall prey to software mitosis. There are a few common causes:

increasing customization;

local control and modification;

mergers and resulting consolidation;

geographical distribution of the organization.

For instance, the US department of defense possesses myriads of similar payroll systems and many variations of personnel training systems, and there is more redundancy [ 5 ]. In these situations, the crucial question is: How to bring all this variation under control? For all of the above cases, the ideal solution is the same: turn the existing variants into one overall system where the points of variation are migrated into a product line. We call this a reactive product line . Both proactive and reactive product line approaches are extremes and reality is usually somewhere in between. Often, even when starting with the green field to develop a proactive product line, this evolves over time to a structure that is quite different from the original. The forces of increasing customization for a growing user base, of local control and modification, and of corporate mergers and resulting consolidation are very likely to result in significant architectural alteration. So whether you are to deal with much historical evolution and accident (i.e., reactive case), or started with an explicit and clear architecture before encountering the aforementioned forces (i.e., proactive case), or you are in a hybrid situation somewhere in between, the methods we describe in this paper are very likely to be useful.

Configuration oscillation

Software mitosis should not be viewed as a bad phenomenon, because apparently the business recognizes the value and<