Software Product Lines
Framework Home
Introduction
Product Line Essential Activities
Product Line Practice Areas
Software Engineering
Practice Areas
Technical Management
Practice Areas
Organizational Management
Practice Areas
Building a Business Case
Customer Interface Management
Developing an Acquisition Strategy
Funding
Launching and Institutionalizing
Market Analysis
Operations
Organizational Planning
Organizational Risk Management
Structuring the Organization
Technology Forecasting
Training
Frequently Asked Questions
Glossary
Bibliography

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section

Developing an Acquisition Strategy

Acquisition is the process of obtaining products and services through contracting [Bergey 1999b]. This practice area applies to those organizations that are purchasing or commissioning, rather than developing, at least some of the products, or parts of the products, that they turn out. The growing trend towards outsourcing or "off shoring" makes this practice area much more common than ever before. If your organization has limited resources, you can use acquisition in a variety of ways, from augmenting your own development effort to commissioning the development of an entire product or group of products. Other motivations to use acquisition include being able to

If you commission an outside source to provide assets for any part of your operation, you will have to incorporate the means of managing the work performed under contract and the resultant contract deliverables. To be effective in contracting, you must develop an acquisition strategy so that you can mitigate the risks associated with acquiring technical products and services from external sources and integrating them into your operations.

Because an acquisition strategy is of great importance to those organizations that primarily acquire rather than develop, this practice area is especially important for government agencies, such as the U.S. Department of Defense (DoD). Although industry may rely heavily on acquisition for obtaining software, corporations are less likely to acquire an entire system. For the DoD, this is closer to the norm. The DoD is an acquisition-based organization.

For acquisition-based organizations, a traditional acquisition approach is to have a separate acquisition for each system and to maintain the system independently throughout its operational life. This is a case of n acquisitions for n system developments followed by n maintenance efforts that may require another multiple-of-n acquisitions (because maintenance contracts may have to be rebid several times for long-lived systems) in order to provide ongoing support for the life of the systems.

Developing an acquisition strategy involves analyzing alternative contracting approaches (some of which are offered as example practices), considering pros and cons, and performing tradeoffs. The strategy should address

For each contract, the strategy should answer the following questions:

Multiple contractors may be involved in acquisitions that incorporate competitive runoffs, multiple suppliers, or teaming arrangements.

An acquisition plan is the artifact used to document the acquisition strategy. The plan should also record the costs, risks, and considered alternatives to the adopted strategy.

Aspects Peculiar to Product Lines

A product line acquisition strategy is a plan of action for achieving a specific product line goal or result through contracting for products and services. In the case of a software product line, the types of software products acquired through contracting include core assets and derivative products built from those core assets. Potential software services include elements of core asset development, product development, and management. Acquiring services means contractually engaging an identifiable task rather than furnishing an end product.

If your make/buy/mine/commission analysis returned "commission" for any product line asset, you have made a decision to acquire that asset and therefore need an acquisition strategy. Even if you rarely acquire software, you still need an acquisition strategy for those occasions when acquisition is your chosen (or only) option.

Acquisition for product lines is typically structured much differently than acquisition for single systems. First, the acquisition of core assets is usually the result of a contracting effort apart from the acquisition of products. Second, the fundamental role of architecture in a product line imparts opportunities for contracting flexibility. An umbrella acquisition might provide the entire product line production capability–architecture, infrastructure, and core assets–or the production capability might be acquired in pieces. The architecture itself might be acquired as an independent step. The acquisition of software components or services (whose interfaces and interoperating requirements will have been specified by the architecture) might be distributed among several suppliers. Products built from the core assets might be acquired individually or under contract for an entire set. A small number of follow-on acquisitions can accommodate ongoing product development and support for sustaining and enhancing the core assets and products over the life of the product line.

