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

Structuring the Organization

This practice area is about how the organization forms groups to carry out the various responsibilities inherent in a software development effort. All organizations have a structure, even if it's only an implicit one, which defines the roles and responsibilities appropriate to the organization's primary activities. Particular organizational structures are chosen to accommodate enterprise goals and directives, the culture, the nature of business, and available talent. The organizational structure reflects the division of roles, responsibilities, and authority.

In a traditional organization (one that isn't oriented to product lines), individual product teams tend to be fully responsible for technical decisions that affect their products. Even in a matrixed organization, once engineers join a project from their specialty groups, the projects run independently. Specialization might require each product to have its own development group, with no sharing of personnel. The role of the organization's management in this case is to gather and allocate resources and provide high-level oversight–all with the end goal of supporting product teams.

Aspects Peculiar to Product Lines

A product line approach entails new roles and responsibilities related to the creation of core assets and of products from those assets. This practice area deals with placing those roles into the appropriate organizational units to most effectively support the product line approach.

In a product line context, the dual development of core assets and products dictates an organizational structure that is not product-centric. Beyond that, management must be concerned with identifying the organizational charter and boundaries, identifying functional groupings, allocating and assigning resources, monitoring organizational effectiveness, improving organizational operations, establishing interorganizational relationships, and managing organizational transitions.

Product line organizational structure goes hand in hand with product line operations (see the "Operations" practice area), because it is the embodiment of the roles, actors, and responsibilities defined there. Structuring the organization is like assembling a symphony orchestra–determining how many of each type of instrument will be in each section, selecting the musicians, and assigning people to the appropriate chair in their sections. "Operations" is the practice area that provides the music everyone will play together and guides them through performances. Both practice areas, obviously, are necessary. They result from an overall vision of how the product line will operate on a day-to-day basis. The job of organizational structure is to make sure that each responsibility and function of the product line operations has a work unit in which to reside.

An organizational structure should be chosen to assign at least the following tasks to the appropriate organizational unit or units:

Application to Core Asset Development

A first-order choice that must be made when choosing an organizational structure is where to assign the people who develop, maintain, and evolve the product line's core assets. Typically, organizations take one of two approaches: (1) they form a separate unit for the developers and maintainers of core assets or (2) they house that effort in the same unit or units that build products [Bass 1997a, Bass 1998a].

Both approaches have their advocates. On the one hand, having a dedicated core asset development group makes the core asset developers one level removed from the pressure of project deadlines, making it more likely for them to produce assets that are generic and not too biased toward the individual product that happens to be under development at the time. Their loyalty is to the product line, not to any one product. On the other hand, having product engineers produce the core assets ensures that the core assets will be truly useful for products and ensures that people who build the core assets are not too far removed from the day-to-day realities of product production. In either case, there must be someone with a cross-product perspective and authority who can identify useful assets for the core asset base and encourage (if not direct) the appropriate product group to produce each core asset for use by other products.

When choosing whether to establish a separate core asset group, consider these factors:

An evolutionary organizational structure resolves the choice essentially by having it both ways. The approach starts the product line effort without a core asset group so that the engineers can assume the full responsibility for turning out a real product under the product line paradigm. However, as soon as there are parallel developments in progress, product development is separated from core asset development. Other approaches that seek a middle ground include frequent staff rotation and processes that require close communication among the groups.

Whichever way this issue is decided, the product line core assets must be managed to bring long-term benefit to the entire organization, rather than to just one specific application. The organizational structure chosen for product line production must assign the decision-making responsibilities for these functions.

And while managing the architecture and other reusable software-related core assets is an obvious product line responsibility that must be assigned to the right organizational unit(s), the management of non-software core assets must be allocated also to achieve the full benefit of core asset reuse. For example, where, how, and by whom will core assets such as product plans, schedules, and budgets be maintained for use across the product family?

Application to Product Development

Product line systems are developed and managed according to a life cycle that differs from the norm. Building products from core assets places greater emphasis on software integration and the testing of interfaces across components. For the unit or units assigned to product development, responsibilities include the following:

The product unit(s) may also negotiate customer requirements to situate new products within the scope of the product line to the greatest degree possible, although some organizational structures assign the management of product line requirements to their own units.

The organizational structure must assign responsibility for these roles, as well as for the more traditional product development roles.

Example Practices

Organizational models from a Swedish product line survey: Jan Bosch described four separate organizational models [Bosch 2000b] after studying a number of product line corporations. He discriminated between the models based only on organizational size and did not take into account other factors. The four models he identified were

Organizational structure for a reuse business: Jacobson, Griss, and Jonsson call for organizing a reuse-based business around a set of competence units, which contain "workers with similar competencies and entity object types that these workers are responsible for" [Jacobson 1997a, Ch. 9]. They prescribe the following units:

The component support unit is responsible for "packaging and facilitating the reuse of component systems, and [is] mostly concerned with maintaining the facades and distributing the component systems so that reusers can access the desired components" [Jacobson 1997a].

Workers from these competence units are drawn to form an application family engineering team, one or more component system engineering teams, and a group of application system engineering teams. Application family engineering is where product line decisions are made such as which applications to develop and when. It also crafts the broad product line architecture. Component system engineering is responsible for the detailed architecture and design of a component system. Application system engineering builds products for individual customers.

Small, distributed core group with component representatives: In choosing whether the core asset group is separate or distributed throughout product groups, at least one company we know has opted for a hybrid approach. This company, which has about 50 employees building a product line of information systems, has a set of product groups that revolve around a small but central core group. In this model, the core group is responsible primarily for common support activities such as configuration management, maintenance of the core asset base, some process definition, and the like. An architect for the entire product line would also normally reside in this group. However, in this company, the architecture is not being evolved, and the architect has been reassigned. In each product group, a component representative has the joint responsibility of ensuring the use of core components and creating and evolving the software core assets. A strict protocol is enforced in which any candidate for inclusion in the core asset base must have at least two component representatives sponsoring it. This protocol ensures the asset's reusability across at least two products.

Structure for a distributed or globally dispersed organization: Work force distribution and globalization present additional challenges for organizing a product line effort. Some organizations are addressing these challenges in these ways:

Practice Risks

Further Reading

[Bosch 2000b]
Bosch describes four product line organizational models.

[Brownsword 1996a]
Brownsword and Clements describe stages in the evolution of CelsiusTech's organizational structure as its software product line matured and organizational needs changed.

[Jacobson 1997a]
Jacobson, Griss, and Jonsson describe an organizational structure based on the concept of competence units.

Next Section Table of Contents Previous Section

 

1 Myers, C. R.; Maher, J. H.; & Deimel, B. Managing Technological Change, Version 1.92. SEI Workshop given in 1990.