A Framework for Software Product Line Practice, Version 5.0

Operations

This practice area is about how business gets done; it is the engine that makes the organization run. Without it, the organization is mostly just a collection of staffed units, poised and willing to do the right thing but unsure of precisely what that is. Any organization in the business of developing products operates under the aegis of its organizational and/or management strategies and policies, business processes, and work plans. Operations puts all of these items together into a coherent unified corpus of policies and practices. The vehicle for documenting these policies and practices is an operational concept [ANSI 1992a]. The operational concept

describes the processes for fielding and maintaining the products from an operational perspective
describes how the organizational units work together to execute these processes
defines the role that acquisition will play and points to defined acquisition strategies and policies
facilitates a common understanding among members of the organization as to how products are fielded and how the production capability is evolved and maintained
serves as a baseline when the organization considers alternatives in its approach as warranted by changing conditions

Aspects Peculiar to Product Lines

With product lines, this practice area spells out how the organizational structure populates and nurtures the core asset base and how it uses the core asset base to build products. In the figure which shows the product line's essential activities, operations tells how the wheels are set in motion, how the right information flows along the arrows, and how management orchestrates the entire business.

Operations breathes life into the organizational structure that was put into place to carry out product line activities. The "Structuring the Organization" practice area positions people in the right work units and assigns them broad responsibilities. However, without a clear definition of the operational concepts for building and running the product line, those people will flounder or, at best, perform inefficiently. To borrow an assembly line analogy, structuring the organization is like telling automobile workers, "Stand right here, and here, and here. When parts come along, put them together so that an automobile comes out at the end." That's not enough instruction. Operations, on the other hand, tells the workers how the pieces fit together and in what order, what to do when the right pieces aren't in place or don't fit together, how to report pieces of poor quality, how to make suggestions for improvement, how to interact with workers standing at stations near theirs, and what they are and are not allowed to do (for example, "Don't bend the pieces to make them fit together!"). Both structure and operations are necessary for the assembly line to roll out quality products.

The product line approach is not a case of "one size fits all." Operations spells out how the approach is implemented in organization-specific terms.

Operations describes how and which organizational units

produce and evolve core assets according to those assets' work plans and evolution plans
define and evolve the production plan
use the core assets and production plan to field products
continuously monitor and improve the health and profitability of the product line

Operations also describes the interconnections among those carrying out the essential activities of core asset development, product development, and management. These interconnections would include communication mechanisms, decision and conflict resolution processes, a document map, and a supporting Web site or wiki for the product line.

The best way to document the operational concept is to develop a formal product line concept of operations (CONOPS). An organization develops this document (which is, itself, a core asset) to describe its product line approach in organization-specific terms. The CONOPS documents the decisions that define the approach and the organizational structure needed to put it into operation.

The more conventional purpose of a CONOPS is to represent the user's operational view for a system under development. This view is stated in terms of how a system will operate in its intended environment. The CONOPS for a product line serves much the same purpose but for the product line organization. The CONOPS documents the organization's decisions about its product line operations–that is, how the members of the organization work together to accomplish core asset development and product development and manage and orchestrate the product line effort. All product line personnel use the CONOPS as the guide to how to carry out any product line action or communication. In particular, managers use the CONOPS to determine who is affected by a decision and who needs to be informed about specific decisions. Technical members of the organization use the CONOPS to determine who to contact for decisions.

Someone, usually the product line manager or a Product Line Steering Group, needs to own the operational concept, make sure it is well documented, effectively communicated, followed in everyday business, and improved as necessary based on measurement and feedback from individuals within the organization and customers of the product line.

Application to Core Asset Development

For core asset development, operations defines what plans, processes, strategies, policies, and constraints the core asset developers will carry out to do their jobs and how those items will be managed. Therefore, the operational concept for core asset development documents the organization's decisions regarding

the organizational elements and the role each of them plays relative to the core assets
the production strategy to be used for core assets and the production strategy to be used for products
the core asset development activities moving from scoping through requirements engineering, architecture definition, component development, using existing available software, the mining of assets, testing, and software integration
the strategy for maintaining the core asset base, which covers the process for creating new core assets, modifying existing core assets (including changing the architecture), and declaring core assets obsolete
specific guidance for supporting the shared responsibilities of core asset evolution. Such guidance guarantees that the architecture and assets will be used to produce products and that feedback will be sent about that use to those responsible for core assets. That feedback helps to continuously improve those assets.
communication mechanisms used to coordinate core asset development activities with product development, and with configuration management, measurement, and other management activities

Application to Product Development