Plan your acquisitions early. The contracting process is often arduous and can consume an enormous amount of time before a contract is in place and operative. Plus, an acquisition strategy cannot be developed in isolation. It exists to serve the product line goals and interacts with the results of other practice areas (named below), some of which inform us about what we wish to acquire. Accordingly, you will need to allow sufficient time to coordinate and interact with those carrying out the work of these other practice areas.

If acquisition will fulfill a major role in your product line, you should form a small acquisition team to develop and implement an acquisition strategy. Begin by drafting a charter to empower the team, define roles and responsibilities clearly, and ensure the participation of key stakeholders. The team leader should come from the product line organization. Team members should include a contract negotiator, a representative from the product line organization, representatives from participating product groups, individuals with significant acquisition experience, and key product line stakeholders who have a vested interest in the acquisition. Make sure that you

The acquisition strategy team should begin by understanding the organization's concept of how the product line will operate and the role that acquisition will fill. Therefore, the team should coordinate with those carrying out the activities in practice areas in which these issues will be decided. These practice areas include

A product line approach is a natural fit for specifying and coordinating efforts across a distributed or geographically dispersed workforce. Facets of a product line approach that support workforce distribution include

Application to Core Asset Development

Acquisition can serve several roles in obtaining all, or part, of the core asset base. They include the commissioning of one or more contractors to

Core asset acquisition may also involve the acquisition of contractor services, such as scoping, domain analysis, configuration management (CM), testing, and training. An acquisition organization can fill these core asset development needs and/or acquire these services through a single acquisition or multiple acquisitions involving one or more contracts (or contract options) that run sequentially, run concurrently, or overlap.

If an organization is going to commission the development of core asset software components, an architecture will have to be specified, because the architecture places constraints on the components or services that will be included in the core asset base. The architecture also determines which components are common across all products (or at least across subsets of the product line) and defines the necessary variations among instances of those components. Since the architecture plays such a pivotal role in product line operations and constitutes a strategic competency area, the business impact and necessity of commissioning the development of the product line architecture by an external party should be carefully considered.

Application to Product Development

Acquisition is also an effective means of obtaining new products (or parts of products) in the product line. Acquisition can play several roles, including the commissioning of one or more contractors to

Product acquisition may also involve the acquisition of contractor services, such as requirements engineering, CM, architecture evaluation, software system integration, and testing.

A commercial organization must carefully consider how to protect intellectual property rights when commissioning the development of products from its core asset base. Lack of care could result in the supplier becoming a competitor. One way to reduce this risk would be to commission the development of product-unique parts or to contract for specific product-creation services. One of the example practices below provides guidance in this area.

Example Practices

Considering core competencies and strategic directions: For commercial organizations in particular, selecting an acquisition strategy should be dependent on what core competencies the organization possesses and the strategic business impact of acquiring products and services from external sources. The criteria embodied in the following figure provide insight into the considerations that should potentially govern whether a product line operation should be included in the acquisition.

Criteria for Outsourcing a Particular Product Line Activity

Criteria for Outsourcing a Particular Product Line Activity

The considerations for these criteria are

Clemons and colleagues provide in-depth insight into the issues that inform and motivate such strategic sourcing decisions and their associated risks [Clemons 1997a]. The criteria shown in the above figure are useful for establishing what product line activities are candidates for outsourcing. The selected activities become the basis for developing a comprehensive acquisition strategy that can achieve the desired end state.

Setting the acquisition context with the SEI Adoption Factory pattern: Even if an organization relies heavily on acquisition to achieve its goals, it will still have a major role in the execution of many of the product line practices. In setting the context for the product line, the acquisition organization will have to specify what constitutes the product line and establish structures and practices that parallel those of an organization that does most of its work in-house–a key difference being the emphasis on "doing" versus "overseeing the doing."

The "Launching and Institutionalizing" practice area contains a discussion of the Adoption Factory pattern, which provides a general roadmap for product line adoption [Northrop 2004a]. This pattern is a useful guide for helping acquisition organizations determine what they should do first. The following are some of the important early tasks listed in the pattern's Establish Context phase:

