John D. McGregor is a visiting scientist at the Carnegie Mellon Software Engineering Institute. Peter Bell is CTO of SystemsForge.
Think about where your business was a year ago and where it is now. Whether better or worse, it's likely that your business environment has changed, and chances are those changes have altered how you think about software. Tasks that you haven't automated now have to be done so frequently that they're soaking up too much precious time. And that elegant abstraction you designed? It now takes too long to tailor for each new product.
This pretty much describes SystemsForge, a company that develops e-commerce, content management, and custom Web applications -- building more than 200 apps over the last four years alone, in fact. Originally written in ColdFusion, the first version of SystemsForge's software used a component-based architecture built around a content management system, with "Pages" within a "Site." When building a new Site, developers ran a wizard to generate the code forthe project, then used the content management system to add Pages with features such as product catalogs, checkout, e-mail newsletter systems, and event calendars. Each Feature was actually a component -- a series of interdependent scripts implementing the iFeature and iFeatureAdmin interfaces. iFeature handled runtime client requests and iFeatureAdmin provided a wizard to allow non-technical site developers to configure common options.
This approach worked well for the first few clients. When it started, the product catalog feature had 30 options and was implemented in a manageable 2,500 lines of code. But by the time SystemsForge had 40 clients, the featurecatalog had more than 450 configuration settings, nearly 13,000 lines of code. That was unwieldy, didn't scale, and was littered with configuration variables, conditionals, and loops that obfuscated the intent of the code. That's when the company opted for a software product line approach.
A software product line (SPL) is an innovative approach to software development that lets organizations develop, deliver, and evolve an entire line of similar products with much higher degrees of efficiency. The key characteristic of an SPL that distinguishes it from other development efforts: the extensive reuse of core assets. Those assets -- referred to as "essential practices" by the Carnegie Mellon Software Engineering Institute -- include requirements, architectures, designs, source code, and test cases. SPLs even include people, who share their expertise around the assets and procedures associated with a product line.
An SPL is most often used to manage a software portfolio, but it can be extended to companies managing a portfolio of end products, like manufactured goods, where the reuse of practices as well as parts is key to lower costs. Companies such as Cummins, General Motors, Hewlett-Packard, Lockheed Martin, and Nokia have invested in using SPLs, looking for better productivity, quality, time to market, and product line scalability.
Systems and Software Product Line Engineering at Lockheed Martin MS2
"At Lockheed Martin, the timely and cost-effective delivery of the latest technological advances to our customers is mission critical. Our goal is to constantly 'push the envelope' in employing state-of-the-art product development tools and methods." Norman Malnak, Chief Engineer and VP of Technical Operations, Lockheed Martin MS2
Lockheed Martin's Maritime Systems and Sensors (LM MS2) Division recently implemented a multi-year Common Product Line engineering initiative to reduce the time, cost and effort required to create, deploy and maintain its product lines. The new engineering approach had to minimize duplicate effort, maximize commonality among design and implementation assets, and optimize the reuse of effort across similar systems within the MS2 product lines.
As LM MS2 searched for an enhanced systems and software product line (SPL) engineering solution, it was clear that early generation SPL approaches did not enable the organization to fully integrate and strategically reuse engineering assets across the entire product development lifecycle -- from requirements, to design, development, documentation and testing. To address this challenge, LM MS2 decided to adopt an emerging second-generation SPL solution that provides a common framework and extends SPL variation management constructs across engineering artifacts in each stage of the lifecycle. This unified "Product Line Engineering" approach ensures that traceability, control, and processes flow cleanly across each stage of the lifecycle and enables LM MS2 to realize the benefits of its Common Product Line vision.
-- James Cezo, Principal Engineer, Lockheed Martin
The organization that builds the products in a software product line provides more than just continuity across a set of product development projects. The organization develops a production capability that will produce the products that are within the scope of the product line. This capability is somewhat like the production capability of a manufacturer such as Toyota. Each step required to produce a product is planned before the assets are finalized, and the steps are engineered into an effective and efficient sequence. This plan is used across the set of products; however, the inherent fluidity of software requires a flexible, craftsman-like ability to customize products like the Ferrari personalization program.
The production capability of the product line is described in a production plan. The production plan coordinates the actions of those who create core assets and those who use them to create products. The plan effects this coordination by defining a production method that describes how to build a product using the core assets. Although the production method places constraints on the technical approach to product building, a wide range of approaches has been successful. From this method, the core asset developers determine how they will design the core assets to support product building.
The choice of production method can mitigate some of the effects of change by decoupling the means of expressing concepts in the problem domain from the implementation of those concepts. A rainbow of general-purpose languages, including C++, Java, Ruby, and others, has been used successfully for their power to express abstractions. More focused frameworks, such as Grails, are particularly suitable for building the discrete assets to be assembled into products. Product line organizations have invested in domain specific languages (DSLs) because of their flexibility and expressive power and the fact that with sufficient products under one management, the cost of the language is more likely to be recouped. These DSLs target specific features of the products such as the user interface or the persistence capability.
The approaches to development and evolution of the core asset base of a software product line vary over a continuum. At one extreme, the proactive adoption approach builds a full set of reusable parts before any products are built. This is feasible when the decision to build multiple similar products is made before any of them have been built and there is a reasonable certainty of what products will constitute the product line, a specific strategic business decision. With this approach a large investment is made before any of the parts are tried out in building a product; so this approach is useful in a context where the organization has much experience in building similar products. At the other extreme, the reactive approach first builds a product and then builds reusable pieces from the pieces used to build that first product. Product builders mine the initial product for functionality that will be useful in many products and create a reusable asset for it. Reacting is appropriate when the priority of delivery of the product is higher than creation of the reuse infrastructure.
Whether the iterations begin before any products are built or after some products have been built, virtually all software product line organizations build the assets using an iterative process. Iteration reduces the risk of prematurely producing the wrong assets but begins to build a reuse infrastructure quickly without having to risk waiting to react to the results of the first product development effort. Both RUP and agile-based methods have been effective for guiding the iterative product development in a software product line. The manner in which releases of the core assets to the product building teams are handled has been as varied as in any development organization. Some choose to release continuously, some release on a regular, time-boxed schedule, and others release when significant new functionality or high-priority repairs are ready. The longevity of a software product line organization is a virtual guarantee that things will change along the way. Recently some software product line organizations have begun to switch to a compositional approach to product building as opposed to integrating components. Compositional techniques stress parallel development of features that are released asynchronously so that other component developers can build on top of them. This change is partly a reaction to a phenomenon that many successful product lines experience: growth. Once a software product line is proven successful, many product teams ask for their product to be added to the product line and more customers want the lower prices and quicker delivery possible with products of the product line.