Suppose you are a manager in a software development organization that markets a number of products in a particular application area. Each product is the purview of a similar but independently run project. Some of the developers have started to share common code, informally. While that helps a new product launch more quickly, it does nothing to help with maintenance since the copies diverge off on their own evolution paths. This is consuming an alarming amount of resources. You’ve read about organizations that use the software product line (SPL) approach to turn out new products in a matter of days or weeks, evolving them as a single family, whereas it takes your company months or years. As you start to think about what it would take to transform your company from a piecework operation to a smoothly running software factory, the complexity of the change starts to sink in. To really change the way your company produces software, you’ll have to make business, technical, organizational, procedural, financial, and personnel changes. And, practically speaking, you have just one chance to get it correct—a false start will be expensive and undermine customer confidence. “How,” you wonder, “can I get there from here?” Having a roadmap to product line adoption that lays out the necessary decisions and actions would be invaluable. Such a roadmap is presented in this article.
A SPL organization embodies a core asset development function and a product development function, all orchestrated by a management function. These three functions are mutually supportive, providing inputs and feedback to each other. Core assets—the artifacts common across the family of products—are maintained as common resources for the entire SPL and are customizable in predefined ways to fit the needs of individual products. Core assets include plans, requirements, designs, documentation, and tests, as well as code. Product creation produces feedback about the quality and usefulness of the core assets in addition to producing products. Which products are built in the product line is a management decision based on the capabilities provided by the existing core assets and the needs of the market. This decision is accompanied by the necessary managerial oversight to ensure the core assets are truly useful in developing the products and those products are built by faithfully using them.
The practices needed to successfully field a SPL are fairly well known; the SEI’s Framework for Software Product Line Practice (see www.sei.cmu.edu/productlines) describes 29 of them. These are practices familiar to any software development activity but that take on a different flavor when it comes to SPLs. For example, configuration management is a standard software development practice, but it takes on additional complexity in a SPL setting—versions of products must now be tied to versions of the core assets they use.
Knowing the practices is one thing; applying them smoothly in concert with each other is another. Product line practice patterns [3] show how practice areas can be combined and coordinated to accomplish useful outcomes, such as setting up the organization’s core asset development function. Whereas a design pattern organizes software elements, a product line practice pattern organizes the activities of an organization. One of these patterns—Adoption Factory—maps out the broad coordination among the many practices needed to initiate (that is, adopt) the SPL development strategy [7]. The Adoption Factory pattern serves as a roadmap for product line adoption.
Adoption Factory Pattern
The Adoption Factory pattern shows how to carry out the product line strategy. The solution is captured in the intuitively named set of subpatterns shown in Figure 1 and the relationships among them. The arrows in the diagram indicate both information flow and shift of emphasis among the activities.
An adopting organization progresses through three broad phases, from start-up activities in the first phase to product production in the third phase, delimited in Figure 1 by vertical dashed lines. The horizontal dashed lines delimit sections of the pattern that identify broad focus areas: the organization, its processes, and its products.
The three subpatterns along the bottom row indicate an organization’s status. The Cold Start subpattern is used when the product line has not been initiated. The In Motion subpattern builds on practices established during application of the Cold Start subpattern. The Monitor subpattern is used when the product line is operating and needs to be optimized. Figure 2 is a “practice area view” of the pattern, showing the practice areas that constitute the subpatterns within each cell.
Using the Adoption Factory as a roadmap lets the manager answer the question “What do I need to focus on next?” by charting and applying practices following the “informs” relationships among the areas. But unlike a path through, say, a state machine, any position merely indicates heightened emphasis. All the subpatterns remain in play throughout because they indicate practices that must eventually be part of the product line approach.
How a Roadmap Helps
There is still a pervading assumption that product lines involve a new technical approach only. Most product line adopters vastly underestimate the management commitment and involvement required to succeed. Organizations new to product lines typically suffer from inappropriate organizational structures and processes, lack of training, insufficient and inappropriate resources, and lack of carefully constructed plans for product line adoption. Engineering organizations tend to jump right into architecture and component development activities without defining scope or a business case. Frustration and wasted effort result.
Our work with product line adopters across multiple domains bears this out. We have seen cases of product line adoption failure where our roadmap would have provided essential guidance [4] as well as cases where organizations have demonstrably benefited from Adoption Factory [5, 6].
Adoption Factory maps out the combination of technical and business activities that need to occur. It properly orients an organization to establish its product line context before developing code and to establish real production capability before attempting to operate the product line.
To illustrate Adoption Factory as a product line adoption roadmap, we present an example, based on real experience, of a hypothetical company new to product lines.
The Roadmap in Use
Our hypothetical company, Arcade Game Maker (AGM), has been in operation for many years. It produces a set of video games that share many identical features but vary from one another in terms of the platform they run on and, obviously, the rules and elements of the games. The company’s management knows it uses existing artifacts when building a new product. However, these artifacts are almost always copied and changed to suit each new product rather than being evolved systematically and strategically to support the entire product family. Over time staggered delivery schedules, platform differences, and other problems have led to a bewildering array of artifacts. Maintenance is becoming extremely difficult, and time to market is falling behind expectations. AGM has decided to adopt the product line strategy to remedy these problems, but requires assistance in organizing and planning the many activities required for successful product lines, and decides to use Adoption Factory as its adoption roadmap.
Establishing the Context. AGM begins by applying the Cold Start subpattern, whose practice areas are listed in the Establish Context/Organization cell in Figure 2. As suggested by the “Launching and Institutionalizing” practice area, AGM forms a working group that will draft the initial adoption plan and manage the production of an initial set of products. The group uses other practices in Cold Start to help them fund and plan the work of the organization. AGM decides to fund two efforts initially: a mining project that will extract core assets from existing artifacts and reengineer them to be useful across AGM’s product portfolio and a pilot project to produce a small set of products from those core assets. Both projects are funded by the research division of AGM.
AGM managers next concentrate on the Product focus area of Adoption Factory and follow the What to Build subpattern, which includes practice areas such as “Building a Business Case” and “Scoping” to help identify what products to build. AGM uses feature modeling [1] and economic modeling [2] to select products to include in the product line. In the business case, AGM specifies business goals, including reducing the time from product idea to market by 25% and increasing the number of optional product features offered to customers by 50%. The business case predicts a positive return on investment after three products are produced, given the commonality among products as defined in the feature model.
AGM’s business case also identifies several risks. For example, there may be resistance to change. AGM’s product development projects have been encouraged to compete with each other, but the product line strategy requires them to cooperate. AGM’s review of its recent process assessment report identified process discipline issues that may also be risks in its product line adoption effort.
These risks feed into the “Organizational Risk Management” activities, again in the Cold Start subpattern. To mitigate these risks, AGM must reorient its business practices. Following the “Structuring the Organization” practice area, AGM designates a product line manager to manage the effort and defines positions for creating core assets and building products. The “Operations” practice area directs AGM to create a Concept of Operations document that specifies product line roles, responsibilities, and communication paths.
Establishing the Production Capability. Once the activities identified by the Establish Context phase of Adoption Factory are firmly under way, AGM begins the next phase to establish its production capability. Informed by the Product Parts and Assembly Line subpatterns and their associated practice areas, AGM defines processes that prescribe how products will be built; these processes culminate in a production plan that explains in detail how the core assets will be used to build products.
The Product Parts subpattern specifies activities that result in the raw materials—product parts—to produce products. These parts can be obtained in a variety of ways. AGM will use a combination of open source components, reverse engineered existing code nominated for inclusion by the mining project, and newly developed components. Product Parts include familiar activities such as requirements engineering and architecture definition; however, these activities must be generalized to accommodate all the products in the product line yet provide mechanisms for expected variations. For example, the requirements model contains use cases that cover the whole range of AGM’s products, but is structured to identify variation points through abstract use cases.
Operating the Product Line. Once it has established production capability, the Adoption Factory pattern leads AGM to the third phase, Operate the Product Line. Using the production plan and the other core assets, each individual product development project goes through a miniature version of the development process using the Product Builder subpattern. The requirements for the product are determined by resolving the choices specified in the product line requirements model. Other product line core assets, such as the software architecture, are tailored to the specific product being built using preplanned variation mechanisms.
Organizationally, AGM continues to look for ways to assess and improve its performance against its business goals as the Monitor subpattern takes over where In Motion leaves off. Then AGM will make another pass through the roadmap revising and strengthening its product line practices as it moves toward full institutionalization.
Conclusion
The SPL strategy has produced clear benefits for many adopters—reduced time to market, reduced cost, greater agility, greater quality, and higher productivity. Gaining the most from the approach requires a strategic commitment by the organization and some amount of initial investment, depending on the product line’s goals and the practices needed to satisfy them. Bringing product line practices to an organization requires planning and coordinating many business and technical activities. Our experiences with clients using the Adoption Factory pattern have shown it to be a useful tool in answering the question most often on the minds of managers who want to bring the product line approach to their organizations: “How do I get there from here?”
Join the Discussion (0)
Become a Member or Sign In to Post a Comment