Putting architecture first: One acquisition strategy, which is most applicable to government agencies that rely very heavily on acquisition, involves procuring only an architecture in the first stage, procuring other core assets in the second stage, and procuring products (built from the core asset base) in the third stage. The first stage would then focus on devising a strategy for acquiring the architecture. Listed below are four potential strategies for architecture acquisition that are distinguished by the source of the architecture.1

  1. systems architect: A contractor is hired to develop the architecture for the system, but the contractor does not build the system or components. The acquiring organization funds, owns, and controls the product line architecture. Another contractor is hired for the implementation of the architecture. This strategy helps to curtail the risk of getting an architecture that does not fulfill program needs, because the program retains control over the architectural development. However, there is still a risk in terms of whether the architecture will be implemented correctly when the system is built, as well as other risks in terms of cost and schedule adherence.

  2. standards group: An architecture that is either built by a "standards group" or conforms to established standards is acquired. Industry and/or government collaboration creates a public architecture. The acquiring organization influences but does not control or own the product line architecture.

  3. single contractor: A single contractor is commissioned to develop the architecture. The contract is put up for bids, and contractor selection is based only on the architecture portion of the system design. However, the same contractor may also end up developing components and/or the system under the contract. The contractor supplies the architecture and ownership, and control is negotiated.

  4. collaborating contractors: A contract is developed that requires a group of contractors to collaborate on developing an architecture that they all can use later. In addition, each of the contractors is given a contract to develop and maintain some of the system's components. Ownership of the architecture is usually shared among the development contractors, with the acquiring organization holding the licensing rights. The acquiring organization funds joint development and manages the architecture requirements.

Other acquisition strategies: There are several other acquisition strategies for moving toward a product line capability. They are distinguished by the initial product line capability that is desired. They include the acquisition of

The last strategy listed above, which focuses on product development, also results in the acquisition of an architecture, a set of components and their supporting artifacts, and a product built using these core assets. This strategy is an extension of the third strategy listed above, which reduces the risk of architectural and component incompatibilities. The quality of the architecture and components is demonstrated more thoroughly by building an actual system based on the core assets. Also, this strategy aligns with the natural iterative learning that takes place in establishing a product line. Proving that the core assets can be used to build a system provides valuable credibility for them.

A significant variation on this "core assets plus product" strategy is to acquire an additional system–a second product–that will reuse the core assets. This approach allows the program to reap the benefits from the investment in building the core assets.

Practice Risks

Introducing acquisition into the equation clearly provides an organization having limited resources with an effective means of pursuing a product line approach and tapping skills and resources that would otherwise be unavailable. However, acquisition also has its attendant risks by virtue of introducing a new, and sometimes arduous, paradigm for managing the products and services that are acquired through contracting. A poor acquisition strategy will result in contracts being let that are not in the best interests of the acquiring organization. In the worst case, the goods delivered do not meet the needs for which they were acquired, and the resources (not the least of which are the time and effort spent on the contract and the time spent waiting for the goods) are wasted. Deadlines will be missed as the organization scrambles to recover. A poor acquisition strategy can result from any of the following factors:

Tompkins describes 40 major risks when you take the following steps to outsource: strategy, selection, implementation, and management [Tompkins 2004a]. These risks are especially applicable to commercial organizations interested in avoiding the pitfalls and realizing the benefits of outsourcing.

Further Reading

[Bergey 1999b]
Bergey, Fisher, and Jones give a nice overview of the U.S. Department of Defense acquisition environment interpreted for software product lines.

[Bergey 2004a]
Bergey and colleagues provide a companion document to this framework for government organizations that routinely acquire rather than develop their software. This document provides augmented information for acquisition organizations on the essentials of software product lines. In addition, it serves as an interpretation of the framework from a strictly government acquisition perspective.

Next Section Table of Contents Previous Section

 

1 Fisher, M. CECOM Architecture for Practitioners Course. SEI course given in 1998.