For product development, operations defines what plans, processes, strategies, policies, and constraints the product developers will follow to do their jobs and how those items will be managed. Therefore, the operational concept for product development documents the organization's decisions regarding

the organizational elements and the role each of them plays in product development
how the organizational elements effect the production strategy and use the production plan to carry out the product development activities
the strategy for maintaining the products and coordinating that maintenance with the evolution of the core assets, including configuration management policies and processes
specific guidance for feeding the results of using core assets in product development back to those responsible for core assets in order to support the continued improvement of those assets
specific guidance for recommending new core assets or changes to existing core assets

Finally, the production strategy for products, described in "Core Asset Development," is reflected in the operational concept.

Example Practices

Creating a CONOPS: The stakeholders in the product line organization need to participate in the creation of the CONOPS in order to ensure that the operating concept is realistic and to mitigate the risks associated with failure to buy into the product line approach. Holding a workshop for the formulation, or at least the review, of the CONOPS is one way to involve stakeholders in its definition.

Managing the operations: A product line manager, or an equivalent organizational unit that performs the role of product line manager, orchestrates the product line effort. Suggested managerial practices for the product line manager include

defining and articulating the product line vision and promulgating it throughout the organization consistently and often–in fact, every day. That can be done by posting the vision in a publicly accessible location (such as an intranet Web site), crafting slide presentations to be given by organizational and technical managers, and discussing the vision at opportune times, from brown-bag lunches to management seminars.
creating and posting both personal and organizational performance objectives that embrace the product line goals and strategies
establishing promotion and reward structures that provide real benefits to individuals who follow the documented product line approach to building products, contribute to the improvement of the product line effort, and design and build core assets that are, in fact, reusable
communicating product line progress early, openly, and often
removing from the critical path (or from the organization) those individuals who are barriers to product line success because of either a lack of productivity or a consistent lack of alignment with defined product line practices
learning about technology change management, taking formal training if possible
championing the product line at higher levels of management
protecting the product line staff from unnecessary distractions (perhaps imposed by higher management or requested by overfamiliar customers) that do not further the product line effort
ensuring stable funding for true "operation" of the product line. The funds must cover not only the development and evolution of the core assets but also the entire supporting infrastructure.
integrating efforts across organizational boundaries by relying on support and assets from other parts of the organization or other organizations

Developing scenarios: Scenarios can help those developing a product line CONOPS gain an understanding of product line operations. You can create scenarios for the following tasks:

using the product line architecture and other core assets to build a product
developing product-specific assets
submitting new or modified components to the core asset base
updating the core asset base and migrating the changes into existing or in-development products
determining whether a candidate product is in or out of the product line scope
delivering product line systems to customers
supporting the implementation and maintenance of the development and execution environments for product line systems

An organization can cast these scenarios as a series of "A Day in the Life of . . ." vignettes. Because they are focused and lack extraneous information, these vignettes make product line activities come alive for individual or small groups of role players. The role players themselves could be asked to draft the vignettes, thereby testing their understanding and encouraging more enthusiasm and buy-in than scenarios developed by management would.

Practice Risks

An inadequate or inappropriate operational concept will result in the product line staff working at cross-purposes and in conflict with each other. Productivity (and morale) will drop. Also, (depending on the nature of the problem) core assets might not be used in the way they were intended, products might not be turned out as planned, and the product line might stagnate and die. An inadequate operational concept can result from the

lack of management commitment and/or leadership: Product line operations, most especially during the early stages of a product line effort, require leadership, commitment, and follow-through. Setting in place an effective product line operational concept often requires culture changes and changes in the organizational structure.
lack of the necessary ingredients: Product line operations rely on the existence of plans, processes, strategies, and decisions relative to organizational structure, lines of authority, communication, measurement, and so forth. Without these necessary ingredients, the operations will falter, the core asset and product wheels will not spin, and the information will not flow.
failure to identify a product line management role: Success of the product line requires strong visionary management. Some specifically designated manager or group of managers must maintain the vision and keep the organization aligned with that vision during the period of change. In particular, the person or entity acting as product line manager needs to oversee the development of the product line operational concept personally and obtain the buy-in of key stakeholders.
failure to update the operational concept: Operations will evolve and so must its documentation. The operational concept must not become shelfware if the organizational engine is to keep churning efficiently. The operations and its documentation should be reviewed and revised constantly as the product line is fielded, lessons are learned, and the product line evolves. If the operational concept is not maintained, newcomers will not have sufficient orientation, and new managers will have a tendency to undue what has become effective. Moreover, the product line may not evolve successfully to address the needs of new customers.